First off, in the spirit of full disclosure, I should explain that I was involved with the creation of the agile method DSDM and have worked with agile groups like the Agile Alliance (I was a board member for a couple of years) and helped create several agile certifications (iCAgile, DSDM Leadership, PMI-ACP). So, I am not immune from the pulls of standardization, but hopefully that adds some credibility to my encouragement to rise up and evolve your methods. The biggest threat to agile I see is not dilution and confusion, it is obsolescence and abandonment because they are not keeping up with new demand of collaborative teams.

Agile teams often talk about “Shu, Ha, Ri” progression that describes a three-step process of increasing mastery that progresses as follows:

1.         Shu: Obeying the rules (shu means to keep, protect, or maintain)

2.         Ha: Consciously moving away from the rules (ha means to detach or break free)

3.         Ri: Unconsciously finding an individual path (ri means to go beyond or transcend)

The Shu-Ha-Ri model is used to describe the appropriate approach to process tailoring. Put simply, people should know and practice the “plain-vanilla” process works before removing things or inventing new flavors. However that’s where the commonly available advice seems to end, there is a definite lack of Ha and Ri recommendations for teams practicing for a couple of years who want to improve.

When creating DSDM in the early 1990’s we were influenced by the Participatory Design approach pioneered by Enid Mumford. Mumford reported, after years of trials and studies, that getting the customer involved in design improves buy-in and engagement. This results in higher quality deliverables that are more suited for purpose and have higher satisfaction levels. This is old news today, but useful back then so we engaged the customer in design workshops and got great results.

Continuing this idea we then engaged the customer in architecture and technical design workshops. However, rather than bringing more benefits it brought a bunch of conflict and problems. Customers 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 nobody 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 process failure and the associated adaptation of 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 learning's 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 Scrum master 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.

Figure 1 - Sarah Sheard’s “Universal Technology Adoption Lifecycle”

All ideas get carefully replicated at first, then copied, then misused, unfairly blamed, criticized and rediscovered, and we should get used to it. DSDM was enterprise friendly and scalable from day one, it was criticized by other agile method practitioners as too large and heavy weight. These people are now adopting SAFe, Less and DAD to scale agile in the enterprise. It is all good, it is just the cycle of technology adoption.

The Evolution of an Agile Team

As a case study illustration, I recently worked with a high performing team that remained stable for 8 years. The company recognized them as a highly productive group and had the foresight to keep the team intact and bring new projects to this stable team rather than disband it and go through the Tuckman stages of Forming, Storming and Norming all over again.

The team of 9 people was co-located originally and then two people moved away but continued to work remotely. The remote members used predominantly instant messaging to keep in touch. The team had prolonged and heated debates; sometimes I thought I should intervene, but when you listened to the topics they were progressing (slowly) and led to strong buy-in for the decisions generated.

When they suggested they drop the frequency of stand-up meetings I was cautious, but not alarmed. We tried having them three times a week and then just twice a week for a couple of weeks. Soon they had dropped stand-ups all together but their output and quality remained high. People were still communicating all the time and it was obvious stand-ups had become redundant.

A weekly “Show and Tell” meeting was introduced for everyone to demo what they have been working on and discuss the next set of features queued for development. After the Show and Tell that included the whole team the developers stayed for a “Tech Talk” session that was part code review, part refactoring discussion.

We switched from two week iterations to a continuous pull of features from the backlog. We retained a weekly demo cadence and monthly release cadence, but dropped the two week planning, estimating and review cadence. T-shirt sizing and throughput metrics replaced our story estimation in points and velocity tracking. Retrospective were stopped, I questioned the team about this one and the response I received was “Why would we wait until a planned meeting to discuss and implement an improvement?” Instead “Sense Pull” is the practice of pulling improvements into the process just in time, like features are pulled in a lean process.

Throughout these changes, productivity and engagement remained high. The business was very happy with the quality of the work delivered and continued to fund additional projects. These adaptations to process came from the team and suited their work practices and environment. I would not recommend they are copied piece-meal because 1) I simplified the descriptions to keep them short and 2) they were the product of one individual team’s reflection and adaptation. Different teams will most likely have different evolutionary needs.

Moving Forward

“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 who are happier to substitute and adapt. It is a tricky subject, and as always, there is some truth in the extremes and more sense in 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. On July 1 2015 Jeff Sutherland tweeted "Scrum is the Minimum Viable Bureaucracy. Keep the framework whole or it will fail."

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

For instance, “Small Releases” support “Continuous Integration” remove one and the other will suffer.  Again, great advice, people really must know how the plain vanilla process works before removing things or inventing new flavors.

Interestingly, Kanban takes a different stance; in David Anderson’s Kanban book he states:

”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 endeavors 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 practices 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 forward thinkers. I had a good discussion with Jonathon Kohl a few years back about agile methods evolving to embody new practice 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 

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

The future belongs to people solving the pressing problems, challenging the status que and mixing things up. In a community who practices experimentation and evolution towards a better state for solutions I am continuously amazed at the reluctance to truly take this to heart. Yes, when you venture off your scrum roadmap you will have a risk of going the wrong way, but also opportunities to find great benefits.

If done correctly we can capitalize on successes and step back from failed experiments. Using the techniques we employ for product adaptation we can drive the next generation of tools and techniques. And remember: “Change is inevitable, except perhaps from vending machines.”

(note: this post first appeared at ProjectManagement.com here)