In the previous post I asked whether project managers can debug the process when something doesn’t work. But how do you debug the process?

Before you can debug the process, you need to understand the underlying ‘laws’ of the process. By laws I don’t mean physical equations that you can solve to get an accurate answer. Rather, it is understanding the factors that affect software development, so that when something happens you can understand what needs to be changed.  Without understanding the laws, you will resort to fixing the symptoms of the problem based on a partial (or incorrect) understanding.

This is much like giving ice to a patient with fever. Does the problem go away? No. It remains, or even gets worse.

The root cause needs to be addressed, but you can only do that if you understand the underlying cause.

It seems that the debate over certifications has started all over again. The Scrum Alliance is now going to start offering a Certified Scrum Developer program. It’s kind of odd, because Ron Jeffries, who had a part in developing the program says 1) Certification is essentially worthless 2) It puts butts in the seats. This is kind of scary, because at the very least you expect that program organisers should believe in their own program. Imagine paying big bucks to go to a CSD class and the first line you hear is “Students, this certification which you paid good money for is useless. But it was the only way we could get you to attend.”

Anyway, the CSD reignited the debate on certifications all over again. So are certifications useful or not? Here is my take on it.

In general, I think certifications do have value. A certification is just a qualification. It sets a minimum bar. A certificate is not a guarantee.

This is where people in the agile community are completely missing the point. For some reason, we in the agile community are treating certifications as if they should be a guarantee of quality.

For example, take this quote from James’ article:

…if your employer values certification above actual ability, it’s probably not a great place to work.

C’mon. Companies don’t hire based on certification instead of ability. Companies hire based on certification in addition to ability.

Did you graduate from college? Thats a certificate. Sure, there are good people who didn’t graduate and there are many bad ones who passed all the exams. Still, a company would rather choose the best among 25 graduates, than interview 100 random people because, hey, there might be a few good ones who didn’t graduate. The certificate is simply a first filter, not the sole condition.

Think about this:

The next time you want to get your accounts done, would you go to a Chartered Accountant, or pick a random bloke off the street?

The next time you want to visit a doctor, would you go to a registered medical practicioner, or pick a random bloke off the street?

Yes, there are poor CAs who managed to pass all the exams. Yes, there are poor doctors who managed to pass all the exams. Yes, there possibly are good accountants or doctors who didn’t graduate.

On the whole though, you are better off trying your luck with the ones who’ve got the certificate. You just have a better chance of hitting it right.

Where the Scrum Alliance gets it wrong

So, what about the CSM (and now CSD) certification then? Here is where the Scrum Alliance gets it wrong.

The problem with the CSM is that you get the certification for simply attending a two day training course. If a certification is supposed to set a minimum bar, then this bar is so staggeringly low that it makes absolutely no difference at all.

In fact, if we consider that most of the participants to the CSM are hearing about Scrum for the very first time, then the CSM is actually an anti-certification. In an weird way, if you see a person with a CSM, it probably means that they only have a couple of days of theoretical knowledge of Scrum, and have never applied it in real life. The majority of people who have done Scrum for any length of time are not CSMs.

Instead of certifying people who are experts in Scrum, the Scrum Alliance has gone and certified only the rank newcomers to Scrum. You may actually have a better chance of getting a good hire by ignoring the CSM pool altogether!

The goal of a certification is to certify that a person already has the required competence. Not to take in new people and teach them – thats training, not certification. Training should be provided by anyone, certification by the certifying body.

Doing certification right

The reason why we trust accountants and doctors is simply because the certification sets a reasonable minimum bar. Not everyone can attend a 2 day course and become certified in tax law or medicine.

Similarly, any agile certification should actually certify something! The challenge here is that practices are evolving at a very rapid rate. How do we decide what to certify?

Having established what are the important knowledge areas and competencies that are important, the next challenge is to figure out how to evaluate it. Tests? Hands on? Both?

Finally, how do we keep it consistent? A certification is worthless if it is not consistent.

Also, separate out the training from the certifications. Let people get trained anywhere (or by self study). They can then come over and take a test to get certified.

The Lean SSC certification

It looks like the Lean Software & Systems Consortium is thinking about doing a certification program. A few thoughts on that

• It is a good idea, if done right (see points above)
• Doing it right will be hard, but its worth taking a shot at it, if only to see what comes out of it
• Hopefully it won’t go the way of the Scrum Alliance by offering training courses disguised as certifications
• It should focus on certifying the experts rather than using it as a marketing program to spread awareness. CSM has contributed to increasing awareness of Scrum, but it has come back to bite it now that there are too many certified people who don’t have the quality. A certification that doesn’t establish a minimum bar is worthless.
• I wonder if it is too early? The right time for a certification program is post-mainstream when companies are complaining that they are unable to get the right people for lean/kanban.

So what are your thoughts on certifications? Worthless? Useful? Impossible to do right?

I recently gave a talk on 5 pitfalls in agile development. One of the points in the talk was about how traditional methods focused on managing projects by cost and schedule, whereas agile methods looked at other ways of measuring progress. For example, working software is held as a primary measure of progress. So is delivering business value.

One of the interesting ways of measuring progress is through learning. At the start of the project we are faced with a number of unknowns. How much progress have we made towards resolving these unknowns? Thats one way to look at progress of a project.

So what does all this have to do with scope creep?

Scope creep is bad right? We all know that. It’s the first thing we’re taught. If you want to stay on time and on budget, then don’t let the scope expand. Common sense!

Except it might not always be.

Scope creep originally meant small, low priority items, that popped up here and there which would cause the scope to increase almost without anyone noticing (hence the term creep). These days it is applied to anything that causes the requirements to be changed.

Now if we look at a project from a learning perpective, one of the things to learn is to identify the actual problem and the right solution. And we learn this by putting out small releases and iterating on it. Thus everytime we get feedback, we are increasing the learning and progressing towards getting the right solution.

Each bit of feedback also causes scope creep as new requirements get added based on the new learning.

From a learning perspective, this kind of scope creep is actually good. It means we are incorporating the new knowledge, and making progress towards delivering the right software. But from a traditional cost & schedule perspective, it is bad. It makes a mess of the estimated cost and schedule.

This is one area where there is potential to trip up. Many companies are still fundamentally measuring projects in terms of cost and schedule and for them scope creep is really bad. This leads to a dysfunctional situation where an agile process is used, but feedback is not incorporated because it messes with the schedule. The end result is that you may end up delivering something, but the value delivered may not be all that much.

ComputerWorld UK has an excellent article that quotes Alistair Cockburn and Kent Beck about agile projects that go bad. The most common cause of failing agile projects is when teams apply agile practices without understanding the principles behind them, leading to dysfunctional application of agile. This has been documented many times. However, it is also possible to reach a dysfunctional state when you apply the practices too much to an extreme, ignoring everything else. This is an interesting case – a team that is too religious about the practices, that again causes the project to fail.

I was long ago involved in a project where I decided to adopt unit testing. This was sometime in 2003 or so. I got so fixed up on it that we stopped delivering value to the customer. This is a perfect example of what can happen when you focus too much on the practise that you ignore the bigger picture. But the reverse is also true: Stop writing unit tests and you may deliver value for a while, but you will incur a huge amount of technical debt.

An experienced agile team can see both these extremes and choose a path that is best suited for them. Teams new to agile will usually end up on one of these extremes, probably even oscillating between both for a while before they correct the course to a level that works for them.

In the article, Alistair and Kent mention the following dysfunctions:

• Checklist processes: When you have a checklist in front of you and you do practices without understanding them only because the checklist tells you that it needs to be done. Example: Checklist says we need to do a standup – so we do a status meeting that takes 1 hour, everyone reporting to the ScrumMaster
• Missing out the big picture: Asking the customer only for requirements for the next iteration and missing out the big picture in the process. This happens whe you become so focussed on gathering and completing individual stories that we lose out on why we are developing them or whether these are the right stories to be done in the bigger context of the system. Jeff Patton has a fantastic explanation of this dysfunction along with a possible solution in his article “The new user story backlog is a map.”
• Sudden increase in scope: Quoting Cockburn – The ‘Agile’ team might say, “This looks like 170 story points,” but they don’t have any basis for that estimate. It turns out to be 700 story points, “But they only discover that as they go along, much to the depression of everyone involved”
• Not knowing when a practise doesn’t make sense: A variation on the checklist process is when a practice doesn’t make sense for the situation at hand, but it gets done because the book/coach/checklist said so.
• Not engaging the sponsors and customers: With a weak product owner, the programmers may end up deciding the backlog. At the other extreme, the programmers never make a decision, pushing all decisions back to the product owner.
• Sometimes agile is not the right process: For certain situations, another process may make more sense, but the management adopts agile because its the latest buzz word.

Finally, the biggie (especially with hardcore agile teams): Agile as a religion. Quoting Cockburn again:

Sometimes Agile principles are grossly misinterpreted, according to Cockburn. “I get called in by a CIO, CTO, any CXO, and they’re suffering because their programmers are telling them ‘You don’t know anything about Agile. Agile means we don’t have to give you a plan, Agile means we don’t need an architecture’-a whole bunch of rubbish that isn’t in the Agile manifesto.”

So Cockburn, or people like him, have to come in and tell the CIO that it’s okay to ask for a plan and an architecture. “But it takes me to come and do it,” Cockburn says. “If anyone else says it, they get told that they’re just an old fuddy-duddy, [and that] they don’t know anything about Agile.”

All in all, this is a fantastic article. I highly recommend everyone to read it, especially those who have been doing agile for a while. It provides a balancing view to a lot of the agile stories on the web. Read the whole article here.

The Ministry of Micro, Small and Medium Enterprises (Govt. of India) (MSME) is organising a 1 day seminar series on “Cutting Costs with Agile Software Development Methods” on Friday, 20th of March.

Topics that will be covered:

• Business Case for Agile Software Development
• Introduction to Scrum
• Adapting to changing requirements
• Benefits of self organising teams
• Releasing quality software
• Agile metrics

Plus an open discussion where you can bring up the topics you’re most interested in.

Click the image above for all the details regarding content and registration.

One of the best posts I have seen in a while. Cory Fox on what matters more, people or process:

It’s a good question. I saw good code at places with crappy practices. And I saw crappy code at places with good practices.

But in almost all of the places, I saw code that was on par with the motivation of the teams in place. In other words, teams that were excited about what they were doing, and kept up with trends, etc, often had code they were proud of. Teams that liked their job, but basically were just there had code that worked and had issues, but they didn’t mind. And teams that were just in a crappy place had code that was crappy.

In the previous post I wrote that Sanjiv Augustine was giving a talk in Chennai. After the talk we had a discussion about implementing Agile in maintenance projects. This is one of those topics that is not discussed very often, but it’s a topic that crops up very often in an Indian context where many teams are working on offshore maintenance projects.

There are two types of maintenance projects that are commonly encountered. One is when you have a bunch of feature enhancements to an existing project. The second is when you get bug reports from the field that are fixed as they arrive.

The first type is quite straightforward to handle — just prioritize your feature request list and handle like a normal agile project.

The second type is a lot more tricky because you are fixing bugs as they arrive. This means that there is no backlog as such. Rather, bugs are worked on as they arrive in a first-come first-served manner. Sometimes you might have a few bug reports come in simultaneously in which case some basic prioritisation is done, but on the whole it is mostly first-come first-served. What is more, there is no specific “release,” but bugs are fixed and then immediately pushed into production.

It is this second type of project that I want to discuss in this post, because my experience has been that iterations are really ill-suited for this sort of development. The problem with iterations is that you need a definite start date and end date, but it doesn’t make sense to wait and collect bug reports, then plan it out and release them all at once at the end of the iteration. It would be much better if you could work on bug reports as they come in, using some sort of queue.

Naturally, the first thing that comes to mind is David Anderson’s Kanban based method which is based on queues and flow rather than iterations. This seems to be ideally suited to the variable input rate that occurs in bug fixing. One caution is that applying this method requires a good understanding of lean and a mature team and is definitely on the “Ri” end of the “Shu-Ha-Ri” scale. If you are interested, Sajiv has links to a talk that David gave at Yahoo! a few months ago.

Another option that Sanjiv mentioned was doing extremely short iterations. By extremely short, I don’t mean 1 week iterations, but more like 1 day iterations(!). The basic idea is that each day you look at the bug reports available, select some to implement that day, then code, test, integrate within the same day. Repeat every day. Some teams do 2 day iterations instead of 1 day iterations, but the idea is the same – plan, implement and integrate over a very short time frame. This may be easier to implement for those who are familiar with Scrum because the basic principles still apply, though over a very, very short time frame. Given the huge popularity of Certified Scrum Master courses and the subsequent familiarity with Scrum, it might be easier for a new ScrumMaster to go this route.

Another challenge with maintenance projects is that you are often not dealing with your own code. You might be working with some messy legacy code with bad design, no unit tests and so on. What do you do then? All I can say at the moment is to check out Michael Feather’s excellent book, “Working Effectively With Legacy Code“. It’s a must read book for anyone doing agile, maintenance or otherwise.

Corey Ladas: There are no a priori best practices. There are only the practices you are using now. And practices that are better than the ones you are using now.

I recently gave a presentation on an Introduction to Agile Methodologies. Unfortunately, I only have the presentation, and not the audio narration that goes with the presentation. Therefore a few of the slides might not make sense taken out of context from the narration. Here is the presentation:

| View | Upload your own

Mike Griffiths has a fantastic three part blog series on how to adopt agile methods in an organization. As can be expected, there is a lot of emphasis on managing change in the organisation (the number one stumbling block in my experience)

• Part 1: Why, Who, What, When, Where
• Part 2: Why change is difficult, why people naturally resist change, and when people do accept changes
• Part 3: A change framework to effectively implement agile methods

Through the three parts, he points out 16 mistakes that are often made while implementing a change program for agile adoption. These include mistakes like Mistake #8: Underestimating the resistance to change, Mistake #9: Think people will want to adopt agile because it is better and Mistake #14: Not explaining that things will feel uncomfortable to begin with.

If you are leading the change effort for agile adoption in your organisation, then you owe it to yourself to check out the posts.