Iterative insights
The great thing about Agile is that you’re constantly measuring, learning and changing. It’s about following the data that drives every decision. Which unfortunately means that the be-all-and-end-all Agile guide for non-techies published at the 6 month mark, is out of date a few sprints later!
Constantly learning and improving. It’s a good thing.
So here are three small but important updates we’ve learned since we wrote that first series. (To make sense of this, you’d probably want to have read the ‘How to become and Agile Team’ series).
1. Research. Research. Research
That dastardly data-driven design approach.
We had a really interesting sprint (a sprint is a short time-bound period to complete a clearly defined goal or output) which highlighted a need to kick off any new ‘product’ or solution with a research phase or sprint. We wrote an article on that too. Check it out here. In summary there were a few painful learnings to share.
The research sprint (or discovery period) doesn’t need to be long, but it needs to give the sprint team enough time to understand the problem from the customer’s point of view and therefore the scope of the issue. An example of this could be interviewing potential customers to find out if your hypothesis about them is true. Just five people should give you enough to spot a trend (see Sprint by Jake Knapp) You can then pull together a research summary that targets and confines the scope of the problem.
Without this team research or discovery phase for a new product, it never really becomes the team’s challenge, as requirements are filtered through the Product Owner (this is the person fighting the cause for the output). If the team sees this as someone else’s problem, they’ll never really own the solution. If they don’t own the solution, they’ll just end up going to the Product Owner (PO) for more direction and confirmation…
And this means no empowerment or self organising team. Therefore no Agile. Cause and effect. It’s really that stark in our experience.
2. Over-planning problems
Over-planning may mean unpicking
In the main article, we’re pretty strict on saying that you need to plan out all the tasks for a feature at the beginning of the sprint (a feature is a bucket of work/ output). In theory this sounds pretty sensible.
In reality, understanding grows and requirements change.
So we’re now more relaxed about this, and it’s in the hands of the sprint team as to how much is planned up front. Usually they plan the tasks for the first or most important feature, which could even be the research phase if it’s not been done yet. The rest of the tasks will naturally build out during the sprint once more is known, or the sprint deadline gets closer!
This puts the onus back on the team to own the state of the board and keep it tied to the sprint goal or bigger picture (we use a Trello board to track the progress of work in the sprint). It also means less waste. We used to spend a lot of time mid-sprint changing tasks and unpicking features that we simply didn’t understand at the beginning.
3. The Problem with POs
We love a good PO, but it’s a tricky, tricky role.
In our main article, we brazenly said anyone could be a Product Owner. And that’s true to some extent, if you have someone close to the customer segment and who understands their requirements. For example, a Graduate Experience Manager if you’re focusing on graduate development.
One problem we’ve faced in defining the PO role is when the product or solution cuts across segments of the organisation. In the Learning & Development world, an example would be for something like Manager Development where there’s no clear business owner who can represent them all. So at times we have to assume the role within our team given its expertise on the subject matter. But, staying impartial is really hard. The PO needs to be the window into the customer which means being clear on their requirements and clear on why the product or solution is a business priority.
Having someone within the team assuming the PO role makes it doubly hard for that person to be impartial and not get sucked into just approving their own view of what the solution is (or could be).
This is even harder if they’re a particularly engaged PO. Yep, you read that right.
The problem we’ve seen is that the PO can, through no fault of their own, allow people to fall back into that old school notion of hierarchical decision making. We’ve had sprints where the PO is helpfully ever-present, however the result was the team slipped into deferring decisions, risks and judgment to them. Why do you need to take risks when you can just ask for guidance.
This unfortunately leads to a place where the team isn’t empowered, self-organising, or maxing their creativity. And therefore not very Agile.
The solution? We now simply encourage our PO’s not to join in the daily standup calls unless necessary.
If the team need the PO, they can get in touch. If the PO needs the team, they can get in touch.
They’re a family friend, not family. Harsh but necessary.
Trust in the team because they’re a collective genius.
More learning to come. And probably sooner than I think..
