An humble infographic on methodologies
An humble infographic on methodologies
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
A long time ago, I wondered what all the fuss about eXtreme Programming, and Scrum, and Kanban, was about. Agile became an overloaded word.
So I settled for a long journey of learning, and experimentation. I compared different instances of the Methodology class, and I hope these pictures will help you in understanding what the differences are between them.
These are the objects of my comparison:
- Rational Unified Process, which is an iterative process, not Agile, and serves as a term of comparison. I would dare say that it is the modern day equivalent of waterfall.
- Scrum, maybe the first methodology that comes to mind when thinking about Agile.
- Extreme Programming, also known simply as XP, invented by Kent Beck.
- Kanban and Lean, which weren't originally a software development methodology, but a translation of Lean manufacturing on programmers teams. I have tried Kanban but not a full implementation of Lean, so I will only talk about Kanban.
Since I have experiences with these methodologies from the programmer's side but not from the teacher's side, I asked clarifications about some points on Twitter and I started a conversation with an Italian Agile coach, Jacopo Romei. You'll see some quotes from him in the critical sections of this article.
First we can compare methodologies by how prescriptive they are: how many practices they suggest? What is explictly left to the team's choice? Note that suggest is the right verb; you are not forced to adopt all of them, and this is the main differences between Agile and other methodologies:
None of them does *prescribe* any practice. Strongly suggesting still is suggesting. -- Jacopo Romei
Even RUP suggests picking only a subset of practices.
Note that these numbers are not marks: it's only a thumb measure of how a methodology works. A 10 is not better than a 2: it's only a different approach.
- The Rational Unified Process gets a 10 out of 10, since it is by far the most prescriptive process of all. RUP is incremental and iterative, but is something very far from the meaning of these words in the Agile movement. In RUP, to change a JSP file you have to go updating up to 6 diagrams first. Basically, it's not about accepting change, but about maintaining formal documentation and processes even as change is incorporated in the application.
- Scrum gets a 6: here there are no documentation and "drawing" practices which are coerced on the developers, but there is a set of different tools: timeboxed iterations, and for example a set of hardcoded roles for the people implementing it (ScrumMaster, Product Owner). After years of discussion over the meaning of the Agile keyword, it's now clear that if you're not using at least these tools, you're not using Scrum.
- Extreme Programming gets a 7 as well. However, XP contains most of the managerial practices of Scrum, like timeboxed iterations. At the same time it focuses mostly on the code aspects, as code is the most important deliverable. You're not formally forced to test-drive in Scrum, although it may become necessary to sustain iterations.
- Kanban gets a 2, and it did not even originate as an Agile methodology. Kanban is the porting of a subset of Toyota's Production System in the realm of software development, and it just prescribes the use of Work In Progress limits (for example on how many user stories you can juggle at the same time) and of some metrics like lead time. It does not tell you how to code, nor how to work as long as you work together improving the metrics and try to shrink the WIP limits.
More prescriptive methodologies have less space for process errors, but also for creativity and adjustment to the current team. A big methodology book would never fix a broken team, no matter how much prescriptions it contained. Most successful Agile adoptions are not guided by an immersion into the textbook, but by a sort of guerilla when practices are tried and battle tested one at the time.
Let's see another dimension we can measure these methodologies with: the scale at which we can apply them.
- RUP is endorsed by IBM, which bought Rational Software in 2003. That makes you think, and you're right, that it is used in large organizations with needs for IT documentation and hardcore processes to follow; I guess that's why it is taught in our universities.
- Scrum prescribes small cross-functional teams, usually containing 7 +- 2 people. Scrum assumes you have a team, and it assumes it is of this size: some practices like the Daily Standup Meeting are explicitly tailored to this scenario.
- XP is also useful for small teams, but you can use it alone, as a freelancer. The richness in coding practices make it valuable even when you throw away the management side.
- Kanban does not assume very much on the size of the team (an advantage of being less prescriptive). You can run a factory with it (with multiple Kanbans actually), or build a personal Kanban.
Note that the size presented here it's the team's one, not the size of the organization: although Agile in the large is quite a discussion subject, nothing prevents you in theory of dividing your human resources (what an ugly term) in cross-functional teams of the appropriate size.
Is methodology the right thing to focus on?
There are studies that claim that differences in productivity between programmers account for all the variation in development time and costs; a famous figure cites the most able programmers as 10x more productive than others. At the same time, the differences in productivities by adopting different methodologies are not as high, and are sometimes skewed by the subjects (the early studies on TDD just show that if you put Kent Beck and Martin Fowler working in a team, TDD helps them. But if you give them a stone and an hammer, they will probably do not much worse.)
Thus methodologies are about doing the best with what you have, but you still have to choose wisely your programmers if you want extraordinary results. That said, investing in a book like Clean Code or in a conference for your programmers results in "upgraded" programmers which work for the same salary, and may be better than investing in a transition to the new methodologies of 2011.
Another question comes to mind: we are following RUP at least is a coherent statement. But is it valuable say that We are doing Scrum or We are doing XP? Doesn't the Agile manifesto say people and interactions over processes and tools? Here's an independent opinion:
Actually "I am doing Kung-Fu" requires something more than just a list of techniques/practices. So is for XP. Focusing on definitions belongs to an analytics mindset. Agile values doing more than wondering. Does knowing we are really doing Scrum or XP make us more productive? No. Does it take time? Yes. So it's waste. we must ask ourselves if we can deliver more value, sooner, and then check how suggested techniques may help us. -- Jacopo Romei
The horrible RUP book: Building Web Applications With Uml
Opinions expressed by DZone contributors are their own.