Debugging the software development process, Part 2

Posted on July 13th, 2010 in Agile, Lean, Methodology by siddharta || 3 Comments

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.

Are certifications really worthless?

Posted on April 6th, 2010 in Agile, Kanban, Lean, Methodology by siddharta || 5 Comments

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.

Continue reading ‘Are certifications really worthless?’ »

When Agile Projects Go Bad

Posted on March 30th, 2009 in Agile, Methodology by siddharta || 1 Comment

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.

“Cutting Costs With Agile Software Development Methods” Seminar In Chennai

Posted on March 13th, 2009 in Agile, conference, Methodology by siddharta || 21 Comments

Chennai MSME Workshop

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.

What matters more, people or process?

Posted on April 20th, 2008 in Management, Methodology, organisation by siddharta || 1 Comment

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.

« Previous Entries