Category Archives: Agile

Agile Coaches’ Corner Podcast

I’m pleased to share that the relaunched AgileThought podcast: Agile Coaches’ Corner is now live and available on Google Play, iTunes, TuneIn Radio, Stitcher, and other podcast listening platforms!
Please help us get the word out by listening, subscribing, providing a review, and suggesting topics for future shows.

You can listen on:

Agile Coaches Corner on Google Play
Agile Coaches Corner on Apple iTunes
Agile Coaches Corner on TuneIn 
Agile Coaches Corner on Stitcher 
Agile Coaches Corner on Android
Agile Coaches Corner on our source, LibSyn

This milestone would not have been possible without the the collaboration of several colleagues at AgileThought, including Sam Falco and Emily Culclasure, along with the support of other AT leadership. Thank you, all.

Indiana’s Biggest Agile Conference Returns

AgileIndy Conference 2018 is just around the corner. Scheduled for May 11, 2018, the AgileIndy Conference will be held in the heart of downtown Indianapolis. Get your tickets to AgileIndy while they are still available.

Why should you attend?

There are, of course, valuable sessions to attend and learn valuable lessons. There will undoubtedly be a keynote talk with inspiring thoughts. And, of course, there is the laid-back conference reception. But every conference has those, so why attend AgileIndy?

In three words, I’d say the reason to attend is “people and interactions.” Regional conferences are an excellent chance to meet agile thought leaders and practitioners from around the region. In addition to the attendees from Indiana, there will be many folks from the Chicago, Columbus, Louisville, and other surrounding cities.

Do you have something to present?

Disclaimer: I am not involved in organizing the conference. This information is the best that I have, but is NOT official guidance from any of the conference organizers. 

If you have a session you’d like to be considered for the conference, it is time to get those proposals created. The process for submitting ideas to AgileIndy is different than many conferences. While many conferences have a single deadline for all submissions, and then the sessions are evaluated all at once, AgileIndy will be accepting proposals on a rolling basis. So, if you get a compelling session submitted early, it might get accepted early.

For consideration, send an email to AgileIndyspeakers@gmail.com and include the following information:

  • Title of Presentation – 50 characters max
  • Bio of Presenter – 280 characters max
  • Abstract of Talk – 280 characters max
  • Headshot of Presenter
  • Reason why your presentations should be selected.  This can include links to videos, slides, and a description of how your talk will flow.

The final cutoff for submissions is March 26, 2018, but don’t wait until the last minute.

Have you attended AgileIndy in the past? If so, what is your favorite reason?

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 on 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.

Juvenile 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.