July 22, 2014

All Posts Tagged With: agile

Agile Coaching Blog

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.



Paying Attention: A Critical Capability for Organizational Agility

An agile organization is able to rapidly notice and effectively respond to extreme change while shaping the future in the midst of that extreme change. Without that capability an organization is like a swimmer caught in a raging river, unable to control where they going, flailing their arms to avoid crashing against the endless parade of rocks. Organizational agility arises, and is most effective, in organizations that deliberately work to put it in place.

There’s a lot contained in this statement. In this blog post I’m going to cover “rapidly notice”. Future posts will cover the remaining parts.

Noticing what is happening in the world, with your customers and the markets you serve and within your company is a critical organizational capability for agility.

The information you need to orient yourself in a rapidly changing world is distributed. Your sales people get information from your customers as do your customer support representatives. Your customers discuss your products and your competitor’s products on social media. Industry trends, challenges and ideas are presented online, in journals and at conferences. Your staff, at all levels, have ideas for improving your existing product or creating new products. Analytics within your products themselves provide clues to how your customers interact with those products and respond to your innovations.

In an agile organization, people realize that information is an essential element for the success of the
organization and that the success of the whole is enabled by the speed at which information and meaning
moves across organizational levels and boundaries. Information is shared online, through communities of
practice and through planning events that bring people from multiple levels and disciplines together using
large-­group facilitation techniques. It is part of how people work. To be a successfully agile organization, you need the processes, tools and culture of information collection, curation and sharing. Of these culture is the most important. Tools are helpful, but they can only enable a culture to share – they don’t cause it.Organizational Agility_Attention

Sharing cultures are enabled by safety and attention. Safety is important because sharing often takes place in public forums. Executives openly sharing information, publicly showing curiosity and an interest to learn establish a powerful model for the organization to follow. When they interact with people across the whole organization, not just people on the leadership team, as peer learners, they help break down the barriers to the free flow of information until this becomes a core part of the fabric of the organization. Attention is equally important. Attention means simply that people pay attention to what is shared asking questions and adding to the conversation, This provides positive feedback both for the person sharing information and others who might share in the future. Attention isn’t simply an online phenomenon. Attention is people participating in communities of practice, it is executives sitting down with a team to learn from them. Here too executives can set the tone. If they pay attention it helps create a culture in which others do too.

To summarize, you can’t be an agile organization if you don’t know what’s happening with your customers, your competitors, your market and the larger ecosystem in which you operate. Your organization has broad and deep information that can enable your agility, but only if that information is available and it is given attention. For this to happen, organizations must create that capability through tools, practices and culture. In the next entry I’ll address the next part of organizational agility – turning information and learning into effective action.

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.



All About Agile: Giora Morein’s Interview with Money For Lunch

Earlier this month, I was interviewed by internet radio show, Money for Lunch. The program introduces leaders, authors and innovators to a business-minded audience focused on business and financial news. I spoke with Bert Martinez regarding the topic of agile. We went over some of the basics, such as:

  • What is agile and Scrum?
  • What are the common pitfalls of agile or anti-patterns an organization might see?
  • How does BigVisible avoid the pushback and get organizations to successfully adopt agile?

I speak to the topic of agile as a fundamental shift in how large organizations view the delivery of products and projects – going from big batch, long-phased delivery cycles to something iterative and incremental – quickly bringing products to market.

It’s easy for organizations to become bogged down in their own processes and systems. But more and more, organizations are widely adopting and scaling agile to be more responsive, to increase quality and achieve more successful outcomes because the market is demanding it. Buyers are more knowledgeable and know what they’re looking for and they demand better product in shorter timeframes. If organizations can’t deliver, they won’t be able to remain competitive.

You can listen to the full interview here.

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.