Easy in theory, difficult in practice

The Scrum Guide identifies commitment, courage, focus, openness and respect as Scrum Values. Those values apply regardless of the delivery framework or method used and missing any one of those reduces the benefits of an agile journey. But it might be worth adding one more to round out the list: humility.

Merriam-Webster defines humility as "Freedom from pride or arrogance". I prefer the Cambridge Academic Content Dictionary's definition that it is "the feeling or attitude that you have no special importance that makes you better than others".

Similar to the other Scrum Values, humility could be considered in the context of both the individual and the team.

We don't consider ourselves to have any special authority or rank over other members of our team. We also don't assume that we are always right which makes us open to hearing differing viewpoints and not shying away from healthy discussions in order to produce the best possible outcomes for our customers.

False humility doesn't cut it.

We openly acknowledge when are skilled in some areas and best positioned to help the team achieve a goal but will honestly communicate when we know less. While we are happy to accept accolades for our work, we will recognize that our successes were realized through the support of the rest of the team.

We remain open to feedback about our personal work activities and outcomes and are able to resist the natural tendency to become defensive when we receive constructive feedback.

Without humility, the pillars of Inspection and Adaptation crumble.

We know there is no ONE right way (or framework, or method, or practice or tool).

We may meet our sprint goals every sprint and receive rave reviews from our customers but we have the humility to acknowledge that we can always do better. This supports true continuous improvement.

Product Owners will possess a deep understanding of the product domain but effective ones have the humility to acknowledge when a pivot in product direction is needed and don't allow customer value and team morale to be sacrificed at the altar of preserving the Product Owner's ego. The scientific method which underlies the good practice of Minimum Viable Products depends on the humility of a scientist acknowledging that their hypothesis might be disproven.

Humility extends to the roles supporting our agile teams. Coaches should know what they don't know and be capable of recognizing when those being coached have outgrown their services. Such coaches possess the humility to step aside to let others who are better positioned to help those being coached through the next stage of their capability development.

"Be like the bamboo, the higher you grow the deeper you bow" - Japanese proverb

Long-time readers of my blog will know that I support the concept and principles of objective project prioritization. However I am pragmatic and recognize that a significant percentage of the organizations who aspire to having objective rankings of their active and pipeline projects can’t get there overnight, and even as their practices mature, they still must successfully deliver multiple parallel projects with constrained skills and capacity.

If this sounds like your organization, what can be done to meet commitments while not ignoring the practice improvements required to achieve a more manageable active project portfolio?

• Make sure must-do projects are REALLY must-do – As with any negotiation, the starting point for a project customer will be the one that is in their best interest, namely that their project is the most important one in the portfolio. However, the discussion around priority should always ask the questions “What’s likely to happen if we don’t do this project?” and “What’s the impact if we don’t do this project right now?” to get a more objective understanding of a project’s criticality.
• Understand constraint flexibility (no, that is NOT an oxymoron) – Similar to the previous point, the initial response to “What will happen if we pushed the project back by a month or two?” or “What would happen if we added some external resources to the critical path?” might be negative, but you’ll need to dig deeper to ensure that the portrayed constraints are in fact immovable. The reality is that not all project’s constraints will be fixed – you can either be proactive and have those conversations up front, or back into them when issues arise!
• Don’t overplan – With more concurrent work underway than can be easily delivered, issues are going to emerge and plans must be flexible and scalable to adapt to these challenges.
• Prioritize milestones – Once a small set of must-do concurrent projects has been identified and preliminary planning has been completed, the focus of prioritization should shift to the truly critical milestones within these projects. Near term milestones should be given a higher priority as there is less flexibility or time to resolve issues related to those than with longer term ones. This does not mean ignoring longer term milestones – the confidence level of meeting those should still be reported regularly to leadership teams, but decision making regarding scarce skills should favor near term critical milestones.
• Establish consistent cross-project resource contention issue management at the portfolio level – Significant effort and time can be wasted in dealing with resource contention issues between projects so effort spent up front in defining processes and governance for resolving such contention will pay for itself within the first few milestones.
• Communicate the reality of the situation to all staff – Although the leadership team may understand the rationale for having multiple parallel #1 projects, if they don’t do a good job of cascading this information down through their direct reports to all staff, morale and productivity will suffer.

Juggling multiple balls might seem like an impossible feat to an untrained novice but just as jugglers develop techniques and practices to do this, it is possible for organizations to improve their ability to manage multiple concurrent must-do projects.

However, even expert jugglers eventually tire, and if the volume of concurrent work doesn’t subside to more manageable levels in time, inevitably one or more critical project “balls” will drop along with a side order of skilled staff attrition.

(Note: this article was originally published in August 2013 on kbondale.wordpress.com)

I've frequently said that agile transformations are marathons and not sprints. But when someone runs a marathon there are mile markers to understand how far they've come and to help them get their second (or third or fourth) wind.

While there is no single model for how a company will progress through its agile transformation, it is a good idea for transformation teams to proactively identify tipping points where previously unique outcomes or behaviors have become commonplace. While such milestones won't help them forecast how much longer it might take to reach their ultimate goals, it can provide a leadership team with proof that things are continuing to move in the right direction. Such evidence is critical if there is to be sustained commitment and investment in the transformation.

This list is not exhaustive nor is it in chronological order. Depending on what the starting point is for the organization and where the transformation team chooses to focus their efforts, there may be additional milestones and the sequence of when those are accomplished will vary.

• Team social pressure encourages appropriate agile behaviors without the need for sustained external coaching
• Delivery frequency matches stakeholders' change appetite
• Zero defects
• Empowered Product Owners with sufficient capacity, capability, knowledge and influence
• Team allocation shifts from maximizing utilization to maximizing value delivered
• You don't hear team members say "the business" anymore (we are all "the business"!)
• Pivots in product or solution direction are praised, not punished
• Teams provide accurate and current updates to information radiators and stakeholders effectively pull information from those radiators
• There is NO one size fits all for ceremonies, practices or tool
• Overtime and weekend work is the exception not the rule
• Hiring practices and performance measurement systems emphasize the "how" as much as the "what"

What would you add to this list?

Whether your company is operating at a low level of organizational project management maturity or is world class, one of the most critical points in the lifetime of a project is when it is initiated. Start too soon and valuable resources and time will be wasted while people are figuring out what needs to be done. Wait too late and work on the project may have already commenced in stealth mode and without involvement of key stakeholders.

Designing and rolling out a consistent project intake process helps, but good process rarely compensates for poor execution.

Here are three questions which can tell you if the project is ready to be started.

Why are we doing this now (and what are we saying “no” to)?

If there’s no one who can clearly articulate the rationale in investing in this project instead of the myriad other initiatives which could have been funded it might be best to go back to the drawing board. Beyond that, it’s important to understand why now is the right time to kick it off. Is there a committed deadline of some kind which will be missed if work doesn’t commence immediately?

Who’s backing this project (and can they afford it)?

If there’s no one who is ready to commit resources to the initiative, there’s little point in getting started. Even if there is a sponsor identified (both in the funding and executive support perspective), if they are at too low a level of political influence to be able to effectively align stakeholders, create a coalition of the willing and knock over hurdles in the path of the team, with even a moderate level of complexity, the project will likely get and stay in trouble.

Do we have everyone we need to start (and keep going)?

Even in the first few weeks of a project, a sponsor and a project manager can accomplish very little without active involvement of key stakeholders and team leads. If that critical mass of resources is unavailable, your project will burn time and money without making much progress. In some organizations, if the core team is not assembled, a project is not permitted to start. Faced with a hard completion deadline, that can help increase the sense of urgency across the organization to staff up the project rapidly.

The simplest way to avoid having a project fail is to stop it from getting into trouble from the beginning.

(Note: this article was originally published in January 2015 on kbondale.wordpress.com)

A few months ago, I rekindled my enjoyment of the game of pool after having played it sporadically over the past twenty years.

I find something soothing about the clickety-clack sound of balls ricocheting off one another and relish the challenge of figuring out which shot to play to sink a ball and line up my next shot or if I miss, at least prevent others from making their shots.

Racking my brain (pun intended) for a topic to write about this week I thought why not explore whether there are any lessons we can learn from playing pool which might be applicable to project work?

1. Standard pool is played with fifteen colored balls (not counting the cue ball). Diversity within teams is a source of strength. Yes, it might make the storming and norming phases of team development more challenging, but higher performance, creativity and resilience can be the rewards for persistence.
2. No two pool tables play exactly the same. Until we understand the unique attributes of a given table, making assumptions based on previous games played on different tables is likely to get us into trouble. With our projects, while historical data can be relevant, we need to understand the specific context of a project to avoid using the wrong tool or technique.
3. Define the rules of play with your opponents. There are some generally accepted rules for playing pool, but certain practices might vary by who you play with. There are generally applicable principles for project delivery but work with your teams to develop working agreements and ways of delivery which are best suited to them and the needs of the project.
4. Balance risk with reward. Yes, that tricky bank shot would look impressive to bystanders if you can make it, but if you miss, you might set your opponent up to run the table. But playing it too safe usually won't work out well either, especially if your opponent has a greater ability than yours! When working on projects, we need to find the right balance between playing it too safe and living on the edge. The former might result in mediocre business outcomes but the latter could result in project failure. This is why having good judgment is critical for project team members.
5. It takes self-control to do well. It can be really tempting to apply full force on a shot, but you could end up scratching or sinking one of your opponent's balls. Being mindful about the amount of force required to make a given shot and leaving your ball well positioned for the next shot is important. Delivering challenging projects takes discipline and sloppy execution will hurt us in the short or long term.

Finally, "Take care of your cue ball, and it will take care of you". Support and lead your team and they will help your project succeed.