Apr 8, 2009 / Agile Certification? C'mon Folks!

6 comments

I wrote previously about agile certification. I don't like the idea. However, some new arguments arose recently.

For example. Peter Stevens wrote: "In a time when every office worker gets told 'A Microsoft Office certification is good for your career,' it is clear that certification is part of the game".

It is not the case for companies applied agile software development. For example, at TargetProcess we do not pay almost any attention to official certificates. They all sucks. I personally interviewed many people having several Microsoft Certificates, but many of them were bad developers. They were coders, and that is something we are fighting against. It appeared that certification has nothing in common with developers skills. We hired several people with no certificates at all, and we hired several with certificates. There is no any relations between good developer and certificates they have.

Agile implementation changes company culture. Without this shift agile adoption will fail in the long term.

I do believe that there are many Certified Scrum Masters that did not get the Scrum process right. People are different. Someone may attend the course and work hard to improve his knowledge. Someone may attend the course and take SCM title with honor, thinking that he knows everything to implement Scrum in his company.

On my opinion that is one of the reasons why Scrum adoption fails in companies.

How To Certify Meta Process?

Software development process is a complex thing, that should be adopted to each company, environment, etc. Some best practices may not work in some conditions. It means we can't include practices into certification test at all. What we can include is things that shape the process, things that focus on development process improvements, like retrospective meetings, communication empowerment, self-organization, emergency. But can you imagine how the questions sound like?

• Have you something in place that enables process evaluation and improvements?
• Do you have practices that power communication?
• Do you have practices that enable self-organization?

Guess what answers can we get on such general questions: "Yes, our top managers meets every year and discuss development process improvements", "Yes, we have Outlook, it is great for communication!", "Yes, team located in one room, so it is easy to shout out and assign particular task". The result is obvious though.

What Type of Agile Certification May Work?

Agile certification may be developed in the future, but for the very strict set of conditions. For example, there may be quite good set of questions for the team under the following conditions:

• Team size: 4-6
• Project type: Typical web site
• Project complexity: Average
• Distributed Team: No
• Region: Europe
• Technology: Ruby

If someone creates questions based on the criteria above, that may work. All other attempts to certify teams using General tests will miserably fail in the long term.

Labels: agile, process

posted by Michael Dubakov @ 3:08 AM

Mar 9, 2009 / Agile Bug Management Anti-Patterns

10 comments

Agile development books often skip bug management practice. However, there are several dangerous misunderstandings (anti-patterns) that are quite common. It is better to recognize the problem early and fight to win. Here are three common bug management anti-patterns in a development process.

Bug fixing phase inside iteration

Symptom: You have several days at the end of  iteration fully dedicated to  bug fixing.

If you have a bug fixing phase inside an iteration, you have mini-waterfall in each iteration, which is not a very good idea (in agile we blame waterfall for good reason, don’t we?). Story should be tested as soon as it is completed.

Bug fixing iteration

Symptom: You run several iterations with almost no or little bug fixing and then one (or even two!) iterations fully dedicated to bug fixing.

Bug fixing iterations kill your iterative development. It is even worse than mini-waterfall. Such iterations increase your work in progress dramatically. You have nothing done during several iterations before bug fixing iteration. You have nothing to ship. Moreover, bug fixing iterations reduce motivation, people don't like to fix bugs for 2 weeks or for the whole month.

No “Zero open bugs” rule in user story’s Definition of Done

Symptom: You have open bugs in a completed iteration.

You may have decided that some bugs discovered during story development are unimportant and can be postponed to  future releases/iterations. This is a very dangerous practice that leads to bugs accumulation. Moreover, it may be a reason for Bug fixing iteration (see above). The best strategy is to have “Zero open bugs” rule in Definition of Done for user story.

Labels: agile, bug management, process, qa

posted by Michael Dubakov @ 3:29 PM