login


Google Sign inLinkedIn Sign in

Don't have an account? 

When Agile Isn’t Agile

Underperformance
Team processes
Productivity

28 June, 2018

Cedric Laruelle discusses a team he was put in charge of that didn’t understand Agile processes at all and, as a result hadn’t done a single release in 12 months, and explains the approach he took to get them back on track.

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..


Related stories

How to Effectively Communicate on Slack
6 July

Shridharan Muthu, VP of Engineering at Zoosk, discusses effective communication using Slack including a recommended framework that entails three simple tips to make the most of the tool.

Internal Communication
Remote
Productivity
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

Handling a Mistake - Adopting a New Workflow
6 July

Shridharan Muthu, VP of Engineering at Zoosk, describes how he quickly agreed to adopt new workflows, a mistake he later regretted, and how he handled the situation by spending the time to course correct and taking a stab at making things easier for his team.

Team processes
Agile / Scrum
Collaboration
Shridharan Muthu

Shridharan Muthu

VP of Engineering, Backend Applications at Zoosk

What We Learned From Running Open Spaces
30 June

Jeff Foster, Head of Product Engineering, highlights key learnings from his experience of running open spaces and if and how it contributed to an increase in innovation.

Company Culture
Productivity
Impact
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

Some Ideas for Breaking Down Silos In Your Organization
30 June

Jeff Foster, Head of Product Engineering, shares how he managed to break down silos in his organization by encouraging their employees to choose their own team.

Team reaction
Managing Expectations
Company Culture
Internal Communication
Collaboration
Productivity
Reorganization
Jeff Foster

Jeff Foster

Head of Product Engineering at Redgate

How to Identify Root Cause of an Application Failure
30 June

Murali Bala, Director, Software Engineering at Capital One, outlines how he applied a root cause analysis to fix a recurring outage of their website.

Dev Processes
Leadership
Productivity
Murali Bala

Murali Bala

Director, Software Engineering at Capital One

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.