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?
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.
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?
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.