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