Easy in theory, difficult in practice

With under a week till Christmas 2019, Mike Cohn wrote a good article about what wishes team members might want to have granted this holiday season from their Agile Leads, Product Owners and People Managers.

But even if each of these roles were to grant all the wishes which Mike listed, there is one more role which needs to be considered, namely their fellow team members.

Give me a hand

One of the differences between a group of individuals and a real team is that with the latter we will see team members helping each other out without an explicit request for assistance being made. While it is desirable for team members to ask for assistance during events such as a daily standup, many times the need for help might emerge suddenly and if someone else on the team sees that their teammate is struggling they can provide assistance in a timely manner.

This behavior is often seen in professional sport teams. When an ice hockey goaltender is caught far out of their net while clearing the puck, one of their other team members who has much less protective equipment might put themselves in the line of shots until the goalie is able to get back in the crease. You'll almost never hear the goalie verbally request this assistance, but the teammate sees the need and helps out regardless.

Help me improve

While there are always a few people who don't like hearing the truth, most of us prefer to find out when we could have done something better.

Retrospectives are one forum in which teams can share what's working well or poorly, but these events might not be the best setting for providing one-to-one feedback as they are a group ceremony and the feedback will usually have been delayed by a few days.

I've written previously about the importance of radical candor - most team members would want their peers to provide constructive feedback directly while still demonstrating that they care about them. This is especially critical when the behavior violates the working agreements defined by the team. If the offending team member does not receive direct and caring feedback, their behavior is likely to recur and they could find themselves isolated and ostracized by the rest of the team without knowing what they did to deserve this.

One way to turn these wishes into a self-fulfilling prophecy is to model the behaviors which we would like to see from our team members. When you perceive that a team mate needs help, ask if they would like it before they ask you for it. When you see them doing something wrong, ask for permission to provide them with feedback.

Let's be the change we wish to see within our teams!

(As is often the case, one of the learners in a course I taught this week provided the inspiration for this article, so thanks Maca!).

The PMBOK® Guide, Sixth Edition defines Earned Value as "The measure of work performed expressed in terms of the budget authorized for that work." Notice that the word "value" does not show up anywhere in that definition.

On projects which are following an agile or adaptive life cycle, the expectation is that work items such as requirements or features will be completed end-to-end. This includes meeting the quality requirements of all key stakeholders so that we can be confident that we can ship the work items to a client. If a framework such as Scrum is followed, these work items are batched into Potentially Shippable Product Increments whereas on those projects which are following a continuous flow based delivery approach, we can hand them over as we go.

On these projects, while final business benefits might not have been realized yet by our customers as those will normally lag delivery by days or even months, we might claim that what we've earned is valuable.

However, when we consider projects which are following a waterfall or predictive life cycle, because of the batch, phased manner of those approaches, the time for the first customer handover of capabilities and the time between subsequent handovers is usually prolonged. As such, until we have delivered a project output which will directly enable our customers to realize business benefits from it, have we actually earned any value?

Writing a Business Requirements Document or creating a design might be necessary by-products of the delivery process but if a project is terminated with just those having been produced, its unlikely that a customer would consider they had received anything of real value.

Please don't misunderstand my point.

I believe that Earned Value Management is a valuable, objective tool for both determining a project's performance and for forecasting where we will end up when it is used appropriately. Appropriate usage includes such elements as using an objective, verifiable method for determining how much progress has been made for each work package and that prerequisites such as work package-level budgeting and financial actuals reporting are easily available.

I'm just questioning why we would use the word "value" when referring to what we have earned in the name. Perhaps, for waterfall projects, we should rename the measure to "Earned Delivery Value".

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.

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.

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.