Agile, Simplified

It doesn’t look like there is a good working definition of what constitutes Agile. The  Agile Manifesto is supposed to be such definition, but it is clearly not used in such role - in my career, no “Agile” Consultant or Vendor ever referred to the Agile Manifesto while explaining why what they are doing is Agile.

At the absence of a working definition of Agile, people use is “Agile is something that employs someone who procured a certification from a reasonably established Agile vendor”. And that definition is wrecking Enterprise IT. The even wider used “Agile is something that uses vocabulary and rituals borrowed from one of the known Agile methods” is even worse.

So as a matter of urgency I am introducing the two easy principles that you are welcome to use to assess existing Agile projects:

1. Feedback
2. Rush to feedback.

A project that shows good quality Feedback, and demonstrates efficient, lean, focused Rush to Feedback, is Agile. A project with inadequate Feedback and/or bloated, overloaded Rush to Feedback, is not Agile - and if called “Agile”, is likely a disaster in making. Whatever vocabulary, rituals and certifications are presented.

Of course, there are important additional efficiency techniques Agile possible - say no Agile Development is realistic without Automated Testing. However those techniques are not critical, as they can be (and would be) introduced to an Agiles without changing the fundamentals, while can be present in a disaster of a project, making it slightly more efficient.

Feedback

The quality of the outcome of the project is defined by the quality of the Feedback.

The main idea behind Agile is that you cannot trust the Documentation:

• Stakeholder did not necessarily completely understood what they need, and even if they did, not necessarily verified that the Document written by the Analyst reflects it well
• Analyst does not necessarily understood the Stakeholder well. Plus, the details the Analyst had to add are not necessarily optimal for business ner reflect the best solution.

So Agile states that instead of compliance with the previous documents, the Team should make the best estimation, and seek feedback on the outcome.

Evolution of Feedback

The first Agile. eXtreme Programming, was defining Feedback as Stakeholder comments on running built software

Continuous Delivery and eventually DevOps were introduced to extend Feedback to multitude of users.

Lean Startup suggested that a Startup should seek Feedback from potential end-users through metrics reflecting user adoption.

There is a continuous drive to extend and deepen the Feedback, by getting it closer to what the enterprise is trying to achieve. Which naturally brings us to the topic of the next Section.

Quality of Feedback

The showcase eXtreme Programming project that effectively started everything Agile was Chrysler Comprehensive Compensation System, or C3. Their Onsite Stakeholder left - officially voluntary due to burnout and stress. Yet if you consider that she was not offered a promotion, but instead allowed to leave, and that nobody in Chrysler wanted to replace her, you have to admit that neither the Project nor the Stakeholder were favoured by the higher executives. The system failed to scale, performed poorly on available hardware, was eventually stopped, with the company banning Agile for a few years. Sounds like a disaster, despite utilising well above average Developers and famous Consultants.

The failure of C3 is all due to the poor quality of Feedback. They relied on one mid-level executive who was responsible for everything, from running the scenarios on built software to making the decision on the next priorities. Their feedback didn’t include more than one opinion, didn’t include views of the more senior executives, of the enterprise beyond their project. The opinions of the Operations regarding the performance of the system, was also sought more than a year into Agile Development.

Quality of Feedback describes how well the Feedback that is sought reflects the needs of the enterprise.

Feedback should possess Expertise and Coverage.

Is the Stakeholder equipped to provide the Feedback sought from them? Uninformed approval may be shifting responsibility from the Team to the Stakeholder, however it does nothing to the success of the effort. The Stakeholder should be presented the outcome in the form and within scope that would enable them to use their expertise to provide the Feedback

Also, Feedback should be sought from the Stakeholders that together can assess all facets of the solution under development. Agile Expectation Board (see below) was created to ensure timely Coverage of the Feedback.

Rush to Feedback

If an Agile Team has been allowed to work for half a year doing something wrong, the chances of any correction of their course are slim. The combination of subconscious Confirmation Bias  and conscious aversion of self-harm would drive the Stakeholders to allow the project to proceed to something that could be somehow presented as not a failure it would be. For the Feedback to be adequate and effective, it should be provided before too much cost been sank into the things the Feedback is sought on.

Therefore Agile methods include various approaches and techniques to reduce the time required to getting Feedback on the work done.

• The original eXtreme Programming introduced rapid Iterations, 2-4 weeks, demanding at at the end of each iteration, the outcome receives Feedback.
• They also introduced User Stories which are captured at the rate of dozens an hour instead of comprehensive specs, and mandated coding on the basis of tacit knowledge and informal conversations.
• Scrum introduced “Sprints”, the organisation of work that, when implemented correctly, sets a small number of workers to rush reviewable deliverables
• Kanban Board visualises work that is not ready to be evaluated, thus encouraging the team to finish existing work-in-progress and get Feedback instead of starting new chunk of work.
• Lean Startup introduced the concept of Minimal Viable Product (MVP), the minimal set of features required to be able to get quantified Feedback from the users.

Save Agile!

From the beginning, Agile evangelists stressed that success of an Agile undertaking depended on the quality of people. The problem is, nobody’s resume claims that the person “prefers to study new technology while paid, then seek better paying employment with high in demand skills”, or “narcissist who perfected the art of shifting blame to others”, or “lazy bastard who is good in inventing work that doesn’t take much effort”. Yet those people are out there, with resumes indistinguishable from those of the great people, applying to roles in your project. You cannot bet your project on successfully avoiding them.

So to save your project, and the reputation of Agile, you need to apply the criteria outlined in that paper to the projects claiming to be Agile. They are objective, and are much harder to fool by a malicious, lazy or incompetent actor. Check the quality of the Feedback - is what they do getting validated, are the stakeholders informed and in control? Do they Rush to Feedback, or try to get busy with a lot of unnecessary stuff?

The Paper is license under Creative Commons with Attribution License. So feel free to build commercial services on the basis of it. Just don’t forget to mention to this paper and my profile.

@Alex Jouravlev