Introducing Process to a Development Group - Part 2
Thanks to John for his comment that asks a couple of questions I should have addressed in my Methodology and Madness - Introducing Process to a Development Group article. John’s questions are:
- How do you decide which to solve first?
- How long do you leave between introducing each solution?
How Do You Decide Which to Solve First?
I think the best way is simply to solve the problem that looks like it will be simplest to solve: identify it and introduce a way of working, that is a practice, that solves it. Note that the practice may or may not be supported by a tool. When this is done, look around for the second simplest, and proceed like that. This assumes there is nothing that obviously needs immediate attention. For example, if there is a problem that is causing late delivery, or causing the software to be delivered in a substandard state, then that problem must be solved as a matter of urgency!
How long do you leave between introducing each solution?
I think the best approach here is to introduce a practice/tool, then wait until it has settled in and become part of the development group’s way of working. That is, when people start following that practice without having to make a concerted effort to do so. Then it is time to think about what to do next.
Finally
As more practices (and tools) get introduced into a development group, these practices will soon start to show an improvement that is more than just the improvement any individual practice offers. Soon the development group will find itself following a development process. An important thing to realise is that the process does not need to be optimal from the onset. The first objective is to get out of the mud and into some sort of sensible way of working. Once this is achieved, the group is in a position from which it can improve its process.
Alan:
Deciding what to do first (and when) should be a group exercise. Only if people understand the motivation for a change, and reasons for the specific approach will they give it a chance to work.
So, the “what to do” should come from something like a retrospective, not be handed down by a consultant/manager.
January 15, 2009, 2:17 pmJohn:
I don’t agree with you there Alan. Sure, in some cases that approach will be best, however in others it will not. Each situation and team is different and may require a differing approach - there is no one size fits all solution.
January 16, 2009, 7:16 amMarkR:
Alan seems to be saying I’ve suggested “what to do” should be handed down by a consultant/manager. I don’t see where I have made such a suggestion?
Having said that I agree with John that the approach taken will depend on the team. In particular, it will depend on the experience the team members have. If certain team members do not have the relevant experience to contribute to what practices are implemented and when, then I see no problem with those who do - manager or otherwise - taking the initiative. What I do think is important is to get buy-in from those who will have to practice the practices. In my previous article, Methodology and Madness - Introducing Process to a Development Group, I described how we got programmers inexperienced in C++ to pair program with a C++ mentor. We introduced this practice by suggesting they try it and see if they felt it was beneficial.
January 16, 2009, 9:07 amAlan:
Mark, I wasn’t arguing with you, I was higlighting an issue you haven’t addressed - that the people whose behaviour needs to change have to be made aware of the problem it is causing.
There are various ways to approach this, and I agree the one I mentioned isn’t the only one, but point remains: however good the solution it won’t work if someone simply introduces new working practices as “the answer” and expects change to happen. Trying to impose a solution creates stress, and stress causes people to seek the comfort of established habits.
January 19, 2009, 12:06 pm