Fragile is a kangaroo word. Within the Fragile ‘pouch’ is agile and the two words in a literal sense may not be seen at odds with each other. However within the software development world, we can use the kangaroo word to tell a ruminative story or two and even draw meaningful insights

Note: The two words find a fair mention on the internet for reasons other than the fact that it jingles when spoken together, like ‘Agile Fragile’.

Agile today is all across and its influence is growing day-by-day. Agile is followed to improve the quality of releases, make teams more productive, achieve faster time-to-market through optimised engineering practices and so on. But then we know that Agile is much more than practices. More than the methodologies it has helped sprout, there is the mindset, the philosophy, the culture it helps nurture within teams for expected good results. So then do we really need to take all that is spoken or hyped about ‘Agile’ at face-value? What are the pitfalls we need to guard against or dangers of its misinterpretation? What are the bad habits (agile anti-patterns) that we tend to fall into? What do we need to incubate, inculcate and percolate so that success with Agile can be more assured. Let’s try examine.

Culturally at odds

Agile fails when the organisation which embraces it cannot adapt to make it work. Maybe it has the will but not the method. Maybe both get fumbled at times.

Agile is not a template or a checklist that can be simply adopted. It’s an exploratory cum experiment-laden journey into a land of high promise, openness, and innovation. It’s not an easy transition for many and perhaps due to lack of prescription etcetera, the journey becomes higgledy-piggledy, goes downhill, frustrating its followers with results going down south. Agile coaches help but they are not resorted to by most adopters. Often agile becomes ‘followed’ in organisations after a crash-course training by some ‘senior’ personnel and then through words like ‘sprint’, ‘ceremonies’, ‘retro’ that rule the whiteboards more than the human DNA. The essence or philosophy of agile is what should be embraced and the practices need to be conditioned by this hug.

Agile adopters tend to also succumb to the pulls and pressures of commerce swaying away from the people-oriented, ethically correct practices expected in Agile. The culture thus gets ‘coloured’ for good and agile goes weak in the knees.

New clothes but mindless

It’s been seen due to lack of correct ‘mindset’ that management intervenes and ‘deals’ with the agile team to try shape their correct working. It may be a too many status meetings, extra reporting or ‘tweaks’ made to practices that send the team down a wrong agile alley. Maybe the twisting is down to what was sold earlier on the back of a numerically poor estimate. The balance between autonomy for the team and information to the management when skewed towards the latter tends to disturb the equilibrium. The team then does stand-ups, and other practices more for pleasing or for namesake (ritualism damned ritualism) rather than to ruminate and become better through team retrospectives or being transparent and achieve big-picture understanding via stand-ups and so on.

Agile needs planning and management and the managers have a crucial role to play as facilitators, wisdom-providers, motivators and coaches. The team needs more operational freedom than they did in the traditional world. The team also needs reposition of trust to function without fear of failure.

Disjointed Collaboration

Agile accentuates the promise and concept of one-team, one vision within a group of multi-skilled people responsible for requirements management, architecture, development, deployment, testing and UI/UX.
As much as technology and tools today provide greater assurance to achieve frequent software releases to allow ongoing demonstrable synchronization with business needs, the team needs to collaborate and work effectively to make it happen.

The fragility arises when people cannot do what is required of them. Matters get compounded in agile since each iteration is 2-3 weeks short and pressure to deliver is unrelenting. Consider the following sub-optimal examples that teams sometimes have to grapple with

• The PO prefers working with a less than adequate product backlog
• The user stories are one-liners or provided at the last-minute leaving little room for team discussion and refinement
• The UI/UX person is shared across multiple projects
• Technical debt piles on and the customer rejects any move to deliver anything except functionality
• The team is unduly large / scattered across geographies
• The team is small but constantly over-burdened to meet timelines that cannot move

How is agile expected to stay resilient in such cases and deliver results? Unlikely, don’t you agree.

The business stakeholders have to provide in-depth subject-matter information that the team must glean and use to deliver working software consistently and demonstrably. The team must find ways to work together, feel empowered, and take ownership to deliver value with top management support.

The team ought to regularly introspect and boldly take actions to find optimal manner of working so as to deliver better solutions.

No documentation, we are Agile

Agile gives the wrong notions, rather the manifesto (…“Working Product over Comprehensive documentation”…) is misinterpreted by Agile adopters about what and how much to document. Teams need to be prudent and diligent about what represents useful and worthy of being written down.

For example, compromising on content expression or clarity within user stories may seriously hurt what gets delivered to the customer. A contrary but valued example is where a team agrees that common/repetitive acceptance criteria gets documented separately rather than in each user story they apply to.

An agile team must indulge in brainstorming sessions, use visual aids and face-to-face communication rather than crisscrossing email conversations. Waste of effort and ink must be equally denounced.

Even process documents may not be dispensed with since these may provide context and a sense of direction to the team members. For example a Project Canvas (an equivalent of Project Plan document) in a particular context or a Burn-down Chart maybe a useful wall-adornment for the whole team.

Documentation in an agile context must be deliberated by team and followed if needed rather than rejected outright. They will be worthwhile provided they positively impact what gets delivered to the customer.

Let’s sprint, think later

Projects need to be planned with business involvement upfront to clarify on business objectives, pain areas and so on. This holds true for Agile projects as well. Diving headlong into sprints without sufficient thought to what is to follow is a recipe for disaster. As much as Sprint 0 is what has come to be expected, the need to do more may still exist. Sometimes a discovery phase or an architecture definition phase may make sense to precede the sprints. The discovery phase could involve discussions, PoCs, story decomposition and development, product backlog formation, story maps, governance aspects, estimates of size, cost and timelines etc. This sets the tone, sequencing tasks and clarifies the roles that will need to be played.

Artefacts like definition of done, social contracts, definition of ready and similar maybe process documents but sets standards for the team to consistently achieve. They should not be seen as constraining, rather an efficient and a creative solution for some known ills.

It happens that teams are not adequately staffed at times to carry out some tasks e.g. code reviews if a technical leader is not available. In such cases the non-carry out of such tasks must be short-lived and not permanent. The team ought to see the fallibility of not following such processes and take steps to mitigate it like say paired programming.

Conclusion

So what must be done to ensure that Agile delivers results? There is no quick recipe but in brief considering what’s covered in this blog we could look at

• The organisation going agile should undergo a systematic dive into agile across the board which is monitored and tweaked as needed.
• Agile coaches could supplement the training, working closely with the leadership and the teams
• Ensure that the people in the organisation are assessed and recruited with consideration to role diversity, mindset, EQ and such besides technical skills.
• Regular conduct of retrospectives and town-hall meets at the program level to disseminate information about progress, way forward.
• Regular checks on team morale via surveys, etc.
• Inculcate and progress a culture of learning, openness, courage and innovation
• Employ and innovate engineering practices that improves the productivity, quality of deliverables and the overall efficiency
• Educate the customers with respect to how agile works and what may be expected

To reiterate, Agile is an exploratory cum experiment-laden journey into a land of high promise, openness, and innovation. Failure is surely not an option, so planning, questioning, adapting and reinventing is what should lead to success in the Agile journey, making agile non-fragile and cheery.