IT leaders who started their journey toward adopting agile will probably recognize some of the patterns described hereafter. As corporations progressively experiment with or adopt agile methodology to accelerate their speed-to-market, they can fall into a common trap if their IT department fails to fully embrace an agile mind-set and behaviors. There is a pattern among organizations that pick and choose what aspects of agile to adopt: they think they’re “being agile” when in fact they’re only “doing agile.” Because they fall short of a full commitment to agile, they fall short of agile’s full potential results.
On the surface, the process looks agile: there is a scrum master who facilitates “agile ceremonies,” the four core team meetings within each sprint (short build phase). There is also a cross-functional team mixing front-end and back-end developers, a tester, and a solution architect. There is a process to plan development and a defined cadence—say, every two weeks—to make, report on, and demonstrate progress. There are talks about a minimum viable product (MVP) when new code is pushed into production after lengthy integration tests. There are new tools, such as Jira, to log units of work and track story points to monitor team velocity (productivity).
However, scratch beneath the surface and there are reasons for concern. The scrum master is only a part-time role whose involvement stops at the end of the ceremonies. The customer-experience (CX) designer is conspicuously absent from the scrum team. Instead, CX has been outsourced. User research was performed before the program started but not since. The product owner, instead of driving the product vision, follows the developers’ lead on which features should be prioritized based on how quickly they can be developed.
The team divides user needs revealed by the early research into front-end tasks and back-end tasks assigned to a front-end developer and a back-end developer. But the tasks, once completed, aren’t reconnected to compose an end-to-end user story. Slowing things down further, the MVP release is scheduled several months down the road to allow for the inclusion of features that already exist in the legacy application.
These kinds of delays aren’t often reflected in team reports. At the end of the sprints, the team productivity report shows, for example, that it has increased regularly, although not dramatically, since the first sprint. The tester is performing tests manually and has gotten wiser at choosing what to test. But experience shows that the results of such a partial commitment to agile are, like the process itself, half-baked.
A half-hearted commitment, for example, lacks the customer-centricity mind-set and the empathy that a CX designer would bring to removing perceived inconvenience from the customer experience. A full-time scrum master would relentlessly work to remove impediments, not just facilitate the ceremonies. Priorities would be business driven, not tech driven, and would be based on maximizing user value, not minimizing time to develop.
Companies that are really being agile wouldn’t disaggregate user stories into mere programming tasks, but would use them as building blocks for a better user experience. And user validation wouldn’t be put off until after a full release. Every user story, each granular slice of the user experience, would be submitted to the test of a sprint review, ideally with feedback coming directly from end users. The sooner there’s a working prototype, the better. Efficiency tools such as Jenkins should be leveraged to automate testing as much as possible and facilitate continuous delivery.
In short, successfully adopting agile methodology requires a full commitment, a complete reboot of mindsets and behaviors. The migration to agile must be accompanied by a thorough change-management plan to first instill, then install, and finally institute agile as the new norm applying to every person, process, and tool.