Transformation: Attitude over Aptitude

When you’re involved in any type of Business Transformation, the success or failure of that transformation may lie with the company’s culture. However, there’s more to culture change than the environment everyone works in as there’s a bit of culture within each of us that struggles and resists against change; it’s likely our fight or flight reflex.

Years ago I met Gary Swart, former CEO of ODesk, and asked him how he chose people to join the company. He said he looked for three things in order: Personality, Motivation, and Skills. He said skills are last because you can teach skills. The point is not to abandon those who are of the right mindset and are motivated. Believe in the people you’re working with and it’s much more likely they’ll pull through.

In my view, the team is central to any transformation success once the executive management team has agreed to change. To embolden a team to seize control of the product or service and their customers is the aim. Success is more likely to happen once the team and customers are working together to solve customer problems. A great team solves customer problems to meet business goals.

When hiring, the first thing most people look at are skills which can mean future change of the work force will be just that much harder. While skills are important, personality and motivation are more important. The ability for someone to change is more strongly connected to personality and motivation than the ability to say, write code. Let’s look at a situation where personality and motivation come to the forefront.

Have you ever sat in with a ‘team’ and heard someone say, “it’s not my job” or “it’s so-n-so’s job” or “I’m here to work” or “I wasn’t hired to do that” or “This is the way forward”? Or perhaps you’ve seen a situation where the team has accepted a particular way of working but then a person does their own thing their way? If you haven’t then you might be in the presence of a high-performance team. For the rest of us, this behavior is an anti-pattern to a successful self-organizing, cross-functional, and high performing team. Attitude is arguably more important than aptitude in any team.

I believe there are two different people who say these things:

1.    Person A says this because they’re apprehensive about doing something they’re unfamiliar with but there’s a reluctant willingness to try. They are not sure how to proceed but a glimmer of opportunity exists in their eyes.

2.    Person B says this because they’re stead-fast determined to do what they want to do or do what they perceive as their role to do full stop. They are closed to new and different ideas. They hear the new ideas and say, “but”. They are happy if nothing really changes for them but are quite happy to see others change as long as it doesn’t impact themselves.

Let’s deal with Person A; Person B should be relocated out of the team and given training or a job were this behavior is an asset.

Fear of the unknown, fear of failure, and fear of change are pretty much the same thing (a $1300/hr. psychiatrist might disagree). Helping someone become a better team mate is certainly within the scope of an team’s obligations and duties but it may take time and an abundance of patience. If you’re in an agile environment, having the team solve their internal issues is a great step in building trust and empowerment.

Prerequisite: If there’s a manager of the team, ensure this person is practicing servant leadership and not C&C. This may take several weeks to months to get the desired manager behavior. This step is a prerequisite before a team will feel responsibility for self-management of team members.

How to start the process of building a better team from within:

·    Recognize and understand the specific self-organizing, cross-functional, high-performing goals the team wants to achieve. Person A must understand and agree to these goals.

·    Recognize and understand the specific goals the individual wants to achieve. Fully understand how individual and team goals compliment or compete with each other.

·    Determine specific measures that can be used to determine progress toward a goal, either personal or team.

·    Setup work tasks that allow team members to work with Person A in a pairing environment toward achieving team goals.

·    Have the Team Coach help the team understand the benefits of being a self-organizing, cross-functional, high-performing team. Connect this to business and customer value.

·    The Coach is continuously helping the team to improve and learn from previous actions and work results; blame is not an option.

·    Allocate some time in every retrospective to discuss further both individual & team growth.

The measures for achieving individual & team goals are usually simple. For example, to help someone become familiar with a specific product or outcome so they can contribute, the team and Person A should complete a skills matrix on all areas the team is responsible for. For Person A, the goal may be to achieve a knowledge score of ‘3’ on a scale of 1 – 5 in a specific area. While the measurements are subjective, by having the team determine what great looks like and using the same measurement scales within the team, a meaningful measure will result.

Team skills matrix can help identify areas for improvement.

I once worked with a team who were very much thinking roles and role based responsibilities. The team was having a problem getting new development work delivered. It was found that the 8 developers were feeding all their great work to one person for testing. All their work flowed to one person who did the acceptance & system testing. Here was a bottleneck requiring people to move outside their areas comfort. When I first raised the issue with the team, one developer said, “hire more testers.” The problem was resolved with the COO and General Manager of Product both saying testing was the “job of the team”. The unspoken truth was you act as a team to get stuff done or you’re not likely to be better. The second point is there needs to be a strong, very strong, buy-in from management for the team to be agile in their behavior and work practices.

Another measure a team might consider using is:

“Number of hours in iteration spent helping team members grow and be better”

·    This reflects the total hours per iteration where the team spends time learning new skills, honing existing skills, teaching other team members new skills (T-Skills), interviewing and discussing customer/user problems with the customer/user. Measure in hours of an aspect of a self-organizing team: caring and improving the team.

Summary

It’s the team’s collective responsibility to help individual team members channel the fear of new things into excitement about new things. It’s also in the team’s self-interest to see themselves as responsible for the team’s collective behavior. If the team is unable to enact change then it’s almost a certainty the person is removed from the team and management takes over the disposition of the individual. In my experience this has happened only twice and each time the team and team coach (scrum master) spent more than a month trying to enact change without result. However, overwhelmingly, the team is able to work within itself to improve individual & team behavior in a most positive direction.

Tweet

3 More Questions to Ask During Stand-ups

Most everyone is familiar with the three traditional Scrum questions answered during the daily stand-up as presented in the 2016 Scrum Guide by Sutherland and Schwaber:

1. What did I do yesterday that helped the Development Team meet the Sprint Goal?
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The purpose of the daily stand-up is for the Development Team to review the previous day's plan and then arrive at a plan for the next 24-hours. In most cases, the Development Team can do this pretty well. The daily stand-up is a straight forward and simple meeting that focuses on the sprint goal but what could be done different to enhance the team's daily goals and daily commitments, commitments which the Development Team will hold themselves accountable for.
To help focus the Development Team on the day's planned delivered value, "What will I do today to help the Development Team meet the Sprint Goal?", it is helpful to expand this into 3 questions before taking about today's plan:

2.1 What is the customer value you'll deliver at the end of today?

2.2 Is there something you can show the Product Owner today?

2.3 Is there something you can do to help get the most important story done today?

Now these three questions are not simply the fantasy of the Scrum Master but are arrived at jointly with the Development Team. Each of the above questions have their roots in team retrospectives and, in the beginning, the team wanted the Scrum Master to ask them. It's very important that the team agree to any enhancements to the daily stand-up. For teams still early in their Agile journey, these questions will probably not seem unreasonable. However, for more mature Agile teams, there definitely needs to be a strong motivation to adopt them. In my particular circumstances, the Scrum Team was very mature and each of these 3 questions addressed a very specific problem the team recognized.

2.1.  What is the customer value you'll deliver at the end of today?

When the question is asked, the team provides an answer in terms of acceptance criteria/tests that would pass at the end of the day that currently fail.
I started asking this question of the Development Team several years ago when it was brought up during a retrospective that during the daily stand-up, the team was focusing on the technical aspects of the work more than the customer problem they were actually meant to be solving. It wasn't that the technical stuff wasn't important, it is, but we wanted the team to keep some focus on what why and who they're doing the work for. During the retrospective, the Product Owner said he was unclear of the progress of the user story, specifically the progress of the user story from a value perspective. More focus on the acceptance criteria and tests was a natural way to convey progress on value completed. The Product Owner was happy and the Development Team added the acceptance tests results as part of their daily planning.
This question provides an additional opportunity to further communications and collaboration between the Development Team and Product Owner. This is achieved by tying the customer, the acceptance criteria, and the solution together as a daily goal, a measure of value delivered each day.

2.2.  Is there something you can show the Product Owner today?

This question sprang from the Developments Team's observation that some work was being rejected by the Product Owner, especially user interface work, too late in the sprint to correct it. The problem was the team was waiting until the story was complete before showing it to the Product Owner. This usually resulted in a new user story being written and added for the next sprint.
During the retrospective, the team recognized that some user stories and the intended value were being missed during the sprint because of the delay in showing progress to the Product Owner. The Development Team and Product Owner quickly saw that viewing incremental progress was the answer but the Development Team needed to alter how they broke down the work into tasks to facilitate this. It was breaking down the work differently that was the real challenge for the team as it required some work to be done that would ultimately be thrown away. This was the occasional stub or driver code to get some display components looking 'right'.
This question provides an excellent opportunity to further collaboration between the Development Team and Product Owner. It serves to help focus on what 'done' means for a particular user story and helps reduce rework through a more collaborative approach to solving a problem. It can also make for a better product faster as the Development Team and Product Owner make any adjustments as a story progresses.

2.3.  Is there something you can do to help get the most important story done today?

This question got its start while 4 teams were working the same backlog and it was observed that new stories were being started while higher priority stories were still in progress sometimes with a large number of tasks in 'To Do'. Although this question came from a Large-Scale Scrum (LeSS) implementation, it scales down nicely to a single team working a single product backlog.
What the Development Team was trying to improve during a retrospective was their ability to swarm until done. When I was developing, I would prefer to work it alone, without outside help whether I could use it or not. The Development Team saw that this mindset tended to slow down getting stuff done and suggested that the question be asked during the stand-up to heighten awareness that getting to 'done' was important. The way it eventuated was tasks still in 'To Do' for the higher priority stories were picked up. It also helped in identifying tasks that needed further breaking down.
The question provided additional visibility to getting stuff done rather than getting stuff in progress. Getting work done quicker gives the Product Owner maximum flexibility in releasing or A/B testing of new features. Unfortunately, companies sometimes look at 6 developers and wonder out loud why there aren't 6 stories in progress.

Outcomes

After having the Scrum Master ask the 3 additional questions at the start, the Development Team began using the questions in context to their plan for the day and the questions themselves weren't asked after a time. These 3 questions helped the team find the deeper meaning to the question, "What will I do today to help the Development Team meet the Sprint Goal?"

Please drop me a line and let me know what you think and your results if you give this a try.

Tweet

The Manager and Agile

In a recent post by Michael Sahota, he challenged an assumption the company hierarchy stands in the way of achieving a great agile culture. Michael counters that the way we hold hierarchies within ourselves is in fact the real challenge. While looking at his post it occurred to me our first 18 years of life were spent deeply imbedded within hierarchies. As people, we are fully evolved to live within the hierarchies life puts before us. Here are a couple thoughts on the topic of hierarchies and how we learned to live and expect them. I’d be happy to hear your points of view.

Our Earliest Days

“Leashed children” (CC BY-SA 2.0) by danoxster

When we’re young, very young,  ... Read more here  (https://www.improvingagilepractices.com/2019/03/11/the-manager-and-agile/ )

Tweet

New Scrum Master: Problems to solve in your first days

In the previous two posts. First day as Scrum Master and Second day as Scrum Master, I talked about you as a new Scrum Master to a team and some steps you can take to ease yourself into the team's world. The first post talked about a group meeting with all team members including Product Owner. That meeting set up some introductions and gave you some clues as to how the team interacts and possibly some team dynamics. You followed that up with some one-on-one talks with each member of the team. In this post I'll talk about interpreting the results of your one-on-one discussions with the team members.

Once you've finished your talks with the team it's time to pull all the information together and begin planning your actions. The problems mentioned by the Product Owner, developers, testers, BA's, UXD, and others on the team will likely fall into several categories. What's listed below can be used as a guide but doesn't take the place of your own analysis based on your unique set of circumstances.

Team's ability to self-organize and be cross-functional

One Team, One Goal.

This will be by far the most common area of weakness based on the many discussions I've had.  The clue to this will be problems brought up by the team that they can clearly solve themselves but they'll need your help. Some comments might include:

• "Requirements are poorly written",
• "Working on things before we know what to do e.g. UX Designs incomplete",
• "Too many hand-offs", and
• "Definition of Ready and Definition of Done missing".

I'll look into the first comment, "Requirements are poorly written" in some detail. When the Scrum Development Team say this, I'm thinking there's both a communication issue and possibly some role based barriers in place. The comment given by the Development Team makes me think they're not feeling completely responsible for making sure the user stories are backed with heaps of conversation. Both communication and not feeling it's their job can be resolved through well facilitated grooming sessions. The team can become better at self-organizing by tackling head-on the issue of shared understanding of the customer problem documented in user stories. The team can also build their cross-functional capabilities through greater contributions to the user story including the acceptance criteria. For a developer whose experience may be waterfall and where the sole contribution of the developer was code, helping to write the requirements can be a new and possibly frightening turn of events. You as Scrum Master are there to help facilitate this transformation.

Business or company culture as impediments

We do it that way because that's the way we do it.

Problems or issues cited by the team that fall into this category might include:

• "Too many sign-offs and approvals (Designs)",
• "Little interaction between test and other departments",
• "Business emergencies and no way to stop them", and
• "Fixed end date regardless of start date"

It's clear the company culture is not controlled by the development team but they can have an influence. The comments above could make you think the company is a top down Command & Control shop and you'd be right. One thing I've seen in this kind of environment is nothing is written down, it's all done based on memories of past practices. One way to begin affecting this culture is to document how current work is done paying specific attention to the time it all takes. The Scrum Master and team can do this documenting of existing process and then present an alternative process with the now documented benefits and savings. As Scrum Master, you should also seek out and secure executive support or at least, a powerful mid-level manager who can support change. Without support, you're chances of success are severely limited as I've recently learned first hand.

Technical challenges or knowledge gaps that are impediments

Thomas Edison - Incandescent light bulb

This is something I usually note as a result of listening to the development team but it's rare that the team will directly say something with the exception of how testing is done. What I commonly see is a team hampered due to:

• Specialist on team that can't assist in other technical areas
• Test treated as a separate group or sub-team
• Testing always done at the end of sprint

These fall under a team being cross-functional but to get there will require specific training and strong guidance from the Scrum Master.  I once had a team with one tester doing all the testing. I suggested that the developers help out with the testing to speed it up and relieve the pressure on the sole tester. Luckily there wasn't a rope handy as I'm sure the developers would have hung me then and there for speaking such blasphemy. One developer suggested to the managers that they needed to hire more testers. The managers, GM of Product and GM of R&D both told the developers that hiring wasn't an option and that they would need to better support test. Once the management support was established, I was able to help get the developers to run acceptance and system tests. Baby steps. It was the opening needed to begin the longer term goal of spreading a little knowledge throughout the development team. When I left that company, the Scrum Teams did all the UX, testing, and infrastructure work themselves whereas in the beginning, each of these areas had specialist teams doing this work.

How this helps

After my first days and weeks with the team, I continued doing one-on-one talks with all the developers and Product Owners, noting what changes they felt had occurred in the previous month or two, how exactly these changes affected them, what further changes they wanted to see, and what makes them happy to come to work. I often find myself listening to the team chatter but asking the team to tell me their struggles and their delights helps me focus better on serving them. That's my role as Scrum Master, to serve the team.

I welcome your thoughts and comments.

Tweet

Second day as Scrum Master

In the first post of this series, First day as Scrum Master, I talked a little about he first day with your new team. In this post I want to talk about conducting your first one-on-ones with the team members.

After your first day or so with your new team, it's time to get intimate and personal through one-on-one discussions - I don't call them interviews because I want an informal atmosphere for a discussion and not one where people feel they're playing a role.

I use one-on-one to gain insight into the team members world in a non-threatening way. This is a three step process, setting up an one-on-one, conducting the one-on-one, and making sense of the results. For the team members, this process generally gives them a chance to voice their concerns and issues but it almost always leaves them with a sense that someone cares. For you as a Scrum Master, you do care but it's important the team gets the idea that you are there to serve them, that you actually care more about them than yourself.

Setting up the one-on-one

To get started I approach each of the team members and simply ask if I could have 30 minutes of their time to talk about what's working and what isn't from their unique point of view. This establishes a few things:

1) I value their time by setting a time limit,
2) I value their opinion because I want it from their point of view, and
3) I hold out hope and optimism that I might be improving their personal situation.

Most often the person will give me their time right then but if they're too busy, I don't press too hard but ask when would be a better time and suggest a time. This gives them lots of space in case there's apprehension but also lets them know I'm respectful to their time.

For the one-on-one session, select a neutral, non-threatening, private, and casual space. You should avoid meeting rooms if you can as these are usually sterile and a bit too formal for your purposes. At one company they had a room with sofas where I did these and it provided a very relaxed atmosphere.

Conduct the one-on-one

I open the discussion with a promise of non-attribution and ask if it's ok for me to take notes. If you can do this without notes that's better. I have a standard set of questions that ask, worded appropriately for the context. I ask these specifically in this order starting with what are their expectations of me followed by things that might be slowing them or the team down. I finish with a very personal question that almost always is a surprise to the team member. Examples of these are:

1. Why do you think I am coaching your team?
2. What difference do you hope I'll make?
3. What do you want to learn from me?
4. What outside influences hold the team back?
5. What internal barriers/impediments hold the team back?
6. What can we continue doing or do more of to make life on the team better?
7. How can we work more effectively?
8. Why did you come to work this morning?

The first question is important as it sets up all the followup questions but it also sets the tone. I might specifically say, "My job description says to implement Scrum but I didn't get a strong sense of team's perspective of what that means. Why do you think I'm here?" The tone I'm trying to set is I'm here to learn and not coming in with an agenda.

It's also important that however these questions are put forward, use the exact same structure if not word for word, with each team member. This makes it better and easier to compare and consolidate their responses.

At the end of 30 minutes, conclude the session with a very sincere thank you, repeating the key results and promises to follow up.

Spend a few minutes after the person's left to collect your impressions. Clearly note the issues brought up and what you may have promised to do.

Making sense of the results

Once you've gathered your notes from all discussions with team members, including the Product Owner, begin consolidation and looking for common threads. Use this to help prioritize you contributions for improvements. How to do this with examples will be the topic of my next post coming soon.

Thank you for reading and I welcome your comments and suggestions.

Tweet

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.

Tweet

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.

Tweet

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?

Tweet

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: http://pragmaticmarketing.com/resources/product-backlog-flows#sthash.7ZvUkYFt.dpuf

Tweet

Self-Organizing Development Team

Definitions

·        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.

Tweet

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.

Tweet

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?

Tweet

Organizational Adoption of Agile

From Craig Larman - Larman's laws of organizational behaviour:

 

1.       Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures

2.       As a corollary to (1), any change initiative will be reduced to overloading the new terminology to mean basically the same as status quo

3.       As a corollary to (1), any significant change initiative will be derided as "purist" and "needing customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo

4.       Culture follows structure.

i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. John Seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behaviour (the culture) is a product of the system; when you change the system peoples' behaviour changes."

 

I think that those who believe Agile and Scrum are the way forward will be at odds with most businesses that have a deep institutionalized Command & Control structures that rests responsibility, but usually not accountability, within groups/committees while diverting responsibility away from individuals. In Scrum we rest most responsibility on the Product Owner and hold this person accountable for the business value delivered at the end of each and every sprint. It is often this simplicity Scrum provides that is in direct conflict with the ‘status quo’. So how to begin changes to the existing structures?

 

First and foremost, you must have an Executive Sponsor. Without Executive Sponsorship your attempt to directly adopt Agile will almost certainly fail. This is more than just having managers that agree to allow you to use Agile; this is a person who has the rank and status in the business structure who can influence the often many groups/committees who collectively and traditionally have controlled projects.  Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ The Executive Sponsor, along with possibly one or more Agile Coach specifically trained and experienced in agile adoption at the executive level, will be handing out the oars.

 

What if you have no Executive Sponsor or the Executive Sponsor’s influence is severely limited? Under these circumstances, full Agile adoption is very unlikely to happen. However, there is a strategy that could overcome the tremendous obstacles that are in the way but it does depend on you finding some in Mid to Upper level Management more interested in results rather than institutionalized processes. The ultimate result is usually a hybrid adoption of Agile where all or some of the institutional controls remain in place but an Agile sanctuary is carved out with fewer of these institutional controls than a traditional waterfall project. This hybrid Agile project is not truly Agile but neither is it true waterfall. The strategy follows a bottom up Agile Adoption approach that will take time, maybe a lot of time, to slowly chip away at the traditional structure and replace it with an Agile structure and Agile mindset.

 

The strategy is twofold:

1.       Target getting support from managers in the organization that are more likely to support Agile; and

2.       Target going around the organizational structure of “over seers”

 

The strategy includes targeting those executives in middle to upper management that are more likely to support an Agile process and have some influence on those in the organization who are stanch supporters of the institutional controls. The idea here is not to change these people completely over to the Agile mindset but rather get these targeted managers enthusiastic enough about Agile so they can see the possibilities and potential of Agile. Targeting managers who don’t have influence over supporters of the processes or targeting managers who are the stanch supporters of the processes is usually a tactical mistake. Targeting a manager who doesn’t directly influence those in control of the processes might be an easy convert but other than a quick burst of satisfaction, the real battles will still lie ahead. The manager who is a supporter of institutionalized processes is very difficult to convert; they probably believe in their familiar processes and controls much like you believe in Scrum, albeit for different reasons. A word of caution, because you’ve gotten some support for your Agile project, you must remember that “success has many fathers, failure is an orphan.” For those in middle to upper management who supported you earlier, to ensure their continued support of Agile and endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If your project fails or succeeds but with only a whimper, some, most, or all middle to upper manages may forget that they ever supported Agile.

 

The second part of your Agile adoption strategy will be to identify all those organizational groups and individuals who traditionally sign-off on projects and find a way to exempt the Scrum project from these. These groups are those who sit on gate committees, steering committees, technology committees, or any one of a dozen other committees that approve, sign-off or use other mechanisms of “over-seeing” a project. These groups are often a source of power and prestige for its members and are traditionally very difficult, if not impossible, to get around without an appropriately positioned Executive Sponsor. The best way to get around these groups is to make your project a separate business unit that answers to the CEO/board. This follows along how IBM built its PC division in order to get out from under the bureaucratic thumb of IBM’s corporate structure.  Another tactic is to chip away at the required process these groups require projects to follow. This can lead to some relief for the project but will probably not succeed at allowing full Agile adoption for quite some time.

 

Is doing a Hybrid Agile Scrum adoption good? The short answer is yes. By simply following the activities defined for Scrum, (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff Sutherland has said that this will increase productivity by 20%-30%. However, the greater benefits of Agile are really attained through following of and embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and Scrum Primer. To become “hyper-product” would require everyone involved in the project (managers and scrum teams) to believe in and live Agile and Scrum. Unless the Mid to Upper level Managers of the business are only interested in results and don’t really care how you achieve them, your best approach to adopting Agile is incrementally, one step at a time.

 

Craig Larman is co-author of:

• Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum
• Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
• Agile and Iterative Development: A Manager's Guide

Tweet

Sprint Review Facilitation & Customization

The Scrum Sprint Review is a key Inspect & Adapt meeting where the Scrum Team discusses with Users, Customers, and Business stakeholders what was "Done" in the just completed Sprint. The Sprint Review meeting is short but must cover the agenda items listed below. The attendance by the Scrum Team is required. Attendance by stakeholders is optional but should be strongly encouraged for those key stakeholders most affected by the Sprint results. This article gives some advice on how to conduct the Sprint Review when stakeholders are unable to physically be present.

 

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint and the Product Backlog is amended if needed. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. The Product Owner provides the stakeholders the likely completion date for the release based on the Development Team's velocity and work remaining in the Product Backlog. This is an informal meeting, and the presentation of the Sprint results is intended to elicit feedback and foster collaboration.

 

One hour Sprint Review Agenda includes the following elements:

• The Product Owner identifies what has been “Done” and what has not been “Done” (suggest 5 minutes)   
• The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved  (suggest 10 minutes)
• The Development Team demonstrates the work that it has “Done” and answers questions about the Increment  (suggest 15 minutes)
• The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date  (suggest 10 minutes)
• The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings  (suggest 20 minutes)

 

The feedback from the stakeholders, directed toward the Product Owner and Scrum team, is the most important thing to get out of the Sprint Review. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

 

Customization for Stakeholders who cannot be physically present at the meeting

A Scrum Team strives to ensure the key stakeholders, as identified by the Product Owner, are in attendance at each Sprint Review. The key stakeholders identified may differ from Sprint to Sprint based upon the work selected in each Sprint, but it is important to the success of the project that those identified feel compelled to attend the Sprint Review when asked. When a stakeholder cannot be physically present at the Sprint Review meeting, the Scrum Team loses out on viewing subtle hints on the reception of their Sprint results and future Sprint plans. Stakeholder body language and tone are indispensable clues to the observant Scrum Team which can be lost when stakeholders are not with the team during the Sprint Review. Unfortunately the realities of the business means that stakeholders are distributed across several locations and cannot always be physically present at the Sprint Review. Below are the options in order of preference.

 

Telepresence:

 

Telepresence is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend. Scrum Master would schedule the telepresence rooms locally and at all remote locations if possible. The Sprint Review meeting should be conducted as if all people were in the same room.

 

Advantages:

• Stakeholder sees what those present in the meeting room see
• Stakeholder is not a disembodied voice but a real person
• Scrum Team and other meeting attendees can see and gage stakeholder's reactions to product demo and artifacts
• Scrum Team and other meeting attendees can see and gage stakeholder's reaction to comments, statements, and suggestions
• Facilitator of the Sprint Review can better steer the Sprint Review back to the Sprint Review agenda when necessary
Disadvantages:

• Difficult to overhear side conversations from remote stakeholders

Webex / LiveMeeting / Net Meeting / or other online collaboration tool:

 

Online collaboration tool is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend and access to a telepresence room isn't available.

 

Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.

Advantages:

• Stakeholder most often see what those present in the meeting room see
• Stakeholders can follow and participate in discussions on the just completed work shown in the demonstration


Disadvantages:

• All stakeholders will need the same online collaboration tool installed and available
• Higher likelihood that remote stakeholders will talk over people in the meeting room
• Higher likelihood that people in the meeting room will talk over the remote stakeholders
• Easier to mis-read voice inflection and tone without seeing the body language
• Difficult to overhear side conversations

Speakerphone:

 

Using only a speakerphone (no video link or web sharing) is the last option available for stakeholders who don't have access to collaboration tools and no access to telepresence equipment.

 

To give the stakeholder a voice in the Sprint Review, the Scrum Master or Product Owner, as appropriate, would ask those who are remote to provide their input before the Sprint Review meeting so the Scrum Team and stakeholders at the meeting can review their input together. This way the remote teams know that their input counts and will heard by all people in the room.

 

Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.

 

Advantages:

• Remote stakeholders have a proxy voice in the Sprint Review


Disadvantages:

• Speakerphone stakeholders will not see what's being presented
• Speakerphone stakeholders will find it difficult/impossible to follow discussions during the product demo and presentation of any related artifacts
• Speakerphone stakeholders may find it difficult to collaborate with those in the meeting room without seeing the Sprint results
• Higher likelihood that remote stakeholders will talk over people in the meeting room
• Higher likelihood that people in the meeting room will talk over the remote stakeholders
• Easier to mis-read voice inflection and tone without seeing the body language
• Difficult to overhear side conversations

 

 

Tweet