The other day, I heard someone say, “He comes to the relationship with a lot of emotional baggage.” Truer words were never spoken; some people come with handbags and others come with steamer trunks, but all of us bring our past experiences to any new endeavor.

The same lesson holds true when taking on an agile adoption or transformation effort in your organization. All organizations, and the people in them, have baggage. To succeed in an organizational change effort, we have to accommodate that baggage with a packing strategy.

Identify Your Constraints

Airlines restrict you to a certain number of carry-on and checked items, each of which must not exceed certain weights or dimensions. So the smart traveler adapts his packing strategy and which items he chooses to bring based on these constraints.

Similarly, as an organization goes through change, its members have assumptions and existing rules and standards that need to be identified and considered.

One way to do this is through a game that I like to play with product owners and managers called The Marshmallow Challenge (www.marshmallowchallenge.com). Traditionally, the game is played to understand the importance of the iterative process but I feel the most important part of the game is the realization players leave with: All projects have marshmallows. When used to demonstrate a typical sprint, the marshmallows are a metaphor for assumptions in the product backlog. When used to talk about agile adoption and transformation effort, the marshmallows become assumptions of a different sort. They become the guesses you make about how this new way of thinking about how you build and deliver products will integrate into your existing culture, processes, financial models, hiring practices, leadership styles, technology ecosystems, reward systems, customer interactions, etc. By identifying these “marshmallows,” you can build what I like to call an opportunity backlog and put together a team that can influence change.

Determine Your Goal

From a change management perspective, the effort to transform an organization so that it can leverage and benefit from lean thinking and the values and principles of agility is not very different than any other organizational change effort.  Yet many teams and organizations fail because they do not approach it that way. Instead they see it as a change that will only affect software teams or the IT department. Nothing could be further from the truth.

Because becoming an agile organization has implications far beyond the IT department, most of the techniques that experienced agile transformation coaches use are the same that you would use if an organization were changing business strategies, adding or removing business capabilities, re-organizing or merging with another company, and so on.  As such, experience agile coaches ask questions like these to help determine appropriate strategies:

• What is your vision?
• What is the reason for the change?
• Do the employees know, understand and support the vision?

One of my favorite quotes is from John Kotter’s Leading Change, “Whenever you cannot describe the vision driving a change initiative in five minutes or less and get a reaction that signifies both understanding and interest, you are in for trouble.” Your vision is probably not about adopting agile; there is probably a more specific reason for the change. Spend the time to truly understand the real reason for the change and focus on that. Lean thinking and agile methods may be a part of that change but they will not be the only items in your opportunity backlog; nor will they likely be the most important.

Remember that the most important part of an organizational change is about people changing at all levels of the organization; as such, it is highly complex. Some people resist change while others embrace it. Make sure you have the right people working with you and a toolkit of organizational change practices to explore and embrace.

Get the Right Equipment & the Best Help

Once you have examined your baggage (assumptions & constraints), and determined your goals, you can outfit your organization with the proper equipment to manage the load. The following is a list of tools & practices I want in my toolkit, or want my agile coach or guide to have:

• Brainstorming
• Collaborative and Communication Strategies
• Corporate Evolution (or as Seth Godin calls it, Zooming)
• Creating Learning Organizations
• Cross Boundary Strategic Conversations
• Enterprise Architecture (the organization’s current and future information architecture)
• Facilitation
• Human Psychology
• Influencing Mapping
• Iterative and Incremental Change Techniques
• Kaizen
• Leadership Agility
• Open Space
• Radical Collaboration
• Relational Leadership
• Root Cause Analysis
• Servant Leadership
• Stages of Organizational Development
• Strategy Mapping
• Systems Thinking
• The use of “games” for innovation, interactive design,  product development and self realization
• Theory of Constraints
• Understanding of multiple change strategies
• Value Mapping
• Visioning
• World Cafes

When choosing a coach or guide for you team, make sure you are working with people that have experience beyond just helping teams embrace Agile. The best coaches understand the bigger picture of change and have experience with the majority of the techniques listed above and with various organizational change models. Browse some of the articles on the BigVisible blog site for more really great articles on change – www. Bigvisible.com/blog/

Enjoy the Trip

There are many change models available; all of them have their strengths and weaknesses. Just like agile methods, no one organizational change method alone is sufficient. Just like packing your luggage, when you’re ready to become more agile, think about your needs (vision) and constraints (current organizational reality that may have to change) and come up with a strategy that will help you make it past check-in!

I am lucky enough to work with a great group of people that have experience in many facets of organizational change.  We have combined our many strengths and expertise into a collaborative approach called the “The BigVisible Way™.” I hope you are lucky enough to find a team like BigVisible to help you with your journey.

Each month, we’ll broadcast a twitter chat with one of our agile coaches. Today, we spoke to Tiffany Willis, a Boston-area coach with BigVisible. For those who missed it, we have a transcript of today’s Q&A session. Look for our tweets or submit questions with the hashtag #bvcoach.

BigVisible: Hello to @1TiffanyWillis and our BigVisible audience. Our first coach’s corner is underway. Tweet questions with hashtag #bvcoach.

Here’s our first question: My team can’t complete stories within a sprint, what should we do?

Tiffany Willis: This happens more often than people may think. It’s usually symptomatic of the way the story is written (or the way it’s groomed). Sometimes the team isn’t working to the same defintion of done or coming together as a team to approach the story.

BigVisible: And a follow-up: So where do we start if we’re having the problem of incomplete sprints?

Tiffany Willis: I would ask some questions. How long are the sprints? Does the team feel they can complete the stories in the given time? If the team feels it can’t complete a story, it needs to meet with the PO and discuss ways to resize the stories–To break the stories into smaller chunks that still deliver pieces of working functionality.

BigVisible: Here’s another one for you, Tiffany: We’re confused about testing and agile. Do developers do testing on agile teams?

Tiffany Willis: Yes! Teams are focused on how best to deliver stories not on individuals and completed tasks. So, yes, sometimes developers test. By the same token, though, with one team a QA person did UI development because he had the skills and the team had the need. It was great!

BigVisible: Another team-related question: What about distributed teams? Does agile work for them?

Tiffany Willis: Yes. Agile values communication and collaboration. Distributed teams have to find ways to adapt: video, chat, phones, etc. Co-location shortens feedback loops. So if you are distributed keep the focus on collaboration.

BigVisible: Next question: What do we do about bugs when using Scrum?

Tiffany Willis: There are two types of bugs. The first kind are ones you create during a sprint. You should definitely make time during the sprint to fix the ones you create. The other bugs, ones that are reported, you want to add to the backlog and prioritize, assuming they aren’t mission critical. You want to plan the work to the extent possible, even the bugs. The stakeholders need to know what to expect each sprint.

BigVisible: Last question: Does agile work in a highly regulatory environment?

Tiffany Willis: Yes, why not? It’s about transparency. Let’s understand the environment in which we have to work. Whatever we have to report on (whether that’s the FEC, FCC, FDA…whatever) it needs to be known and included as part of our deliverable. We’re now working successfully with large financial services and life science companies–two of the most regulated industries. So absolutely, it can be done. And done well.

BigVisible: Thank you so much for giving us a coach’s perspective today. Any last thoughts?

Tiffany Willis: Remember to keep trying to do better. Focus on transparency and collaboration. Keep calm and agile on!

BigVisible: This concludes our inaugural coach’s corner. If you have further questions or comments, leave them here and we’ll respond. Join us next month when we host another BV coach.

We all have our least favorite phrases or questions that come up in day to day coaching.  One of mine goes along these lines: “No one has complained about this, so why change?

 ————–

How many of us complained about not having a PC on our desk before HP created one and Apple popularized it?

How many of us complained about not having a mouse and a point-and-click interface before Xerox PARC invented it and Apple popularized it?

————–

Making changes that address complaints or known problems certainly makes sense.  But doesn’t it also make sense to make changes that simply improve the ability to deliver, even if there isn’t an obvious problem to solve?

For just one example, I have worked with teams who used a big visible task board to track progress on their stories, but the board was so confusing that it didn’t add much value.  Simplifying it and making it more readable generally helped to improve the clarity of each story status and the progress of the sprint, and I would notice people starting to have discussions around the board.  Conversations improved, collaboration increased, and the team performance often went up as a result.  Yet, no one had ever complained about the board.

When a team retrospects, they often focus on the things that didn’t go well over the past sprint.  For instance, they might devote a few collective hours of time to solving a very specific problem that was raised; e.g. “I didn’t have the login credentials necessary to access this particular database that I needed to consult to find out some information for my story.”  But, instead they could have spent time figuring out how to collaborate better on identifying business requirements – an activity not driven by any complaints or problems, but one which could generate significant benefits in terms of velocity or delivering value.

————–

How many of us complained about not having a web interface on top of the Internet before Mosaic?

How many of us complained about not having a smart phone before IBM created one and Apple popularized it?

 ————–

Marcus Buckingham, leader of the strengths movement , notes that a person’s “greatest room for growth” is not one of their weaknesses but their strengths.  Might not this also apply to agile teams?

What if, instead of always focusing our retrospectives on fixing the things that are broken, we sometimes take a critical look at things we already do well, but could get so much incremental value out of doing even better?

Investing in cross training, for example, has to potential to be one of those practices that can generate huge improvements in team productivity, even for a team with already broad skill sets.  A team could become so efficient at being cross functional that they never would find tasks blocked due to the lack of an available person with the right skills or knowledge.  Tasks and stories will flow even better and overall team productivity can only go up.  The same might be said for building foundational principles like commitment and empowerment.

Continuous improvement isn’t about fixing problems.  It is about inspecting everything that you do, good and bad, making decisions about where change can make the most impact, and validating your decisions.

I was recently teaching a Certified Scrum Master class and was told by a student that Scrum didn’t work because management still comes and demands additional features or projects and sets or keeps the deadlines and not asking for estimates of how long it will take.

That is not a Scrum problem. That’s a business environment problem. And the solution is often the person lamenting it the most. Perhaps it’s like the guy that complains about dogs because his gets into the trash or barks all night. It’s not dogs that are the problem, it’s his allowing his dog to behave that way.

These are the type of complex organizational development problems that are difficult to solve. They take more than a two day class on Scrum fundamentals to solve. They may be very difficult and take a long time, but they are possible. Don’t think that they are not. There is a world of difference in the mindsets behind possible and impossible.

If you fall into the trap that they are impossible, you give up trying – looking for possibilities, options, trying out new ideas. You lose hope. Certainly if you are a leader, it is incumbent upon you for the sake of the people who follow you. The book Strengths-Based Leadership lists the four needs workers have of their leaders: hope, stability, compassion and trust. If you are an agilist, then you are acting as a servant leader, and therefore need to maintain hope.

I couldn’t tell this student how to solve his problem – that’s contextual and that’s why there are coaches helping organizations with these types of cultural and management changes. Even without a coach helping, there’s a lot of places to look for good information on this.

But you won’t take that first step if you are stuck thinking it’s impossible.

This post was originally posted on Scott’s blog and included in VersionOne’s March Agile Chronicles. You can find more about strengths-based agile teams on Scott’s blog.

Join BigVisible coaches and Scrum community members from around the world as they gather together in Atlanta for Scrum Gathering Atlanta 2012 at the Marriott Atlanta Buckhead on May 7-9, 2012. You’ll find plenty of ways to participate as you share experiences, exchange information and collaborate with fellow Scrum users.

The vision for this year’s gathering is related to the host city of Atlanta, home of the world’s busiest airport. “We see many analogies between the activities surrounding air travel and the activities surrounding a healthy Scrum implementation.” says Scrum Gathering Atlanta 2012 Co-Chairs, Peter Borsella and James Smith of Winnow Management.

Our own Agile coach, Michael Fortunato will be speaking at this event on “Appreciative Agile – Harnessing the Power of Appreciative Inquiry for Your Agile Initiative”.

His session will be broken into 3 parts, beginning with “Introduction to Appreciative Inquiry” where he’ll discuss background information, outline the 8 AI Assumptions, discuss the 5 AI Principles, and cover the AI 4D Cycle. Following this section, he’ll be discussing assessments to start the process, project initiation for discovering and focusing strengths, and ongoing support to build on the foundation. He’ll conclude his presentation with a collaborative workshop where attendees can experience Agile Inquiry for themselves.

For more information or to register to attend this exciting global event, visit the Scrum Gathering 2012 event page on the Scrum Alliance website.

We’re excited to announce a new, ongoing series that gives everyone access to our amazing team of agile transformation experts! Typically, these super-talented individuals spend their days on site at various client locations across the country, providing education, insight, and advice to help guide clients down the road to organizational agility. Now you can experience some of those same benefits by engaging with one of our coaches in a monthly Twitter chat we call Coach’s Corner. Bring any questions you have about agile, project management, or anything else you can think of—we’ll supply the coach.

Coach’s Corner is a monthly Q&A-type format that will take place on the BigVisible Twitter account (so be sure you’re already following us for updates and information leading up to each of our Coach’s Corners). To ask our coaches questions during the event or in the weeks leading up to it, simply tag your question with #BVcoach. That way, our featured coach can tackle your question in 140-character snippets!

Always wondered how agile can apply to your industry? Need ideas for increasing participation in your morning standups? Having trouble getting clients to understand your agile process? Now’s your chance to ask a true expert and get ideas, inspiration, and advice you can put to use right away!

Our first Coach’s Corner is taking place on April 18th at 3:00pm EST with Tiffany Willis, an Agile Coach for BigVisible who works with large-scale organizations in the Boston, MA area. Feel free to follow along during that time or catch up when you can by searching for our hashtag, #BVcoach. In the meantime, make sure your questions get answered by tweeting them with the hashtag, #BVcoach.

Should you use Test Driven Development when creating your Minimum Viable Product?

At first glance, it seems like quite the conundrum.

Agile engineering principles strive for a test first approach, but if I don’t know who my customer is how can I determine what the quality should be?

My current line of thinking is this:

If you are using Test Driven Development to create your Minimum Viable Product, then it is more likely a Minimum Product.

A Minimum Viable Product (MVP) is the smallest batch of work you can complete to gain the most learning about your customers. It may or may not be code. If you are mercilessly TDD’ing your product then it is probably much more than a fake door or concierge experiment. You’ve already committed to a feature or features that solve a customer problem.

TDD isn’t going to bring a lot to the table unless you are building out features.

So instead of asking whether or not you should TDD your MVP, perhaps you should be asking yourself if you’ve really validated the customer need for your value proposition. I would hope so, or you are adding the overhead of TDD to a Minimum Product that may not even be viable.