Category Archives: Agile

Measure Agile Teams at Your Own Risk

Agile methods, when done well, will increase the ability of an organization to deliver value to its customers. Teams deliver frequently. Teams move faster.

In Scrum, the total story points delivered every sprint is the team’s velocity. Increasing velocity is good. Decreasing velocity is bad. That’s the conventional wisdom.

Because we want increasing speed, it’s seductive to make a trend of the team’s velocity. Velocity is easy to measure. Because we measure every sprint, it is easy to make a trend.

Predictability is valuable, so organizations start to set boundaries for what “good” variation looks like, and what “bad” variation looks like. Good variation is modest and generally increasing. Bad variation is erratic and hard to use for predictions.

Because we know what is “good” and what is “bad,” it is easy to set targets for these metrics.  But, guess what? When targets get set, and teams get measured against those targets. Who wants to look bad? Nobody. Team members are smart enough to make themselves look good. And there is the problem.

A team that is evaluated against a target will do whatever is needed to achieve that metric. The easiest thing to do is modify behavior to artificially make the data look good. The metrics will get “gamed.”

Measuring, in and of itself, is not bad. Measuring teams, setting targets, evaluating teams, and comparing teams to one another; that’s bad.

If I had to sum this up in one line, it is this:
If you set a target, the teams might hit the bullseye, but might be bullshit.

Do you have a story of metrics that turned into targets that created unintended consequences? Please comment below.

Do you believe you’ve been around targets that didn’t create unintended consequences? I’d be interested in those, too.

Kanban – More than Columns on a Wall

If you’ve slapped up a board that says “to do,” “doing,” and “done” and called it Kanban, that’s about the weakest implementation of Kanban that is possible.

If you’re interested in really harnessing the Kanban framework, you have to go beyond three columns and:

  1. Model your team’s actual workflow
  2. Apply discipline to your policies, work-in-progress (WIP) limits
  3. Measure
  4. Get nerdy with the data

If you want to learn more about using data with Kanban, go get a copy of Daniel Vacanti’s book on agile metrics from leanpub, or on Amazon.  Read it.

Then, get a trial to Actionable Agile. This tool visualizes data, and integrates with multiple platforms. Watch the videos on the ActionableAgile YouTube channel that gives an introduction to the tool’s capabilities.

Now, use the data and a never settle for “this is as good as it gets.” Dig in and improve your process!

There is an “i” in “Agile”

There’s a popular phrase that states “there is no ‘I’ in ‘team.'” This slogan appears on shirts. It appears on posters. It is popular enough that the phrase has been “hacked” and now there is a funny graphic that says “There is an ‘i’ in Team. It’s in the a-hole.”

There is an “i” in “TEAM.” Hidden in the A-Hole. (Copyright belongs to the image’s creator)

What might that phrase mean to an agile team? There is a SolutionIQ article that states “There is no I in Agile” and discusses how teamwork can make or break an agile team. I agree that teamwork is important. But, contrary to the SolutionsIQ heading, there is an “i” in “agile.” And it is important that we remember that the agile team is made up of a whole bunch of “i’s.” Here are some of the ways to make the “i” in “agile” effective. Work to help each “i”:

  • i realize that i cannot be successful if the team fails
  • i look for ways to help teammates
  • i bring new ideas into the team
  • i am willing to take risks
  • i admit when i need help
  • i admit when i am wrong
  • i grow my skills over time
  • i build upon other people’s ideas with my own
  • i bring my whole self to the team
  • i try to not be defensive
  • i realize others bring their whole self as well
  • i realize that the world outside work impacts people at work
  • i take small risks and learn from the outcome
  • i respect my teammates
  • i foster collaboration across the team
  • i use my eyes to observe what is happening on the team
  • i am a “little i,” not demanding the attention of a big “I”

Remember that your team is composed of many individuals, each with their own background, values, and perspectives. Work to be inclusive of those differences as you work toward a common goal.

The Danger of a Proxy Product Owner

Imagine that you’ve read the Scrum Guide’s description of Product Owner role. You  see that in order to be effective, a Scrum Product Owner needs to

  • Keep the Product Backlog groomed
  • Ensure understanding amongst the Scrum Team, and
  • Negotiate with the Development Team

That takes a lot of time and energy. You realize that the role is so involved that you can’t possibly have your current “product owner” fulfill the Scrum duties as well. You are contemplating using a “Proxy” product owner to fulfill the Scrum Product Owner’s duties. The Proxy Product Owner will not be the real product owner, but they represent the product owner and have the responsibility for communicating the product owner’s perspective with the team.

To fulfill these responsibilities, of a Product Owner, the individual in the role must have the

  • time to do the work completely
  • knowledge of the product and customers’ needs
  • authority to make decisions

Can a Proxy Product Owner be effective? Is it a good idea? Will that work? Let’s explore it a little bit.

Problem Proxy Product Owners

Overworked Product Owners can neither keep the backlog groomed nor be available to the team.

An Indecisive Product Owner can kill the team’s momentum.

What is the danger of having a Proxy Product Owner? The danger of using a proxy is that it often masks organizational problems with the way the role is set up. Many times when I hear “Proxy Product Owner” used, it is used as a euphemism for one of these other types of Product Owner dysfunctions:

Dysfunctional Product Owner Models

The Ignorant Product Owner They lack the knowledge necessary to fulfill the role. They are constantly having to go out and gather understanding from someone else who truly has it. Or, worse, they guess at the answer and inject wastefull activity into the team.
The Impotent Product Owner They have no power to make decisions. They have to go play "mother may i...." with people who really make decisions. This delay negatively impacts the team.
The Indecisive Product OwnerThey have all the information and authority to make decisions, but they're still incapable of deciding. The causes of indecisiveness vary, from fear of punishment for wrong decisions to over-analysis.
The Overworked Product OwnerThis person simply has too much work for one human to do. It is impossible for them to keep the team supplied with a properly groomed backlog, leading to frustrating and ineffective Sprint Planning and delivery.

Effective Proxy Product Owner

A “proxy” is someone who can make decisions on behalf of another. If the person filling the Scrum Product Owner role can completely and truly fill all the responsibilities outlined in the Scrum Guide, then you truly have a Scrum Product Owner.

If the term “Proxy Product Owner” is sometimes used when somebody else in the organization has an existing title of Product Manager or Product Owner. When an organization adopting the Scrum framework already has a position description with the title “Product Owner,” role confusion can emerge. In those cases, it can be valuable to differentiate the Scrum Product Owner from the other duties that are wrapped into the existing title of Product Owner. In those instances, I prefer the term “Scrum Product Owner” versus “Proxy Product Owner.”

Regardless of the name for the role, make sure that the position is fully capable of fulfilling the responsibilities outlined in the Scrum Guide, allowing that person the best chance of being effective in the role.

What do you think? Please feel free to comment and let me know what your experience has been.

 

What does a Scrum Master Do?

I don’t know how many times during my years of agile coaching that I have been asked “What does a Scrum Master do?” Yes, the Scrum Master is responsible for effectively using the Scrum framework. Yes, they act as servant leaders for the team. But, what do they do?

We like to feed the birds in our yard, and I have an interest in photography. On Thanksgiving this year, we had our regular flock of sparrows flitting about. They would sit in the bushes, fly to the feeder, eat seeds, and then go back to the protection of the bushes. Because I had the day off, I chose to try to get some good photos of the birds. Of course, as soon as I stepped outside, the birds scattered. They were fearful of the intruder into their domain.

So, what does a photographer do? In this case, I sat. I waited. I counted to 200, slowly, to make sure I was not in a rush. I listened to the birds in the distance. I waited more. I was still, and calm. Eventually, a single bird landed nearby.

Male Sparrow on a Branch

I continued to be still. Shortly after one felt safe with me sitting near their feeder, the others arrived.

Sparrows in a Bush

They left the safety of the bushes to come near the feeder. Then, and only then did I slowly move my hands to the camera, and aim the camera at the birds, and begin to take photos.

The birds behaved as if I were not even there. A squirrel eventually walked along the top of the fence, joining the birds at the feeder.

Squirrel in a Tree Trunk

A woodpecker and chickadees joined the sparrows. I kept shooting photos, making sure to not make sudden motions and scare the birds. All of the sudden, the birds scattered. Wings flapped as the birds took off in all directions.

Sparrow Taking Flight

 

Silently, and without warning, a coopers hawk flew through just above the bushes and landed in the black walnut tree. Coopers hawks prey on birds.

Jouvenile Coopers Hawk

This experience got me to thinking about how we engage as agile coaches. Some folks love to rush in, waving their hands around telling the team to make changes. They correct mechanics of a Daily Scrum. They try to fix all the “non-agile” behaviors. A “coach” who does not create safety will alienate the team. A coach who does not wait will scare people from truly sharing their concerns. And, most importantly, the coach will miss the complexity of the local context.

If I had been moving around in the yard, trying to get the optimal angle for all the shots, I would have missed what was really going on. I never would have seen the hawk. This parallels experiences in coaching. Remember to be still, watch, listen. Try to notice everything that is happening. Take action when the time is right.

Please share your comments. And, if you’re interested in more photos, check out the Dan R Neumann Flickr profile.

Agile 2016 Book Backlog

Every year I leave the Agile conference with a long list of books that I want to read. This year, I thought I’d publish my list. These books were either cited in conference talks or mentioned in hallway conversations. I’ll make updates throughout the week. Please feel free to add a comment and share the book(s) that you heard about this week. Here’s my list:

 Managing for Happiness: Games, Tools, and Practices to Motivate Any Team

By Jurgen Appelo, this year’s keynote speaker.

Management 3.0

Also by Jurgen Appelo.

Being Wrong: Adventures in the Margin of Error

This was mentioned in Michael Tardiff’s talk titled “Finding Agreement when Everybody is Right

On Being Certain: Believing You’re Right, Even When You are Not

Also in Michael Tardiff’s talk.

 

Leading Change

In Alan Padula’s session on Large Scale  Agile Transformation, he shared a slide based on John Kotter’s book Leading Change.  As with many things, it is hard to change an organization. Kotter provides a framework for that change.Kotter - Leading Change

 

Group Dynamics

Along with hallway conversations, dinner conversations can provide new insights. This book was recommended at Monday’s dinner by one of my AgileThought colleagues, Christie Erbeck.

This book sounds like a good study of group interactions from a number of different perspectives. It’s weighty, but highly recommended.

 

Agile and Beyond – A session for agile coaches

On April 30, Agile Coach Susan DiFabio and I will be sharing our session “A Coach 4-Pack” at the Agile and Beyond conference in Dearborn, Michigan.  In this session, participants will experience at least four different simulation activities that they can take with them and use right away.LegoSeriousPlay1

More importantly than just experiencing the activity, we will share techniques for effectively debriefing participants. After all, while it can be fun to facilitate a simulation, you don’t want your participants going away thinking “What the f*** was that?” If you don’t do a debrief, you run that risk.

 

 

Agile Meme

Agile. You Keep Using That Word.

Agile MemeHow many times do you hear somebody blurt out that something is “agile?” And how many times, after they describe a behavior, you feel like our good friend Inigo Montoya listening to Vizzini?

As an Agile Coach, it is important to explore the “agile” behavior that people are referring to.

Here are a couple ideas for how to explore the use of the word “agile” and what it might mean:

The Principles Behind the Agile Manifesto

Go back to “the source” of what is defined as Agile and explore how the behavior described aligns with, or contradicts not only the Agile Manifesto, but the 12 principles behind the agile manifesto. Sometimes you can simply have a conversation about the principles. More often, it is helpful to have some type of lightweight activity, such as the one that follows.

Reflective Active On The Principles

I created a worksheet for exploring the agile principles. The worksheet gives a framework for exploring the presence, or absence, of individual Agile Manifesto Principles in your team or organization. For each principle, there is a space for indicating that the principle is present (write a “+”), absent (write an “-“) or ambiguous (write a “?”) and then jot a few words about why you thought it was the case.

Conclusion

First, I want to thank my colleague Frank Rios for pairing on generating the meme. Hopefully you find it as funny and memorable as we are. Second, be curious about the use of “agile” and get more specific about what people are thinking when they say it.

 

Agile Principles Constellation – A Retrospective

Have you ever wondered if what you are doing is “agile?” Sometimes the work you’re doing doesn’t feel like it has much “agile” to it, especially if you are being asked to do a specific set of work in a specific time frame. Damn you, iron triangle!

Agile Principle of the ManifestoYour workplace isn’t “agile” or “not agile.” Certainly there are parts of your organization that will be aligned with agile principles, and there are some aspects that are likely not. This retrospective is designed to explore your organization’s alignment as it relates to agile.

Here is the outline of the retrospective. Feel free to adapt it as you see fit. If you do adapt it, please let me know what changes you made.  If you use this retrospective, I would like to hear how it went. You will note that the general flow for this retrospective matches the outline in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen.

Set the Stage With One Word Check In

One word check-in. Consider something like “how did the last sprint feel?” This gets everybody to talk at least once.

Gather Data Using a Constellation

The constellation exercise is a way to visualize the degree to which people feel a principle is present or absent from their work. Here is how to conduct this activity:

The facilitator reads one principle out loud, and then places it on the floor near the center of the room.

People then position themselves relative closer or farther from the statement based on how much they feel the principle is present in their environment (e.g., team, organization, company, whichever you chose). If somebody feels it is strongly present they would stand close to the principle you placed on the ground. If somebody feels it is not present or “anti-present”,  they would stand very far away.

Give people a moment to observe the pattern and perhaps jot down anything they noticed.

Pick up the principle you just used, and move on to the next one. After all twelve principles have been read, move on to generating insights.

Generate Insights

Ask people what they noticed about the constellations that took place during the Gather Data activity. Some question you might consider include:

Which of the principles were strongly present? Which were strongly absent?
What similarities or differences did you notice about those principles?
Which had the most disagreement amongst the group?
Which had disagreement by role?
Which had some individuals who felt differently than the majority of the group? What unique perspective might those individuals have?

Decide What to Do and Closing

I would encourage you to determine what kind of activity makes sense for your team to use for the “Decide What to Do” and “Close”. If you want to get more options for these phases, jump on over to the Retromat and give it a spin.

Retromat Screenshot

Background on some of the decisions

Why did I choose to do all twelve principles before generating insights?

I didn’t want to do a deep dive on each of the principles. I was more interested in having the team see the constellation that formed for each principle, and then generate insights on a subset of the twelve.

Why did I choose not to do a constellation based on the “left side versus the right side” of the Agile Manifesto itself?

Certainly, you could create an activity around the values in the Agile Manifesto. However, I have found that the values of the manifesto are a little too vague for this type of conversation. While the principles are more specific, they are still general enough to generate deep conversation.

Preparation and Supplies

Plan to use a room that is fairly open, leaving enough room for people to move about freely.

In preparation for this retrospective, print out each Manifesto principle on its own sheet of paper.

Have a note-card for each individual participating, so they can make notes about their observations. Maybe pre-print each Manifesto principles on a separate 3×5 or 4×6 card for each person.

Conclusion

It is very important for individuals, teams, and organizations to explore the principles behind how they operate, and not simply follow the rules of the framework-du-jour. The goal of this framework is to explore those principles. Please feel free to add your thoughts.

To Inspire Teams, Forget Goals. Define Purpose.

Howard Schultz on PurposeWhat’s your team’s purpose? Is it a real purpose? Whose life is better because of what you do? What pain do you relieve? What new reality do you make possible? Who would notice if your team stopped delivering? If you easily answered those questions, congratulations. If not, you are like a lot of teams. Many don’t have a connection to a real purpose.

A lot of teams simply have goals. Maybe you are working to improve code coverage with automated tests. Maybe you want to increase code quality, reduce defects, or pair program. Those are worthwhile goals, but they are not purpose. Here is how I see the difference between goals and purpose:

Goals provide a target.

Purpose provides inspiration!

Failing to meet a goal leaves people feeling deflated.

Working for a real purpose gives a rallying point when times get tough!

Goals are used for evaluating individuals.

Purpose is about changing lives!

I hope you see the value in having purpose. For those teams that don’t know their purpose, how do you uncover it? Try these suggestions to help you identify your purpose:

Imagine –This is perhaps most appropriate when you are starting a new venture. How do you see the purpose of the organization? If you can be clear about the purpose early in your team or organization’s life, it can be used as a filter against which to test all the ideas and opportunities that come at you. It will help you say the most important word in the world: “No!” Having a well-defined purpose helps you stay focused and not get distracted by opportunities that don’t fit.

Interview customers – Talking to a customer can have a profound impact on how you see your team’s purpose. What did they struggle with that led them to your product or service? Ask them how you make their life better. Why do they use your product? If the product were no longer in existence, how would their life be less well off?

Visit your customers where they use your product – Interviews can be helpful, but sometimes people are too close to the situation to really see what is happening. When you see your customers “in the wild” you may end up with insights you didn’t have before, and notice behaviors they exhibit that they weren’t even aware of.

Business model canvas – The Business Model Canvas is a convenient way to collect information about how your business operates. There are two aspects of the canvas that apply to the topic of purpose; the Value Proposition and the Customer Segment portions. These will help you articulate what makes you unique from other groups, as well as identifying for whom you are providing that value.

Don’t be efficient about it – All too often, in the name of efficiency, I have seen too few people involved in activities like customer interviews, site visits, and wrestling with the business model canvas. I challenge you to engage the whole team in these activities. You  will get deeper insights when you compare what people saw and heard. You will definitely create a deeper connection between the team and the purpose they saw. Be inefficient, and prepare to be surprised at the positive results.

You might know, but your team might not. How can you help the team to really make the purpose part of their conscious?

Talk about it – Whether you are a team member or a leader, it is important to have a dialog about the purpose of your work. You might have said it before, but there is so much communication noise that it is likely people forgot, especially if it was lost in management mumbo jumbo. Just saying it once is not enough. Invite conversation with your team about the purpose. How might they see it differently? Talk about it, and then talk about it again. There is value in keeping it in the forefront.

Make it relatable by telling a story –Humans have, for millennia, told stories. We are wired to remember stories. PowerPoint slides with bullet points are no substitute for a true story of connection. Ditch the slide deck, and practice telling and rebelling the story. And remember, the good stories need to be told repeatedly. If you don’t have a good story to tell, go see your customers and find the story.

Make it visible – When somebody walks into your business or team area, what do they see? Is it obvious what your purpose is? If not, it is time to do some redecorating. Create visual reminders about the team’s purpose. Make them personal. Do not have eagles soaring over still lakes with motivational phrases on the bottom. Have something that is specific to your team and it’s purpose. Keep the visuals fresh. Don’t let them become wallpaper.

So, ask yourself: Does your team have a goal or a purpose? Goals are, perhaps necessary. Purpose is inspiring. If you find your team has only goals, dig deeper. Identify the purpose for your team’s existence, and unlock the possibilities!