Agile

One team, one initiative

I blogged in April last year about the importance of teams being a ‘cohesive unit’ rather than just a collection of individuals. This post expands on that concept.

Imagine an athletics club with 20-30 members. Those members agree to a football (soccer) match with another athletics club, so they begin working on their football skills, as well as all of the supporting attributes; not everybody will be on the pitch at the same time, so the rest agree to help with things like strategy and tactics, or to be ready to be substituted in when others get tired or injured.

The athletics club in this scenario is a single team, working towards a single goal (‘to beat the other team at football’).

A few weeks later, the club starts playing basketball as well, and they arrange a basketball match with a rival club on the same day as another football match with a different rival club. They have enough people to participate in both, though they will have fewer supporting people and substitutes available.

How should the team respond to having two separate initiatives?

It seems logical that the teams for each sport are decided early on, so that they can each work on practicing their chosen sport, and start working on things like set-pieces and deciding their tactics and strategy for their respective games.

The teams will likely continue to work together at a higher level — they may still be able to help each other in certain areas, or there may be training facilities (like gym halls) that they need to share and co-ordinate their use of.

If this same problem were in software, I know from experience that most organisations would tackle it in a very different way.

If this were in software, the team would continue to operate as one, even when it is anticipated that they will work on separate initiatives for quite some time. They will plan together in a single Sprint Planning session, and synchronise process and adapt plans at the same Daily Scrums.

In so many cases, this simply doesn’t make sense. To have a single team try to achieve two completely separate goals is a flawed approach, because the concept of this being a ‘team’ just doesn’t apply.

A single team can work on different features, but it only makes sense if there is a single goal. For example, a team could work on ‘registration’ and ‘login’ with a common goal of ‘authenticating users’. Even ‘registration’, ‘login’ and a ’shopping cart’ could contribute towards a single goal of ‘allowing signed-in users to purchase products’.

But, when the initiatives cannot be grouped together to solve a common purpose, or ‘user journey’, then it seems unlikely that the work to do them is going to be connected enough to warrant a single team working on it.

When a team is working on multiple goals, they need to ask themselves very honestly if they are still truly a single team, or whether they could be more productive if they were to wholeheartedly embrace the separate initiatives.

There are of course challenges associated with splitting teams, many of which are worthy of blog posts in their own right. There is no guarantee that even a healthy team will survive significant changes to its structure, and even at best a short-term dip in performance should be anticipated.

But greater issues are likely to be faced by smaller teams — it would probably be foolish to split a team of five people leaving “teams” of just two and three.

Final thought: Splitting teams should not be seen as an alternative to effective planning practices or effective Sprint Goals.

Why does your team Sprint?

I was providing advice to a fellow UK-based Scrum Master last week after they came to me with questions about how to help their struggling team.

One of the behaviours that the team was demonstrating was a willingness for items to roll-over from one Sprint to the next, without question or consequence.

This team’s problems are a complex web of bad practices, many of which exist because of their earlier bodged attempts. They have deviated too far from anything that you might recognise as a sustainable agile process, and they now clutch onto whatever is left of their acid-rain destroyed relics from their time of hope.

It raises the question though, when a team is happy with continuous flow (well, continuous ‘chunky vomit’), why are they using iterations at all? What value do they, their business, and indeed their customers get from this way of working?

In Scrum, the Sprint serves many purposes. Above all though, it’s a time box within which the team can creatively and ingeniously craft solutions to complex problems. It gives the team an uninterrupted period to ‘get their heads down’ and work together to build something awesome, and it gives the business a commitment that within a certain period their agreed goal will have been met.

For the business, risk is greatly reduced — no matter how badly things go wrong, they have only lost the duration of the Sprint. There’s no possibility of three months of effort being waste when a fully tested, usable and potentially shippable increment is being produced every couple of weeks.

When you work in a way that fixes scope in a Sprint Backlog, you start to lose the benefits that a time-boxed iteration provides. Likewise, when your focus is on resource utilisation rather than delivery of a valuable working increment you soon detract from the significance of ‘done’, of achieving the Sprint Goal, and ultimately satisfying the customer.

The “continuous vomit" way of working, where you get a stream mirky fluid with occasional chunks of substance doesn’t do anything to control risk, or to protect the team. The ever-growing backlog places pressure on the team to ‘get things done’ rather than ‘to provide value’ (and no, they are not the same thing), and because everybody inevitably becomes obsessed with things at a task level, as opposed to a product level, the product inevitably suffers.

The caveat

“Continuous vomit” is not the same as ‘continuous flow’, although the high level concept is the same. “Continuous vomit” can be thought of as a type of continuous flow, though the water does not run clear so nothing is transparent, and rather than the ‘flow’ referring to valuable work, the ‘flow’ here is a mirky stream of “work” interspersed with unpredictable chunks of value in varying size and colour.

Continuous flow is a valid and acceptable way of doing things, “continuous vomit” is simply disgusting and makes nobody happy.

Who is the Product Owner?

Throughout my career, at some point or another every company that I have had dealings with has struggled with the role of the Product Owner.

I think each Scrum role is confusing for a lot of teams, companies and individuals, but arguably the Product Owner is the simplest one to understand, but one of the hardest to accept.

In simple terms, the Product Owner is responsible for ensuring that the team delivers something valuable. They are not responsible for how work is completed, or necessarily deciding every last detail themselves but they are ultimately the ones that set the direction, manage expectations and generally steers the Development Team in the right direction.

What I have observed as being challenging for businesses isn’t the concept, but rather accepting that this is the best thing to do, and/or actually giving the Product Owner the responsibility and trust that they require to be successful in their role. The Product Owner is one person, not a committee, as the Scrum Guide says — and yet to a greater or lesser degree almost every person I speak to in the agile community tells tales of a Product Owner being second-guessed by their superiors, team leaders, CEOs or even the development team themselves.

When you say to somebody “you’re in charge of steering this car” and then continuously reach over and grab the steering wheel, violently changing the course it’s almost inevitable that the car is going to crash sooner or later, and that in the meantime the path the vehicle takes is not going to be a smooth one.

It is when a development team, or members of a development team, don’t trust or respect the Product Owner that the greatest damage tends to be done. The unity of the team becomes damaged and the value of the work diminishes — in place of delivering value, the team easily starts doing ‘busy work’, choosing to simply do “something” rather than “something that matters” to the users of the product. When teams go down this road it can be very difficult to steer them back on course and in some circumstances it can be very difficult to even identify that this is happening.

When a team is used to doing 30 Story Points of work, getting them to accept that doing just 15 Story Points that deliver 10x the value, even if it theoretically means more down time, is actually better.

The Product Owner needs to be trusted, they need to be allowed to fall over and pick themselves back up without undue pressure or criticism: nobody will make perfect decisions every time.