July 25, 2014

Agile Coaching Blog

Agile Coaching Blog

This agile coaching blog has news & articles from BigVisible coaches and trainers. Find agile topics like Scrum and Kanban. Read about collaboration, communication, & enterprise agile. See hints for better daily meetings, retrospectives, and Scrum reviews. Learn about leading edge tools for lean startup and customer development. Discover information geared toward agile teams as well as leaders & executives.

We hope the information you find here will help your organization become more agile, adaptive, and innovative. Our goal is to help you delight your customers & succeed beautifully.

Let’s Shake Things up at Agile 2014

Let’s shake things up a bit.

No more stuffy sales pitches or inky flyers. Let’s get loud.

Drop by, escape the ordinary.

Be Heard

Subscribe Now to Follow the Action


Velocity Is Like A Helium Balloon

Lately I have had many conversations about team velocity. Most of these conversations have had an element in them about increasing team velocity. Questions and statements like, “How can I get the team to increase their velocity?” or “We must complete an additional 20 points this sprint.” Often these ideas are accompanied by extensive velocity analysis, discussions keeping individuals 100% busy and so on.

Velocity Is Like A Helium Balloon

Attempting to directly manipulate team velocity is risky and often counterproductive. It can result in the team simply increasing their story point estimates or in taking shortcuts of quality and design so they can get a better number. Such actions damage the utility of the velocity as an input to planning and hide reality from the decision making process. Rather than worry and work over making velocity go up, remember this:

Download This Image as a Poster!

Velocity is like a balloon. It will rise on its own if nothing is holding it down!


Why You Should Limit “Work in Progress”

Why You Should Limit “Work in Progress”

Sometimes I sit down at the end of a day or even a week and am dismayed that I don’t seem to have really accomplished anything. I know I was very busy and I know I was working hard on important things, but why don’t I have anything to show for it?

This scenario is as common for teams as it is for individuals. Most of the time the underlying problem is excessive Work In Progress, or WIP. WIP is anything that you have started but not yet completed. Code waiting for testing is WIP. A design you have “finished” but need approval for is WIP. A requirement you have started to look at but don’t yet understand is WIP.
Excessive WIP is bad for three important reasons. First, it exhausts us mentally. Anything I have started but not finished occupies some part of my available mental capacity. The more WIP, the more my mental energy is consumed with trying to keep track of it all. Add to that the time and energy lost in context switching and the add burden of WIP can become overwhelming.
Second, excessive WIP leads us down the garden path of mistaking activity for accomplishment. When we have a near infinite stream of things to work on and the task at hand bogs down, needs help from elsewhere, becomes unclear, or otherwise becomes “blocked”, we can easily set it aside and pick up something else to work on.

So what is wrong with that? Presumably, the thing we were working on has some measure of importance; otherwise we wouldn’t have been working on it. When we set it aside we make an implicit prioritization that whatever I am going to work on instead is now more important. Of course we probably didn’t think of it that way. We more likely thought, “I can’t just sit around, I need to be busy” and so, rather than exert ourselves to get our original task moving forward we can just set it aside and move on to something else. We focus on being “busy”, not on accomplishing valuable work.

Finally, excess WIP hides process problems and other wastes lurking in our system. I adapted this picture from similar images used to show the undesirable effect of excess inventory in manufacturing. For us, and WIP represents inventory.WIP It is partially completed work sitting around waiting to be finished.

The water is our WIP. When we have plenty of WIP, plenty of other work we can switch to, the rocks below the surface remain undetected. It is only by limiting our WIP (lowering the water level), that we can detect the wastes that are taking up our time and resources. When I first saw a picture like this it didn’t make sense to me. Why lower the water level to the point that you start hitting the rocks? Seems like a bad plan! But the truth is that the “rocks” are lurking down there, robbing us of time and energy. Perhaps more importantly, they are creating whirlpools and rip currents that are keeping us from being productive. We are expending a lot of energy being busy, but we are not really getting anywhere.

If we get serious about limiting our work in progress we will be able to identify and address the impediments to a smooth flow of work and increase our productivity while likely decreasing our business. When in doubt: Stop starting things and start finishing things!

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar

Breaking Gantt – Project Reporting in Agile Transition – A BigVisible Webinar by Dave Prior

When an organization makes the decision to move from a traditional (waterfall) approach to Agile, coming to grips with the new way of tracking projects can be one of the biggest challenges. Dave Prior presents on some of the tips and tools he has found to have a positive impact when helping an organization let go of their dependence on traditional project tracking in favor of Agile reporting.

Webinar Topics Include:
• Core differences between traditional and Agile project tracking
• How Agile reporting can impact a traditional organization
• Communication Modeling and Agile Transition
• Understanding the needs of an organization in transition
• Tracking Agile projects
• Hybrid reporting approaches



Random Issues in the Agile Transformation Bridge

The other day I was thinking about the problems I have been seeing with clients. My thoughts expanded from the current team and organization concerns to more general scope of experiences with other transformations. Below is the resulting list of ideas, in no particular order and without fanfare. Let’s talk about it if you’d like to go deeper on your favorite!

Random Issues in the Agile Transformation Bridge


  • Managing by email doesn’t work well. Leading a transformation by email doesn’t work at all.
  • Documents are important. Leading by example is vastly more important.
  • Before you can scale Agile (or anything else) you have to have Agile (or that anything) to scale.
  • If the business around the teams does not change, the teams will work they way they always have and just use the new labels for what they do. And have more frustration.
  • Policies, procedures and processes send messages. These messages define your culture. To ignore the messages is to ignore culture.
  • Culture eats strategy for lunch. And dinner. And steals your lunch money. Unless culture is aligned with your strategy. Then it gives you lunch. And Dinner. And more lunch money in beautiful greeting cards.
  • Ownership of improvements is better handled by those who need to improve. That means improvements mandated by others rarely create the desired result.
  • If a team doesn’t have what they need to get the work done, asking them to work harder will not help much.
  • For every decision maker or specialized skill that is not dedicated to a team add two days to every request. For example, if the stakeholder needs to approve a feature change it will take at least two days to get an answer. If a meeting is needed, add four days.
  • 99% or more of the time everyone is doing the best they can under the circumstances. Check your system and environment for the root causes of failure, not your people.

Better Agile Meetings Through Questions

If you happen to be in a meeting with a written objective and agenda, the agenda will have items like “review the plan”. It sounds reasonable. But it is, in fact, very likely to waste your time.

Why? Better Mtgs Thru Questions_BF

Simply, there is no definition of success, so you could talk about the plan for hours and still not accomplish whatever goal was underlying the agenda item. What does success look like for “review the plan”? Do you just put it up on the screen and everyone looks at it? Do you review every task in minute detail? If you define meeting agenda items using questions that specify success, that will help you get
out of this problem and have more effective meetings.

Let’s translate “review the plan” into a few example questions to show you what I mean. I’ve included the meeting objective which is another key piece of meeting success.

Objective: Have a plan that ensures we’ll have enough stories for our team to start work on July 1

  • Will the current plan enable us to have two sprints worth of user stories ready for building by the team by July 1?
  • If no, what do we need to change in the plan to meet that objective?
  • When can we get together as a team to work for an uninterrupted block of time to focus on this work?
  • If the answer is “yes” to the first question, you can move onto the third. When the questions are answered and the objective met, you end the meeting. If the meeting gets off track you can ask “is this discussion pertinent to the question we’re trying to answer?”

    Like any tip for better living (eat more green leafy vegetables) practicing this is harder than reading about it. Try it for two weeks and see what you think.
    (Thanks to David Spann, who introduced me to this idea in his wonderful meeting facilitation course years ago.)

    Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Enabling Cross-­Organizational Learning Through Communities of Practice

Becoming an agile organization and continuing to improve over time is best supported by cross­organizational learning. People share their successes and failures and help each other get better. Communities of practice, created and managed by peers, with a focus on particular topic of shared interest are a powerful tool for getting this going.

The Challenge with Traditional Approaches
In a traditional organization, ideas are noticed by the management team who then decides that they should be rolled out more widely. This approach has a number of challenges: messages take a while to make it up a
hierarchy, they can get distorted on their path and they may get lost in the volume of ideas a manager
typically has to engage with.

Communities of Practice and Cross-­Organizational Learning
In an organization with strong Communities of Practice (this will be defined more later) there are strong peer networks that speed up the validation of ideas and the sharing of those ideas.
What are Communities of Practice?
A community of practice is a self-­organizing team of people who share common professional interests. For
these communities self-­organization is more effective than manager-­directed. When the manager directs the
activity, people may participate because they think it is expected of them. When self-­organized, people only participate if the experience is valuable. Managers can, however,certainly be participants in Communities of Practice. The following diagram shows the three components of a Community of Practice: the domain, the community and the practices.

How do you get Started?
There are many ways to get started, and certainly trying to get a full-­blown community of practice going all at once is not a good idea. Instead, here are some small things to get things going.

  • Schedule a lunch meeting to talk about a topic you think might be interesting to others, hold it, and ask for volunteers to host the next meeting.
  • Create a group on your internal intranet, invite others you think might be interested to join, and start posting things and asking questions.
  • Schedule a session with a theme, but no specific topic. Determine what you want to talk about when
    people show up by collecting topics, voting on the topics and allocating time to the top vote-­getters.
  • Amplify something someone else has done. If someone has put the energy into holding a learning
    session, writing a post or asking a question about a topic of interest to you, RESPOND! If
    people have a positive experience sharing, they’ll do more, and you get a positive reinforcement loop

How do you do more with a Community of Practice?
If the initial sessions are valuable and well-­attended, it may be desirable to do more. Here are some
examples of what more might look like.

  • Establish a group of volunteers to help shepherd the community and its activities.
  • Establish more formal meeting times and structure.
  • Hold a “summit” where there are a series of topic-­focused presentations.
  • Establish an online place to organize relevant materials for the community and a process for curating that material.
  • Bring in speakers.
  • Send people to conferences and have them report on what they learned when they get back.

Helpful References

  • Wenger, Etienne, Richard A. McDermott, and William Snyder. Cultivating communities of practice: a
    guide to managing knowledge. Boston, Mass.: Harvard Business School Press, 2002. Print.
  • Osono, Emi, Norihiko Shimizu, and Hirotaka Takeuchi. Extreme Toyota: radical contradictions that drive
    success at the world’s best manufacturer. Hoboken, N.J.: John Wiley & Sons, 2008. Print.
  • Toyota has incredibly powerful communities of practice that enable very rapid sharing of practices across an enormous organization. The whole book isn’t about that, but it is a key theme.

    Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Why Busyness Is A Problem and Throughput Is Important

Throughput is the rate at which an organization realizes its goals – sales, client retention, employee
engagement or learning outcomes. Something only counts toward your throughput rate when it’s in a client’s
hands and you are getting the benefit (e.g. revenue). Many organizations suffer from the illusion that
busyness results in better throughput, but that isn’t the case. If you don’t manage your level of activity you can end up with an organizational traffic jam where very little gets done. If you are judicious about what you take on at any one time, and you consciously make sure there is slack in the system, you can break the jam.

Consider the picture of the highway. If you were a traffic engineer, would you be happy? If busyness is
success, this highway is wildly successful. Every square foot of pavement is occupied by a car barely
moving. But the goal of a highway, or its throughput measurement, is the rate at which people move from one place to another. For that goal, the highway at this moment is utterly failing. Why are these cars going slowly? Couldn’t they all just travel at the speed limit with one inch between each car? No, because there are all sorts of variable things that happen: people accelerating, braking, changing lanes, entering and exiting. On a highway that is less utilized, there is room to accommodate these things, but at a certain point of busyness there is no slack, and a traffic jam results. TrafficJam_Throughput_BF

Why can’t organizations run well when people are fully utilized with no slack? Like with traffic, things
happen: someone doesn’t deliver what you expected, something turns out to be harder than you thought, you
have a production issue that needs attention, a visitor from another office asks for your time, a customer
struggles in a user experience test session. As with the highway, if you have no slack to accommodate the
changes brought about by these events you end up with an organizational traffic jam.

The simple answer to this dilemma is to plan to do less, which ultimately results in realizing your business goals faster. This is a practice – you get better at it by doing it. It happens at the macro-­level with initiative portfolio management and at the team level when you pare back the features in a release to the bare essentials before you move onto less-­important aspects of the system. If you plan for a level of activity that seems easily achievable, you’ll have the room to respond when the inevitable unexpected thing happens.

(Thanks to Evan Campbell for the core ideas expressed in this post).

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



My Minimal Viable Meal (Or The Value of a Minimal Viable Product)

Many years ago my wife and I had a nice dinner at Petrossian in Manhattan, so when I got in my mind to
have a nice dinner a few weeks ago I decided to go back. “Sir”, I said to the waiter, after reviewing the menu, “Can I please have an appetizer of your Royal Ossetra caviar, the steamed Dover sole and, being quite thirsty at the moment, a bottle of your Champagne Louis Roederer Cristal 2006?”Minimal Viable Product_BF

“Certainly”, he replied, “all excellent selections”.

“Oh, one more thing”, I said, “I’m on a corporate expense account and can’t really
have any unseemly expenses. Can you please only charge me around $40?”

“But the champagne alone is about six times that!”, he said, looking a bit agitated.

Now I’m gobsmacked. “This is absolutely, without exception, my Minimal Viable Meal. When I came to the restaurant, I was looking for something extraordinary, and only these menu items will do the trick.”

“Well sir”, he replied, summoning up the composure of his full 26 years in the job, “might I suggest the
Seared Long Island Duck Breast and a glass of our iced tea? While not exactly what you asked for, I think
you would find it quite enjoyable, and very close to the budget you have for the meal.”

I pondered. The initial value proposition that had attracted me was an extraordinary meal in opulent surroundings. This might work even if it wasn’t exactly what I’d envisioned.

A Minimal Viable Product, or MVP*, is:
“A product with the fewest number of features needed to achieve a specific objective, and users are
willing to “pay” in some form of a scarce resource.”

In this case the duck was an effective fit for my objectives. Building a product with the minimal set of
features to meet a goals is a valuable end in itself. We write code and build features in order to enable
outcomes and long-­term impact, but the software itself has no value. Software requires maintenance, support and training. The less you have of it, the better. Powerful as that is, there is more value provided by an MVP. When you build the “fewest number of features needed to achieve a specific objective” you also benefit from a rapid learning loop. No matter what you think is true of your customer -­ what they want and what they will do with the product you build -­ it will only be proven to be true (or false) when your product is in their hands. The sooner they get it, with the least amount invested, the sooner you’ll find out if your product ideas are right.

Additionally, if you focus on the critical few features first, then you are more able to respond
effectively when unexpected circumstances arise. And finally, if you run out of time or budget, you are more likely to have something you can ship if you’ve focused on the features that constitute the MVP first. A story map is a powerful tool for identifying those critical few features but that’s a topic for a future post.

*Cooper, Brant; Vlaskovits, Patrick (2010-­10-­15). The Entrepreneur’s Guide to Customer Development: A
cheat sheet to The Four Steps to the Epiphany (p. 40). Cooper-­Vlaskovits. Kindle Edition.

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



The Risk of Writing Too Many User Stories Too Early

I’ve often seen new teams try to write detailed user stories for every feature in a release before it really makes sense. The reason you adopt agile is that you expect to learn through experience. When you write all your user stories up front, you may have stories that need to be discarded because new things you learn invalidate stories you’ve written. The time that you have the least information to write detailed requirements for an initiative is at the beginning, since that is when you have the least amount of knowledge about both the problem and the solution. As an initiative proceeds, you get feedback on your work, and that feedback influences the next stories that you write.

My advice is to write just enough detailed user stories to get started, and then do regular story elaboration throughout the product development lifecycle.

Now this advice goes counter to a need that many teams have -­ they are expected to know if they will deliver all of the requested functionality by the end of the release. There are two parallel approaches to this:

  • Rough estimation using story points -­ best guesses without really having detailed acceptance criteria or
    story detail
  • Work on the stories that represent the highest risk / value first, learn more about your product, then write up the remainder of the stories and estimate them

Learning and designing by doing (Iterative and emergent design) is an effective technique for managing risk and getting you on the best path to a successful product. Writing all your stories up front is a path that often leads to waste and one that will ultimately slow you down.

Want actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.