Showing posts with label Agile Transformation. Show all posts
Showing posts with label Agile Transformation. Show all posts

Saturday, February 12, 2022

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.

Sunday, October 23, 2016

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.

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?