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
This Dilbert comic strip provides us with a good reminder of the fine line which exists between reasonable oversight of activities and micromanagement. Dilbert has allowed sufficient time to pass before seeking an update on a colleague’s assigned task only to find that it has been neglected due to a lack of following up. When Dilbert attempts to get commitment on a revised completion date, he’s accused of micromanaging the activity.
What is deemed a reasonable amount of oversight by a manager may be perceived as micromanagement by team members.
While some teams might possess sufficient psychological safety to embolden team members to voice their concerns, the culture within other organizations or teams might actively discourage this sort of straight talk. In such environments, the frustration felt by the team members festers resulting in impacts to their productivity and slowly poisoning team morale.
And this can become a vicious cycle as team members become progressively more disinclined to share updates with their leaders which results in even greater degrees of oversight.
So how can we avoid this?
It has to start with the leaders and team members collaboratively developing work management practices. If these practices get imposed by leaders or solely developed by team members they will never satisfy the needs of both parties. Early in the life of a project if the objectives for both sets of stakeholders are put on the table and an honest, frank discussion is held about principles governing how those objectives can be met, a set of practices which both sides buy into can be developed.
It also helps to make the oversight process as seamless as possible. Use of visual work support tools such as physical or online Kanban boards can shift the model from assigning work to team members to team members signing up to complete specific work items while simultaneously providing transparency into what’s done and what’s left to be done.
Finally, reducing cross-initiative multitasking can enable staff to complete tasks quicker and with higher quality while eliminating the need for managers to have to constantly follow up with team members to ensure that priorities haven’t shifted.
Micromanagement is like Justice Potter Stewart’s famous description of the threshold test for obscenity : “I know it when I see it”. Given this subjectivity, it’s better to avoid getting being accused of it to begin with.
(Note: this article was published without micromanagement in March 2017 on kbondale.wordpress.com)
A lot has been written about the challenges caused by functional managers when their company undergoes an agile transformation. But with this emphasis on what they shouldn't be doing, not as much gets published about the specific activities we should be doing to help them through the change.
Here are four questions to ask when considering this key role.
Are they learning?
To support a change you need to understand the change. Delivering training focused specifically on what functional managers need to know about agile which includes scenario-based learning to understand what sorts of behavior changes are expected when faced with common situations will help. But it is also important to identify which managers have already shown evidence of having embraced an agile mindset and recruit them to help support their peers who will have a harder time with the transition. In the absence of such internal support, coaches could be hired to create a critical mass of change advocates among middle management.
What are they measured on and what are they measuring?
Metrics aren't the sole driver of behavior but they do draw a lot of focus. As Tony Robbins would say, "Where focus goes, energy flows". If we haven't updated performance measures for functional managers and their staff, it will be much harder to encourage them to change. If existing metrics are focused on how well team members and their managers achieved certain objectives but didn't also consider how those objectives were achieved, deadlines and budgets will continue to dominate rather than collaboration and engagement. These measures need to be augmented with ones specifically assessing stakeholder and team member satisfaction to understand whether the "how" was as good as the "what".
Who are they hiring?
I've written previously about the importance of adjusting job descriptions and hiring criteria but it is equally important to train functional managers on how to leverage these changes. If the job profile calls for servant-leadership but all the functional manager asks about is what a candidate accomplished, the risk of hiring people who are not aligned with the new way of working will persist. Pairing functional managers with properly trained HR staff for panel interviews is one way to address this.
How are they supporting their staff?
Team members will be experiencing many of the same fears and doubts that their manager has about the transformation so it is important that functional managers meet regularly in both one-on-one and team settings to address these concerns. Managers play a critical role in helping their staff gain the confidence to take their first baby steps towards self-organizing and becoming T-skilled. To do this, managers must cultivate a psychologically safe environment within their teams so that their team members feel safe about expressing themselves and taking chances both in the project roles and in their functional ones.
Buy-in from middle management is necessary for any successful organization change, and even though you might think that the sandwich approach of committed senior leadership and enthusiastic front line staff squeezing out compliance, actively guiding and supporting functional managers will be essential to a sustainable transformation.
For those of us who have worked most of our careers in companies with functional or matrix power structures, project-oriented organizations can appear very attractive in comparison.
This is understandable given the many challenges project managers can face when their roles are poorly defined or when they have no little authority over team members or decision making. I can recall countless cases of project managers escalating concerns over individual team member behavior to people managers only to be told that perhaps the project managers themselves are the problem.
Support for project managers can also be limited.
If they are lucky, they might report into a PMO which provides professional development opportunities and they can benefit from the support of their peers but unless the company is at a higher level of organizational project management maturity, the role of the project manager might still be a thankless one at times.
In a project-oriented company, the role of the project manager is well defined, they usually possess formal authority (including hiring and firing power) over their team members, and they are likely to have greater decision making authority than in matrix or functional organizations.
Seems like Nirvana, right? Unfortunately, formal authority is not all it’s cracked up to be.
Just because you have the ability to directly impact someone’s performance evaluation, annual bonus or even their job, doesn’t mean that will automatically motivate them to give you their best efforts. Possessing formal authority over team members can be a curse – you have to work twice as hard to capture the hearts and minds of your team members through vision, influence and persuasion as it is all too easy to fall into the habit of saying “It’s my way or the highway!”. In functional or matrix organizations, that approach isn’t even possible, but in project-oriented organizations, team members will listen because they fear the consequences of not doing so, but you will get their support at the cost of true engagement and commitment.
In project-oriented organizations, the project manager can also bear the brunt of negative project outcomes. They possess the authority, but with that comes the risk that if the project fails or the customer is unhappy, they are more likely to be impacted than in a functional or matrix organization where decision making authority and accountability is diffused.
Finally, what happens when your project ends and there is no more work? Project managers in functional or matrix organizations might lose their jobs if they are unable to find a lateral role. In a project-oriented organization, lack of new projects could mean that not only the project manager, but their team members could also be negatively impacted, and the project managers will have to bear the resulting emotional stress.
Can project-oriented organizations be better than functional or matrix ones? They can, but caveat emptor!
(Note: this functional article was originally published on kbondale.wordpress.com in February 2015)
Project management practices have been used since human beings first started to work together to achieve greater outcomes than they could have accomplished as individuals. Modern practice of the profession started in the 1950's so it is natural that certain practices, tools and nomenclature will be discarded as the profession evolves.
Unfortunately, some anachronistic project management terms still linger in spite of overwhelming evidence that their time has passed.
Waterfall & Traditional
Waterfalls usually provide a one-way journey for those unlucky enough to take a ride over them. Even the most deterministic lifecycle will provide some instances (no matter how small) of iterating back. Traditional is a subjective term. The Manifesto for Agile Software Development was signed in 2001 and before its arrival launched agile into the mainstream, adaptive lifecycles had been used for many years. Traditional could be equally applied to deterministic and adaptive lifecycles when we consider that many new project managers were born around Y2K!
Resources (when referring to people)
The PMBOK's Project Resource Management knowledge area might cover the management of both people and materials, but calling our team members "resources" encourages poor management practices by equating them to commodities and furthers the myth and resulting risks of fungibility. There are many positive synonyms which can be used to reference the people on our teams including their names(!), "talent", "contributors" and "performers" so there's no reason to use such a divisive term.
I applaud the efforts of the PMBOK Guide, Sixth Edition volunteer team in adding the Tailoring Considerations section to each knowledge area chapter but this is just the first step in a long journey of providing guidance for adapting project management practices and tools to the context of a specific project and organizational culture. Certain other professions might have standard procedures which are appropriate in all circumstances (e.g. turn the power off before working on an electrical circuit) but while the principles of project management are universally applicable, specific practices or tools are not.
The practice of trepanation was used in ancient times as a cure for the evil spirits possessing sick people's heads. However, if a doctor was to approach your head with a drill, in all except the most extreme circumstances, you would be forgiven for running away! If we wish to demonstrate the evolution of the project management profession, similar Spring cleaning is needed with our lexicon.