Posts Tagged ‘Agile Methods’

Some of the problems I see in Agile Methods – Part 3

Friday, December 11th, 2009

A few days ago I was talking to a colleague and he told me “I’ve convinced my boss to start using Scrum”. “Great!”, I replied. But then he started to describe his situation and the problems he is having. And the main problem was that they still didn’t have a product backlog. And his question was “What do I do before I’m ready to do my first sprint?”.  This is not exactly the issue I would like to discuss, but it reminded me of another problem I see in agile methods, and it’s the idea that “all sprints are equal”.

Let’s analyze some differences between two iterative and incremental processes: Scrum and UP (or RUP). One significant difference is that UP has the notion of Iteration Phase, or Iteration Type. This means that not all iterations are equal. And this makes a lot of sense to me. Not all iterations are equal because when you start a software project there are many unknowns and things you have to analyze and think about. And when you are about to deploy a system to a production environment or release it to customers there are many other things you need to do that are different from what you do during construction. This doesn’t happen all the time, but it happens often. And then you start seeing agile teams that do “Stabilization Sprints”, or “Release Sprints”. I’m sure those are forbidden words for many agilists, but at least I was relieved to read a post by Mike Cohn about release sprints where he describes a Bank that manages a 13 million LOC core system that needs them. Believe me, they are not alone.

I think Agile methods should put more focus in these issues, which are very relevant in many projects. And give practical and specific advice on how to do all this while being agile. In other words, I don’t think minimizing the potential differences in sprints is a good idea.

So, in this case, the problem I see in Agile methods is not related to what they say, it’s to what they don’t say.

Some of the problems I see in Agile Methods – Part 2

Sunday, November 22nd, 2009

Another problem I see in some Agile Methods is a lack of flexibility about the rules they propose. I see that as some kind of contradiction: for example, Scrum is empirical only for things that it does not define beforehand.

“Don’t change Scrum” is something that Ken Schwaber wrote in his book Scrum and the Enterprise. Here’s his rationale for this: Scrum isn’t a process that you can modify to fit your enterprise. Instead, it exposes every dysfunction in your enterprise while you build products… Whenever people change Scrum, it’s because they’ve run into a problem, dysfunction, or conflict that they do not want to face and fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to the enterprise. If you allow this to happen, you will have lost Scrum’s primary benefit”.

(more…)

Some of the problems I see in Agile Methods – Part 1

Tuesday, November 10th, 2009

First of all, I admit I do not consider myself an expert in Agile Methods. Yes… I’m a Certified Scrum Master and I’ve been involved in several agile projects. But let’s say I don’t know enough and have enough experience to consider myself an expert. Even with this, I will dare say which are the issues that I don’t see addressed correctly in these methods, or at least in the typical “Scrum + XP” combination that used in most cases in Industry. The risk here is that someone will quickly reply with a link to explain how these issues can be solved. Oh well… I’ll take that risk.

I also want to say in advance that in general I have a positive view on Agile methods. I think they are an interesting packaging of useful practices and that they have made a huge contribution to development practice in general. I also value some new practices like TDD and Continuous Integration that have provided smart answers to increasing challenges of software development.

(more…)

Co-evolution – Brooks did it again

Wednesday, October 21st, 2009

In a previous post I commented about Fred Brooks’ great conference when he received the Turing Award. He named it “The Design of Design”. In that conference he spends a lot of time discussing life cycle models and explaining why the Waterfall model is wrong (“dead wrong” as he calls it). And he also presented what he thought was a better model: the co-evolutionary model, attributing it to Maher and Cross. In this model, from a Problem P1 you get a Solution S1. And from P1 and S1 you get a new problem, P2. And from P2 and S1 you get a new Solution, S2. This simple concept explains that the problem and the solution evolve in parallel. And it’s one of the good things that Agile Methods have adopted. If you use agile methods, your lifecycle model is not only iterative and incremental. It’s also co-evolutionary. Let me explain this better.

(more…)

Why do we keep searching for unifying theories for software development?

Monday, June 29th, 2009

I want to come back to the discussion about Agile vs. CMMI. After a presentation about the subject in UTN (National Technological University) in Córdoba a couple of weeks ago, I started thinking a bit differently on the subject. I thought that instead of asking the question “Are CMMI and Agile Methods compatible” the important question is “Should CMMI and Agile Methods be compatible?”

In other words, if they are not compatible, so what? Isn’t software development an incredibly wide field so as to need different approaches to different problems? Didn’t for example Management benefit during its evolution from new theories that presented different points of view about how organizations should be managed? CMMI and Agile methods present many incompatibilities (at the CMMI practice level and not at the goal level), and one of the reasons is that they follow different management theories.

(more…)