From Agile to Fragile: How to unravel your team in one sprint
Some context: In February 2017, we started a 3 week sprint with our whole team of 7. We wanted to break all the rules of manager development: no learning needs analysis, no programmes, no cohorts, no schedule, no top-down design, no trainer, no waitlist. We wanted to apply all the core principles of Agile, including putting the customer (managers) at the centre, making decisions based on data, and rapid prototyping of solutions. Our mission was getting what managers needed, when they needed it, easily. This required a complete rethink of how we identified managers using HR data, used mobile-first tech tools, curated and created digital content, and made space for conversations — all at low cost with an in-house team …
All the signs told us we were working in Agile. We had a Product Owner, a Scrum master and a multi-skilled team of experienced people. We had all the meetings running: a planning session and daily stand ups, an upcoming showcase and retrospective. We were using our usual tech tools.
But it felt all wrong.
The team energy was low and there was very little self-organising. Communication on Slack, our real time chat tool, dried up. The Product Owner was obviously feeling frustrated and so were the team. We noticed an unusual new behaviour of people waiting for work to be delegated and then approved by the Product Owner. The Scrum master was watching it unfold with horrified fascination. It was like months of disciplined fitness training unravel in one all-you-can-eat buffet, open bar weekend. Except no one was enjoying the experience.
How had six months of Agile team brilliance unravelled so quickly?
With a little navel gazing, we found 3 loose threads:
1. Start-up products need limbering up
Up to this point, we had been working with mostly stable products — products we knew well, customers we knew, stakeholders we knew. Our focus had been making the product better, faster-to-market, more valuable. This time it was more like a start-up product. It was unfamiliar in almost every way. The path ahead was unclear, including how to approach it. Everyone on the team was drafted onto it because it seemed so big, but this was also the wrong thinking. Without clarity around the sprint goal and prioritisation, it just meant lots of people putting in maximum effort for minimum progress most of the time.
How to sew it back up: We learned the hard way how important a discovery phase was. People need time to understand the concern and the customer, before exploring product solution options. Without this research, the team was flying blind and will flock to the person who appeared to know the most. We now have a discovery phase built into every sprint, even if it is only one day. Go slow to go fast. We are also getting more selective about who and how many people work on each sprint. A small, cross-functional team can stay connected and navigate complexity more easily.
2. Get your roles straight
The domino effect of a start-up product with an unclear scope, was that we found ourselves confused about roles. Who was the Product Owner really? There was a senior person who had set the overall product vision but she wasn’t involved in the day-to-day sprint (in Agile they call these HiPPOs [1] — Highly Paid Person’s Opinions!). What if the person acting as the Product Owner is also a Subject Matter Expert (SME)? Can they detach themselves from the ‘best practice way to do things’ enough to be customer-centric? Probably not without data! When a product is new, how do you involve multiple stakeholders without slowing momentum?
The end result was confusion. The brief changed frequently, the boundaries were vague so people went off in all sorts of creative directions (this is waste!), and because of the time pressure it became more about the Product Owner giving instructions and delegating tasks. It more closely resembled a typical define-design-deliver project. On top of that, multiple stakeholders kept adding their two pence worth, so the team didn’t know which way was up. In the end, the team got a worthy product out the door for the customer but it was a painful experience for everyone.
How to sew it back up: The key priority is to get real data that help everyone understand the customer need as early as possible. Because in our world we have the PO/SME role overlapping, this becomes the first priority. The discovery phase of our sprints, which are now non-negotiable, provide the clarity for creativity to flourish. The data also helps manage the HiPPOs. They can define the high level vision and decision making principles, but the end solution needs to be owned by the team in service of the customer.
3. Planning is hard when you don’t know what you’re doing yet
We had been starting all sprints with a goal and doing a full planning session to kick things off. Planning for us is 1–2 hours with the whole sprint team, discussing the sprint goal with the PO, and mapping all the tasks on our Trello board. This approach worked well for our stable products. But when the solution needs to be designed iteratively because it’s unfamiliar and untested, planning all the sprint tasks on Day 1 results in lots of change and wasted effort.
How to sew it back up: You guessed it: a discovery phase in the sprint. We have smart people in our team who learn fast and are passionate about what they do. We just needed to build in some time for them to get the information they need to produce something our learning customers’ value. It’s like a research phase. As soon as they get the data and because they are experienced learning designers, they can build a plan on Trello very quickly. Importantly, this plan has minimal waste.
Believe it or not, all of this happened in just three weeks. And to the full credit of the team, as the deadline loomed they pulled rabbits out of hats to ensure a quality learning product got to the customer. But it took its toll and left everyone feeling more fragile, less agile.
The good news is we immediately went into two new sprints the week after. This time the team was so aware of what they didn’t want to happen, they all became role models for Agile.
We were back.
[1] The author of this article was the HiPPO referred to in this sprint. Writing this has been part of her own learning experience on how to be a better sprint sponsor!
