The Manifesto’s missing link: Valuing agility over agendas

The Manifesto for Agile Software Development gave us four values supported by a dozen guiding principles. While methodologies or practices can be domain specific, taken as a whole, the Manifesto’s values and principles can be applied to almost any industry or domain to deliver customer value in an efficient, people-focused manner.

But there is one more value which might have helped to avoid some of the failures attributed to agile transformations – agility over agendas.

Do any of the following behaviors sound familiar?

  • Empire building – vest someone with the authority to lead an agile transformation and they might join the Dark Side by setting up squads of Stormtrooper Scrum Masters
  • Turf protection – this often seen in functional managers who might view the restructuring of teams and development of generalizing specialists as a dilution of their formal authority or encroachment on their fiefdoms
  • Framework fanaticism – the Balkanization of agile methods and certifications has helped spawn a large number of fundamentalists who are unwilling to accept that their chosen method or credential might not be universally applicable. This is an unfortunate side effect of limited exposure to the significant breadth of agile knowledge.
  • Hoarding knowledge – the desired shift to T-skills might cause panic in those who have rested on their deep but narrow competencies as they fear being dispensable rather than embracing this as a resilience opportunity to learn new skills
  • Prioritizing politics over progress – who is best suited to fill a key role such as a Product Owner or Scrum Master might not always align with the politics of an organization or department
  • Ego stroking – it might be a Product Owner using an autocratic approach towards prioritizing the backlog or a team member who refuses to have someone partner with them in pair programming or other non-solo work

Some of these behaviors are hardwired into us from our Neanderthal days, and to in small doses might sometimes result in good outcomes. But when we double-down on them at the cost of agility, we need someone to remind us that we’ve lost perspective.

If you see something, say something and remind the parties involved to value agility over agendas.

 

 

 

 

Advertisements
Categories: Agile, Facilitating Organization Change | Tags: , | Leave a comment

The art and science of backlog prioritization

A key responsibility of Product Owners is ensuring that the order of work items in a backlog best achieves the goals and vision for the product. Unlike project portfolios where selection or prioritization decisions are often made by a governance committee, with a product backlog the responsibility for the business success or failure of the product rests on the Product Owner’s shoulders.

This activity is both science and art.

Multiple competing factors need to be considered and balanced including:

  • Business value
  • Alignment with the original vision
  • Dependencies
  • Constraints
  • Risk reduction

Evaluating cost of delay or Weighted Shortest Job First can inject consistency and objectivity into activity but also takes learning and effort. If used, such scoring approaches should be used to guide decision making rather than replace it.

The Product Owner needs to collaborate well with key stakeholders to ensure that releases won’t just satisfy his or her needs. This collaboration requires willingness on the part of the Product Owner to push back the release of certain “hot” features if that will result in a better product overall.

When working with a new team, the Product Owner needs to actively listen during backlog refinement discussions with team members as some of them might lack the courage to openly challenge a short-sighted decision. One way to help overcome such growing pains is to actively ask the team as work items are being ranked whether they see any flaws with the order or whether they are aware of any work item which might need to be tackled sooner. Prioritization might be a good item to consider during retrospectives to ensure that the process is regularly inspected and adapted.

The Product Owner will naturally want to maximize business value realization while solution owners will want to tackle solution uncertainties or address scalability or flexibility early on. Healthy prioritization should feel like a tug-of-war between the representatives for each influencing factor.

A good Product Owner should be ego-less about the prioritization activity as their goal is not to demonstrate omniscience about the sequencing of the product’s development but rather to release the best product possible.

 

 

Categories: Agile | Tags: , , | Leave a comment

Cultivating psychological safety happens one person at a time…

Since 2015 when Google’s research identified psychological safety as one of the key attributes of high performing teams, it has received a lot of airtime. While there might be greater awareness of this characteristic, there is little guidance on how to cultivate it within an organization or team where it is absent. Hence, when I saw today’s Dilbert cartoon strip, it reminded me that instilling psychological safety is a cultural transformation.

Scott Adams does not provide insight into why the Pointy Haired Boss fired Ted but Wally’s curiosity about recent terminations and his use of Ted as a scapegoat for his project’s schedule variance clearly demonstrates that they are working within a corrosive culture of fear where failure is not recognized as a statistically expected outcome but rather is the catalyst for a witch hunt.

Sound familiar to any of you?

In one of my earlier articles, I’d provided some suggestions on how a project manager could help to instill psychological safety within their team but did not cover the need to understand the underlying causes for its absence.

While we think about psychological safety as being a team-level dynamic, it is a deeply personal feeling and like all change, needs to start at a individual level.

There are two forces operating against our feeling psychologically safe – from without and from within.

Our colleagues possess the ability to destroy our confidence in being able to take calculated risks. Every time we see someone being criticized for attempting to push the envelope it supports our personal need to play it safe. Relationship-oriented organizations can unwittingly reinforce this as no one wants to be perceived as rocking the boat.

But we shouldn’t ignore our own insecurities which might be causing us to avoid taking risks. I’ve frequently encountered individuals who hesitated to make a decision which they believed to be the right one simply because they felt they couldn’t. When pushed to identify a specific policy, standard or mandate supporting this, they were unable to and yet they still remained unwilling to proceed. When their leaders were asked if they had said anything which might have caused this, they were flummoxed. Pogo continues to be omniscient – “We have met the enemy and he is us.

Taking the time to understand what might be causing one of our team members to feel unsafe is time well spent as it will improve our likelihood of changing their perceptions.

 

Categories: Facilitating Organization Change, Project Management | Tags: , , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: