When Agile Isn’t Agile

Problem

"I started working as a Product Manager for a company making software for large distributors, such as French supermarkets. A few years before I joined the company they had switched to Agile processes. They thought they would be much better than they had been before but it ended up in a huge mess. This was because they didn't understand Agile at all, so they didn't specify anything, didn't define anything and they would code in production. As a result, there were about 50 people in the product team working on the company's legacy product, and they hadn't been able to do a single release in the last 12 months. While they had tried, each time they had created more problems and ended up with a lot of big bugs."

Actions taken

"In terms of Agile processes, I came to the conclusion that the team was really unprepared for Agile. If you consider why Agile was created and where the methodologies come from, it started as a more rapid version of cascade. Companies normally start out with a cycle of six months to a year where they work on everything. At the end, the product doesn't look at all like what you first required, and it's been a year so the product no longer fulfills your needs so it fails. Often, this is why people turn to Agile. However, using an Agile process doesn't mean you don't have to specify things or test. The team I had inherited didn't understand any of this. I told the team that they had tried Agile and it hadn't worked out, so we should go back to basics and use cascade processes. I then explained once they understood how to use cascade processes, we could move on to Agile. By teaching them the basics, they could then move on to more complicated processes. We went back to two-month planning, which is long for Agile but quite quick for cascade. I was initially like a tyrant about this. I told them I didn't want them to start developing until every single thing had been specified and defined. I pushed really hard for this and did a lot of it myself because, as a Product Owner, a lot of the specifications were up to me. I worked really hard to get back on track so by the next release, everything would be ready for the next development cycle."

Lessons learned

"This worked really well. After the team had shown it could fulfill working releases, I then gradually introduced a bit more agility and flexibility, reduced the timeframes, and started running sprints in parallel to one another, until we reached a much more Agile method of working."