Agile Development Blog

I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (“sharp” or “pointed”) and moros (“dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

• Small batch sizes, short cycles that create rhythm
• Reduction in queues through pull
• Reduction in work in process inventory
• Design quality in
• Stop-the-line defect control
• Value streams the link to the customer
• Integrated learning through reflection
• Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?

This post continues on our series of questions and answers from the webinar Dave West from Forrester and I did on Scaling Agility with Lean: Proven Methods of Operational Efficiency.

At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.

DW – is Dave West from Forrester

RAM – is Ryan Martens from Rally

How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?

DW – The flippant answer is it can’t. ☺  But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile.  Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not.  The PA’s always seem to imply lots of documentation, but they do not have.  You can keep the documentation to a minimum, but still deliver them.  Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.

RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.”  The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation.  According to SEI, it does not.  Most teams would not adopt CMMI without a specific business need.

(more…)