Recently received this email from a fantastic gentleman who runs an Engineering team in a wonderful part of the world (let’s call him Bob). Bob is facing some challenges with the business side of the company who is his customer:
- Business wants hard deadlines for completed functionality. However they do not provide clean and concise scope / acceptance criteria. Further, they struggle with the concept of iterating to a solution and just want it now.
- Lack of understanding from the business about the level of effort required to be a successful Product Owner. The business is the customer and the customer can not articulate their vision (perhaps they believe we should read their minds).
- The business can not focus, going from one thing to the next before Engineering has had a chance to complete the first item.
It’s great to get emails like this as it just reminds me we’re all struggling with many of the same challenges. For instance, I’m having a similar conversation with another fine gentleman (Steve) in another part of the world, at another company. The key difference is that Steve is on the other side of the equation. Steve is the business side that is struggling with an Engineering team which can not deliver.
I wanted to share the two sides, as told from different people at different companies, as they are useful in helping us overcome these shared challenges.
So, Steve is on the business side and can’t understand why the Engineering team just doesn’t deliver what he wants, when he wants it.
Steve and I walked through an exercise where I asked him for all of the requirements he wanted in his “2.0” release. He rattled off several things, and then started out on some more. I asked him why they were important, what he was trying to solve with each.
All the while his Engineering team is struggling – they hear “go this way”, “no, go that way” and never feel like they have clear direction or a vision. So, I continue with the gentleman (who should be wearing a PO hat, although is a business owner so “doesn’t have the time”) and ask him to order the top three things he wants, out of that long list of ideas. Steve does so.
I want to confirm with him – “are you sure these are key to 2.0?”, I ask. Steve says that yes, that is what he wants for 2.0. I explain that he hasn’t mentioned the UI/UX rewrite the team is currently working on, nor has he mentioned X, Y, Z from the teams backlog. “So why are they working on all this stuff which is nice to have and not valuable?” I ask.
Steve hasn’t noticed that he is pushing the team in a different direction every day. He hasn’t noticed that the vision has not been set, or communicated.
In that situation, and I’m sure this is similar to Bob’s, there is a lot going on. The business folks have a million things they want, but there is only one thing top of mind at the time you speak with them. So it looks like they have no vision. I asked Steve to write the release blog for his 2.0 – what would he like it to say, how would he pitch it to his clients, etc.
This was a forcing function to get Steve to consider the scope for his 2.0. It was a release planning exercise in language he understood – a blog post, not a backlog.
Now I’m not sure how successful this approach will be at every company, for every team. I do hope that it provides the business side an understanding of what is involved in being a product owner and setting a vision. Of course you can also use this as a tool to define scope for a release – if/when the business comes back to Engineering and adds something to the list you can respond with “didn’t we agree last Tuesday to do X, Y, Z first, and then move on to other items?”. Don’t let agile be an excuse for less discipline, more WIP, and less value being delivered.
Be agile. Be smart. Help the business side, or your customer, have some discipline and get value early and often. We need to educate our customers as much as we need to educate ourselves.
Got thoughts or suggestions for Bob or Steve? Share them in the comments below.