Category Archives: Agile

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.

Proxy Product Owner

The term “Proxy Product Owner” is sometimes used when somebody in the organization has an existing title of Product Manager or Product Owner. There may already be a position description that corresponds to a title of “Product Owner.” 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.

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 have a Scrum Product Owner. And, if calling them a “Proxy” Product Owner is synonymous with Scrum Product Owner, and helps differentiate the Scrum activities from the other organizational activities that are across the two Product Owner titles, then it can work well.

What is the danger of having a Proxy Product Owner? Many times when I hear “Proxy Product Owner” used, it is used as a euphemism for one of these other types of Product Owner:

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.

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 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!

Take a Trip to the Principles Office

Agile Principles PresentationUnderstanding, and embracing, the agile principles is fundamental to becoming Agile. That is why I chose to present my session “take a trip to the principles office” at the Agile and Beyond conference in Dearborn, Michigan. I want to encourage people to consider the principles as they encounter novel situations and work to determine their best path forward.

The presentation Take a Trip to the Principles Office is available for download as a PDF.

The Take a Trip to the Principles Office worksheet is available for download as a PDF.

If you are interested in the journey lines activity, you can find that on the Coaching Agile Teams site.

The Challenge of Getting Components Working Together

Will the components work together?If you take a large, complex process, break it into components, give separate components to different software team, and then recognize teams for their completion of individual components, you run a risk that when you stick all the pieces together that it won’t work. So, if you are in a component-centric delivery teams, what can you do to help have the best chance of producing a working solution for your users? I’d like to share three tips for giving your team the best chance to build a working solution.

First, make sure that folks are vigilant for the functionality of the whole system. You might opt to have a separate team be the watchdogs for the system, but ideally it is everybody on the individual teams, too. Building a complete system requires a mindset for thinking about the whole, even when working on just a part of it. Without a mindset for the whole, it will be impossible to do anything to retrofit the quality into the work product.

Second, once folks are vigilant for the system as a whole, the next simplest thing to do is to make sure that each team is engaging with the teams that are “upstream” and “downstream” from them. Individual component teams should make sure that the adjacent component, those that you consume or the team(s) that consume the results of you work, work together as intended. Engage those teams to identify the points of interaction and define the behavior that each side expects. It is important to have a conversation that goes deeper than just what the structure of the data is going to be. Be sure to agree on what the data is going to mean, and what the anticipated behavior is going to be based on the data. Once you agree on what the structure is, and the behavior that will be driven from it, you can “mock” the interfaces, creating a dummy interface to work against until the actual system to interface with is in place.

The third bit I would like to share is to move toward an end-to-end suite of automated tests. Consider defining the tests that need to pass before you build the system. Then, you automate the tests, and components are only “done” when the tests for the whole process pass. The test-first approach forces the conversation about what should happen in the system, versus trying to catch all the things that do happen. This type of change will not happen overnight. It takes time and technical skill to put it in place. But, you have to start somewhere, and work toward a robust framework for components to be plugged into.

So, in summary, here are three important elements to have a complete quality picture for your product

  1. Build awareness and a mindset in team members
  2. Get teams to coordinate with the teams who build components that need to be interacted with
  3. Begin working toward test-first automated suites

Being good agilists, it is unrealistic to think that all the behavior will be implemented at once. Agree on the general plan for iterating toward the complete solution. Over time, you will build up a more robust, higher performing, system of people and technology.