Agile Coaching

Building an Agile Environment

My favourite Agile Manifesto principle is "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

As coaches, we naturally work with people helping them form cross-functional teams and install agile practices that drive iterative product development. How many of us throw our energy into improving the environment that people work in? Yes, most agile coaches know how important it is to setup a visual workspace, with cards on a board in the team space, as Xavier illustrates so well on his Visual Management blog. What more can we do?

In the first edition of "Extreme Programming Explained", Kent Beck exhorts us to "rearrange the furniture" to make team working and pair programming possible. Keith Braithwaite reminds us at QCon that larger monitors for programmers should be a no-brainer to improve programmer productivity. I'm particularly sensitive to inappropriate space for team meetings. No new kit needs to be acquired to shuffle the furniture and enable the team to stand comfortably standing around their board or to remove superfluous tables from a meeting room so the team can work together more closely.

Rearranging the furniture seems like a very practical way to support the teams you're coaching but it's more than that. Kent goes on to explain that for a team "Taking control of their physical environment is the first step toward taking control of how they work overall." Changes in the work environment send a powerful signal to the team that change is afoot and that the needs of individuals on the team are valued.

And there's more to environment than desks and computers...

At Open Volcano , Marta Gonzalez encouraged me to join her in hosting a session about "Creating an Agile Environment" based on a series of workshops I ran with Mike Hill at XPDay 2006, SPA2007, and Agile2007. There was an empty slot in our open space schedule so we announced the topic and posted it on the board.

   

The previous workshops with Mike involved asking participants to model environments with craft materials and Mike's old lego bricks. We had a sack full of crazy Playmobil characters (including pirates, medics, and firemen) that I picked up on eBay to represent people at work---surprising how appropriate some of the characters are for work situations. However, I figured we could do roughly the same format at Open Volcano by inviting participants to draw agile work environments on flipchart paper.

Everyone loves to tell horror stories about places they've worked. So we start the workshop by drawing "hellish" work environments, based on their real experiences. The pictures quickly fill up with pictures of noisy phones and windows with bars on. You'd think drawing would tend to focus on the obvious physical features of the workspace, such as furniture, but people also showed invisible annoyances like noise, temperature, smells, and management culture.

When we shared the drawings with the group, Marta and I teased out the following environment factors as sometimes impeding the work of teams:-

• Access to information and people
• Temperature (too cold or hot for comfort)
• Noise (from printers, phones, construction work, and other people outside the team)
• Coffee (eg, broiled brown liquid labelled as "normal coffee" isn't!)
• Smell (from food or team mates)
• Light (no daylight)
• Drabness (beige and grey decor doesn't spark creativity)
• Status symbols implying hierarchy (manager has the private office with windows)
• Rules (notices from other departments about what's allowed) --- like Irving's Cider House Rules written by someone else who does not understand the needs of the workers.
• Space (some offices are cluttered and cramped with stuff that doesn't belong to the team working around it)

Some of these are what Hertzberg called Hygiene Factors, we notice their absence and many reflect the company culture indicating whose needs are appreciated by the organization. Talk to the team about what annoys them about their work environment, now you can work with them (and managers) to start resolving these things. Many of these can be improved by the team. For instance, the team can brighten up the team space by bringing in pictures and plants from home, or club together to get a better coffee machine.

Next, we asked the workshop participants to draw a heavenly environment. Not surprisingly, agile teams want plenty of mobile whiteboards, movable desks with large screens that support pair programming comfortably. We also saw more human needs reflected in the work environments, such as pets!

It's clear that people may have different preferences about work environment, which may not be compatible, and this becomes a concern when they are working too close together.

The key seems to be people want to be able to configure their workspace. Here are some ideas for coaches to improve your team's work environment:

• Work in stealth mode, ask for forgiveness afterwards!
• Get everyone involved in the design.
• Offer to restore environment after trialling new setup.
• Read Christopher Alexander "The Timeless Way of Building" and visit Frank Lloyd-Wright buildings.
• Visit other agile teams to get more ideas.

It goes without saying that changes shouldn't conflict with genuine concerns from an organization's perspective such as health, safety, and legal concerns.

Last but not least, here's a great cartoon that Chris Matts drew while talking to Marta about her perfect work environment while she took care of our youngest participant, baby Noah.

Is Working Outside-In Always Better?

On Sunday, I went to GOOS Gaggle, a micro-conference on the development ethos described in  "Growing Object-Oriented Software Guided by Tests", the new book written by XP stalwarts, Steve Freeman and Nat Pryce.

After the main presentations, we moved into Open Space format. I joined a conversation with John Daniels and Willem van den Ende about "Why Start with End-to-End Tests?". Although we agree whole-heartedly with this, John was interested to explore whether this approach is always a good idea? You can read John's write-up of our conversation on his blog.

John starts by writing this up on the board.

When you start solving a problem from the outside, you ensure that inner workings connect to the real world setting. You start to grapple with all the interfaces to the system from user interface to the back end activities of logging and persistence. An excellent way to flush out any issues that might catch us out and require rework later on.

 
We wonder if the reason working outside-in and creating end-to-end tests is the simplest way to ensure we tackle risks early. John suggests that the biggest risk on some projects could be in the inner logic, for instance if the project was based on running complex calculations. Maybe there are situations where an outside-in approach may not be the best one to take?

Then I rack my brain trying to remember past projects where we didn't start end-to-end. What were the barriers that stopped us doing this?

The first example I remember was back in 1994 when I was working on a broadband switch demonstrator. My company was providing the call-control component but we were working in a consortium where other companies were providing other components that we would interface to, such as a set-top box, etc. Message protocols were not agreed and the hardware was work-in-progress but we had a hard deadline to demonstrate the kit at an industry expo. We did the only thing we could to make headway. We made-up a reasonable message protocol and then worked against software stubs which piped in messages in our imagined protocol. When the real interfaces were revealed, we mapped them into our own internal protocol, on the way in and out. This worked really well for us. We made the trade show deadline. Another example is more recent. A team I am coaching are building on some content-management infrastructure being developed by another department. It's not ready and they've been trying to work out whether to: wait, work on other features, or build their own solution using existing infrastructure.

Realistically, sometimes you need to make a start without having full end-to-end picture.

Our worry is that sometimes teams may prefer the "path of least resistance" because it's easy or they're naive about integration.

However, we ought not to forget that sometimes the biggest risk is organizational politics. It can be important to demonstrate progress to get buy-in from key stakeholders. Scrum can be perfect for mitigating such risks. We work on tangible product backlog items that we can demonstrate every few weeks. This builds trust in the team's ability to deliver on their commitments.

Willem adds that it can be hard for a team to justify "technical" product backlog items that mitigate risk over juicy features with obvious business-value. The team can attempt to make the value of such technical items more obvious by linking them to the money lost in downtime when a site crashes or security is breached.

Another common approach is to pair a Business Product Owner with a Technical Product Owner for projects where there are lots of infrastructure considerations. John pointed out that there's likely to be a tension between long-term technology decisions and short-term project goals. This is where it can help to have a project manager facilitate decision making. Thus, you need a three-way balance (as in this sketch) rather than (as we see too often) the Scrum team kowtowing to Product Owner without speaking up on technical risks.

Perhaps one of the main values of the GOOS approach and working from outside-in guided by tests is that we are able to flush issues out early rather than attempting to anticipate them. Thus we avoid awkward conversations with a Product Owner about potential risks because the issues stare us in the face having driven them out with end-to-end tests.

How "Agile" Is The Concept of Scrum?

How would you answer the question on this sticky note?




This question "How 'Agile' is the concept of Scrum?" was posed by Lucy, a business analyst with around six months experience on a team attempting to apply Scrum.

On face value, her question seems to be asking "Is Scrum a member of the Agile family of methods and frameworks?" Clearly, the answer is "Yes!" Jeff Sutherland and Ken Schwaber, the thought-leaders credited with creating Scrum,  took part in the summit that created the Agile Manifesto. Plus, the titles of "Agile Software Development  with Scrum" and "Agile Project Management with Scrum" books explicitly align Scrum as an Agile approach.

I took a deep breath. Before diving into an Agile history lesson, I tried to unpack Lucy's question, to see if I could get closer to answering her. "You seem to be asking "Whether Scrum is an Agile approach. Is that right?"

Lucy's brows creased and she shook her head. "No. I meant 'How flexible is Scrum?' Is anything in Scrum optional?" She went on "Our Scrum Master wants us to do Scrum by the book. That's difficult for us because people on our team come from different departments, we get conflicting messages from our line managers. I'm expected to work on more than one project and it's not working for me."

When I hear about Scrum Masters or teams attempting to "do Scrum by the book" it sets alarm-bells ringing for me. Scrum is a starting point on a team's journey towards agile software development.  Being Scrum is not the real goal. We use Scrum to deliver product increments. No one is going to come along to your team to check up on your Scrum conformance. There are no shiny Scrum badges to give out to the teams who doing Scrum correctly. Besides, Scrum has evolved over the years, you can find one book is at odds with another.

We follow the Scrum mantra "Inspect & Adapt" and fine-tune our working practice through retrospectives. As we become more proficient at delivering product increments, our team can decide to drop initial practices. For instance, they may find maintaining a Sprint Burndown in a spreadsheet is an unnecessary overhead when everyone can see progress on our task board. Scrum is definitely flexible.

However, being able to flex Scrum and not seeing Scrum conformance as important isn't quite the same as opting out of implementing various parts of Scrum because it's difficult.

Scrum is finely-balanced to maximize motivation and productivity. Scrum frees the team up to get on with work in sprints rather than constant churn from conflicting stakeholder requests. Scrum sets the team up for success by positioning a Product Owner, as broker for all stakeholder requests with a Scrum Master acting as Gatekeeper to minimize disruption during the sprint. I drew this picture to show how requests to work on other projects are headed off by the Scrum Master.

My picture could be improved by drawing the bubble around the team as a dashed line. The team is not hidden away. The team gets exposed to stakeholder feedback in Sprint Review and their visible backlogs make progress toward their commitments transparent.

Scrum is not a fashion statement. Make believe that you're doing Scrum by having daily scrum meetings and skip the rest. But be warned, without ring-fencing the team, you'll find it's a struggle.

If Scrum team members are asked to work on more than one project, they have conflicting priorities, which distracts them from working toward a common goal. Stand back and watch how this sucks the energy out of a Scrum team.

If your organization can't commit to putting the starting conditions in place for Scrum, they cannot expect to get the full benefit. Lucy's question came up because she was sick of being asked to pretend to do Scrum without experiencing any of the joy that can be gained from teamwork and regularly delivering useful products.

Agile Coaching is about humane and sustainable development, I hate to see people being asked to use process and tools that waste their time. We need to reach out to management to help them understand the basic principles underpinning Scrum and help teams to make the costs of multi-tasking more visible.

Shu-Ha-Ri Considered Harmful?

Back in 2002, Alistair Cockburn wrote about three levels  of practice: learn, detach, transcend that we can apply to our listening, reading and coaching. He used Shu-Ha-Ri from Aikido to illustrate that these three levels of practice are found in other skill areas.

• Shu, the student copies techniques without adapting them.
• Ha, the student reflects on what has been learned and breaks free from traditions.
• Ri, the student is now a practitioner extending the art.

In the 2nd edition of Agile Software Development, Alistair adds "You can apply Shu-Ha-Ri to designing courses and writing technique materials."

Although he takes care to say "Organize your material to reassure the advanced people in your course that it is not being presented as a cure-all, but simply as another technique in the toolbox of the professional. .. But before you finish, put the technique into a larger context so that the beginners can start to see where they will expand to and so that the advanced people can see how this technique bridges to others they might already know or want to learn."

I've seen Agile rollout programs styled around Shu-Ha-Ri for years. In the early days of both XP and SCRUM, it was stressed that you should first do all the practices by the book. Only then would you be in a position to adapt them. You would avoid the travesty of Pretty Adventuresome Programming  where the team avoids any difficult new practices and also drops stuff not mandated like documentation!

Jeff Sutherland relies on the same Shu-Ha-Ri philosophy when he expounds "You enter the dojo and do what the Sensei (teacher) says. You repeat exercises over and over until it is part of muscle memory. Only when you have mastered the basic practices are you allowed to improvise. And the last and most important – Before you have gained discipline, centering, and flexibility, you are a hazard to yourself and others."

I'm uncomfortable with approaches that force students to follow agile practices without questioning. These approaches seem to violate the first value of the Agile Manifesto "Individuals and interactions over processes and tools." I question whether introducing agile software development techniques to people is anything like martial arts training. Software development is knowledge work and our aim is to build a team of reflective practitioners. To do this we need to engage with how people think about their work. Are techniques from physical arts that build muscle-memory really applicable here?

For me, agile Boot Camps and Shock Therapy approaches lack basic respect for the team's unique context and the experience of people on the team. Agile software development is a much looser discipline than a martial art like Aikido. Organizational culture and nature of the product being built are major factors in what agile techniques the team will benefit from most. If we establish a sensei-novice model, we're not fostering the independent thinking and reflection that will take the team beyond the Shu level.

A different approach that draws from martial arts is the Coding Dojo . Dojos are becoming a popular way to encourage learning in groups without this emphasis on a sensei.

Installing a basic set of agile practices by force can be done quickly so the organization starts getting benefits from new ways of working faster. Teams are superficially at the Shu level in the space of a few weeks. Often, the management team considers the agile rollout is now complete. It's assumed that teams will continue to apply what they've learned. But without any experts around to enforce agile practice, pretty soon a team falls back to their old ways or sometimes worse carries on with agile practices that don't make sense for their project.

I was pleased to see "cargo-cult agile" called out in the new book "Practices for Scaling Lean & Agile Development" by Craig Larman and Bas Vodde. They say "Avoid forcing--When coaching we encourage: volunteering; do not force any agile or lean approach onto people; people should be left the choice to think and experiment...with concentrated long-term, high quality support. The best, the most sticky adoptions we have seen had this approach."

Learning new ways of working takes time.  As Ron Jeffries once said "They're called practices for a reason".."You have to have done them. Practice makes perfect." If you base an agile adoption on Shu-Ha-Ri model, the trick is to remember the goal is beyond the first-level. Your teams need more than training. Allow plenty of time and on-going coaching support for teams to get them into the Ha phase and beyond.

How does an Agile Coach differ from a ScrumMaster?

This year there's an increasing interest in Agile Coaching. Sessions about the role of Coach have been popping up in agile conference programs around the globe. Agile2009 even dedicated a stage to sessions on Coaching. Our book on "Agile Coaching" is the first book dedicated to explaining how coaches work with Agile teams. Meanwhile, Lyssa Adkins is also working on a book, "Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches and Project Managers in Transition", which should be out in the summer of 2010.

Yet, despite the burgeoning Agile Coaching movement, there's not much written about how the role of Coach fits into the Scrum framework. It's easy to see why people are curious. There's no Coach role in Scrum reference books, such as the Scrum Alliance Scrum Guide---although if you do some digging you'll see Coach was included in the original SCRUM pattern language. Yet what's puzzling is that Scrum Alliance's certification program includes Certified Scrum Coach, as an advanced level qualification on  your "journey to mastery". To qualify, you have to demonstrate significant coaching experience with client references. But how is a Scrum Coach different from a ScrumMaster?

In our "Agile Coaching" book, we focus on how to coach a team in a vanilla flavor of Agile rather than getting sucked into the specifics of the Scrum framework. So you may be surprised to learn that I often coach Scrum teams and ScrumMasters. Last month, Christoph Mathis invited me to share my experiences on "Being a Scrum Coach" at the Scrum Gathering in Munich. I was delighted to find there was a whole track dedicated to "Coaching & Continuous Improvement". This panel session was the first time I was put on the spot and asked "What's the difference between a ScrumMaster and a Scrum Coach?" that's when the seed for this blog post was sown.

Last week, the same question came up in an OpenSpace session for Agile Coaches and that gave me the extra nudge I needed to write up my thoughts. I've posted a photo that shows some points in our discussion here.

I'm sure you'll agree that a ScrumMaster needs coaching skills to perform their role well. I'd add that you don't need to be a ScrumMaster to be a Scrum Coach! Coaching skills are like good fertilizer. In my experience, it makes sense for you to spread these skills around the team. The ScrumMaster is not the only person who needs to absorb them. My goal, as a coach, is to encourage the team to become self-coaching rather than continuing to rely on any one team member to be the coach. So for me, a coach is a transitional role until the team grows their own coaching capability.

When you take this perspective on board, your next question is "Does an experienced Scrum Team continue to need a ScrumMaster?" Surely, once they've got experience under their belts in applying Scrum, the need for a ScrumMaster disappears. Let's revisit to the responsibilities of the ScrumMaster. Are there any important aspects that can't be absorbed by the team?

Naturally, Scrum continues to evolve and over the years the role of ScrumMaster has been described in different ways. Ken Schwaber compares the ScrumMaster to a "sheepdog" who guards the team from interruptions, they're often the first point of contact for anyone outside the team. A ScrumMaster also focuses on removing impediments. Maybe it's down to personal coaching style, I'd never do either of these activities as a coach. My rule as an external coach is never to do any tasks for the team. I want to avoid creating any dependency on me. Instead, I teach the team to notice and respond to impediments and interruptions themselves.

As Mike Cohn reminds us there is no end state when transitioning to agile. Adopting Scrum is just a beginning to your team's Agile journey and a team doing "Scrum by the book" is not the end that ScrumMasters or Scrum Coaches are working toward.

Stop calling people Chickens and Pigs

If you attend a course on Scrum you're likely to hear the following joke:

As a ScrumMaster, you introduce the metaphor of Chickens and Pigs to help your team understand that Scrum meetings are for them because they are the ones who commit to the Sprint plans they make. Whereas a chicken, as Michael Vizdos explains, is someone who has something to gain by the pigs performing and does do not contribute to getting things done. Of course, all the Scrum roles including Scrum Team, ScrumMaster and Product Owner are considered to be "pigs" who take responsibility for making their process visible and engaging with "chickens" to get feedback on what they produce.

I'm blogging about this because I recently ran a release retrospective for three Scrum teams working on the same product. I was surprised to hear team members raise a number of worries about "chickens" in the pre-work surveys. When I invited the team to work in groups to draw pictures of what it was like working on the project, chickens also featured in some of their pictures (one headless chickens at a crossroads and another big chicken waiting at the top of a stairway moving backwards with a pig struggling up it). Something seemed strange about this and not healthy.

When the development manager followed up with me afterward, I told him that I was surprised to find a team using chickens/pigs language so much---especially as they were not new to Scrum. My opinion is that the chickens and pigs metaphor helps a team understand who talks at the Scrum meetings when they are starting out. These are not really roles to be performed with specific responsibilities so not a useful concept for the team to keep using.

Calling people animal names is likely to offend and tends to dehumanize the sitution. My opinion is that a Scrum team should be trying to build bridges with their stakeholders rather than labeling them as "chickens". There will be people outside the team who need to have some visibility into the work of the team. Take time to build a Stakeholder Map with the whole team and get to know who everyone is (without labeling the pigs or chickens). Likewise ensure that team get to meet stakeholders and hear their feedback firsthand at Sprint Review.

There are rare situations where you encounter a "chicken" who wants to get a bit too involved. How can you handle this? Often it's a case of educating them in the basics of Scrum so they understand when it's appropriate to share their opinions and ask for information. Mark W. Randolph lists some additional things you can try for talking chickens - I'd add treat metaphors as ways to introduce ideas not roles to be reinforced ever after.