Easy in theory, difficult in practice

by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Defeating the multitasking monster

Just because you have information radiators doesn't mean senior stakeholders will review them!

What's the right sprint length for your team?

There can be only one (and it is not YOUR project)!

A camel is a horse designed by a committee

What's the right sprint length for your team?

Categories: Agile, Risk Management

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:

  • How "new" the team is
  • Their delivery process
  • Constraints on their being able to complete product backlog items
  • The maturity or capability of the team to disaggregate work items to a small enough size so that they can complete multiple items in a sprint
  • Expectations from the stakeholders who will participate in sprint reviews

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!

Posted on: May 05, 2019 07:00 AM | Permalink | Comments (7)

There can be only one (and it is not YOUR project)!

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:

  • Getting and sustaining senior leadership commitment and support is going to be much more difficult. Even your sponsor might have more important projects to support.
  • Keeping your team focused on delivering the project's scope, especially if they are also working on higher priority projects is a constant struggle.
  • Ensuring that functional managers remain responsive to changes in staffing needs and providing you with the "right" staff to get the job done won't be as easy.
  • Securing funding for more than the absolute bare minimum is tricky - especially contingency reserves or budget for team events.

So what can you do to improve your odds of success?

  • Practice effective, full life cycle risk management to reduce the number and impact of unpleasant surprises.
  • Consider using an incremental delivery approach so that your sponsor and other key stakeholders achieve an early and progressive return on their investment.
  • Spend extra effort emphasizing the holy trinity of purpose, autonomy & mastery to inspire your team members to do their best.
  • Double-down on team development through free or low-cost events and simple, but regular recognition of individual and team efforts. Help your team to identify the rituals and working agreements that will define team culture.
  • Have a "Plan B" handy so that if your staffing complement or funding gets slashed the team will still be able to deliver something of value. Wherever possible, structure your scope delivery to deliver higher value work packages early.
  • Take the time early in the life of the project to develop positive working relationships with the functional managers who will provide the staff for your team. Explore opportunities to help them achieve their goals through your project's success. For example, if they want to raise the competency level of their team members, identify stretch activities or other learning opportunities within the project which might address this. If you can earn some IOU's early on with these functional managers, those will come in handy down the road when you'll need their help.

"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

 

Posted on: April 28, 2019 10:12 AM | Permalink | Comments (13)

How much technical knowledge should a Product Owner possess?

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:

  • Responds to technical inquiries from stakeholders without confirming the answers with the team
  • Places higher priority on technical work items in the product backlog and neglects the true business needs of stakeholders
  • Turns a blind eye or even encourages technical gold plating
  • Provides the team with system requirements or design guidance thus reducing the team's ability to be creative or innovative
  • Unreasonably challenges the team's sizing of work items or how much they are able to complete within a given amount of time

With great knowledge comes greater responsibility.

Posted on: April 14, 2019 07:00 AM | Permalink | Comments (11)

Don’t get blindsided by stakeholder influence

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)

Posted on: March 14, 2019 08:51 AM | Permalink | Comments (9)

Tips for taking over an active project

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)

Posted on: March 06, 2019 07:00 AM | Permalink | Comments (15)
ADVERTISEMENTS

Sometimes I think war is God's way of teaching us geography.

- Paul Rodriguez

ADVERTISEMENT

Sponsors