Silver Stripe Blog

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.

Continue reading ‘Is scope creep bad?’ »

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.