Recently, I came across an interesting article: Scrum is dead: breaking down the new open development method. I usually do have big problem with such big declarative statements like 'Scrum is dead'. Actually, it's pretty easy to refute the whole rationale by bringing about one counter example!
But, to be frank, the article is good, with the author trying to put some basic principles for the profession of software development; principles that I fully agree with and promote. On the other hand, I strongly disagree with some very fundamental ideas in the article:
First, I find the author builds upon a fundamental idea that "Agile is a methodology". Well, this is incorrect. Also, the article conveys an idea that Agile and Scrum are two sides of the same coin (a misconception about Agile. May be the author doesn't mean that, but this idea is there in the article). Actually, Agile does not prescribe any methods. Rather, there are methods which are built while Agile in mind. So, what is agile? I always preach Ahmed Sidky's definition of Agile:
In this sense, there is no point of discussing whether Scrum, Kanban, or Open Development are useful methodologies or not. Because the whole idea of usefulness is very situational. What is useful in one situation is not useful in another, what makes sense for one team is totally irrelevant for another.
The other statement which I find misleading is that Open Development is an "evolution of Scrum". Well, this is also incorrect. The Open Development description as appears in the article is totally in accordance with the Agile mainstream since its inception. The stream upon which ideas like Scrum and XP was built. In such mainstream, major advances in Software development were invented, such as automated tests and Continuous Integration and Deployment; and major ideas were revived or re-established like IID (Iterative and Incremental Development) or self-organizing and cross-functional teams.
Having said all of that, I do admit that Scrum (as per the official Scrum guide) is not suitable in many cases. A better statement is that: Iterative development is not useful in many cases. Some project types cannot be led using timeboxed iterations. Usually, the reason is that the demands of the business and the development pace are much faster than a one-week timebok, which is the smallest iteration timebox. The idea is very simple: If business needs something now, and development is capable of providing this thing at this now, why wait till end of iteration, which may be 2-3 or even more than a week ahead?!
On the other hand, I recently came to a situation where I couldn't use Kanban to manage my project. The unknowns of business are so much, and the availability of the business people is limited; besides great technical risks which needs prolonged time of team collaboration and deep thinking. In this specific case, we switched from Kanban to Scrum.
Managing Flow or Managing Iterations?
Actually, what we have done is to move not from Kanban to Scrum, but from Managing Flow to Managing Iterations. Kanban and Scrum nowadays are metaphors for two more fundamental management ideas: Managing flow versus managing iterations.
So, In this project instance, I found that putting constraints on flow is stopping us rather that helping us. I found that a timebox of one or two weeks gives the team more room to act, react, and innovate. In the meanwhile, it gives us some very high level indicators about team progress.
When shall we use None?
One final thought is that even if you're doing Scrum or Kanban, it's just a starter. It just brings about a sense of discipline and cadence which enables the team to measure it's progress and improvement over time.
So, if this is only a starter, you should expect that teams will move to other practices and probably invent their own process in the near future. At this time, I would say that this team is really Agile!
But, to be frank, the article is good, with the author trying to put some basic principles for the profession of software development; principles that I fully agree with and promote. On the other hand, I strongly disagree with some very fundamental ideas in the article:
Agile is Not a Methodology
First, I find the author builds upon a fundamental idea that "Agile is a methodology". Well, this is incorrect. Also, the article conveys an idea that Agile and Scrum are two sides of the same coin (a misconception about Agile. May be the author doesn't mean that, but this idea is there in the article). Actually, Agile does not prescribe any methods. Rather, there are methods which are built while Agile in mind. So, what is agile? I always preach Ahmed Sidky's definition of Agile:
"Agile is a mindset, that is in the software world, established through 4 values, grounded by 12 principles, and manifested through many many different practices"
In this sense, there is no point of discussing whether Scrum, Kanban, or Open Development are useful methodologies or not. Because the whole idea of usefulness is very situational. What is useful in one situation is not useful in another, what makes sense for one team is totally irrelevant for another.
Is Open Development an "Evolution of Scrum"?
The other statement which I find misleading is that Open Development is an "evolution of Scrum". Well, this is also incorrect. The Open Development description as appears in the article is totally in accordance with the Agile mainstream since its inception. The stream upon which ideas like Scrum and XP was built. In such mainstream, major advances in Software development were invented, such as automated tests and Continuous Integration and Deployment; and major ideas were revived or re-established like IID (Iterative and Incremental Development) or self-organizing and cross-functional teams.
Well, when to use which? or shall we use None?
Having said all of that, I do admit that Scrum (as per the official Scrum guide) is not suitable in many cases. A better statement is that: Iterative development is not useful in many cases. Some project types cannot be led using timeboxed iterations. Usually, the reason is that the demands of the business and the development pace are much faster than a one-week timebok, which is the smallest iteration timebox. The idea is very simple: If business needs something now, and development is capable of providing this thing at this now, why wait till end of iteration, which may be 2-3 or even more than a week ahead?!
On the other hand, I recently came to a situation where I couldn't use Kanban to manage my project. The unknowns of business are so much, and the availability of the business people is limited; besides great technical risks which needs prolonged time of team collaboration and deep thinking. In this specific case, we switched from Kanban to Scrum.
Managing Flow or Managing Iterations?
Actually, what we have done is to move not from Kanban to Scrum, but from Managing Flow to Managing Iterations. Kanban and Scrum nowadays are metaphors for two more fundamental management ideas: Managing flow versus managing iterations.
So, In this project instance, I found that putting constraints on flow is stopping us rather that helping us. I found that a timebox of one or two weeks gives the team more room to act, react, and innovate. In the meanwhile, it gives us some very high level indicators about team progress.
When shall we use None?
One final thought is that even if you're doing Scrum or Kanban, it's just a starter. It just brings about a sense of discipline and cadence which enables the team to measure it's progress and improvement over time.
So, if this is only a starter, you should expect that teams will move to other practices and probably invent their own process in the near future. At this time, I would say that this team is really Agile!
