Phil Kan (philxan on twitter) recently sent in a problem to the The Agile Revolution problem bag:
We have a Product Manager who’s supportive of Agile in theory, but won’t do the work we need him to do. How do we manage that?
A few tweets later we learnt a little more…
They aren’t available for the discussion of stories (often away) & the highest priority work is the customer who screams the loudest. Rather than product progression, we do a lot of tweaks and minor bug fixes. We do showcases after each 2 week sprint (a release is usually 3 sprints). Are we just expecting too much from our customer?
Because we were running incredibly over time there was a little skimming of the issue and I wanted to take some additional time to cover off a few points that we might not have been awfully clear or comprehensive on.
The stance –
- Craig: Do you have the right person?
Is this really the right person as your Product Owner? Is someone more suitable that can give you the time that you need? - Tony: Stop working on the product.
If they can’t give the time then they are obviously not committed to the product. By stopping work on it (tools down) you are testing their commitment. If they are upset that you are no longer working on their product then as calmly as you can explain that they need to provide more time in order for you to reach your goals. Ask them the question “If you wanted a renovation on your home, would you just hire a builder and say ‘Do what you want, I’m sure you’ll get it right.'” My concern is that sometimes commercially this is not a viable option.
- Consider moving to a Kanban method rather than using Iterations (which was my second thought five seconds after tools down). I hear a lot of complaints (and more of them from product owners) that say Agile has too many meetings. Kanban has a more natural flow. You can still release every six weeks if you want. Or just release whenever now. Yes the product owner will still need to groom the backlog and provide details for you to build off but this is now on a more pull basis then scheduled.
- Replace your product owner with your true end customers. This is really an extension on the above thought. If you move to Kanban you can setup a regular cadence with all of your customers at once and groom/define stories in the backlog. David J Anderson talks about this process a bit in his Kanban book.
- Consider shifting to three week iterations. If the complaint is that there are too many meetings then three weeks will reduce the number of meetings over time, but in reality this is more of a perception. Don’t get me wrong, perception trumps and if they think it is better, even though it is the same then it is win-win.
- Conduct a root cause analysis. Gosh we are so bad at this. Look at how we all initially reacted. Solution, solution, solution! Now in fairness, if you give a problem in a single tweet you are only ever going to be able to go straight into solution mode, but spend some time being frank with your customer. Call the spade as it is. Explain that it is an issue for the team, but that you want to work with them (the product owner) to find a resolution for all. Get to the depths of why they cannot provide the time. Get to the depths of why you need the time. If an understanding can’t be made then maybe look at the solutions above.
Agile Forest 
As at the time of writing the podcast isn’t up yet. Fingers crossed it will be up later tonight.
Did any of this help Phil?
Hi Renee,
I think your post describes a company that is only Agile because everyone else is Agile. It is following the methodology, but when it comes to the human work involved in making the methodology work, nobody (in this company) is really practicing Agile.
What’s the point of having user stories if those who should be involved are not even there?
PS: Check point #5 in this article, and I hope you’ll get the chance to comment…
Howdy,
I cannot comment on the company as it isn’t mine. That leaves us with only the fact that the customer seemingly cannot give the time.
I would argue any methodology would have issues with this problem. In fact I have seen it first hand in waterfall whereby the developers and the business analyst weren’t given any customer time and just made up a solution (all 200 pages of beautiful requirements were nicely signed off and contractually expected to deliver, regardless of the fact that part way through delivery they didn’t make sense anymore). It was incredibly fun from a development perspective, but at the end of the day how useful was the product to the end user? It cost $6m to deliver and cost the same to re-factor afterwards to be usable.
What is the point of having a requirements document if no one will sign it or take accountability for it? It is the same problem just with a different doona on it.
I know Agile has weaknesses. It’s biggest weakness is the same one that plagued Waterfall, and RUP, and WUP, etc. It’s called chaos. Where people don’t know what they are doing or how they are doing it and they have limited feedback cycles included to course correct. Agile fails when chaos begins and the chaotic elements are stopping the feedback cycles.
No one I think would say that Agile is a methodology. It is a framework. For me I take Alistair’s stance on it – it is a reflective improvement framework.
From the problem one person is not playing the game. I won’t conclude that it is a systemic cultural adoption issue from a single tweet.
Thank-you for popping in and I appreciate your thoughts.
This is definitely one of the more frustrating aspects of Agile – dealing with a customer who doesn’t buy into it.
My personal inclination is to go with Tony. A software development project is an expensive exercise. By not providing the necessary time, the stakeholder is ensuring that there will be rework and waste – it just doesn’t make economic sense to proceed on a project without a stakeholder who commits. Still, good luck with that approach… I’ve never seen a project where that is a politically viable approach.
The root cause analysis may show up something, but if it doesn’t then this is where BAs get to earn their money and become true customer proxies. Send the BAs away, have them work embedded with the customers for a couple of weeks and learn the domain, then bring them back to represent the customers. They’ll develop a stronger understanding of the problem space, establish good lines of communication, and work on building trust. They can also bring representatives of the development team in to discuss feature ideas and bugs at the convenience of the stakeholder – which leads to more trust and better communication.
One possibility I didn’t mention is that the stakeholder may simply not have enough time themselves. They may simply be swamped with their normal day-to-day work, and not be able to free up the time required to be an effective customer. This would be particularly common in organisations or departments that do not provide themselves enough slack – and it is precisely these areas that may want to just throw money at the problem to make it go away.
If that’s the situation, I would definitely go with the customer-proxy route, but focus on clearing up small-but-time-consuming problems first. Like scaffolding on a work site, this wouldn’t be the end goal, but would be used to _make_ some time available.
Good point Robert. The BA proxy is definitely a possibility but it is potentially just shifting the problem.
It is along the lines of Craig’s point – a proxy might be the right person to be the product owner.
Hi Renee,
Sorry for the late reply! As you know, life gets busy: work, kids, cycling to the Gold Coast… you know… 🙂
Yes, some of it was useful, and interesting. I’ll try to answer a few of the questions raised, and clear up a few points.
Firstly, our customers are spread all over the world. Getting them all into a single room would be impossible, and I suspect they would also be unwilling, given the commercial sensitivity of their operations. Our Product Manager (ProdMan) acts the BA, trying to see the patterns that emerge from customer requests, and passing those onto the team to develop. In this way, its partly “greenfield”, but not entirely – there is a lot of maintenance thrown in with the new stuff.
As for the team, we are essentially pioneering agile techniques in the office, and in company (we also have offices overseas, and the company has a number of products). We are all experienced developers, all with at least some agile experience, most with quite a bit. The comment about education, and how well it was “sticking” with the ProdMan made sense here. When he’s back next (away this week, again!) I think I’ll interview him on what he thinks his responsibility is to the team – where he fits in to the picture. It will provide some insight into how he views his role.
The Development Manager (DevMan) does act as a proxy product owner to the team. More and more, he is being drawn into customer facing roles too and so is spending less time with the team. He does have a very clear view of where the product should be heading, and communicates it clearly. Where he’s unsure of priorities or direction, he confers with ProdMan, and feeds that back to the rest of us. Incidentally, we all sit in the same open plan room – devs, qa, DevMan and ProdMan – and when we are all here, it leads to a good deal of discussion and reassurance (as devs) that what we’re working on is the right stuff.
The best thing I think I took away from the podcast however was the discussion on kanban, particularly as it relates to maintenance projects such as we’re working on. Being the “devman in training”, I have certain influence here, and will look at it more closely. I’ve read some things about kanban, but never experienced it. Time to hit those blogs and papers you mentioned!
Thanks so much for this.
Regards,
Phil
(BTW, its Kan as in kanban, although the origins are different!)
I am still amazed at how some CIOs are fooled by the lure of ‘agile’. They have absolutely no clue as to the permanent wounds that will be left in an organization once the genie is unleashed. Fantastic developers become disgruntled coders. Lazy coders become… well actually they stay the same. And mediocre programmers become lazy coders.
Check out this hilarious video as to why a CIO would even consider agile in the first place.
John