Agifalling

Agifalling – verb

1. A description of a hybrid waterfall/Agile project in the throes of failing. “Oh no, we’re agifalling,” or “I’ve agifallen and I can’t get up.”

Many of you may have encountered what’s become known as a ‘hybrid’ project. It combines waterfall and Agile techniques to deliver software. The principle of combining the two approaches seems to have evolved from dissatisfaction with both techniques: waterfall is perceived as too rigid and Agile is perceived as not rigid enough. Although many people have had success with combining the two practices, a merely bad project with either technique can turn into a disaster when waterfall and Agile are combined without sufficient understanding or caution. If delivery is late using waterfall, delivery will completely fail on a bad hybrid project. If developers find it hard to code from traditional requirement specifications, they’ll be completely confused on a bad hybrid project. If the customer balked at the costs of doing waterfall, they’re in for a nasty surprise on a bad hybrid project.

So how does a bad hybrid project start and what does it look like? Bad hybrid projects usually begin with a poor grasp of both waterfall and Agile, and to add insult to injury, the waterfall components are included because no one trusts anyone enough to let the teams manage themselves, and Agile gets adopted because someone read a blog that said Agile would make developers code faster.
The project is consequently split into different practices depending on your role. The developers get the most Agile work. This usually involves two weeks of sprints and daily stand-ups but there’s no product owner and zero contact with the customer. The project manager’s job doesn’t change – they move around the tasks on their Gantt chart until they have everything in sequential order in much the same way as they did with waterfall, only it’s relabelled “Agile” (or “iterative”).

And what becomes of the BA? The BA is caught in the middle between delivering requirements on a waterfall-type schedule while trying to keep up with an Agile development team. In an effort to cover the bases, a BA is usually faced with producing more documentation than they would have delivered on a waterfall project.

A bad hybrid project can result in a BA writing use cases and then extrapolating user stories from the use cases for the developers. Or, distrustful of user stories (not to mention Kanban boards) and thinking use cases are too hard, the project decides that all of their requirement elicitation woes will be cured by producing extremely detailed screen prototypes that take weeks to produce (not to mention 10 to 30 pages of documentation per screen) but contain zero business context.

Although most BAs understand that the job is all about communicating the requirements in a way that allows the requirements to be understood, BAs on hybrid projects can find that they can’t keep up with delivering requirements in a way that will keep pace with a sprint. Usually a BA on these types of projects is pushed to “just make a start” without any idea of the overall features required. This is based on the assumption that Agile will help the overall goals and features naturally make themselves known as an outcome of the process. If the team has been tasked with delivering hi-fi screen prototypes as their sole source of requirements then the opposite is true. As super-detailed prototypes are developed and people are sidetracked by fonts and radio buttons, the overall design and purpose of the application seems to become more obscure.

The ensuing pressure and panic to define requirements using nothing but screen prototypes coupled with trying to keep pace with the development team usually results in a project that is in a constant state of anxiety. Keeping to schedule somehow turns into doing whatever the customer wants without question, even if what the customer wants is a very bad idea, because it’s far easier just to say yes to everything and shove the wants down the line. Any problems are pushed to the development team, which ends up with an ever-increasing product backlog and sprints that never get out of testing.

Without the additional Agile practices of regularly reflecting on the work done to date and adjusting the approach as needed, all that happens is everyone wearily traipses off to the daily stand-up so they can be harangued by the project manager about why the schedule is slipping.

What can you do if you’re a BA on a bad hybrid project?

Firstly, it’s going to depend on where you are on the project. If it’s already agifalling and the developers are drowning in sprints that never seem to deliver then it may already be too late. You can try suggesting to the project manager that it’s time to limit the requests from the customer and prioritise the product backlog. It’s also probably time to get an idea of the overall feature set to help sort out the backlog. This won’t make you popular since people cling to the notion that Agile is about accepting any and all changes at any stage, but there’s no way you’re ever going to end at the rate you’re going.

You could try talking to the project manager about Agile being a collaboration between the customer and the development team, which means that it would be desirable if the customer could be on site with the developers and the business analyst(s) for a number of hours per week to allow direct and unhindered communication. And if that’s not possible, at least arrange regular conference calls and/or Skype sessions. You can also look at going back to the prototypes giving the development team the most trouble and ensure that you do a quick user story or state a business goal for each screen, showing how the various screens relate to each other. This will at least give the developers some context.

If the idea of running a hybrid project is being discussed but has yet to start then you may have an opportunity to help the project manager avoid the problems that will rapidly appear. This will depend on how comfortable the project manager is with trying new techniques. However, if a hybrid project is pitched from the perspective of making their lives easier, a BA may be able to offer tips and tricks on how to keep the requirements process running in a way that actually focuses on delivering value for the customer (identifying business goals/needs, etc.) while tracking with the developers fortnightly sprint cycle. The project manager may be deeply uncomfortable with most Agile techniques (except for the ones that purportedly make developers code faster) but it may be an opportunity for a BA to design a sneaky template and wedge in a user story or two anyway. No one ever said that a user story had to be on a sticky note.

For example, you could add a small paragraph at the top of the screen prototype (if you’ve been forced down that path) that outlines the goal and how the customer envisions using the screen from a business perspective.

If you’re going down the path of writing use cases first and then extrapolating user stories from the use cases, you can definitely save time by factoring in the user stories at the start. Make them part of the use case as an additional section. This is a little sacrilegious but you’re on a bad hybrid project so any thoughts of using best practice or standard techniques have already gone out the window. Do whatever you can to save everyone time further down the track.

My final thoughts on the hybrid project is that they’ve emerged as yet another ICT attempt to find the silver bullet that will make the extremely hard software development stuff happen as if by a miracle. All of the techniques, whether plan driven or change driven, tend to be successful with the right team of people, the right attitude and a huge dose of pragmatism.

A bad project is a bad project no matter what technique, practice or methodology is used. But that’s a different article.

Don’t forget to leave your comments below.