The Scrum Guide calls sprints the "heart of Scrum" and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.
A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?
Their decision should consider a number of factors including:
For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.
When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.
The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team's productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.
Sprint duration is another case of Goldilocks and the three bears - finding out what's "just right" will take some trial and error!
Managing a high priority project can be a wonderful experience.
You will usually receive ample support from senior leadership in resolving critical issues, getting funding for team celebrations is rarely a challenge, and helping team members and other key stakeholders understand the importance of the project and how its success will benefit them should be simple.
But this is rarely the case. Most of the time, we are working on initiatives which, while important, are not top of mind for your senior executives.
Here are just a few of the challenges with managing such projects:
So what can you do to improve your odds of success?
"You should never view your challenges as a disadvantage. Instead, it's important for you to understand that your experience facing and overcoming adversity is actually one of your biggest advantages." - Michelle Obama
In an earlier article I'd written about the pros and cons of a Scrum Master or agile lead having deep technical expertise in the solution space but what about a Product Owner (PO)?
In their 2003 book, Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner coined the well known acronym C.R.A.C.K. to describe the attributes of an effective PO and the K in that acronym stands for Knowledge. Normally, we consider that this is business or product knowledge, but couldn't it also extend to technical acumen?
Technical expertise is likely to help the PO prioritize the product backlog such that there is a healthy balance between business and technical drivers. In the absence of this knowledge, team members might find themselves spending greater effort in helping the PO understand why certain technical work items are time sensitive from either a risk management, dependency or technical debt reduction perspective.
While there is some benefit in a PO having such knowledge, it comes at the cost of greater vigilance. The PO will need to be disciplined to ensure that he or she is maximizing product value by focusing on the "what" and "why" of the product and letting the team own the "how" and "when". Without that mindfulness, such knowledge could result in a PO who:
With great knowledge comes greater responsibility.
I’ve written a few articles on the risk posed by resource availability to most knowledge-based projects, and I still feel that this is a frequent cause of schedule & budget overruns. Other common risk factors impacting projects include requirements clarity, technology uncertainties and organization change resistance. Finally, project priority is a major source of risk these days – the “star” project that receives funding and focus today could morph into the “dog” tomorrow that is starved of resources.
A more subtle risk factor, and yet one that can be equally pernicious has to do with that unique project role – the stakeholder. I was once told this definition for a stakeholder: “Anyone with the ability to sink your project”.
One tends to think of negative stakeholder influence as a common source of risk to construction or other highly visible external projects, but any moderately complex internal project could also possess multiple stakeholders with competing agendas.
To address this source of risk, the best response is thorough and regular stakeholder analysis. If you are not sure that you have identified all of your stakeholders, seek advice from a peer or mentor. Meet individually with your stakeholder representatives early on and reinforce these relationships throughout the lifecycle of your project. It may be naive to assume that you can satisfy the needs of all of your stakeholders, so your objective should be to manage the impacts of their influence on your project. If it is not possible to work towards a “win, win” situation, you may need to solicit assistance from your project sponsorship or other stakeholders.
Project teams working on high stress, aggressive time line (is there any other kind?) projects tend to focus on their customer or their project steering committees. This myopia can be fatal – stakeholder influence is perhaps the best example of Dr. Hillson’s definition for risk: “Uncertainty that matters”.
(Note: I wasn't blindsided when I wrote this article in January 2011 on kbondale.wordpress.com)
I’ve written previously about the need for a project manager to proactively plan for a smooth transition if someone else will be assuming the role on one of their projects. Should you be fortunate enough to find yourself taking over from a project manager who has followed some of those suggestions, it will make your life easier.
But often we don’t have that luxury.
When projects get into trouble, rightly or wrongly, the project manager may have been identified as a convenient sacrificial lamb and you might join the project after they have been expeditiously shown the door. Other times the individual might have just been moved to a different, higher priority project but they did not maintain a complete, accurate project control book or they may simply not have the time to help with your onboarding.
In such cases, what should you do?
Meet the sponsor
Even if there are documents such as a charter or project management plan, there’s no substitute for learning about the needs and wants of your sponsor as early as possible. Developing a productive, symbiotic relationship with this critical stakeholder will often make the difference between success and abject failure.
Make sure you take the time to understand what they expect from you from both a communications and expectation management perspective, but also gauge their willingness to support you when decisions, issues or risks have been escalated to their attention.
Meet the team
Recognize that the team will be experiencing the change churn of having lost a leader.
If the previous project manager was despised, you will bear some of that baggage and will want to ensure that you don’t get drawn into a comparison competition with your predecessor or having to defend the value of project management. On the other hand, if the team adored their project manager, you may face suspicion and resentment and will have to avoid the temptation to become defensive about why you were placed in the role.
Be curious, ask questions, but most important, strive to be a servant-leader, giving the team some time to grieve but also demonstrating your value by escalating or ideally removing any hurdles that have hampered their productivity.
Trust but verify current state
Status reports, feedback from the sponsor or the team might provide you with insights into the project’s state, but seek evidence that supports their assessment.
Identify recent milestones and confirm that different stakeholders agree that those have been successfully met. Once you understand what milestone is coming up, check with the sponsor and team to ensure that there is alignment towards its completion. Ask questions about the top three risks and issues. Check the financial health of the project with your finance partners to ensure the books are in good shape.
While a project plan might exist for your project, you should still create a personal onboarding plan reflecting the specific activities you will need to complete to be effective in your new role. Treat this role transition as you would any meaningful project – plan the work, and then work the plan!
(Note: this article was originally published to kbondale.wordpress.com in January 2017)