Archive for June, 2012

June 28th, 2012

The “Domestique” – Leaders, Your Teams, and the Tour de France

I am drawn to watching the Tour de France every year and I’m already looking forward to the event starting this weekend. There is just something about watching people test their physical limits every day in such a beautiful yet challenging environment.

I have learned a little about the dynamics of a cycling team and it’s quite fascinating. There is typically one cyclist who has the best chance of winning and the others are there to support that rider in their quest.

The riders who are doing the supporting are called the “domestique.” Domestique translates literally in French to “servant.”

Throughout the race, the domestique are performing a variety of functions. During long stretches of the race they are out in front of their leader, as it’s easier to pedal when someone else is cutting through the wind ahead of you. The amount of energy saved by drafting behind another cyclist is somewhere between 30 and 40 percent.

The domestique will surround their leader in the “peloton” or the primary pack of riders to keep their main rider out of any trouble or big crashes.

The domestique are also tasked with falling back to the team vehicle to pick up food and water for the rest of the team. They do this so the others remain strong and do not spend the energy needed to catch back up to the peloton.

In most cases, the domestique are there knowing they have no chance of winning.

As organizational leaders, we may find ourselves thinking we are the rider designated for the victory. I know I certainly have.

But what if we consistently embraced some of the characteristics of the “domestique.” Perhaps we would be more inclined to:

Sacrifice. Do we make things easier or harder for our people? Are we cutting through the wind of bureaucracy, red tape, and politics or are we staying behind the pack to let our teams take the brunt of it? Are we the ones creating the red tape for our own comfort? Domestiques remove resistance, not create it.

Protect. Does everyone on your team feel empowered to make decisions and express themselves without reservation? Are we creating team environments built on trust and respect? Do people feel comfortable being themselves? Domestiques provide security.

Nourish. Are we freely willing to leave our own ambitions aside and expend energy to ensure our teams remain strong and ready for the challenges ahead? Are we spending time to provide meaningful encouragement and coaching every day? Domestiques ensure strength.

It’s not easy being a domestique and certainly not glamorous. But there is reward in the silent knowing of the part you played in people enjoying coming to work again and succeeding in ways they never thought possible.

Tags:
June 27th, 2012

The Power of Pilots

Leaders are tempted to decide on organizational or workflow changes and reveal them with a “big bang.” The reveal will often include a new org chart with the instructions that we’ll figure out the details later. As organizations grow larger and more complex, the success of implementing change in this way becomes questionable. At the very least, the changes will be stressful but they are often painful to those affected.

As I see it, here are a few of the problems with using the big bang approach when it comes to organizational change.

First, the changes are often designed in isolation. Change originated in isolation is rarely received well – even if the change being designed is solid and sound.

Second, the changes are often reactionary. Change originated as a reaction to a negative event or issue will often bring emotion and politics into play.

Third, the changes are often made in desperation. Change originated from desperation will limit options and creativity.

An alternative approach would be to use pilots to prepare and engage an organization around the change. Pilots are small, controlled initiatives with a select group of people or teams. During our Agile transformation, we used pilots extensively to see what would work with our organization and what would not.

There are cases when a change cannot be piloted but if you start early most of them can. Here are a few of the advantages in piloting organizational change initiatives:

They put ownership in the hands of those most impacted. Change is not easy on people. Most people do not like change and they especially don’t like it when they feel like they have no control over what is changing.

They allow you to experiment with your ideas. Looking to merge departments or remove constraints in the value stream? Setup a small transformation team to capture the current pain points and use the pilots to experiment with new roles, activities, or work products.

They allow adjustments to be made. Once the pilots are underway, use them to learn how the changes are received and if they are effective. Make changes as necessary and pilot them again.

They build examples and evangelists of the change you are looking for. Once a pilot is deemed successful and the change is moved to a broader implementation the people on the pilots become advocates and evangelists for the change.

Again, starting change initiatives early and getting those who are impacted involved will allow organizational change to be truly transformative…and you may find that you have created an empowered workforce along the way.

June 21st, 2012

It’s Later Than You Think (Organizational Change and Mountain Climbing)

While writing my earlier post about Coaching Pull, I started to use a mountain climbing analogy but after a few edits it just didn’t seem to fit. But it did get me thinking…

Having personally climbed a large mountain (or two) and being active in organizational change initiatives, it seems to me there are some parallels we can learn from.

Starting Early. Many organizations realize far too late when change is required. When the realization is finally made, the necessary change is more dramatic and painful than it should have been. The same is true for mountain climbing. This is encapsulated in my favorite mountain climbing quote from Gaston Rebuffat in his book On Snow and Rock in 1959:

Rise early. Fix a time-table to which you must try to keep. One seldom regrets having made an early start, but one always regrets having set off too late; first for reasons of safety-the adage ‘it is later than you think’ is very true in the mountains.

Preparation. Unless you are a world-class adventurer, you will need someone who has local knowledge of the mountain to guide your way. With organizational change, build an internal guiding coalition and partner them with an outside coach who has experience in change management. Make sure you have the right equipment for the journey as well.

Safety. Just like with climbing, human lives are at risk when enacting organizational change. While usually not a life or death situation, it is important to understand that change affects people in different ways – physically, emotionally, mentally. Through proper preparation, be ready to handle any human need. Treat every organizational change as if a life depends on it – because it does.

Acclimatization. Going too high, too fast at altitude will have consequences. The approach when climbing involves heading to a higher elevation for a short period and going back down. Trek back up and settle at the higher elevation before repeating the process. If you have started early with your organizational change, you have the freedom to experiment and pilot with small changes and little fixes leading to an end goal. Try something out, get accustomed to the new change, see what works, adjust if necessary, repeat.

Whatever change is necessary, just start. It’s later than you think.

 

June 19th, 2012

Coaching Pull

An important dynamic of becoming a fluid and well-functioning Scrum team is when team members are continuously pulling. As opposed to being pushed or waiting to be pushed, the team is in constant motion, pulling from a queue of features that should deliver value to customers. The product owner established the queue of features by pulling from the overall organizational vision and strategy and a backlog of stories are created and prioritized.

The team pulls from the top of the backlog to decide what will be accomplished in a sprint. Team members pull from the task board throughout a sprint, regardless if its their speciality or within the scope of their role. Status is not pushed to the team but rather, they pull their progress from task walls and burn down charts.

Like many of you I imagine, I have worked on teams that were oriented to pull and I have worked on those that were pushed. This post is not meant to debate the merits of one over the other but for me and others, being a part of a team collectively pulling is much more satisfying and exciting than the alternative.

What I have experienced on teams who are being pushed (as both the pusher and pushee) are the ones doing the pushing are usually managers, supervisors, or project managers. They are expected to deliver results and they may very well obtain them but often at the cost of long-term team and organizational health.

You can always add more pushers and use brute force to get something done. Eventually the people doing the pushing will wear out and you’ll run out of pushers. Those being pushed may, at some point, have had enough of being pushed and move on.

It is also hard to change directions when in a constant state of pushing. You have probably tried moving a string around a table. Push it and it becomes a ball. Pull it and it goes wherever you want.

If you have made the decision as an organization to focus on pulling rather than pushing, here are a couple of things to consider when transforming or building your team:

Establish a compelling reason for people to pull. A pulling team requires a vision and a target – without one they will just keep themselves busy or they will create their own target until one is supplied to them.

Design your workflow system around pulling vs. pushing. Your system should make it obviously painful when someone within the organization begins to push. Pushing occurs when a common vision has not been established or communicated effectively. Many Scrum mechanics will help reveal when pushing occurs so treat any push events as impediments.

Teach and encourage the system. People will be hesitant to pull when they aren’t sure what impact their pull will have. Before coaching pull, make sure leaders and team members understand why pulling is so important to the overall health and success of the organization.

Latch on to strong pullers. You will be able to spot the strong pullers. They are the ones at the front of the line asking what’s next. They are not comfortable waiting and are often an expert within their role. They don’t mind blazing new trails for the team. If there is someone struggling with proactively pulling, have them shadow a strong puller for a couple of weeks.

 

June 14th, 2012

Scrum Master Interview Questions

Hiring a Scrum Master? Interviewing a Scrum Master? Here are 28 interview questions or scenarios to consider:

Phone Interview Questions
I would use these questions to quickly determine if a candidate has a base understanding of Scrum and should be brought in for in-person interviews.

  • In two minutes or so and at a high level, describe the Scrum process. Overall Scrum knowledge
  • How many teams have you been a Scrum master for and what were the size of those teams? Experience
  • What deliverables should emerge from a sprint planning session? Detailed Scrum knowledge
  • A new Scrum team has launched and you are the Scrum Master. How do you get them started? Ability to facilitate, coach, and build teams
  • If you could describe the Scrum Master role in one or two words, what would it be? Understanding the role

In-Person Questions
If the candidate has made it this far, it’s time to see what they are really made of. These questions are based on the expectations and noble cause from the Scrum Master vision sketch I have created for the Scrum Masters on my team.

Shaping Team Experience

  • You have some team members who are quiet and not as social as the others. How do you ensure their voice is heard? Looking for a strong approach to facilitation and possibly coaching and mentoring techniques.
  • How would you ensure team inclusion for team members who are located remotely?
  • You have new team members who are new to Scrum. What is your approach to teaching them?
  • A product owner (or team member) is struggling with writing meaningful stories with clear and concise acceptance criteria. What would you do to help them?

Team Flow

  • What characteristics does an Agile team in “flow” have? Looking for things like consistent velocity, rare story carry overs, team camaraderie, creativity, self-healing, frequent deployments of valuable features, low internal stress
  • What role does a Scrum Master have in keeping a team in “flow”?
  • What are some signs that a team is out of flow?
  • Team members are not stepping up at grabbing tasks from the task wall – it seems like they are waiting for someone to assign tasks to them. How do you coach “pull” vs. “push”?

Team Health

  • You see the developers and testers consistently working independently of each other, what approach would you use to promote collaboration?
  • How would you respond if after a retrospective, a team member asked you “Why do we have the retrospectives? They are a waste of time!”
  • The team does not feel like a cohesive unit and the retrospectives are feeling like blame sessions. What steps would you take to discover the problem? Looking for strong listening skills and the self-awareness not to try to solve or force things
  • One of your team members does not seem to be pulling their weight with the team. How do you coach the team to be self-accountable?

Information Radiation

  • What purpose does the burn down chart serve?
  • How should a Scrum Master react to an over-committed or under-committed burn down?
  • Why is it important to meet every day at the task wall?

Removing Impediments

  • What are some likely impediments you would see within a Scrum team?
  • What approach do you use to remove those impediments?
  • How long would you wait to escalate an impediment?
  • An email thread has been bouncing around the team discussing an issue that has clearly become an impediment. What do you do?

Change Your Community

  • How do you make your retrospectives powerful and meaningful?
  • What are some effective retrospective techniques you have used in the past?
  • How do you track actionable change items emerging from a retrospective?
  • During your retrospective, consistent issues continue to emerge around technical environments. How would you handle this?
June 12th, 2012

There’s a Glitch in the Matrix – Getting an Agile Team Back into Flow

One of the attributes of a healthy Agile organization are teams being in a state of flow. You can easily tell when a team is in flow. There is a sense of purpose and vision, there is very little stress, there is laughter and comraderie. They are committed to each other, and when a challenge comes, they handle it together, without drama. They just solve problems, together. The team is not perfect but they sense when something is not right and self-heal.

It seems like the team in flow gets more done than any other team and from outside appearances, they make it look effortless. Sound to good to be true? I’ve seen and experienced teams like this. They are a joy to watch and its absolutely possible.

Now, when a team is the opposite, they are out of flow, the results can be damaging and perhaps even create an unhealthy environment for team members. When teams become out of flow, they:

  • Are always playing catch up. It feels like they are on a treadmill with the incline slowly being increased to an unsustainable height.
  • Will have a tough time reacting to change as its challenging enough getting planned stories completed. The team heart rate is too high from the increasing incline to tackle the next hill.
  • Are challenged to establish retrospectives as a time of gratitude and renewal as these sessions will often devolve into gripe or blame sessions. They are out of breath to put meaningful effort into making this session a time of true retrospect, collaboration, and improvement. They may be too tired to even realize they are out of flow.

If you have a team out of flow, here are some steps to bring them back:

1. Go Back to Basics
Always start with this one. Pull out your Agile framework or Scrum Guide and facilitate a team basic training session. In many cases, a team becomes out of flow when there is a deviation from the framework. Someone is not fully living into their role, a work product is not being produced as it should be, or an activity is not happening when it should be. Bring the team back to “shu” in the “shu-ha-ri” levels of practice.

2. Look at the Planning Session
Once the team has a solid understanding of the basics, observe the sprint planning session. Is the team asking the hard questions during this session? Have they sufficiently answered issues around technical feasibility? Nothing stops a sprint faster than large, unresolved technical design questions. Are user stories well-written with robust acceptance criteria? Is the team over committing? “Flow” can be designed and planned and it starts with this session.

3. Promote the Vision
Give the team a reason to get back into flow. Is the product vision strong and compelling? If not, it may be time for the product owner to take another look at the vision and freshen it up. If the vision is solid, then promote and publicize it. When a vision is exciting and worth pursuing, the team will rally around it.

4. Protect the Team
Distractions from leaders, other teams, and requests from other areas may be pulling attention and time away from your sprint goals and causing team members frustration or anxiety. Do whatever you can to protect the team and keep them focused on the vision. This is why you have a Scrum Master…use them.