Allan Kelly

About Allan Kelly

Allan Kelly has held just about every job in IT, these days he provides training and consulting in development management, processes & products, especially around Agile. He specializes in working with software product companies, aligning company strategy with products and processes. More about Allan at http://www.softwarestrategy.co.uk/allankelly

3 Styles of agile (part 2)

In my last entry I set out what I call “3 Styles of Agile – Iterative, Incremental and Evolutionary.” In this entry I’d like to discuss the model as a whole.

Lest anyone start “my style is better than your style” I am at pains to point out that each style has merits. Regardless of whether any of us regards one style as superior, or one style as “wrong” the model describes what I find in companies and teams. I also believe you can use Scrum, XP or Kanban in any of the three styles.

That said, I confess, I see evolutionary as “superior” to iterative and I probably don’t do a very good job of hiding my preference. Rationally I must accept that each style has its own advantages and disadvantages depending on your context.

So how should one use the model? Or rather what does the model show?

Firstly (#1) the model is useful in naming the way a team is working and resolving conflicts. I frequently find that one group of people in the organization think Agile development means one style (e.g. Evolutionary) while another group thing it means another (e.g. Iterative). The result is a conflict with each group thinking the other is stupid and doesn’t understand.

This extends to much of the writing in books, blogs and elsewhere about agile. Sometimes the writer is implicitly assuming one style but their reader may be thinking another. In the extreme subscribers to one style will see the other as “Idealistic” or “Purist”, or contra wise: thinking someone “wants to do Waterfall” or “lacks flexibility.” One person’s “Pragmatic Agile” is anthers “Flawed Agile.”

Simply recognising the model and talking about it exposes assumptions and beliefs. It can also help to recognise that different teams within the same organization will work to different models.

The second (#2) use of the model is as a change model. Typically a team with a dysfunctional (or sub-functional) process and wanting one particular style, say, evolutionary, can enter at iterative and advance up in steps. It is fairly easy to see how a team working in iterative style could become incremental. (Of course a chaotic team finding itself in a controlling environment might make the opposite transition, from evolutionary to iterative.)

Thirdly (#3) – and already implied the last paragraph: organisations might rationally choose to adopt one style in preference to others. For example, for an organization which follows a strict budgeting process, operates in a slow paced market and has no intention of changing its management approach (e.g. a large insurance company) it is probably right to adopt an Iterative approach. Adopting evolutionary would just upset too much of the organization and possibly destabilise it.

One of the things I would like to understand – and something I should devote more time to is: understanding the forces which lead an organization to adopt one style over another. There are rational reasons for attempting to freeze out change (while achieving efficiency benefits) and there are rational reasons for embracing change (and sacrificing efficiency).

Now, while it sounds rational to say “A company can choose its Agile style” I don’t believe that is how it happens. Rather the style a company operates in has more to do with where they came from – what economists call path dependency.

Companies and teams seldom rationally choose the style they want. Rather their existing mental models and assumptions leads them to understand “agile” in one of the styles listed. As a result when they encounter engineers, consultants and books which assume a different style they a) ignore them, b) get confused or c) dismiss them as “idealistic” or “not in the real world.”

The net result is that it is more important than ever to name these things. Just naming them (#1) and recognising the styles for what they are is a great step forward. What you do next is a far deeper issue tied up with the wider organization.
 

Reference: 3 Styles of agile (part 2) from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog.
Related Whitepaper:

Applying Agile Principles To The Development of Smarter Products

Agile development has become a cornerstone of most software development organizations.

Marked by iterative processes that deliver incremental value over time, agile development has enabled organizations to manage software complexity more effectively and to improve quality and time to market compared with previous development processes.

Get it Now!  

Leave a Reply


6 + eight =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books