Anti-Nostalgia or something about Agile projects problems

There are few signs that signal about some deep misunderstanding of what is the nature of the successful SW management project:

1 – “Cargo cult”

2 - The notion that a project shall be “driven by Jira”

3 - The planning and design processes, along with formalized requirements solicitation process are being considered as the synonyms to a “waterfall” process (and this term is pronounced in such way as if it is not a “W” word, but an “F” word)

4 – Using as s project management/tracking tool Gantt charts with strict fixation of “stories” for a few consequent Sprint without constant (then) adjustments as to tasks sequence, as to their actual duration.

5 – Assignment of static roles and responsibilities for team members (without overlapping)

6 – Targeting 90% and more efficiency for the “Agile” process

7 – Ignoring (in the degree that borders to despising) need to create/maintain a crucial set of project’s documentation. 

Documentation is the project’s crowning effort. In order to be crowned at the end, one is to be noble from the very beginning. Project documentation creates “common ground” of shared knowledge, “anchors” concepts, visions, and what is most important holds all details as of solution architecture as of its implementation. If you don’t have documentation – you’ll always suffer from wasting time on “information re-discovery”. Key principles? Enjoy in moderation, maintain actual, create a glossary and high-level architecture diagrams and don’t fall to a temptation that “the code is documentation” (Because after all the code represents only ONE of the perspectives.)     

“Agile” SW development process by its intrinsic nature assumes some “waste” of time and efforts. It starts from acknowledging either uncertainties or incompleteness (MVP, do you remember?). Ones which disagree with that – need to start planning the implementation of “Lean production” process. (And there is a huge chasm between these two methodologies)

If the roles and responsibilities of team members are very formalized and don’t overlap, at least it plays as an extra risk factor. Because life is life and people can unpredictably get sick or have any kind of emergencies and/or personal issues. And it is the lesser of possible risks – the bigger one is in “information lock-up” and results in the fragility of the whole process.

Simply said, Gantt chart just is not a good tool to manage an Agile project which spreads over three and more Sprints. (Unless one diligently, on a daily basis, maintain its actuality). Nonetheless, it can be used, on premises to control the execution of not specific tasks (that can migrate from one Sprint over into another) but some abstract functional points. Once a team is certain about the overall set of features it has to deliver, to each of these “line items” (regardless of how they are being referred to: “stories” or “tasks” or “jobs”) assessed as implementation of some number of “functional points”. Then it becomes quite simple to track that every sprint delivers a certain number of the functional points. Here we need also to mention the subject of “burnout”, that will be linear only if “functional points” assigned accordingly real importance of each item but not just its “tangible” effect.

Without ahead planning, without paying special yet regular attention to architecture and design – the project is doomed to suffer for architecture attrition and technical debt accumulation. One may think that "design thinking" is dead, the more one is certain about it – the faster next project will get onto its “death march”. In essence "Agile" is continuous planning, repetition of PAC/SD cycles of a daily basis, (Plan, Act, Control/Study, Decide)  

Regardless of all preaching about “the most advanced social structure and advantages of plan economy” Soviet Union collapsed first of all due to its economic inefficiency and complete disorientation at all levels. Its upper management spent time at long meetings and issued nicely looking plans that started crash just next day after they were signed off.

The same happens when the management of Agile projects becomes mostly preoccupied with a visible part of Agile rituals (like proper stand-up, Sprint Planning, or Sprint retrospective meetings) without recognizing the need in real planning and other preparatory work. When control and visibility over plans execution are being substituted with a monotonous conundrum of regular stand-up meetings it leads to a guaranteed failure. (Let me remind you that observing just rituals without filling them in with proper actions is what referred to as a “Cargo Cult”)

It took me with surprise that almost all “establishing fathers” of “Agile manifesto” issued forms of “Agile is dead” statements during the last 5-7 years. (Check out on Youtube, Techzone and/or Medium). Because just observing Agile rituals does not guarantee the success of the project.

Adoption of the Agile mindset implies much deeper transformation than just care about Agile “rituals”. After all, it is not the rituals that deliver the results, but people who play in them.