A few days ago, I was talking to a friend of mine who works in the innovation department of a bank. He had driven a small but important project within the bank using Agile. He had built an app that let the field team keep track of important information, and report information back. The app simplified a lot of the work that the field team needed to do, especially around reporting, and gave instant analytics to senior management.

He was elated about how quickly he was able to get the project done using Agile compared to the regular way of doing things.

 I confess I did not share his enthusiasm.

I’ve seen my share of Agile transformation attempts, and I’ve seen first hand the havoc it creates before the organization settles down. When large organizations that are used to a way of doing things first brush against Agile, they usually try one of two things:

  • Do a pilot project to test feasibility and/or
  • Shift whole hog into the Agile methodology and get Agile coaches to help the transition

Many organizations start with a vision of embracing Agile, but find that the transition is difficult. The shift slows them down due to the enormous changes required in the ways of working.

Some stick on to Agile fundamentals, but most others fall back to some form of Hybrid Agile – doing some things the Agile way and the others the waterfall way.

 Over multiple discussions with development leads & architects across organizations, I have realized there is a fundamental difference in the way they see Agile.

Agile as a process

Though Agile is meant to help plan on the go, many organizations are unable to let go of the process of planning.

They place a lot of focus on getting everything ready for sprints: getting user stories and acceptance criteria fleshed out; ensuring there is a deliverable, however small, every two weeks; rigorously testing every small bit and documenting elements in some central repository.

The process around agile is so important for these teams that it becomes an end instead of means to an end.

The aim of these teams seems to be maximizing development output. But in the process, they sacrifice ideas that are not mature and consumer understanding.

The scrum master’s primary objective here is to ensure that everyone has enough to work on during a sprint. Hence there is immense pressure on the product manager/product owner to complete the set of user stories with valid acceptance criteria.

Product owners are on a perennial run to complete stories for the upcoming sprint, and have very little time or energy for other activities like understanding market and user needs.

UX designers also face a lot of pressure to details specs for stories, leaving little or no time for exploration of different ways to achieve results.

Treating Agile as a process gets in the way of being effective. While the team manages to have fortnightly releases (potentially shippable increments, but usually with caveats), the weight of the process slows down the team over the longer team.

When I was the product owner/product manager for one of Nokia’s maps apps, we were newly experimenting with Agile. The app itself had components built across different teams, and had dependencies on new features in the operating system. Each team was trying to work in an Agile manner, but managing complexity across teams became a huge challenge. When one of the core teams slipped on the deliverable for a dependency, all other teams’ plans went haywire.

 While we had planned out EPICs and sprints, we often found that the progress was slow and would end up negotiating how many features we had to drop just to keep the app stable.

 Needless to say, all teams ended up being frustrated. The business/product teams were frustrated because our asks were compromised, while the tech teams were frustrated that they had to rewrite a lot of the software code because of changing dependencies or not having enough clarity in the beginning.

Agile as a concept

After I quit Nokia, I spoke with multiple firms on their Agile implementation journeys. While many had faced similar challenges, there were a couple of firms that had decided that they would follow Agile as a concept and not a process.

 How was this different?

For starters, teams sat and figured out which components would be best developed using Agile. They realized that some components that were core to the experience would require time and iterations. For these, they decided to first build the hook APIs for other components and simulate outputs for these. Later, they would experiment with the different ways of building the core components.

 They also observed a couple of sprints and decided to change their cadence for effectiveness: one firm decided to move to a 3 week sprint for a section of the work as they figured 2 weeks was too constraining. Another decided to work only in 2-month sprints.

They were also flexible on time requirements for different members.

One of the teams in a firm I spoke to sat down and discussed how best to use UX. They realized that in stressing on the detailed specs for every sprint, they left no time to test important ideas.

They decided to lock down deliverables two sprints in advance and make time for the designer and architect to sketch or build light prototypes for these in advance. This helped clear a lot of questions when it came to implementation.

In one of the projects I ran at Nokia, we had tried something similar out. I had an architect and UX designer sit with me for a couple of days before we began the project, and we sketched out a blueprint of the interactions and core architecture. We then presented this to the team as an early sketch. Once we factored in the team comments, we used the sketch as a high-level reference guide for the project.

During the actual sprints, we would use the reference guide to clarify points without having to spec out each and every detail. This also helped the QA team build their functionality tests quickly.

As a product owner, I also found that this freed up time I would have spent discussing every feature/criteria with the team. I could use the time to plan ahead on the overall product roadmap.

I found that treating Agile as a concept to be experimented with often gave teams more ownership to play with the process to make it effective in their context, rather than adapting their style of working to suit yet another process.


A version of this article first appeared here.