Thursday, November 22, 2012

Standard Agile Process

A few days ago a friend described to me how in their company they were introducing a new development process. To go with the flow they decided to introduce agile methodologies at the same time. To make sure that all worked on the same basis they are calling their new process “Standard Agile Process”.

I think that is a contradiction within itself. Either it is standard or it is agile but not both. Let me explain.

In my view at the very core of agile methodologies is the ability to adapt to the environment. Many factors can influence the decision including people, experience, customer base, technologies, product, target market, time zone differences. Since 1999 I haven’t found two teams who used the same agile approach not even within the same company.

Given sufficient autonomy and authority a team will adapt as well as they can. Is it reasonable to expect that any two teams (regardless of being in the same organization or not) start their journey at the same time, progress at the same speed, learn the same things at the same time, have the same set of experiences and end up making the same choices? Evolution is never the same if the factors influencing it are different or if the timeline is different.

It’s even more complicated - or easier depending on your viewpoint. One of the teams I’m working with is using multiple process all based on agile principles, no two are the same. Factors that have influenced their choices are type of work, product and customer. And each of the processes (at least three) is evolving at a different speed following a different set of changes. Changes are applied as the team identifies the need for them, if needed multiple times a day. Occasionally a process stays the same for a few weeks.

So when you see or hear the term “Standard Agile Process”: If you are impacted by it, keep the above in mind. Don’t switch off your brain. Think for yourself. Speak up.

Or just have a good laugh in particular if your leadership team allows you and your team to be truly agile. You may or may not believe in Darwinism. But history suggests that those who adapt faster and better not only have a better chance of survival. They also tend to have a better life, i.e. are more successful and have more fun.


Ed Sykes said...

I think you're spot on here. I think standardisation is function of communication. What often happens here (at 1e), is that there will be lots of new techniques and ways of working evolve in different teams. Once we talk about what we're doing it becomes clear that someone has found a better way of working. Those ways are then adapted to all the teams that share the context that led to the way of working.

This means we end up standardising, then diversifying, then standardising.

By standardising I don't mean that all work is done the same. I mean that one aspect of the way we work standardises.

Elena Yatzeck said...

I agree with Ed. If a company is new to agile, I don't think it's harmful in and of itself to provide one internally coherent process description as a template for all the teams to start with. Of COURSE all teams will adapt to fit their needs, and this should be encouraged. But starting completely from scratch encourages things like "just do standups and you're agile" or even worse, "beat up a team every two weeks for not delivering what they promised." People love to learn from examples. To me the trick isn't "avoid the sample." It's "avoid locking down the template as the only way to do things."

Hostgator promo code