Agile is fun and all, but what about projects?
- Richard
- Jan 24, 2020
- 6 min read
You've made it! You've got your company convinced and working agile, you even got some customers and suppliers working agile now. Great job! But we're not done yet. Let's zoom in on how to run projects in an agile environment.
Traditionally, what roles do you have in a project? You've got the salesperson who promised more than you can deliver. Then there's the buyer who won't budge when choices need to be made about deadline, scope or money. One or two project managers who are nothing more than smooth talkers when things go south. Your suppliers account manager who tells you they did what was expected, and if not you have not been clear with them. Oh and let's not forget about the workers who are always working on other projects than yours. Yes, I know, I'm a bit harsh here. But isn't this what most of the bigger projects feel like? Don't even get me started on projects that are so big we need project managers for your project managers.
Now your company has a few of these projects running, and you have a fancy scrum team for your workers. Now, if you were to sit right across from me, look me in the eyes and said these don't interfere with each other, I would have a hard time believing you. Because your project has a deadline, and you tell your product owner what needs to be done. The business analyst will take a look at it, and tell you it's way more work than what's been sold. The product owner will tell you they'll do their best, but running with the other projects and deadlines and this being more than expected, you're most likely not to make it. So you duck for cover and hope for the best. somewhere halfway through the project your customer will ask you for a status update, and you will ask your product owner. He explains he's behind, and you explain again how important this project is, than you smooth talk things over with the customer explaining things aren't as bad as it might seem. The deadline is coming closer, and you start upping the pressure on the product owner, you even pass him sometimes and put some pressure on the workers themselves. Still acting like everything's fine to the customer, there's just a little hiccup, nothing too serious to worry about.
Does this all sound familiar? It can be really demotivating for everybody involved. The customer isn't getting what was promised. The workers feel bad and pressurised. The project manager worries himself to sleep, feeling like she's the only one going for this goal. The salesperson getting a call this wasn't what he promised. So nobody ends up happy with situations like these. Unfortunately they happen all the time, but thankfully most project manager have found ways to make them less bad.
Still acting like everything's fine to the customer
Let's try combining some of the best practices from both project management and scrum to see if we can be more agile and less demotivated. What if you break up your scrum teams that are basically departments and instead call your project team a scrum team? And while you're at it, why don't you do this before anything's been sold. The customer shows interest, that's great. Let's get a team together to work out some kinks. Let your business analyst work with the customer to see what exactly she wants, let your business analyst work with your workers to see if it's at all possible and to get estimations on how much work it would be. Then let your product owner see where it would fit in the schedule. Now get everyone together to decide on the scope, the deadline and the costs, and then sell it. You've now managed to set the proper expectations.
There's a good chance this project will be in the freezer for a while until there's room to work on it. Close to when you're about to start working on it, get everybody together in a quick call again, and remind everybody what you're doing and why you're doing it. It's always good to fresh up everybody's memories so when the start date comes, nobody has to read up on it anymore. Because one quick call versus 5 or 10 people reading up on it, saves a lot of time. This is also a good moment to see if the start date is still viable. It is really important to include the customer in these calls, they need to be part of this project as much as you are. I suggest using this call to set up a schedule as well, would it be possible to have a little digital stand up every day around noon when we've started? Great!
Things are already looking a lot smoother, everybody's invested because everybody's part of it. Now let's take a look at the reviews, one of the two most important meetings scrum tells us to have. The review is where you get your feedback on the product, or in this case the project. Sure you can set it bi-weekly, just like your sprints. But does that really make sense? I say add it to your daily call, if something is done, please let the customer touch it, get your feedback and discuss what to do with it. The second most important meeting is the retrospective, which is about feedback on the people in the project. This one I wouldn't do in every call, you can do it weekly. Bi-weekly might be a little bit too long, because you easily forget things that happened before the weekend. Inform your customer that this is a free speech, open opinion, safe meeting. So even the customer can be told you don't like something they're doing, if she's open to this, it will only improve the project and your bond as customer and supplier. In all these meetings you need to be transparent with your customer and your customer needs to be transparent with you. The truth will find its way back to you one way or another.
As in any project, things can come up. People might get sick, unforeseen technical debt showed up or the customer wants to add things to the scope. There's a lot more what happen, but it's important that this becomes obvious during your daily calls. This allows you to have an open discussion with the customer, who sees it happening out of anybody's influence, about what to do next. Should we add a phase two? What would that cost the customer? When would you be able to do that? Should we drop something else from the project? Is it possible to add more resources? All valid options to consider, as long as you consider it as a group. Who knows, maybe because people are so invested in this, they might even offer to work late in exchange for a pizza. Personally I'm not a fan of juggling with different projects. Like when one needs more resources, you steal some away from another, because that one has more jiggle room only to see that project become a problem later on. If a project stalls, needs more resources or whatever it needs, that is the issue of this project and it needs to be resolved within this project. If you've done anything as I've told you, the customer will be understanding and willing to help offer solutions, even if it might hurt them. This is especially true when people are in multiple projects, or scrum teams, because taking something from the other project will impact themselves.
I know I did not propose any unique idea here. A lot of these ideas are actually being used already. The problem is, they are being used too late. When things have already taken a wrong turn, these ideas are being used as measures to calm the angry customer and to save the project. All I'm saying is, start doing this from pre-sale until after the project. Sit down afterwards, ask everybody how he or she felt during the project, and if the project feels to be a success. This is the most rewarding experience, where you will find kindness and humanity.
Comments