Sunday, August 15, 2010

Ad-hoc to ISO to CMMi to Agile

Process journey of Eurocenter from its inception to date is touching my senses on how teams behave under different process styles. It is interesting to see how a project that required 25 member team at early days is now possible with 8 developers in agile.

Eurocenter processes were ISO certified for about a half a decade now. Those first generation ISO processes were mostly based on RUP practices and assumed ‘big design upfront’ methodology. Quality and productivity is delivered through rigid review/control mechanisms. Feedback loops were of high process importance and the quality actions were mostly reactive and corrective. Still most importantly, ISO brought in predictability to the projects in Eurocenter. With ISO, the effort was reasonably estimated and quality was well controlled at a release to the customer. The risk of never ending chaotic projects was not much seen in Eurocenter after ISO era.

Company moving towards CMMi brought a new dimension to the picture. Rather than being reactive, CMMi shaped the processes to be more "proactive" to achieve quality. An obvious result was a reduction of “rework” effort. We know that reduction of any form of effort meaning more productivity. Important observation is that there was no notable difference of actual amount of work performed in ISO and CMMi based models for a given project. The team composition, role/reporting hierarchy remained more or less same.

Today, most of the Eurocenter projects run with agile/Scrum methodologies. With agile, we have experienced further increase of productivity, but wasn't by reducing the rework as CMMi did. Productivity increase in agile is by reducing the amount of "work" performed to deliver a given requirement scope.

Following diagram shows how effort patterns evolved from ad-hoc processes to agile processes today.

How is this actually possible? Can a methodology reduce the amount of work to perform in delivering a given scope. We know that technology frameworks is capable of doing that.. but a process methodology?

To answer this question let have a look at how a traditional hierarchical team operates in delivering a project. There are typically few guys front ending and a massive machinery is in operation behind the scene (called the back-office). Work, instructions, feedback, reports everything flows up/down the hierarchy. Often in projects, the ones at the bottom of the pyramid never meet the ones at the top.

In this formation, most of the members in the team are actually “creating” work for the others in the team. Instead of delivering value to the customer, there exists small ecosystems that create work and resolve work within. For example, some processes may exist in a way that QA and Dev go in cycles without actually adding any value to the end objective. Dev and QA then make work for the PM, and PM pays back by making more administration work for Dev and QA.

Scrum/agile has actually changed the way teams are structured. Every member gst exposed and gains better visibility to the business requirements. It isn't possible for team members to hide behind others to fool around. Customer/management has good visibility to the work performed by each individual in the team. Teams started getting tuned and developers who were unable to cope up, had to be replaced by better candidates. In overall, around 50% of work performed in mini ecosystems disappeared with agile methodologies and work performed became more relevant to the business needs!

Disclaimer: This is purely from my own observations of my company's process journey. The numbers and information shared here is only for the explanation purpose and does not reflect any actual measures.  
[tag: 99xp ]

2 comments:

rositad said...

it's indeed a very good article. my observation in agile is, that all depends on the team. If we have tools in place and a good scrum master armed with a collaborative and stable team, agile would be the most admired methodology.

Hasith Yaggahavita said...

Agree.. one more thing, my experience is that you don't need a agile team to start agile development. Agile methodology itself is a tool that build such teams. When more focus is on individuals and they are empowered (made responsible) that itself is a bootstrap method of building a such team.