Easy in theory, difficult in practice

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

People and not policies, processes, practices or platforms are required to achieve successful projects.

This is why the following principle from the Agile Manifesto needs to be careful considered whenever an agile transformation is underway:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 

The required shift is significant but subtle.

It's a project manager changing how they phrase a simple action from "assigning work items to team members" to "team members committing or selecting which work items they will complete". It's a sponsor being mindful of how she expresses her concerns when observing a daily standup. It's a team member volunteering to help peers without fear that someone will say "Focus on your work, that's NOT your job!".

Training at all levels is a good first step in the journey, but as with any type of soft skills learning, there is no substitute for hands-on experience.

Coaching will help to create behavioral muscle memory, but good coaches don't come cheap, and limited availability of effective coaching support could act as a throttle on the pace of your agile transformation.

Leaders who walk the talk are essential but it is insufficient to have only executive leadership aligning with the desired to be set of behaviors if functional managers or other important influencers continue to follow traditional playbooks. This is one reason why coaching services could add value beyond just delivery teams by reinforcing leadership learning.

Behavior changes need be embedded across all aspects of culture.

One way to support this could be by taking the Manifesto's value statements and principles and incorporating them in a personal, meaningful way into the company's core values. These will provide a baseline for verifying individual alignment during performance appraisals and could also serve as a litmus test for evaluating how well potential candidates might fit.

It's relatively easy to change organization policies or to introduce updated procedures or tools, but (to mashup Lao Tzu and Gladwell) changing human behavior requires a journey of ten thousand steps.

(Note: this article was originally written and published by me in January 2017 on my personal blog, kbondale.wordpress.com)

It’s hard to argue that effective project sponsorship is a critical success factor.  Whether it is through providing funding for the project, exerting influence to avoid roadblocks or supporting and championing the behavior changes that must occur to achieve expected business results, the absence of good sponsorship can leave a Project Manager feeling like they’ve jumped out of a plane with no parachute.

There are multiple possible causes for poor sponsorship including an inconsistent understanding of the role & its responsibilities, a lack of good governance practices related to project selection, prioritization or initiation, as well as missing links between project results and sponsor performance objectives.

There are equally as many methods of improving the situation – some are within the control of a project team, while others require systemic or governance changes.

Some foundation changes that can improve results include:

• A consistent, organization-wide communicated definition of the expectations and responsibilities of a project sponsor.  This definition should be signed off by the C-levels.
• Tying annual evaluations and bonuses for sponsors to project performance
• Incorporating evaluations and feedback from project teams as an input into the sponsor’s annual evaluations
• Required involvement and sign-off from project sponsors on project charters

A project team could try some of the following approaches:

• The PM should meet with the sponsor as early as possible to understand the sponsor’s expectations but also to convey the project team’s expectations for the sponsor.  Issues or risks identified in that meeting should be responded to or escalated promptly.  Beyond this meeting, the PM should regularly meet with the sponsor as a medium for the PM to provide constructive feedback about the sponsor’s “performance”.
• The sponsor should be asked to play a significant role in the kickoff meeting.  Beyond stating the vision and expected outcomes for the project, the sponsor could re-state the expectations for their role at this meeting.
• The sponsor’s name should figure prominently in all key project documents including regular status reports.
• The PM should respect the sponsor’s expectations for information updates, and should neither keep the sponsor “in the dark” nor overwhelm them with minutiae.
• The project team as a whole should ensure that project information that the sponsor is exposed to is accurate, complete and business impact focused.  Similarly, the decision-making approach used by the PM and team should be focused on business value impacts.
• The sponsor should be requested to attend periodic reviews of the project risk register as well as the reviews of significant project change requests.  While the project team is likely to identify and assess project risks, the sponsor can provide valuable feedback on business risks.

While these may not be as effective as magic eyeglasses, the one-two punch of process and project team tactics could help to make an invisible project sponsor materialize.

(Note: this article was originally written and published by me in January 2011 on my personal blog, kbondale.wordpress.com)

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.

“First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth. No single space project in this period will be more impressive to mankind, or more important for the long-range exploration of space; and none will be so difficult or expensive to accomplish.”

When Kennedy delivered this speech in 1961, while many listeners might have thought he was dreaming they were also inspired.

Most of us can summon the energy to work on short projects, but when faced with a long, challenging project where the end state or penultimate objective remains fuzzy, if there isn’t an obvious “What’s in it for me?” answer, it’s little surprise that enthusiasm can fade.

In most environments, this gets aggravated by the multitasking faced by project staff – while the large, long running project they are on might be of greater strategic value, their understanding of the expected benefits of shorter projects or even of day-to-day operational responsibilities means that they may choose to prioritize those tactical quick wins higher over persevering on completing their work on the larger project.

If the vision for a project’s outcome is not obvious, it is our responsibility as project managers to engage the sponsor and others to be able to define what the world will look like from the viewpoint of team members, their managers and key stakeholders once the project’s outcomes start to be realized.  That envisioned end state needs to be depicted as personally as possible to the team, and depending on its duration, we should remember to reinforce the importance of the project at regular times over the lifetime of the project.

I’m guessing there’s a (very) small desire on the part of some project managers to live in the time of the Pharaohs when it was expected that Theory X measures would be used to sustain team member productivity!  However, persuasion is always superior to use of formal authority, and you’ll find that 1% of inspiration will help to generate the 99% of perspiration required to complete your projects!

(Note: this article was originally written and published by me in November 2012 on my personal blog, kbondale.wordpress.com)