Iteration Management – Post #13 – Involving stakeholders
This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.
If I could pick one thing that will most impact whether your project will be successful, it would be how well you work with your stakeholders. I don’t know how many times I’ve heard people say that they key to their team’s success is the involvement of a good product owner from the business. As an iteration manager, your responsibilities might include working with stakeholders to involve them in the process.
Product owners
When I refer to a “product owner”, I’m talking about one person in the business who is the primary person to make decisions about the project. While you will likely get input from many people in the business, the product owner is the go-to person who will make decisions when people disagree and make sure that you are getting the information that you need.
What happens when you don’t have a good product owner? Any number of things.
- Getting behind because you’re waiting for answers
- Lack of detailed requirements
- Lots of requirements changes due to people changing their mind
- Getting conflicting messages from people in the business
That’s not to say that you won’t be successful if you don’t have a good product owner, but if you don’t have one, there are a lot more things that can go wrong.
Here’s what I tell management when we don’t have a defined product owner: requirements have to come from somewhere, and someone needs to answer questions, fill in the details, and settle disputes. That can either be someone in the business who has the knowledge and ability to make those decisions, or it can be people on the development team. I don’t know that you always want developers making decisions about how things should work, and I don’t think developers really want to do that either.
Often times I’ve seen a BA end up being the de facto product owner. If you have a good BA that really understands the business, this is probably your best choice if you can’t get someone from the business to step up. It’s still a risk that should be monitored and mentioned to the people who are paying for the project. You can write the best application in the world, but if you build the wrong thing, it was all a waste of time.
Iteration planning
If you’re working within the context of iterations, you’ll want to meet with people in the business before the iteration starts so that you can discuss the project and let them decide what you should work on. This is also a good time to ask clarification questions and make sure that you have everything that you’re going to need to do the next iteration’s work.
How you do this is up to you. Maybe you have a scheduled meeting before the iteration, or maybe you have a backlog of tickets that the business keeps prioritized. It really helps if you’ve estimated the work before you do this exercise so that everyone understands how what each feature is going to cost. Maybe they asked for something but when they realize how hard it is, they might decide that it’s not worth it anymore.
Even if you’re on a project where all or most of the work was scoped out before the project started, it’s still a good idea to have this meeting. Things are always changing, so the business might have different priorities now than they did a few months ago.
By letting your stakeholders choose what you work on, it involves them in the process and lets them have some skin in the game. If you’re not involving the stakeholders on a regular basis, they might assume that everything is going great when in reality the project might have all kinds of problems. At some point those problems are going to surface, and the sooner you can make people aware of them, the sooner you can work together on a solution to get things back on track.
Handling changes within the iteration
Even if you have short iterations, things are going to come up during the iteration and the business might want to change things mid-iteration. Some teams might find this annoying. I find it necessary. Successful businesses able to adapt quickly and respond to change quickly, but if IT is unable to keep up with the changes, then IT is keeping the business from being successful.
That’s why I welcome people asking if they can bring something new into the iteration – provided that they take an equal amount of work out and that they understand the impact of the change of focus (for example, if they want to remove something that is already half done, they should understand the impact of having the development team stop working on that feature). One of the reasons I like having a physical board instead of an online tool is that it’s much easier for business people to do this because they can just come over on their own and see what’s available to swap out for new work.
I love seeing this happen because it means that people in the business get it. I love when they come over and say, “We have this issue that just came up, can we swap out these two tickets for this new one?” I’m sure they love being able to have that level of control, and the development team can adapt to the change without having to get slammed with extra work.
Demos/user acceptance testing
Towards the end of the iteration, take some time to do a demo for your stakeholders and show them what you’ve been working on. This lets them know what you’ve been up to, and it also gives you (and them) a chance to make sure that you built the right thing. Maybe you even have some users try out the new functionality see if they’re able to do what they need to do. This feedback is essential because it’s so important that we build the right thing and that we build something is going to make the users’ life better.
How many times have you had an app on your phone that you really liked, but then a major update was released with UI changes that made the experience worse? I’ve had this happen multiple times with apps that I liked, and most times it led me to uninstall the updates or switch to another app altogether. You don’t want to do this to your users. It’s not about you or building what you want to build, it’s about what they want and what they need to do their job.
This stuff is important!
Your user base is hopefully very interested in seeing your project succeed, and if you can develop a good working relationship with people in the business, everyone will be happy in the end.
My current project has a very strong project owner. She is very involved in the process and is very in tune with everything that is going on, both on her team and the development team. She’s always willing to make decisions when the development team has questions and actively manages the backlog of work for future iterations. As a result, we’re able to get a lot of work done, and the users have been very happy with the outcome, and that might just be the most important part.
Read the next post in this series, Keeping up.
