Blog


Leadership & Effective Decision Making on High Performance Teams

Trust, Vision and Ownership

In a previous post, I identified "3 Necessary Conditions for 'Going Agile'": Trust, ownership and vision. There, I used up my quota of blog space by focusing on trust and its impact on a high-performance team.

Here, I will continue that voyage by exploring ownership.

High Performance Defined

To get started, here’s a definition of a high-performance team from Wikipedia:

A high-performance team (HPT) can be defined as a group of people with specific roles and complementary talents and skills, aligned with and committed to a common purpose, who consistently show high levels of collaboration and innovation, that produce superior results. 

Common characteristics of HPTs include:

Participative leadership Open and clear communication Clear goals, values and principles Mutual trust Managed conflict Flexibly defined roles and responsibilities Coordinative relationship Positive atmosphere Continuous improvement

Nice, right? Who wouldn’t want to have more of that in their organization?

Delegation and Decision Making

With the characteristics described above, ownership of and attention to results is distributed as equally as possible. To accomplish this, decision making is taken up by various team members so that “the call” is no longer the domain of any single individual, especially not “the boss,” because command and control is simply too slow.

Distribution of decision making, aka delegation, is a great deal more than “Either you do it or I do it.” To avoid that mindset, I coach my teams to experiment with a matrix that provides four types of delegation:

Type 1: Decisions that only the leader can make/take - Type 1 can be made with or without consultation/discussion/buy-in with/from the team, though consultation is of course preferred. Type 2: Decisions that individuals/the team can and should make/take themselves, but need to first run by a leader - In the event of a “tie” or a disagreement on how to proceed, the individual/team calls it. If the individual/team is not willing to take accountability, then it reverts back to a Type 1; there is no “Type 1.5.” Type 3: Decisions that individuals/the team can make/take themselves, and inform the leader of after the fact – These decisions can be made either “contemporaneously” or “routinely.” Type 4: Decisions that individuals and team can make/take themselves. In other words, the “Just do it” method.

Technically, there’s a fifth type as well:

Type 5: Wait until you are told what to do by the leader.

We don’t want Type 5 to be an option. Why? For a boatload of reasons, including these: No one person can know as much as a talented team, and being told what to do demotivates talented individuals and removes accountability.

Where is the Team Today?

To begin the distribution journey, start by developing a picture of your team’s present conditions. Grab the team and the leader, a pad of post-its and some pens. Crowd source a divergent list of all the decisions that need to be made over the course of the coming month. Have an unfiltered brain dump and fill the white board.

Next, affinity map the individual decisions to converge on topics and themes. Using those groups, build a matrix, placing topics/themes/details in rows and each of the four delegation levels in columns.

Then, like planning poker, have each team member pick a number from 1-4 to indicate what type of decision they think should be applied to the topic at hand today. The range of votes may or may not surprise the participants.

Then, discuss the results and see if both the team and the leader can agree on “where things are.”

Newly formed teams typically start off heavily skewed with lots of Type 1’s, and maybe a few 2, 3, or 4’s, while more experienced teams tend to have a more even distribution of all types.

Envision the Future

Once both the team and leader have a picture of where they are today, rinse and repeat the poker rounds for where folks want to be in the not-too-distant future, like the next sprint or the end of the next quarter.

As a team matures and becomes more gelled and performant (retrospectives help on this path), things should move as far to the right of the matrix as possible. Loads of type 4’s, 3’s, a few 2’s and almost zero 1’s is ideal.

Why? Because moving decision-making deep into the team and away from “the boss” reduces bottlenecks and wait times, reduces waste and multiplies by orders of magnitude the speed at which a team can move, experiment and learn.

Put a date on the calendar to do this exercise again, perhaps in three months. A team and its leaders should be careful not to build the future state matrix once and then never revisit it out of a misplaced need for consistency or a fear of stretching out of their comfort zone. Instead, remember to regularly inspect and adapt. 

Group Decision-Making Models

As decisions move into the realm of the team, a common issue that comes up is how exactly they should go about making them without resorting to asking the leader: “What should we do about this?” (by the way, if you are a team leader and you hear that question too often, try simply answering with: “What would you do if you were me?” More on this approach here.)

There are many models that can help a team choose options when it comes to team decision types 2, 3, and 4 (consult first, inform after or JFDI, respectively). None of these models are perfect, and each has its own strengths and weaknesses:

Consensus – A collaborative approach. Typically requires that the majority approves, but also that the minority agrees to go along. In other words, if the minority opposes the idea, consensus requires that it be modified to remove objectionable features (see: Fist to Five). Since everyone gets a voice, consensus is both useful and appealing, although it is also potentially dangerous. It can quickly devolve into a battle for who is willing to argue their point the longest, or a watered-down compromise. Advice – A simple form of decision making where any individual can make the call. But, before doing so, they must seek advice from all affected parties as well as those with expertise on the matter. The individual, however, is under no obligation to integrate every piece of advice they receive. Random – The group leaves the choice to chance. Put the options in a hat and pull out the winner, roll the dice or flip a coin. Unanimity (or “12 angry peers”) – The group discusses the issue until an agreement is reached by all those involved in the situation. I Can Live with It – Anyone might have well-reasoned objections to a given decision. However, they agree to work toward the goals of the decision anyway. Solidarity – Unwavering commitment wherein individual will is suppressed for “the good of the group.” Rock Paper Scissors – See “Random.” :) Experiment

Different decisions call for different decision making models and types of delegation. Some teams may not be ready for all of the types covered above, and not all types are the best fit for any given team.

For best results, try to come to an agreement on the following:

(Type 1, 2, 3 or 4, or any other nomenclature that fits your culture) Which one will be used for the decision at hand today Which one the team wants to use tomorrow

See what works, see what doesn’t and continuously improve. Not only will the team experience a significant increase in productivity, but there will be a greater degree of trust and innovation as well. Once again, that is the promise of truly embracing agile.

Linguistics in Agile: Top 10 Anti-Agile Terms

Agile practices have introduced a new lexicon for people to absorb and understand. Happily, along with the useful terms comes a more entertaining vocabulary.

Here are my top 10 favourite anti-agile terms:

Agile in Name Only, or AINO: Companies that have adopted agile frameworks and practices without embracing the cultural changes required. Dark Scrum: Abusive forms of Scrum, where the framework is misapplied to oppress and exert power over developers. Ron Jeffries introduced this term in September 2016. FrAgile: Agile practices that are performed without rigour or discipline. FrAgile provides an excuse for poor quality development that avoids accountability. Lipstick Agile: Agile practices cosmetically applied without any understanding or noticeable difference to the true nature of development. In other words, you can put lipstick on a pig, but it will still be a pig. ScrumBut: Scrum is "adopted," but dysfunctions are accepted by the team as the standard way of working. The syntax for this is (ScrumBut)(Reason)(Workaround). For example, "We use Scrum, but we have thirty-four people in our development team because we are working on a complex project.” Scrumdamentalist: An evangelically pure follower of Scrum practices who operates from an ivory tower, typically with a two-day CSM "qualification" and no experience. Essentially, scrumdamentalists have no sense of reality. TrAgile: Tragically implemented agile frameworks or projects that end in tragedy. In these situations, agile practices are nominally in place but without true understanding or tangible improvement. For example, daily Scrums which contain 32 people, last an hour and consist of everyone giving a status report according to a Microsoft Project plan. Wagile: A hybrid of waterfall and agile development practices resulting either from desperately trying to save failing projects, or from slipping back to waterfall from agile. By completing several short waterfalls, teams delude themselves into thinking that they are agile. At best, this adds shorter iterations, agile walls and daily meetings to failed waterfall projects in an attempt to reduce overall risk and appease management. Water-Scrum-Fall: A failed implementation of agile where requirements gathering is completed first, and teams then perform the implementation before the results are passed to the deployment team for eventual release. Zombie Agile: A blind adherence to agile practices without adopting the mindset required to make them work.

Please tell me about your favourite agile (or anti-agile) term in the comments section below.

#NoEstimates: Crazy Talk, or Agile Compatible?

A couple years back, I started hearing about an interesting movement in the software and web development community called #NoEstimates. At the time, I was fresh out of CSPO and PMI-ACP certifications, and I naturally started wondering about this movement that was too new to be taught by the courses I took to earn those certifications.

I had colleagues who were adamant that we avoid estimates in most cases, while others insisted it was insane to suggest that accurate estimates were not always necessary or possible. Before forming my own opinion, I decided to examine as many sides of the discussion as I could and read up on the thoughts of various writers and experienced professionals in the community.

What I found were well-reasoned arguments on both sides. However, one thing that bothered me was that people who did not favor implementing a strictly defined agile framework didn’t tend to want strict estimations either, while those who wanted to implement a more elaborately defined agile framework also tended to support formal estimates.

It made me wonder – can #NoEstimates and agile coexist in the same team? Did being agile and Scrum certified mean that I automatically needed to reject and exorcise our team from this dangerous school of thought? I didn’t think so.

Don’t get me wrong – Scrum and other agile frameworks explain a thoughtfully evolved process for estimation that is rock-solid, clearly defined and often 100 percent part of the framework. However, not all agile frameworks are the same. Many teams use formal estimates with great success, and I want to be clear that I’m not advocating that there is one correct answer for every team.

The only thing I’ll advocate in this debate is to consider reasoning from all sides. To help facilitate this, I’ve prepared some points that are inspired by some respectful and intellectual discussions I’ve noticed on LinkedIn, various web development blogs and conversations with other professionals.

Below is a summary of some of the points that have stood out to me from the various discussions. Of course, this list does not contain every point that can possibly be made, so feel free to share your own points and express your own opinions in the comments section at the end of this post.

Points Supporting Less Emphasis on Estimates
For some teams, estimates are often inaccurate. While teams attempting to adopt Scrum and other estimate-supported agile frameworks will probably want to refine and improve their estimation process before abandoning it, some experienced programmers have found that the teams they work on over the years tend to have inaccurate estimates. They point out that these estimates often err on the side of over-optimism.
Some people intentionally provide inaccurate estimates. Some people believe in overcompensating, for example doubling their initial estimate to create a timeframe that’s twice as long. While this might ensure that fewer estimates are overly optimistic and fewer deadlines are missed, this can be problematic if the goal is to coordinate with other teams like marketing and sales, who might be caught off-guard by an earlier-than-expected release.
In many cases, accurate estimates are too difficult to provide. For example, if you’re being tasked with building an integration with a system or API you have little experience with, it could be challenging to form an accurate estimate. A lot of research would be needed, and necessary documentation could be inaccurate or lacking. There could be other factors, like the quality of libraries or wrappers provided for various programming languages, API stability, ongoing support and security, which could also affect an estimate’s accuracy.
Estimates are often misused. Rather than viewing estimates as a basic guess, teams can be tempted to treat them as hard deadlines complete with budgets assigned and people held accountable. Similarly, stakeholders often express disappointment when finished work isn’t delivered per the original estimate. In the very worst cases, teams are punished for needing more time than originally estimated, which can lead to a demotivated team, less accurate work and even less accurate estimates.
Estimates don’t make work ship faster. Any given work takes a set amount of time to complete, regardless of the estimate applied to it. The process of estimation, justifying estimates, explaining why actual work time varied from estimates and all other estimation-related activities can serve to slow down the team’s ability to ship work and deliver value.
Some teams become too focused on estimates rather than prioritization, scalability, careful scoping or other factors. Some teams divert so much attention to delivering per the estimate that they make sacrifices in other areas, like scoping the work carefully or making sure the work is scalable. This is harmful for the product and potentially delivers less value long-term. Points Supporting More Emphasis on Estimates Estimates can be made accurately, and there are ways to increase accuracy. The more you estimate, the better your estimates should become. Eventually, you can compare upcoming work to a larger historical data set of previous work performed by the same or similarly skilled and experienced team members. The more historical data you have, the more accurate your estimates will be.
Other teams need to plan business decisions around estimates. Marketing teams need to know when to launch marketing initiatives around major launches or updates, and sales teams and customer success teams need to know which features will be available, and customer support teams need to be staffed properly for a large release. No team wants to feel like they’ve wasted time and efforts by preparing for the wrong date, and they also don’t want to miss major opportunities by arriving late to the party.
Estimation can help set more realistic expectations. Some other team members or managers might take it upon themselves to assume how long work should take. Wouldn’t you rather set the expectations with your own estimation rather than open the door to other estimations from people who haven’t studied or scoped the work as carefully?
Estimates do not mean your workflow cannot be continuous. If you finish early in the sprint, you can pick up future sprint or backlog items that fit into the remaining time. How do you know they fit into the remaining time? They’ve already been estimated! In this way, estimates do not need to reduce work efficiency.
You need at least some kind of estimate to do an effective cost-benefit analysis. How can you know if it’s even worth doing the work if it could potentially take so much time and money that the costs outweigh the value delivered? How do you know this work is more valuable to pursue than other work, if you don’t estimate how much effort each is required to complete? Imagine agreeing to have a plumber fix a dribbling sprinkler head with no estimate and then learning the cost will amount to your entire life savings.
Estimation can reveal inaccurate expectations with burndown charts and other tools. Burndown charts can help show if work is proceeding at expected paces or if it looks like scope, time or budget will need to be adjusted to ensure success. This can be done without punishment for inaccurate estimates, but simply by responsibly tracking progress and comparing to customer expectations. Identifying any significant discrepancies early on can help moderate and readjust expectations to avoid unpleasant surprises.

Again, this list is not exhaustive, and not all points will apply to all teams. Some of these concepts may seem like they’re taken to the extreme, but I’ve personally seen, heard and read these exact concepts from real teams and professionals. Please share your own opinions and experiences in the comments section below, and let me know what you think about the value of #NoEstimates.

From Scrum Master to Product Owner: A Journey

Many of us have transitioned from either a sofware engineer role or a QA engineer role to a Scrum Master. This is a natural path for those who want to become a servant leader, working with the teams/stakeholders, coaching people and leveraging agile/Scrum across the organization. Furthermore, it requires a different mindset with more focus on soft skills.

It’s also common to see software engineers and QA engineers turning to a product owner role.

Therefore, how difficult is it to be a product owner when you are a Scrum Master? Well, there are a lot of challenges, due to the fact that these two roles have different perspectives and skill sets.

Scrum Master: Abandoned and Chosen

Once upon a time, a company I worked for as a Scrum Master decided to get rid of all Scrum Masters for various reasons—the most critical being budget.

Consequently, the role of the Scrum Master merged with the engineering manager, and the engineering manager took over the Scrum Master’s responsibilities. As usual, some of the engineering managers weren’t prepared to assume this new role because either they were toxic to the teams or hadn’t been trained enough in Scrum.

At the same time, all Scrum Masters were laid off by the company due to major cuts on the budget, my boss asked me if I would like to become a product owner once the team I was acting as a Scrum Master for didn’t have a full-time product owner.

I was already doing part of the product owner duties: working with the stakeholders to gather the requirements, writing and prioritizing the user stories, digging into the product and envisioning its growth, working close with the teams, and being the voice of the customer.

The team’s product owner was so busy with another priorities that she didn’t have enough time to focus on that particular team. I took the initiative and action on behalf of her.

A desire to deliver a delightful product to my customers was always on my mind. With a lot of excitement and anxiety, I finally accepted the challenge of officially taking on the role of the product owner.

New Journey: Ups and Downs

Several Scrum Masters like me have faced many challenges with their product owners and sometimes they become the impediments for the team. As a Scrum Master, we should address and remove them.

As the first time as a product owner, I didn’t want to be the impediment and cause of the difficulties for the team. As a product owner, I wanted to create the user stories using the INVEST model, write good acceptance criteria, groom the user stories with the team, prioritize the backlog, be available to the team, define a goal for every sprint, and so on.

I was doing my part, however how about the Scrum Master (in fact, the engineering manager) for the team and product? Well, she became the impediment, because she was not doing her part.

I was frustrated due to the fact Scrum was not being implemented as it should be and the whole benefits were being lost. The team was still looking to me, waiting for me to remove this impediment, but I wasn’t supposed to take action anymore, only concentrating on the product.

On the other hand, I was the Scrum Master before, so I still had the ability to coach the new Scrum Master, no excuses. However, the engineering manager didn’t want to follow coaching and I was reprimanded when I was told I was on the product side and couldn’t influence the engineering process anymore.

This is the hardest part of converting from a Scrum Master to a product owner role: your brain has to do a mind-shifting and move away from the old habits and responsibilities.

For several months, I continued facilitating the sprint planning and review, because the Scrum Master didn’t want to do that or didn’t know how to do it, but the product had to be delivered anyway.

Resilience and Working Hard for the Team and the Customer: Reward

It might take time, but you can adapt yourself to the new norm from Scrum Master to product owner. In the beginning, the path seems long: our focus is different, more on the business side, staying closer to our customers, and understanding their pain points.

If you’re faced with this challenge, don’t give up, make all your efforts to switch gears and mindset, and the reward will come.

What did I learn? Make the team feel part of the product, and they can help you to drive the results and goals of the company. The team will support you in the process for a while if you are open, transparent and trust them.

Be present in every retrospective and ask how you can improve in a very honest conversation.

Be humble and listen. Change your attitude, demonstrate that you’re working hard not only for the success of the product, but for their success as well.

As a new product owner, learn every piece of the business rules, talk to the stakeholders, create effective roadmaps and be the “CEO of the product.”

Last, but not least, go to conferences, training, read books about product management, be involved in the agile community. It’s now time to focus your knowledge and strengths in the product ownership.

New Hope: Continuing the Journey

New challenges appear every day and this is a good sign because the world keeps evolving and each challenge is an opportunity to grow in your career and as an individual.

Improve the method of creating the user stories, leverage the product, streamline the process of delivering the features continuously, go outside of the building and listen to your customers, experiment new things and finally delight your stakeholders with innovative products.

The path and the migration from a Scrum Master to a product owner can be complicated; however, it’s rewarding and valuable for several reasons: business model understanding, value proposition creation, industry standards and terminologies in practice, customers and partners relationship, channels and segments applied, generating revenue by different methods, applying innovation and open new markets, and the list goes on.

Are you also transitioning to a product owner role and need some help? Feel free to leave your comments or questions and I’ll be glad to help you out.

How to Get Your Teams to Estimate Better

“We need to get better at estimating,” an experienced member of a Scrum development team once told me. “Management is getting concerned that we keep coming up short on our commitment.”

“Really?” I responded. “What have you been committing to?”

“Thirty story points” she said. “We get there about 50% of the time. In a couple of recent sprints, we’ve even exceeded thirty points, but the last sprint marked the third time this quarter that we fell short of our target.”

“Why was your forecast off target, do you think?” I asked.

“Well, things come out of left field occasionally. You know, stuff that couldn’t be anticipated in sprint planning,” she answered.

“So, why are you estimating effort if you can’t predict what will happen in the sprint?” I said.

Now, at this point I want to make clear that I am not one of those who say that development teams should not estimate effort. For me, the ability to estimate independently is an important part of the autonomy of teams. What I was trying to do in this particular conversation was to get the team member to consider why teams estimate in the first place, and what “commitment” means in that context.

It is not just a matter of those doing the work being the only ones who are able to estimate effort, which I believe to be true. I recently participated in a large multi-team project of effort being estimated by a centralized systems analysis unit. In that project, the development teams were involved in estimating, but it was the systems analysts’ forecast that was being communicated to the customer. The result was massively inflated customer expectations, and retrospection revealed that the teams’ estimates were about four to five times larger—and thus far more accurate--than those of the analysts.

Why Estimate Effort?

So, development teams make the best and most accurate estimations. That’s all well and good, but it still doesn’t answer the question of why estimates are necessary in the first place.

Scrum is a “pull” system in that it balances demand with the team’s capacity to do work by giving the team control over how much work is brought into the sprint. No one can tell a development team how to do its work, or how much work it must do.  Effort is estimated – in story points, in the number of stories or in person-hours – so that a judgement can be made about how much work can be pulled in from the product backlog in order to meet the sprint goal.

When either team members or their managers start to fret about the team’s commitment in terms of its target velocity, it is a sure sign of old muscle memory kicking in. After all, the velocity is a forecast, not a commitment. The team’s commitment is not to its velocity but to the goal that was agreed upon in the sprint planning. And, in any agile environment, commitment means that, given the information we have right now, the resources we have at our disposal and our judgement about our capacity to do work, we think we can get to a certain point by the end of the sprint, and we are going to do everything in our power to get there.

Therefore, a commitment can never be equated to a guarantee. It is akin to the moment a football team walks onto the pitch: the team is committed to winning the game, but there are too many variables in play (not the least of which is the opposing team!) for victory to be guaranteed from the start.

When managers ask me questions about the target velocity of the teams, my first response is to ask them why it should be any concern of theirs. They typically mumble a reply about making sure the team is working to plan, or being efficient. A brief chat normally follows in which I point out that management’s concern should be with business outcomes and with making sure the teams have the environments and tools they need to deliver them, not with the team’s tasks.

Target Velocity and the Sprint Goal

So, at this point we’ve established that target velocity is a concern of the development team and no one else (OK, the product owner needs to know about velocities so he or she can make trade-offs in the ordering of the product backlog, but that’s another story entirely). Estimates simply need to be accurate enough for the team to confidently identify the items at the top of the product backlog that can be worked on to meet the sprint goal.

A good product owner will give the developers extra wriggle room by articulating the sprint goal to customers and stakeholders independently of the product backlog items (PBIs) or the stories that might constitute it. By giving the upcoming increment a named state, or by describing the expected value in a few sentences, the product owner can work with the team if a mid-sprint descoping of the forecast is needed, without compromising the sprint goal.

All of this means that while the team’s estimates do not demand the same precision as task estimation in waterfall-based planning, they do still need to be accurate. Actual velocities that go up and down like a roller coaster help no one, and some level of predictability is needed. I’ve seen teams agonize over what a 13-point story should look like, and have even been shown handbooks in which reference PBIs are described for each number in the Fibonacci series. In my experience, this type of overly complicated approach never works.

"Smaller" is More Predictable

There is only one way to improve the estimate of effort for PBIs: breaking them down into smaller PBIs. Think for a moment about the values most often used in planning poker, for example: 1, 2, 3, 5, 8, 13, 20, 40 and 100. They loosely follow the sequence in which each number is the sum of the previous two.

This raises the question, why “20” instead of “21”? Simply, because “21” would be too precise. In effect, we are saying that anything more than 13 can be considered large, and will probably need to be decomposed.

The larger numbers in the sequence and, more specifically, the larger gaps between them, reflect a corresponding level of uncertainty. Suppose the team thinks a PBI is bigger than an 8, but is probably not big enough to be a 13. In that case, it might “precisely” be a 9, 10, 11 or 12. However, they can only categorize the PBI as either an 8 or a 13. Essentially, the larger a PBI is, the greater its possible variation from its predicted effort. On the other hand, if all the stories are, say, a 5 or smaller, then it is only when a PBI sits between a 3 and a 5 that you begin to see significant variance.

It doesn’t really matter whether the team uses stories and story points or not, as long as the underlying goal is still the same: to break the PBIs down to the smallest size they can be and fit a number of them into the sprint. In my view, this is the only way that a team can reliably improve the accuracy of their estimations.

5 Signs Your Team is on the Path to Agility

Some of the comments on my previous article, Mixing Roles in a Scrum Team, explored the idea that the successful mixing of roles is dependent on a team’s maturity level.

However, this begs the question: how can we accurately assess a team’s maturity?

In the article Agile Self-Assessments, Ben Linders gathers many tools which any team can use to assess its maturity. Based on the results of such assessments, agile leaders can make informed decisions on how to proceed with team structuring.

Since I’ve already shared some of the signs that a team is lacking an agile mindset, I would now like to share five signs that an agile team is on the right track.

1.       A Release at the End of Each Sprint

The ability to release at the end of a sprint indicates several positive team traits, the most important of which is that the team understands and adheres to the definition of done. That is to say, all user stories which were finished in the sprint are in a releasable state. In these situations, “releasable” usually indicates that the product is suitable to be released to an internal integration environment, not to the end customer. However, an internal release is still a release nonetheless.

2.      A Staircase Burndown Chart

Having small user stories which can be finished in a short amount of time is a talent acquired by both the product owner and the team as they move upwards on the agility ladder. A staircase burndown chart showcases the team’s understanding of prioritization as well as the importance of delivering the product in small chunks rather than as a full-blown application.

3.      Gathering to Solve Problems

If you see the team sitting together around one computer and problem solving as a group, this reveals that the team is sharing knowledge, brainstorming, seeking a solution and, most importantly, that they are truly working together as a team.

4.      A Prioritized Backlog

Developing an estimated prioritized backlog is the main responsibility of the product owner, and he or she can’t do so without the help of the rest of the team. For a backlog to take shape, the product owner will need the team to estimate and clarify user stories, ask the proper questions and form adequate acceptance criteria.

5.      Short Planning Meetings

In general, the shorter the planning meetings, the more mature the team. This is because short meetings typically mean that many of the team’s uncertainties were already clarified during the backlog grooming session or via frequent communication with the product owner.

These are just a few of the many signs that a team is mature, but they are the ones which can be most easily spotted by agile leaders of any level.

Do you know about any other indications that a team is on the path to agility?

I would love to read about them and any other thoughts you may have in the comments section below.

3 Necessary Conditions for “Going Agile”

In the terrain of agile software development, there are three rivers - Trust, Ownership and Vision - which flow and converge into a confluence that helps to create the necessary conditions for a high performing, self-managing team. A team that adapts quickly to what its customers want, delivers great business value at a sustainable pace and is filled with happy people. In short, the ideal agile team.

This is true regardless of the industry, the geographic location and the organizational size. And, if you’re in the software development field like me, it makes no difference whether you’re using  SAFe, LeSS, DaD, XP, Scrum, Kanban, Scrumban or some new framework of your own.

Sure, at times the waters can be choppy and the currents unpredictable. But one thing is certain: a disruption of any of the three rivers will result in a true storm. Either the crew will start thinking about mutiny, or the boat will run aground on one of two shallows: command_control or anarchy_chaos

Beware the Twin Sirens:  Command and Control

The biggest challenge for leaders in a transformation is often that of leaving command and control behind. While they can easily articulate a clear vision of where to go, leaders  tend to have a hard time refraining from telling people how to get there.

In my experience, many of the difficulties these leaders face result from the fact that the leader can no longer play the old role of the hero with all the answers.

In his great book "Humble Inquiry", Edgar Schein says:

“Our culture emphasizes that leaders must be wiser, set direction and articulate values, all of which predisposes them to tell rather than ask.” (emphasis is mine)

The simple task of coaching and encouraging leaders to ask the right questions instead of providing the answers begins to catalyze them at every level. This reaction will in turn multiply the speed at which decisions can be made and new learning can take place. (For more on change, see my previous blog post: Personal Change: Unlock Successful Organizational Transformation)

Trust Above All Other Things

The transfer of power, which allows for rapid inspect and adapt cycles, requires great trust in individuals as well as in teams. Trust can be the difference between success and failure, especially as the boat heads into the rapids. In those inevitable whitewater situations, the importance of trust should not be underestimated. As Stephen M.R. Covey says in his book "The Speed of Trust":

“It [trust] is the one thing that changes everything. If you promote a high-trust environment where you have capable people who do what they say they are going to do, in my experience, anything is possible. If there is not a high-trust environment in place, virtually everything, including the most mundane activities, can feel like an ordeal for the group and impede progress. Over time, I have found that trust, based on competence and character, trumps all other attributes.”

Is Your Organization a High-Trust Environment?

A lack of trust in an organization can manifest itself in a multitude of artifacts and patterns:

Deadlines and forced commitments (instead of targets and goals) Roadmaps are created but hardly ever updated (instead of product visions that are combined with inspect and adapt) Waterfall over the wall / it’s not my job / us and them / barriers / silos (instead of collaboration / cross functionality / build / measure / learn) Individual KPI’s imposed from above (instead of team-selected accountability systems) Manager / subordinate performance reviews and stacked ranking (instead of 360º feedback and team / peer reviews) Small “Inner Circle” of communication / information / lack of transparency in “leadership" (instead of transparency and a circle of safety which extends to the “outer edges” of the organization) Focus on performance by numbers, burndowns and velocity (instead of a people-first approach which focuses on inner work life, team happiness/morale, OKR's, delivery of value and outcomes instead of outputs) Lack of mutual respect & transparency / leadership relying on “authority” / back channel communications / disengaged workforce / fear (instead of individuals and teams giving it their all with no holds barred)

Observations on the presence of the above artifacts and patterns are generally qualitative. If you’re more of a quant, take a look at the following two-part assessment that any organization or team can conduct. It comes from Pollyanna Pixton’s book "Agile Culture".

Assessment Part 1: Leadership

The first part of the survey measures leadership’s trust in their team.

Prompt: As a leader, indicate a score between 1 and 10 which response best reflects where you are for each row in the table:

Low (1-3)

Medium (4-7)

High (8-10)

Score

I trust no one on my team.

I trust some of my team.

I trust my entire team.

 

I require that everything must be defined before the team can do anything.

The big things, such as cost, schedule, and scope, must be defined before the team can do anything.

I honestly accept and allow genuine ambiguity and uncertainty from my team.

 

My team cannot take risks without my approval.

I let my team take risks – but only when the risks are low.

I encourage my team to take risks in order to deliver value more effectively.

 

 

 

Average (total / 3)

 

Results: Average individual scores, and then average those across the organization. This will tell where leadership believes it is on the Scale of Trust (max = 10)

Assessment Part 2: Team Members

The second assessment gets to the roots of how team members feel about the level of trust coming from leadership.

Prompt: As a team member, indicate a score between 1 and 10 that best reflects how you feel about each row in the table:

Low (1-3)

Medium (4-7)

High (8-10)

Score

I have to get permission to do anything.

Managers and processes sometimes get in my way.

I am trusted to do my work.

 

I am told what to do and how to do it.

I can sometimes find my own solution.

I am trusted to always be able to find my own solution.

 

If I don't do things the approved way, I am at risk.

There are certain low-risk things I can do.

I can take chances without feeling at risk.

 

I always must give the organization exact numbers.

I sometime can tell the organization when I am uncertain.

I can honestly tell the organization when I am uncertain without risk.

 

 

 

Average (total / 4)

 

Results: Average individual scores, and then the scores across all team members. This will reveal the team’s position on the Scale of Trust. (Max = 10)

What is Revealed? Compare both the leadership and the team member overall averages. Is there a gap? (If leadership and team scores are identical, then congratulations, everyone shares the same view!) How close to “10" are the final scores? Is there anything the organization can do to raise the score?? (If your scores are all at 10, share the secret sauce, please!)

If there is a gap between the averages of Part 1 and Part 2, this indicates a cultural disconnect honesty and openness.

On the other hand, low scores on both Part 1 and 2 indicate a different kind of problem: a known lack of trust on an organizational level.  As Ricardo Semler asks in his book "The Seven-Day Weekend" 

“If you don’t trust the people on your team, why are they on your team? For that matter, why are they in your organization?”

Running Pixton’s assessment will require a leap of faith. After all, agile doesn’t promise to fix anything, it just promises to bring the organization’s issues to light.

Point the Boat in the Right Direction

If there is a significant gap between the team and leadership assessments, or if the overall level of trust is low, ask yourself the following questions:

Can folks have an open discussion about causes for conflict that center around trust? Can leaders and team members develop a shared understanding of their expectations around trust? Can anyone generate new practices and agreements regarding trust? Understand What Trust Looks Like

Here’s the good news: there are various tools and exercises that can help guide the way by showing teams and leadership how to paint a picture of what “trust” means to them. 

Alexey Pikulev has run numerous divergent exercises over the years with agile teams to explore elements that influence trust. He has identified the following most frequently occurring themes:

Clarity Connection Compassion Value Competency Commitment Contribution Consistency Paint a Picture

Pikulev has put the above themes together in the form of a “canvas” that teams can use to paint a portrait of what trust means to them:

To get started, participants can begin adding items to each theme. They can fill out of the canvas in a couple of different ways:

Silent brainstorming on all the themes Rotating flip charts with one group per theme

I’d like to add two of my own suggestions to Pikulev’s approach. The first comes by way of Jurgen Appelo and his ideas from Management 3.0: as the participants are filling out the canvas with specific items in each theme, they should consider four discrete aspects for each theme:

Trust from leader(s) to the team (Part 1 assessment) Trust from the team to leader(s) (Part 2 assessment ) Trust among team members Trust in oneself

The second suggestion I’d like to add is that participants label each item with either a “+” or “-,“ thus creating a force field analysis where “+" indicates driving factors (catalysts/nourishers) and “-" indicates restraining factors (toxins/detractors) with regard to trust.

Once the canvas or flip charts have been populated with ideas, the participants can group and converge the items. They then run a voting/ranking exercise based on two characteristics:

Importance: Rank the relative importance of each converged item via dot voting Influence: Rank the team’s ability to impact a change in each converged item

At this point, participants will have constructed a pretty clear image of what “trust” means to them. They should have a firm grasp on the following:

Things that add to trust and things that take it away What factors are collectively important for creating trust What the team feels is within their current sphere of influence to change, and what they feel is outside their control Avoid Scylla and Charybdis via Ownership

In light of the results of both the trust assessment (which shows where things currently are) and the trust canvas (which shows where things could be), what kind of picture emerges? Have areas of current or future conflict reared their heads?

Often, the important issues need to be resolved through a change in delegation and a realignment of ownership. However, big gaps in ownership and trust are likely to change only with intervention from powerful allies within the organization. Instead, explore things through the lenses of “start, stop and continue” or “keep, add, less and more” (or any other retrospective technique). Collectively come up with safe-to-fail experiments,  gradually nudge the delegation levels deeper and deeper into the team, ensure continuous feedback, honor the prime directive and always inspect and adapt.

In short, don’t be afraid to set sail the agile way -- you're sure to make it past the treacheries of a transformation without losing any crew.

Enjoy the Journey

The right kind of organizational environment – one that is filled with mutual and ever-growing trust, ownership and vision – creates a palpable flow of energy and innovation. It fosters teams that can respond quickly to changing currents and obstacles, and enables a voyage where everyone knows and owns the results of their efforts.

It results in a productive and joyful journey that delivers delight not only to an organization’s customers but to all members of its crew as well.

And that is the promise of truly embracing agile.

 

Agile Tips for Working with Non-Agile Teams

During agile training, we’re taught that everyone in our team should operate within the agreed upon agile framework. However, the question remains: how should we operate when interacting with less predictable teams outside of our own?

Once we get into the agile groove, it’s easy to feel complacent. After all, we’re pushing along at a productive pace and delivering shippable features iteration after iteration. Having all our team members working together with the same principles, methods and frameworks is very comforting – so comforting, in fact, that we might be afraid to operate in any other way.

On the other hand, the world beyond our nice little agile haven is a terrifying, stagnant realm filled with waterfalls leading nowhere and rigid, outdated plans that bend the laws of time. It’s easy to fear interaction with the scary, non-agile world, and it’s also easy to get frustrated when our colleagues or customers don’t have the same liberating habits that we do.

However, for many of us it’s impossible to avoid working with non-agile teams completely – and, as a matter of principle, we shouldn’t refuse to work with others before giving them a fair shot. I’d be willing to bet that almost all of us have, at some point, been required to collaborate with an internal or external party that has little to no agile training, let alone any kind of certification.

While you may be unlikely to suddenly convert the other side to an agile framework overnight, there is still hope. To help you smooth the edges of these sometimes-difficult interactions, here are a few simple, agile tips for working with non-agile teams.

Try Simple Prioritization

If I had to prioritize my advice, I’d prioritize prioritization. The internet is filled with prioritization templates and agile prioritization templates, but you might want to start with something simpler.

If you’re working with an external customer, chances are you can’t afford to exclusively accept agile customers while telling the rest to find someone else to throw their money at. Similarly, if you’re working with a non-agile party internally, you may be equally unable to control their level of agile training.

One of the most common problems faced by non-agile teams is unmitigated scope creep in the form of numerous concurrent requests with limited direction in regards to priority. In this environment, almost everything seems important, and by the way, why didn’t you finish this other important task over here?

Well, as we all know, the answer to that question is that we were busy finishing a more important task that had a higher priority. But, can we pinpoint how that priority was determined in the first place? If the customer isn’t prioritizing their own requests, then your team will be doing most of the decision-making independently (with some level of external input, of course). The more your team prioritizes on its own, the less customer collaboration takes place – and, as we already know, customer collaboration is an important value in agile.

When dealing with a non-agile customer or colleague who does a poor job of conveying the priority of a task relative to other concurrent requests, it’s usually easy to quickly summarize a bulleted list of the current requests and ask the customer or colleague to rearrange them in order of priority. Without realizing it, they’ll start forming their own prioritized product backlog.

Want to take it a step further? Try using one of the many agile prioritization matrix templates available on the internet. I personally like to keep things as simple as possible, but for a larger project and a larger scale of requests, having additional structure may be helpful to some teams.

Emphasize Progress in Iterations

Some people get spooked when you show them early iterations designed to tackle shippable increments. For many non-agile folks, their instinctual reaction may be something along the lines of, “where’s the rest of it?” or “yes, but we still need x, y and z…” and so on.

In these situations, it’s important to explain the advantages of delivering through iterations. Remember, these colleagues or customers may have never used iterative approaches in their careers, so what seems obvious to us may be an uncomfortable shock for the uninitiated.

The advantages of iterative approaches are numerous, but here are some highlights which might help you to convince non-agile colleagues or customers of its practicality:

Frequent demonstration of features and progress Frequent feedback and communication, which improves subsequent iterations Less likely to deviate from desired outcome Product can adapt to change quickly A cross-functional team can quickly shift resources as needed

You might not be able to get the non-agile party to obey a Scrum Master without question, but explaining the value of iterative and incremental development can plant the seeds of agile and ultimately pay off in the long run.

Suggest User Stories Before Solutions

Another pitfall for many non-agile colleagues and customers is the tendency to jump to a lengthy, prescribed solution without clearly and thoroughly explaining either the actual user need or the problem that needs to be solved. Rather than putting forth well-defined user stories that lead to constructive collaboration, this approach can often lead to the dreaded iterative waterfall that isn’t agile at all.

However, before you can expect a non-agile collaborator to write well-conceived user stories, you’ll first need to explain what user stories are and what their value is to the customer. Since the agile team needs to know what problem their work should be solving before they can build an effective solution, it’s in the customer’s best interest to write user stories that answer the “why” as extensively as possible before getting into too much of the “how.” Starting to develop the solution without clearly understanding the problem at hand is rarely a good idea in any setting, and the same holds true for your colleague or customer’s planning process.

Notice a Pattern?

When it comes to working with non-agile collaborators, the best way to ensure buy-in is to explain the value of agile processes. After all, why should someone be expected to adopt your methods if they haven’t yet seen how those methods can benefit them?

Prioritization, delivering over iterations and writing well-crafted user stories are just a few of the ways you can make your collaborative process more comfortable and effective when working with non-agile folks.

What are some of the challenges and solutions you and your team have noticed while collaborating with non-agile parties? What worked, and what didn’t work? Share your story in the comments section below.