When Agile Isn’t Agile
28 June, 2018
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.
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.
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..
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Yang Wang, Engineering Manager at Bond, shares how she coached several women engineers in her team to boost confidence and help them grow in their careers.
Engineering Manager at Bond
Angel Jamie, Chief Product Officer at Yayzy, recalls his transition from a well-established tech company to a sustainability startup, and the major differences he experienced.
CPO at yayzy
Rachit Lohani, Head of Engineering at Atlassian, decodes the positive changes he made to the company's recruitment process by getting into the crux of the issue.
Head of Engineering at Atlassian
Rachit Lohani, Head of Engineering at Atlassian, shares all his ideas and principles on providing feedback and avoiding discomfort while doing so.
Head of Engineering at Atlassian
Joëlle Gernez, Vice President, Engineering at Pinger, shares how having visibility on the processes that engineering teams work on is crucial.
Vice President, Engineering at Pinger
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.