Agile Preservation or Progression?

This content is syndicated from LeadingAnswers: Leadership and Agile Project Management Blog by Mike Griffiths. To view the original post in full, click here.

Shell Back in 1994 when we were defining DSDM, I remember our experiment of getting the user community engaged in the application architecture. (Not a successful experience!) It was at Data Sciences in Farnborough, UK and we were working on a project for a government client called ECGD. Following ideas from Enid Mumford on Participative Design we were testing how far the benefits of closer business engagement went and discovered a limit.
For us at least, having the business closely engaged in scope discussions, screen designs, and planning was extremely positive, but having them engaged in our architecture sessions was a net negative experience. They leapt to implementation ideas, disregarded IS strategy, and did not know enough about the architectural issues to be helpful in the discussions. We got frustrated, they got frustrated, and no body seemed better off.

So we discussed it with other DSDM Consortium members and agreed business involvement should not extend to architecture. The DSDM framework was updated and we carried on with our experiments and evolution of the method. For me this was a transformational moment, it was my first time of witnessing a failure and adaptation of a process within DSDM and how we learn and adapt. We just changed the methodology; there was no sacred cow, just good old scientific experimentation.

Business involvement in GUI design: Good
Business involvement in architecture design: Bad.
Therefore, involve them in GUI design, but not in architecture.

There were plenty of other learnings after this as the methods grew from collective lessons learned, and now I have no qualms adapting process based on circumstance and feedback. This of course is not unique to DSDM, all methods evolved this way. When I took Scrummaster training with Ken Schwaber in 2004, Sprints were 30 days long, no discussion; now two weeks is more common. Good on the Scrum folks for seeing the light and adapting.

Agile methods have come a long way since 1994 (for a start we did not call them “agile” until 2001) and with their widespread use has come some widespread misuse and failure. I found this a little sad until I discovered Sarah Sheard’s “Universal Technology Adoption Lifecycle” and realised it is inevitable.

Technology Adoption Cycle

All ideas get carefully replicated at first, then copied, then misused, unfairly blamed, criticized and rediscovered, and we should get used to it.

If you want to make enemies, try to change something.” - Woodrow Wilson

Lots of people are very passionate about protecting agile methods. So now we see large camps of agile purists and ScrumBut bashers wanting to preserve the faithful reproduction of proven practices. They are in disagreement with agile pragmatists, happier to substitute and adapt. It is a tricky subject, and as always, the there is truth in the extremes and the middle of the arguments

As Ron Jefferies says “Agile ain’t just any damn thing” and I think most people would agree with this. There has to be some common framework, values, and principles present otherwise the boundaries blur indefinitely and the name becomes valueless.

Kent Beck warned us that XP practices are a balanced, self-supporting network and removing some will cause the others to fail.

Agile System

Again, great advice, people really must know how the plain vanilla process works before removing things or inventing new flavours. This is backed up by Alistair Cockburn’s “Shu”, “Ha”, “Rei” model based on Zen Buddhism. Progression moves from obeying the rules (Shu – to Obey), consciously moving away from the rules (Ha – to Break), and finally unconsciously finding an individual path (Rei – to Separate).

Recently Kanban has emerged as a potential agile supplement or replacement (depending on where you sit) and a section in David Anderson’s new Kanban book that caught my eye said:

”Kanban gives permission to create a tailored process optimized to a specific context... You have permission to try Kanban, You have permission to modify your process. You have permission to be different. Your situation is unique and you deserve to develop a unique process definition tailored and optimized to your domain, your value stream, the risks that you manage, the skills of your team, and the demands of your customers.”


 “The heresy of one age becomes the orthodoxy of the next.” - Helen Keller

 As agile becomes the default approach for IT projects we can be sure that many projects will fail using it. This is simply because many projects are ill conceived, doomed from the beginning, poorly executed, funded, or supported. Before we rush to defend the method we should remember that a fool with a tool is still just a fool and no method is likely to change that. Also, many projects are high risk and a certain percentage of these high risk endeavours will fail.


Failure is not fatal, but failure to change might be.” - John Wooden

So the question becomes how do we allow good changes to occur, like Scrum’s move from 30 day Sprints to two weeks, and poor choices like collaborative architecture, or random acts of laziness to fail? I think the answer is pretty simple. Try the change, evaluate it, validate it, adopt successful practices noting circumstances where they work, and stop doing failing practises in your circumstances.


Nothing is complete and thus nothing is exempt from criticism.” - James Luther Adams

The one thing we must not do is think that we are done with the development of agile methods and now all we have to do is execute them. That is when learning stops and methods stagnate, only to be replaced by the next set of foreword thinkers. I had a good discussion with Jonathon Kohl a few years back about agile methods evolving to embody new practise vs remaining a static model to be replaced by the next better thing. Link Here Whether under the “agile” banner or some other name, we both agreed that progress and change are essential.


If you don't like change, you're going to like irrelevance even less. “ - General Eric Shinseki

I think it is worth reiterating that we have to keep on learning and improving our skills, since standing still is the recipe for becoming obsolete. Nobody wants a mummified manifesto or petrified principles that are no longer relevant. I am very encouraged by the complimentary dialog about agile and kanban (Link) I think this is one of the more promising areas of potential growth seen in recent years.


Talent ... is most likely to be found among non-conformists, dissenters, and rebels.” - David Ogilvy

Reading the forum discussions about purists and pragmatist is interesting, but I try not to get sucked in, and I thought twice about posting these thoughts. It is so easy to spend huge amounts of time defending a point in a discussion where both parties are somewhat correct. I’d rather be learning what people are trying, maybe struggling with; this the breeding ground of the next great idea.

The upcoming Agile conference has many great sounding research papers and presentations that seem to be stretching the envelope. There is several sessions on Behaviour Driven Development and sessions such as “Is It Time to Ditch Your Product Backlog? Using Story Maps to Visualize Backlogs” sound really interesting.

I think we need to carefully innovate to ensure we get the useful changes (30 day Sprints changed to 2 week Sprints) and always be on a the lookout for evolving and improving. And remember: “Change is inevitable, except perhaps from vending machines.”

Leave a Reply

What is 10 + 10 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”