Saturday, October 1, 2016

First day as Scrum Master

If you've been hired as a Scrum Master, you'll most likely have a vision of the future state of the team based on interview questions. But do you really know what's going on? Here's what I have done to start integrating myself with the team and building my knowledge.

The very first thing to do after you get a brief tour of the place, it always starts with a tour, is have a general meet and greet session with your team. Tell them your story, invite questions, and if appropriate, like the team is new to Scrum, discuss why you're there. This is a light-weight meeting more about introductions than any deep understanding. But, you're not just saying hello, you're watching and listening closely. The team will almost certainly be on their best behavior at this first meeting so the clues of how they interact will be subtle and mostly come from body language. Watch how the others react when someone speaks.

Start by asking each team member in turn what their most recent proudest moment, greatest success, or greatest satisfaction was as a member of the team. As you go, note the introverts and extroverts, the cynics and optimists, and note how many shared the same positive experiences. If everyone shares the same experience as their best then this becomes your target of understanding later, that is, what about that experience pulled the team together. If there are several 'greatest' moments then you'll need to dive into this during the one-on-one meetings with the team after to figure out how each person measures success.

Ask each member in turn what their biggest issue or impediment is. Write this down. Be seen as writing it down. This is important as you need to follow-up. The first question is about past successes but the second question is about the team's future and although not explicitly stated, it's setting the goal of more successes in the future.

On your first day, you're looking to set the tone as an open and honest person, as someone who cares about the team, as someone the team can be open with, and as someone there to help. You can do this following these three steps:

1. Telling your story with some personal details, family, pets, an awkward moment but use caution to not go too far. You want to leave the team yearning to learn more about you, not for them to make final judgments.

2. Ask a question about team successes that helps to reveal team dynamics and ask it of each individual. Listen and watch closer for clues to the team. Be cautious that you're not judging but ask any follow-up questions to draw out the experience they felt.

3. Ask the question of what the team expects or hopes you can do for them. You make it clear that you serve the team. Resist any temptations to "solve" problems here, this is not the setting. Do follow-up on any issues or problems, you need to establish that you're there to actively help.

The next thing to do is conduct a one-on-one interviews but this is another topic.

Have a supremely successful week.

Sunday, September 25, 2016

Leadership and Vision

If you want to build a ship, don’t drum up the people to gather wood, divide the work, and give orders.  Instead, teach them to yearn for the vast and endless sea. – Antoine De Saint-Exupery,  Author of The Little Prince

When you’re working to change the way things work, always strive to provide a strong and compelling vision. If you’re simply telling people to do ‘A’, ‘B’, and ‘C’, and you have the authority to do so, then you’ll most likely get compliance. You’ll also probably get something done in the near term but it’s very unlikely that the change will sustain itself.

Instead, share the the vision of a better world with the team, share the hoped for impact of the change and share why it might be better. Share too the idea that it’s an experiment to be better. If the team can see the vision, have them provide the way to achieve it. Then, serve the team by helping them achieve it.

Try these three steps: Vision, Actions, and Outcomes.

Vision: As a Scrum Master or as a Product Owner, I see the Team talking with customers, understanding their pain points; getting to the heart of the problem the customer most wants solved.

Actions: Create an interview script that has the interviewer asking some questions. Pair off the team members so that only two meet with the customer. Identify what customers to talk to and arrange a casual meeting over coffee. Conduct the interview using a pull technique to get their number one problem and what their world would look like with it solved.

Outcomes: A Lean Business Canvas to make visible the hoped for business outcomes, a release plan if the the business plan is feasible

The Vision in the example above doesn't specify what happens afterward but only after the vision is established do the Actions and Outcomes become apparent.

Saturday, March 12, 2016

Agile: Don’t Sell It, Demonstrate It

There are many things you can sell including some ideas but you can’t “sell” behavior and you should not try to sell Agile to people. Both of these are learned and become part of what you are; they become the standards of behavior by which you live. Because these are learned, try substituting “demonstrate” for “selling”. This is not to say you don’t persuade your C-Levels of the merits of Agile so you can experiment but selling alone isn’t going to be enough. If you approach your C-Levels about being Agile you might start at a disadvantage because, unless they're planning on becoming an Executive Scrum team, their main interest in Agile will most likely rest on results and outcomes, not theories. To put another way, if the business needs a hole, talking about the merits of using a shovel over a spoon won’t get the hole dug and won’t bring any value to the business. Instead, demonstrate a great and mighty hole can be dug quicker and more efficiently with a shovel, then do it again just to show it’s repeatable.

The Experiment

When I first started using Agile, the CEO & company were faced with a particularly challenging business opportunity requiring an innovative software solution in 3-months. The CEO asked if development could meet a hard commitment in 3-months but the answer was no. We followed a Waterfall paradigm at the time but we knew we couldn’t execute successfully in the short time available using our current methods and practices. Being in the right place (the business needed an alternative) and at the right time (we had just completed research into the various Agile methodologies), and of the proper Agile frame of mind (we were eager to experiment with Agile), I was able to implement a variant of Agile Scrum that allowed us to pivot 180 degrees and build a software solution within that 3-month window. Agile and Scrum made it possible for Development and Product Management to capitalize on our business opportunity quickly and efficiently. Did the CEO want us to do Agile? The simple answer was he really didn’t care what means or tools we used to be successful; what he wanted was for us to be successful. Adopting a flavor of Agile gave him and the business the result and success they wanted. And once he had seen a positive result, he asked why all the development teams weren’t using “that Agile thing”.

The Demonstration

The CEO was never “sold” the idea that Agile was anything special but instead we demonstrated that Agile could bring special results. The CEO, the board, and the shareholders want the company to be successful and profitable. If the way to achieve success is both repeatable and sustainable, all the better. If they had that success using Waterfall or Agile or any of the dozen or so other software methodologies, everyone would be happy. The R&D Manager and Head of Product Management suggested to the CEO that the only real possibility of success lies with using an Agile Scrum framework and practices. This was essentially the only executive coaching needed. The high visibility resulting from using Agile Scrum and Agile’s built in ability for the team to absorb changing requirements, gave the company a fighting chance to take advantage of the opportunity which, in the end, was met, exceeding most expectations.

To move the business at its highest levels often requires a demonstrable success. A business may still choose not to change after a demonstration (or two) but what are your chances for change if all you have are theories and anecdotal data from other companies?

Wednesday, October 28, 2015

Product Backlog Flows

There are plenty of discussions in the agile community about how agile teams work and develop over time. Often neglected or poorly understood is how that work makes its way from the customer to the team. Below is a blueprint for creating an effective and efficient flow of work. I’ve included details but also left it flexible enough to be customized for your company’s specific circumstances.

- See more at:

Self-Organizing Development Team


·        Self-organizing teams are composed of individuals who manage their own work, pick up work based on need, and participate in team decision making.

·        Self-organizing teams must have a common focus, mutual trust, and respect.

By being self-organizing and self-managing, the team brings decision making to the level of the problem. This increases the speed and accuracy of problem solving.

Self-organizing and the Scrum Framework

The Scrum Guide gives the Scrum Master the role of coaching the Development Team in self-organization but doesn't provide insight or guide as how this is accomplished. So …

Tips For Management, Agile Coach, and Scrum Master to organize a team toward self-organization

·       Management (yes, management) must establish any parameters that the scrum team is required to work within. For example, usually only managers can hire and fire people. Otherwise, management should ensure they don’t get in the team’s way. Managers need to support the scrum teams rather than be a distraction.

·       Give a scrum team room enough to fail in order to allow them to succeed. Managers must not ‘step in’ every time they perceive the team is on the wrong track. The team may very well be on the wrong track but there are several inspect & adapt opportunities for the scrum team to correct itself. This is the big reason sprints are short, no more than 30 days, and most often 1 or 2-weeks long. I've seen a development team start a sprint, go down the wrong architectural path, discover it, do a re-design, re-do work they had already done, and still meet the sprint goal. True story. However, the chief architect had chewed his nails down to the knuckle while not saying anything. How proud was the development team after this? Extremely – they were trusted to get the job done and done right.

·       From the start, guide the team to do scrum (scrum guide). Shape the mindset and expectations from the start as this will be harder to influence and change later. Doing scrum by-the-book will not make you good at doing scrum but it will be easier for the team to later learn and adopt the nuances and spirit of scrum. 

·       Help the team become confident in their use of scrum early on. Use examples of how each inspect & adapt meeting can help improve the team’s work and their environment.

·       Remove any misconceptions the team has of scrum. Most teams will perceive that scrum is easy to do but it is actually hard to do scrum right day after day. Anticipate the development team’s reaction to this truth.

·       Use positive reinforcement and build a sense of achievement in the team by helping guide the team to successfully completing their sprints. Do not allow a team to over-commit in their sprint planning meeting based on hope alone. Guide the team to select a sprint goal that is achievable and don’t let ‘hope we’ll get it done’ be the team’s strategy. Hope is not a strategy.

·       Encourage ongoing adherence to scrum and agile practices. Watch for danger signs the team is reverting to older, non-agile ways of thinking and doing. For example, do they want to skip the daily scrum or sprint retrospective. Do they think only one person can do work in a specific area. Are they not forthcoming at meetings.

·       Get the customers and users involved in the process. Customers and users need to be engaged during requirement gathering but most importantly, must be engaged with the scrum team during the sprint review. If the customers or users are consistent no-shows at the sprint review or not showing interest at the sprint results, the development team will more likely lose their sense of purpose and possibly blame agile for their lowered self-worth.

·       Inspect & Adapt over blame. When someone on the team messes up, don’t say “Jane screwed up” or anything like this. I would try and restate it along the lines, “how was it the team allowed this thing to happen and what can the team do to prevent this from happening again?” Encourage the team to re-examine their team processes to see if something needs to change to avoid repetition.  Every effort should be made to make the team, as an entity, the focal point during inspect & adapt meetings and discussions rather than specific individuals. This will help reinforce that the everyone on the team is equally responsible and accountable for the results and outcomes of the team. This is along the “all for one and one for all” philosophy. While it’s important to know someone forgot to get their code, document, etc. reviewed, it’s more important to understand how the team allowed this to happen and to see if there’s something the team can do in the future to prevent it from happening again.

·       Identify team members who hamper or slow down the team’s productivity because of their personal characteristics and practices. Individual personality of team members can be considered more important than skill sets when selecting people for a development team. Work with the team and management to remove people who have difficulties adjusting to agile. This is a hard decision but one that needs to happen quickly; these are not ‘bad’ people but are people who can’t adjust to agile and scrum ways of thinking. Many believe the most productive scrum teams are open, honest, willing to change, and can see the team being greater than the sum of the individual team members. If a person doesn’t have or can’t quickly acquire these characteristics, then they may be an obstacle to self-organization and pose a threat to productivity necessitating their removal.

Wednesday, April 29, 2015

Why Just Saying "Good Job" Might Be a Bad Idea

Have you been to a Sprint Review where someone sings out, "good job"?

When this happens we might feel happy or encouraged to continue doing whatever it is we did in the review but what does this comment really mean? The idea that someone calls over their shoulder "Good Job" as they leave a meeting, can leave the team in a slight quandary, what exactly was good?

Scrum Teams need to be able to improve in areas where improvement is warranted. Having constructive criticism is healthy for the team and can help them focus on improving whether that be taking a valuable behaviour or practice and making it better or re-thinking actions and activities that don't add much value. The key is getting valuable feedback. For the Scrum Team, it's important to get as specific as possible about what someone thought was good (or in need of improvement) but more importantly, is why they thought to mention it in the first place.

Understanding why is arguably more important than the what in two aspects: 1) it can bring the Scrum Team insight to what the stakeholder values and 2) it can inspire the Scrum Team to design and build better solutions to meet stakeholder expectations of valuable software. For example, if a stakeholder says they liked the demo segment of the sprint review because it showed an easy way to make a credit card payment, the Scrum Team might conclude that the stakeholder values simplicity in the user experience. The Scrum Team might also conclude that in the future, they'll put a little more attention in the UX design to exploit simplicity.

Scrum Teams need feedback to self-improve and need to find the best way to get the gather this information. The easiest way is for the Scrum Team to listen for all stakeholder comments during any of the team's Inspect & Adapt events (daily standup, sprint planning, sprint review). The team may need to follow up with the stakeholders to understand the what and why of their statements. Through the practice of 'Active Listening' and developing a deeper understanding of stakeholders intent, the Scrum Team can improve and provide greater value to the team's customers and stakeholders.

Friday, March 20, 2015

The Scrum Master: Career Path or Career Oblivion

What is the career path for a Scrum Master?

That question was raised recently when I was asking people in the Development department if they thought they'd like to be a Scrum Master and whether they would apply for a Scrum Master role. Of course the question and answer related to their specific company but I've heard the same question asked at Agile meetups and Agile conferences. The short answer [to me] is: there's a clear career path for Scrum Masters. The key to this career path is growth.  Let me explain.

Those of you that work in Development are sometimes isolated from the business. This is not an insurmountable problem but let's be honest, work on products occurs in Development and the business of the company occurs in the sales/marketing offices of the various regions. You could think of Development having the intellectual property of the product, the brain, whereas the regional sales/marketing teams (Americas, Asia, Europe, Australia, Africa) form the heart. Neither can survive without the other and both are necessary for growth and vitality. The best scenario is that the brain (Development) and the heart (sales/marketing teams with their customer insights) work together in a seamless, symbiotic relationship. Establishing and maintaining a great communications link, having everyone working from the same page, and working toward a shared product vision are essential ingredients for growth. From a Scrum prospective, the Scrum Masters are the people whose role it is to find a way to make this happen.

In the Scrum Guide, Ken Schwaber and Jeff Sutherland imagine a world where the Scrum Masters, get the organization to understand and work with the Scrum Teams by:

  • Leading and coaching the organization in its Scrum adoption,
  • Planning Scrum implementations within the organization,
  • Helping employees and stakeholders understand and enact Scrum and empirical product development, and
  • Causing change that increases the productivity of the Scrum Team.
A Scrum Master will hasten the adoption of Scrum Values (from the Scrum Alliance
  • Focus - Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner. 
  • Courage - Because we work as a team, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges. 
  • Openness - As we work together, we express how we're doing, what's in our way, and our concerns so they can be addressed.
  • Commitment - Because we have great control over our own destiny, we are more committed to success.
  • Respect - As we work together, sharing successes and failures, we come to respect each other and to help each other become worthy of respect.

But how does this lead to a career path?

By improving lines of communications, by getting those in direct contact with customers communicating the pain customers feel, by getting the product development teams to have empathy with the customer, by understanding the impact of technical solutions on the customers, by keeping all aspects of the business informed of customer problems and potential solutions, by being transparent, by continually striving to improve, by creating a culture where learning trumps blame, by creating a culture where the question is not, "what have you done?" but instead, "how can I help you?", by doing all these and more, the Scrum Master will create the opportunity for the company to experience unprecedented growth. And when you have growth, you create more jobs and a larger product base and with that comes the need for more sales people, more marketers, more product managers, more products, more projects, and more Scrum Teams. I should say that Scrum Masters are almost never ever directly responsible for a company's growth. However, through the actions of the Scrum Master and many of the communication improvements and process streamlining, the inevitable result will most likely be growth.

Scrum Masters typically move into roles like product owner, product manager, head product owner, head of product management, program manager, project director, program director, agile coaching, development manager, technology manager, and others. Most of these roles may not exist today but with growth and expansion, some of these roles will come into being.

Whether your company or business has a global footprint or is a young Start-up, Agile and Scrum can be tools for growth and the Scrum Master role is positioned so that the results of good Scrum Mastery is company growth. Once there's growth, there almost always follows more and greater opportunities. Who is better positioned to move up and forward than the Scrum Master?

Your thoughts?