Easy in theory, difficult in practice

by
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog

RSS

Recent Posts

Early experimentation is key to reducing project risk

Cultural transformations of high-performing teams

Small is beautiful for product backlog items

Do your performance evaluation and recognition systems support cross-functional teamwork?

Don't be like a squirrel hiding nuts with project lessons!

Early experimentation is key to reducing project risk

Inspection and adaptation are two of the pillars of the Scrum framework but all agile methods recognize the wisdom of Deming's Plan-Do-Study-Act cycle.

While the Manifesto does not explicitly reference the scientific method, it is implied in the value statement "Responding to change over following a plan" and in its final principle "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Agile teams embrace experimentation in many ways.

Some of these relate to the product. Minimum Viable Products and Minimum Business Increments can be designed and run to test hypotheses about what we feel is valuable to customers at a macro level. Split testing and similar short feedback techniques might validate whether specific features should be pursued or not.

Some relate to the team's delivery process.

Both the Rational Unified Process and Disciplined Agile Delivery highlight the importance of proving solution architecture early and one effective means of doing this is through the design, construction and execution of experiments focused on quality attributes such as performance or flexibility.

Working agreements such as Definitions of Ready or Definitions of Done can be thought of as experiments to validate whether teams are able to efficiently complete work items and whether teams understand what complete means.

Ceremonies such as retrospectives help a team to identify delivery improvement ideas. Rather than assuming these ideas will help and implementing them on a broad scale, teams will run experiments to see whether these ideas actually show promise. For example, improving product quality through pair programming might seem like a good idea so a team might elect to try pairing on a subset of their upcoming work items and comparing the outcomes to those completed using their previous methods.

Spikes are another form of agile experimentation. Rather than losing significant effort in comprehensive analysis of a specific uncertainty, a short time boxed deep dive focused on learning which options might be feasible is often a better alternative.

So how could adopting this commitment to experimentation help those teams using a predictive life cycle?

Assumptions which have not been validated are a common source of project risks. While a team could wait for an assumption to be passively proven, wouldn't it be more effective to frame a critical assumption as a hypothesis and then design and run an experiment to get data to make the team feel more confident about that assumption?

Incorporating ongoing experimentation into the risk management life cycle might provide a more effective method of de-risking all types of projects.

Posted on: December 08, 2019 06:59 AM | Permalink | Comments (10)

Cultural transformations of high-performing teams

Categories: Agile, Team Building

While I was delivering a course on agile fundamentals this week, one of the learners in the class asked me how the mindset and behaviors normally associated with agile teams might impact or be impacted by culture. He suggested context (low or high) as a cultural characteristic which would influence the starting point for a team and which could then change as the team matures, but the same can be said for other cultural dimensions. (So thanks, Tony, this article is for you!)

Geert Hofstede's research into national culture identifies multiple dimensions which can be used to describe differences between countries. Some of these could be considered in addition to context when observing how such teams develop.

  • Context: When members have never worked together, a newly formed team will often exhibit low-context cultural behavior. Ground rules have to be developed, documentation needed to support delivery tends to be heavier and hand-offs are explicitly communicated. As the team matures, its culture shifts towards a higher context where interactions become more tacit than explicit. We often see this in the puck passes made by hockey players who have played together for a long time. Rather than having to yell out "Pass!" or "I'm open!", they seem to communicated with each other using telepathy!
  • Power Distance: Formal power, titles and status will generally be of greater importance to members early in the life of a team, but as the team matures, there is greater acceptance and less attention paid to formal power imbalances. My earlier article about the television show, The A-Team, referenced this with regards to the dynamics between Colonel John "Hannibal" Smith and the other members of the team.
  • Uncertainty Avoidance: When a team is newly formed, its members will have varying degrees of comfort with risk and ambiguity based on their individual risk appetites and that of the divisions or organizations they belong to. But as the level of psychological safety within the team increases, there should be a corresponding lowering of uncertainty avoidance. This doesn't mean that people will jump from being risk averse to becoming gamblers but rather that over time they will move down that continuum.
  • Assertiveness: Depending on the culture from which individual team members come from, they might exhibit high or low assertiveness when they first join the team. Over time, the team will become balanced between the two extremes. While higher degrees of empathy and collaboration will emerge as the team matures, we would also see all team members having the courage to speak truth to power or providing feedback with radical candor.
  • Long Term Orientation: This dimension considers the degree to which we value long-term gains over short-term ones. This may be impacted less by the stage in a team's development but more by the shift in collective mindset from traditional delivery emphasis on big, heavy [planning, requirements, design] upfront to the lean principle of deferring decisions till the last responsible moment.

Understanding culture across these dimensions can be helpful for leaders such as agile leads and functional managers to interpret the behaviors they observe so that they can better support the development of high-performing teams.

Posted on: December 01, 2019 06:59 AM | Permalink | Comments (8)

Small is beautiful for product backlog items

One of the reasons for having small work items at the top of a product backlog is so the team is able to complete them within a short amount of time. This benefit applies regardless of whether your team is using an iteration-based delivery approach or has adopted a lean continuous flow-based approach.

But what are some of the other benefits of having small work items?

  • While size does not always positively correlate with complexity, usually the smaller a work item, the easier it should be for team members to come to a shared understanding with the work item originator as to what is desired and how they will deliver it.
  • Smaller work items often require less documentation than larger ones.
  • It might be less challenging for team members who are new to test driven development to apply this practice for small work items.
  • If the team is using an iteration-based approach, the probability of getting a higher percentage of completed work items is greater if they forecast a larger number of small work items in an iteration as opposed to a smaller number of large ones.
  • The amount of re-work or wasted effort involved if a particular work item does not meet general or quality requirements should be lower.
  • If most work items for a release are small “enough”, the team has the ability to skip the use of story points or some other relative sizing method in favor of just tracking how many work items they can complete within a given amount of time.
  • Finally, splitting a large work item into small pieces provides greater feature choice to product owners when prioritizing the backlog.

But before slicing our work items too small, we need to remember that size is just one of the criteria provided by Bill Wake when he came up with the INVEST acronym for assessing how good a story is. A work item which is too small might not be sufficient independent or provide value to a stakeholder.

But keeping these caveats in mind, good things come in small packages.

Posted on: November 24, 2019 06:59 AM | Permalink | Comments (14)

Do your performance evaluation and recognition systems support cross-functional teamwork?

While it is usually Wally who openly expresses those thoughts which we normally keep to ourselves, Dilbert is letting his inner voice do the talking in today's strip. Let's imagine for a moment that Dilbert's co-worker is part of a cross-functional team which Dilbert is part of. Dilbert's response might seem unnecessarily blunt, but this behavior is not uncommon in those companies which place an undue emphasis on individual recognition or which don't require managers to actively solicit feedback from outside of their own teams.

While most of us would consider ourselves to be helpful, without some measurement and organizational encouragement our willingness to help someone is likely to be reduced by our need to finish our own work as we know the latter is what is measured.

In many organizations, functional managers are under no obligation to solicit feedback from others about their staff's performance. While these managers might ask for input from within their own team, they might be reluctant to contact those co-workers who report to other functional managers. If they evaluate their team members' performance purely on achieving functional objectives or on how they interacted with others from within their own team, they might not consider whether someone works well within a cross-functional team. While this type of feedback is certainly available from project or other functional managers in a matrix structure, the functional manager might not always be open to soliciting or acting on the feedback. When objective feedback from co-workers outside of a manager's team is a required component of formal performance evaluations, it encourages both managers and team members to look beyond the walls of their own silos.

It is also quite common to find generous enterprise-level budgets for individual recognition but not as frequently for team recognition. With strategic or large projects, a project manager might have sufficient influence to secure budgetary approval for team-level rewards but this is usually not the case on smaller initiatives. Without equal weighting given to both individual and team recognition, it is no wonder that team members will prioritize individual success over that of the team they are on.

We want team members to feel confident that if they ask for help from a co-worker who happens to report to a different manager that there is a strong likelihood that they will get it. We would like to encourage team members to be willing to slow down their own activities if it helps their team get ahead. But when environmental factors such as performance evaluation systems and recognition programs discourage such behaviors it can be difficult to build high performing cross-functional teams.

Posted on: November 17, 2019 07:00 AM | Permalink | Comments (11)

Don't be like a squirrel hiding nuts with project lessons!

As weather gets colder, it is common to see squirrels digging holes to bury nuts and other food items to feed themselves when resources becomes scarce during winter time. But given the volume of nuts which are required to sustain squirrels through the long winter months and the large areas covered by an average squirrel, they often end up forgetting where they have buried all of their treats. While observing the little fellow I captured in the photo above, I was reminded that we are not so different from our furry friends.

Whether we capture lessons over the life of a project or wait till the end of a phase or the project as a whole, we frequently end up forgetting most of the lessons we have foraged.

Squirrels will eat a few nuts while they are in the process of gathering them. In the same manner, there will be certain lessons which we can implement right away.

But what of the remainder?

If we just store them in a repository or, worse yet, in standalone documents or distributed Wiki pages, we are no better than squirrels who have forgotten where they have buried their nuts.

Thankfully, unlike squirrels who are unable to invent and use GPS-based nut finders, we do have a few options:

  • Enhance our standards by incorporating identified lessons. This option works well as there is no need for practitioners to search for lessons but over time it could result in overly prescriptive, bloated standards.
  • Share lessons in community of practice meetings. One approach would be to leverage the oral traditions of storytelling from our ancestors by taking dry, theoretical lessons and make them come to life.
  • Develop playbooks or other types of practice-based learning offerings for practitioners. These would offer identified lessons as options but not as prescription.

Putting the "learned" back in lessons learned begins with doing a better job of learning from the lessons we have previously identified.

Posted on: November 10, 2019 07:00 AM | Permalink | Comments (11)
ADVERTISEMENTS

"America had often been discovered before Columbus, but it had always been hushed up."

- Oscar Wilde

ADVERTISEMENT

Sponsors