6

We currently drive changes to our process through the following mechanisms:

  • Weekly wrap-up meeting
  • Project postmortem

We discuss what isn't working, what is working, etc. I use these settings to introduce new practices, and eliminate ones that aren't working. We usually only make 1 change at a time and try it for 2 weeks to a month.

To validate our change we look at:

  • our velocity and std. deviation (work accomplished week over week)
  • dialectic
  • our opinion/perception of the practices effect and effectiveness

Those practices which seem to work for us we keep. Everything else is removed. This has worked pretty well for us, but I'm always interested in better ways to do this.

How often/When do you review you development process?

How do you validate the changes in your process are effective?

Improve this question
2
  • 1
    You are doing it right. It is also known as Retrospectives. There is a wonderful book on the subject.
    – user2567
    May 24, 2011 at 17:48
  • It's a great book. It's called Agile Retrospectives
    – Rein Henrichs
    May 25, 2011 at 3:35

3 Answers 3

Reset to default
3

How often/When do you review you development process?

All the time.

How do you validate the changes in your process are effective?

By monitoring and evaluating everything all the time.

This may sound unbelievable, but where I work we do not stop reviewing. Apart from the formal release post-mortem with regard to planned and realised issues (and why some were postponed or brought forward), and the usual HRM "performance reviews" we do not have a formal schedule for evaluations.

We evaluate and learn. All the time. No schedule. Whenever we encounter something that we would rather not have happen again, we try to work out a way to prevent it happening again. Whenever something goes especially well, we try to figure out what it is that is making it go better than other times so we can replicate that in the future.

It is informal and very ad hoc, but very to the point and very effective as well. For one because any disection of a situation is immediate, which means everything is still fresh for all involved. For another because if you weren't involved in the situation and/or are not part of figuring out the solution, you do not have to waste time in scheduled meetings to which you may have nothing to contribute.

Personally, I like this continual (continuous?) attention to how we can improve our product, our processes and ourselves. You can't do this in any ol' team though. It requires:

  • A very clear idea of the priorities in all aspects of the product and its development.
  • A team of very open minded people.
  • An absence of ego's/ego-tripping. Nobody is perfect and prima donna's just get in everybody's way.
  • No code ownership by individuals. No one is the sole master of a piece of code, everybody can work on anything. Though expertise is taken into account, knowledge transfer is equally important.
  • An atmosphere where it is recognized that errors happen and everybody can make a mistake or misjudge the impact/required time for an issue. This does not mean we like errors or mistakes. We certainly don't like to see the same error by the same person more than once.
Improve this answer
3
  • +1 We also do alot of ad-hoc evaluation. However, I like explicitly review the previous week/cycle as it changes your view to the macro rather than the micro (where it's usually at).
    – snakehiss
    May 24, 2011 at 20:52
  • @dietbuddha: I guess we switch continually between macro and micro. The interaction between development (developers/testers) and non-developers (support, speccers, consultants) is quite direct. One of our developers is 50% developer and coordinates the support team in the other 50%... These dual roles certainly help to keep a broad perspective. Of course our overall manager has weekly progress meetings with the coordinators of our development, qa, and support teams. Though they are focused on progress of a release's development, I am sure that processes and performance come up when needed.
    – Marjan Venema
    May 25, 2011 at 6:03
  • @Martin: Yes, almost, we have got plenty of challenges left :-) However, I do indeed count myself very very lucky to be working where I am. It took me long enough to find them: approximately 21 years in software development to find the company that is an almost exact match to what I find important in a job/employer/team... :-) (btw it is not the company listed in my profile, that's my to-the-side business).
    – Marjan Venema
    May 25, 2011 at 12:13
0

I like your answer, but here's another, for the sake of variety:

  • review 2 weeks and/or 3 cycles after start of process or practice - when your team has just enough time to have ironed the "we did this totally wrong" type problems and is just starting to get a handle on it. "Start" can be a new phase (like waterfall phases), or the instantiation of something new that should transcend phases - like a new continuous build system

  • review at critical mass - when you have a "statistically significant" amount of data to look at. I had to put it in quotes, cause I don't really do statistical analysis here. But 3 iterations is too small. I mean somewhere between 10-20 repetitions of something where you may have enough data to see some outliers or an average trend. This can be really machine-relevant stuff like the time it takes to do a build, or it can be subjective stuff like the accuracy of individual estimates or the estimated time it took to fix a class of bugs.

  • review at completion - if the practice will be stopped take a look and see if it was bad or good, could have been better or had any great side effects that you didn't anticipate.

  • review at staff change - whether you're growing or shrinking, staff changes are a good time to touch base and review. If it's a new person joining the team, maybe they have some great tricks you don't. If it's a team member leaving, capture that last knowledge. This may not necessarily be a team sport - it may be a manager/changing staff thing - particularly if you think it's cherished process that is up for serious critique.

  • review because the game changed - either the product or the environment in which you build it changed - time to assess and see if you need to do anything differently.

Can't say I do all those things all the time. Too much navel gazing will drive you nutty. But these are all decent touchstones to be used with consideration.

Improve this answer
0

I am gonna play the devil here, because I strongly believe in changing for good rather than changing for the sake of it. I also believe every team slowly moves towards an equilibrium - it can hang there for eternity.

Have you measured the cost/benefits of changing processes constantly? I know of a bunch of teams who have been working on an incremental development model with regular meet ups for years and its perfect for them. Yeah new team members join in, old ones leave - but the process has stuck and worked wonders.

Another question I have is how do you scale this / adapt this for a busy team with tight dates? I can see this may be working in a small team with manageable deliverables - but have you tried this out at a larger team / company level?

Improve this answer
8
  • You're attacking a strawman here. No on is suggesting "changing for the sake of it" or "changing processes constantly". We're talking about incremental, measured improvements to process of exactly the same kind you already find useful in software.
    – Rein Henrichs
    May 25, 2011 at 3:40
  • No attacks. Just want to understand how these improvements work cost/benefit wise. It is one thing to change stuff like interview patterns that happens about 10% of your time - but totally different trying to get me to follow different processes every two weeks.
    – Subu Sankara Subramanian
    May 25, 2011 at 3:42
  • When I say "you're attacking a straw man", I am referring to the logical fallacy. Once again, no one is suggesting "trying to get [you] to follow different processes every two weeks". That's the straw man to which I'm referring. It is a flaw in your argument.
    – Rein Henrichs
    May 25, 2011 at 3:44
  • Valid point - Still I would like to know if there are costs associated with evaluating/changing processes frequently.
    – Subu Sankara Subramanian
    May 25, 2011 at 3:53
  • 1
    @Subu I can say that my teams tend over time towards more frequent and higher value deliveries, lower defect rates, and higher team morale and confidence. I can also say that as a less experienced team lead who didn't perform proper retrospectives, these changes were less pronounced. Of course, that could also be due to other improvements in my team leadership. It's hard to isolate and quantify these changes in a complex system but anecdotal evidence (mine and others) is overwhelmingly in favor of the efficacy of retrospectives.
    – Rein Henrichs
    May 25, 2011 at 4:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.