Agile Preservation or Progression?
This post is from LeadingAnswers: Leadership and Agile Project Management Blog by Mike Griffiths. Click here to see the original post in full.
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.
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.
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.”