Is it time for a Sprint?
Sprints in Project Management
One of the first posts I wrote about was comparing PRINCE2 with PMP and something similar and just good old common sense. At the time, I was working with a process-based-methodology, something that my employer at the time had built on the back of PMP.
I weighed up one against the other and felt that whilst PRINCE2 told me why to do something, PMP was better at telling my how to do something but I never really thought of them as working hand-in-hand.
I felt they were independent and that things like Scrum, Agile, 6-Sigma were methodologies that stood on their own, usually used in specific industries rather than specific projects.
As my journey continued, I realised that these methodologies can integrate quite nicely. One of my Clients uses a Waterfall approach to overall project management, but as a software house, they use Sprints to run through the software builds and Kanban to run through DevOps and Platform management.
Sprint product owners put forward some pretty good arguments supporting the use of Sprint in any project, and they might be right, although I would say it is better suited to some types of work vs other types of work.
Better Sprints come from Bigger Challenges
Situations where Sprints work:
- Stuck
- Time
- High Stakes
Sometimes a project just gets stuck and you need to something to give it a kick-start, to get people back into the room and get their focus. A Sprint gets the problem solving juices flowing, it gives you a good kick up the rear end and helps you find fresh approaches with things like brain storming sessions.
Time is another area where a Sprint can help. If you have a particularly challenging timeline, such as a deployment schedule, you need to get your solutions lined up, Sprint is perfect for this type of scenario.
High Stakes, projects can be tricky and they can be costly, getting them wrong is in no-ones interest. A big problem can be overcome with that brain storming session, at least a path can be set, it’s not the answer to the problem, but it get’s people pointing in the right direction.
The Decider
One of the key concepts in a Sprint is having The Decider in the room! This is the person that can approve the sprint. Someone with authority to make decision!
A Decider should understand the problem and ideally have strong opinions on how to address the problem, someone that’s going to throw in ideas as well as challenge the other ideas that are coming in. That’s not to say that their ideas are the best ones, but they need to know how to objectively break apart an idea to make sure that everyone else in the room understands the expected outcome.
If The Decider isn’t in the room, you may find that no matter how successful the Sprint seems to be, The Decider may simply put a stop to it because they don’t think that you’re tackling the right problem! They may be right or they may just be upset not to be included.
If The Decider couldn’t make the entire Sprint, they need to provide a delegate, someone that can make decisions they are allowed to sign-off on and someone that can provide concise updates to The Decider at suitable times.
If your Decider is still not playing ball, then you’ve probably got a big red traffic light right there! The problem you’re tackling is probably not the correct problem. If the problem isn’t big enough to get such a key person to join the team, then you’re probably focusing on the wrong things. Try speaking with The Decider and try to understand their take on the matter, it may help you re-focus or better sell the reasons for the project.
The Troublemaker
Before every Sprint you should take a step back and try to identify The Troublemaker. This is the person that is likely to cause trouble if they aren’t included or don’t see value in the project. Causing trouble can mean a number of things often as simple as disrupting the flow by talking down the project to the remaining team members. This type of activity is harmless enough on the one hand, but it sets a negative environment that can reduce productivity and increase resistance to the project from a wider group of people.
I want to believe that you don’t have this role in your company, but if there is one, get them involved, it only needs to be a cameo appearance, perhaps a Monday morning slot only, but get them involved, make them feel connected to the project, invested in its success. This is especially useful if they’ve had a chance to be involved in the brain storming sessions.
We don’t want them there all week (unless they bring other valuable skills) as there’s actually a key number of people in the Sprint world that helps ensure success, too many people definitely does not help, it actually slows things down. I’ll talk about team numbers in another post.
Another reason to bring along The Troublemaker is that they likely see things in a different way. Let’s imagine you produce awesome-product-x, your team has built the product, sold the product, use the product. They are invested. When people start talking about the v2 of this product, people get excited, they drink the kool-ade. The Troublemaker, might be an amazing developer or facilitator, or even the star salesman, but they will look at the product in a different light to the folks that are personally invested in the product. They may see different solutions, maybe they see crazy solutions that just wont work or maybe they’ll see something that you might want to think about. The worst case is that you have another view point, maybe a couple of wacky ideas, but that person is now connected to the project and their input might be key.
Don’t confuse The Troublemaker with The Jerk, this latter is not going to add value!