Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 638 posts at DZone. You can read more from them at their website. View Full User Profile

An humble infographic on methodologies

01.18.2011
| 6421 views |
  • submit to reddit

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.

Prescriptivity

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.

Scale

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

References

Kanban and Scrum: making the most of both

The horrible RUP book: Building Web Applications With Uml

Extreme Programming: A Gentle Introduction

The Toyota Way

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Josh Marotti replied on Tue, 2011/01/18 - 12:01pm

I'm confused at this article.

First, the one thing I can say about the 4 things you are comparing: Apples and oranges

RUP: Rigid PM methodology

Scrum: Loosely ruled PM methodology

XP: Development methodology

Kaban/Lean: More like a process than a full methodology

 

It appears that only your RUP knowledge is complete (and maybe XP, but it doesn't fit with the rest), as their are many errors in what was written.  An example:

A Scrum team is the same as a normal project team in RUP.  That means an enterprise can use Scrum entirely (I've worked at one, and I can tell you it is a fabulous experience to be in), and that RUP can be used in small teams only.  You just tell us that RUP is used in enterprises and Scrum is used in small teams?  Can you cite that information?

 

Maybe it would be a better approach to find someone that is an expert (or at least highly successful) on each of these methodologies write in about how each is represented and then combine them into a more complete article that gives the pros and cons of each methdology.  Comparing them, though, seems off.  I can run Scrum with XP development practices and use kaban.  So if I can combine them, I shouldn't be able to compare them since they aren't really directly comparable.

Just my two cents.  Hope I wasn't too critical.

Giorgio Sironi replied on Wed, 2011/01/19 - 7:57am in response to: Josh Marotti

The size cited is team size. For Scrum, you can find the famous figure 7+-2 people in a team everywhere:

http://www.google.com/search?q=scrum+team+size

For RUP, you can actually use with large or small teams:

http://www.ibm.com/developerworks/rational/library/jul05/kohrell/

but it's sold as something that performs well with large scale. For small teams where all members can easily communicate verbally and informally, it never made sense to me to use RUP to document everything. There has been many discussions about this:

http://blog.ivarjacobson.com/yes-rup-is-my-baby/

where Jurgen Appelo says:

What people hate is a heavy process where lightweight methods are sufficient. I’m afraid RUP has always presented itself as a heavy process. Just browsing through the Kroll/Kruchten books makes the average software developer want to cry out in agony. [...] Would I buy and downsize a Boeing 777 if it’s only a bicycle that I need?

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.