Agile Wars: Revenge of the Waterfall

You may have already faced Agile discussions on the Internet. People treat and apply Agile differently, for that it is a flexible methodology. We have created the list of things to remember when applying Agile frameworks in corporate environment based on NIX Solutions’ experience.

Roll it out step-by-step

First off, never ever assume Agile methodology is a silver bullet. Did you know the success rate for Agile-driven projects was 63% in 2017? That is abysmal in anyone’s books, Agile or Waterfall. Remember that Agile methodology suits small and medium companies just fine, while cracks may appear for larger-scale implementations.

Start with one department, and when success story will speak for itself, gradually roll it out to the rest. If you hit a snag (hit it you will), you would still be able to get your Lessons Learned together, and make adjustments down the road, ironing out implementation details specific to your operating environment. While if you hit the same snag by introducing Agile frameworks simultaneously across-the-board, the opposition will take hold, and you won’t find it easy to get a buy-in from employees the next time round.

From NIX Solutions’ experience, gradual introduction of Agile-specific ceremonies is a proven way to increase the chances that both your team and the customer will successfully adopt the framework. Starting off with just sprints, and then on to scrum meetings, and not necessarily daily ones, would ensure smoothness and predictability that so many business partners are after while still providing the small wins to justify the ongoing transition. End result on a real-life project? Cutting down the average time to complete a feature from around 12 work-days to… just 6. Showcasing similar ‘before’ and ‘after’ metrics will not simply help your case with transitioning to Agile, but would make it a cinch with most of decision-makers.

If your organization is exceptionally large, you might want to consider SAFe, warts and all.

Establish baseline metrics

Do not fall for the continuous delivery or no-estimates fibs. P. Drucker nailed it: “What you cannot measure, you cannot improve”. Know where your newly introduced Agile frameworks are taking you. Start off with some baseline delivery metrics, and re-check them both along the way and when Agile principles have been fully embraced by the organization. Do you see improvements, digits-wise? Congrats, you have made it right!. Are the pre-Agile metrics actually better than post-Agile ones?.. Re-visit, re-adjust, and continuously improve. Add the “Days-in” field to your Kanban board to instantly showcase how long an item stays unattended in the development pipeline (that field does get displayed in default JIRA implementations). Track the time logged for each user story. Do statistics to illustrate to the management that it is really working, by means of either Scrum board or Kanban board. And if not, find the root cause, fix it, and re-iterate!..

A senior champion is not enough

While it is extremely important to have senior management on board before rolling out any Agile methodology, remember that the onus will be on rank-and-file employees. Continuous delivery and 2- or 4-week sprints are awesome news if you are an account manager, but to a regular developer, QA engineer, BA, etc. on the team, it spells a continuous, non-stop stress of hopping from one mini-release to another with no lull in between. More stuff done for the company’s clients in the same time-span? Yay! What employees will hear is ‘more stuff done than I usually do for the same salary’. That is a cultural shift, particularly for bigger companies where some employees tend to get virtually lost, pun intended, in a forest of cubicles. So get them on board, too! Think of what exactly would motivate employees in your company. Develop a communication strategy to keep everyone informed and stem out any ‘oldie-but-goodie’ rumors about how the previous ways were just fine, and the new-fangled methodology is just not right for our company. Indicate the advantages: fewer specs to complete; less formalized communication channels, Agile conferences and trainings, new job titles, career progression, maybe, a financial incentive at the end of a fiscal year. Have either an in-house Agile champion, or hire a contractor to get the framework up and running. Communicate the progress regularly, do not leave them guessing, and involve all team members, i.e. the proverbial ‘pigs’ from that age-old parable, not just chickens.  If you involve just senior management, I bet you London to a brick your newly introduced Agile frameworks will degenerate into a series of humdrum stand-ups and retros well before the first year of the roll-out.

At NIX Solutions, we know that most of Agile ceremonies stem from the experience garnered by development communities and are there for a reason. Here is a cautionary tale fit to be added to any Scrum master’s Lessons Learned: on a project plagued by mismatch in expectations between two geographically dispersed teams, the in-depth analysis revealed that a retrospective session was attended by team members simply because… it was mandatory. Lunch? Check! Retro? Check, and would you like fries with that? : ) Appointing a retrospective session facilitator, and then laying it on the line for the team in terms of expected retro outcomes brought the project back on track fairly quickly.

Never over-commit

Make sure your Agile team does not feel pooped out by the end of a sprint, whatever its duration. That’s a no-no. We all know what happens to those who continuously sprint: they eventually burn out. It is a marathon, never a sprint. If you love your team, do not do it  — people will vote with their feet. 

Factoring in some leeway when planning for the next sprint could be a surefire safeguard against the team’s physical and emotional burn-out. Chuck on the backburner anything you feel your team members will not be able to complete within the sprint’s scope, and vary the workload with assignments not directly linked to the project’s subject matter. In other words, if your team’s regular sprint velocity is around 80 story points, and your Planning Poker™ game has resulted in well over 90, consider cutting it down to ensure there is some breathing space at the end of the sprint.

And what if you don’t? Statement of Work and deadlines to meet? There is only as much as one can fit in a sprint, regardless of its duration. Piling up more user and technical stories, bug-fixes, and enhancements will inevitably cause a spill-over into the next sprints, both in terms of Code Complete and QA Complete items, leaving you with very little room to maneuver around new feature requests, etc that you must add. At NIX Solutions, there is a Case Study doing rounds that clearly pinpoints the JIRA burn-down chart going from 85% in terms of an average sprint completion rate to 60%, 40%, and finally 10% (!) of planned workload across 3 sprints where the scrum master had to progressively add more items to pander to the top brass requests. If you find yourself in the same sticky wicket, raise your courage card, ask for the time-off, and have a sprint dedicated entirely to catching up on both outstanding items and/or technical debt.

Beware lightweight documentation. Seriously

An Australasian provider has allegedly gone into receivership for misusing their ERP app in a nearly total absence of supporting documentation. The vendor’s delivery team, you guessed it right, had used the Agile frameworks. True story. While Manifesto’s working-software-over-documentation is fine, think of what it means for your organization.  Are you from the healthcare, finance, compliance, machinery, or other knowledge-heavy industry? You simply cannot afford the know-how either sitting in the developers’ heads or buried in a pile of user story silos. Demand ‘just-enough’ administration and knowledge-base guides. You won’t need any for a Facebook app, but not having any for complex industry sectors will cost you big-time. Remember the business case of Polaroid’s lost know-how and many more. 

Stay tuned in for more! To be continued in the second part of an Agile trilogy.