If you’re working in a Scrum software house, ideal development teams are self-organizing, empowered to make decisions, and engaged as a full partner in the business as it relates to the product. But what are the essential first steps that will begin the development team’s Agile journey to get there?
We’ll take a quick look here at some steps I think are necessary for that journey to occur:
- The business gives the team space to make decisions by defining the boundaries
- The business empowers the team to make decisions within these boundaries
- The team actively takes on the responsibility for all work by building skills within the team
- The Scrum Master, team lead, and managers help the development team by practicing behaviors they wish the development team to adopt
When a Scrum team first forms, it’s built from the remnants of the previous methodology, usually Waterfall. This is fine because the team starts off knowing something about the product and code. Still, a freshly hired team might have the advantage of not having preconceived ideas about their roles, responsibilities, and teammates. This sets up a change issue that needs to be overcome during the development team’s transformation to Agile: reset the thinking team members have about roles, limitations, and responsibilities. If possible, the Scrum Master tries to reset the development team so they start their Agile journey knowing their specialties and interests but without any other preconceived ideas of roles or responsibilities. Resetting and changing team member views of roles will be challenging but not impossible. Maybe.
When I was introducing Scrum to a team, I had a problem with getting everyone on the team to contribute to the testing effort during their very first ever sprint. The developers had always done code & unit test but they were never asked to do acceptance and system level testing, that is, until Scrum showed up. The situation arose when the single professional tester on the team became overwhelmed with writing and running tests. The developers were sympathetic but their only advice was for the company to hire more testers. The team lacked imagination and work experiences to even entertain solving the problem themselves.
Instead of listing out options from simple to hard, they fell back on their past experiences and decided that the way to solve the problem, the way they’ve seen it done in the past, was to throw bodies at it. For the developers, the simplest solution was to make it someone else’s problem, In this case, the managers needed to hire more talent. This had been a learned reaction by the developers over the years doing Waterfall and you couldn’t fault them too much.
There’s a high likelihood that while the developers were under the Waterfall umbrella, their work was specialized. It’s also likely the project manager’s task assignments in the project plan was based on these specialties. For example, a back-end developer would probably not be asked to do front-end display work and no developers would be asked to write the system level tests when there was a perfectly good team of QA testers available. The idea of development team members knowing one thing super well and to continue perfecting that one thing, is pounded into them from the first day.
With the Scrum development team, we still celebrate each team members’ special skills, the skills that made them valuable to the company in the first place. These skills will continue to be valuable when adopting an Agile mindset. So there’s really two things we want to change in the development team:
- Get the team to feel that development and delivery problems are theirs to solve even when it requires work outside your strengths and
- Develop stronger team thinking skills for problem resolution.
And the way to change how development thinks starts with management.
Management support of Scrum means tough love
Getting the team to acknowledge that our test situation was their problem to solve took a bit of time but they eventually did accept it. That there was a problem was obvious and this was not in dispute. We needed to get the development team to see that the old way of dealing with this kind of problem wasn’t an option. The journey’s first step was begun by senior management.
I was lucky that the General Managers of Development and Product were supportive of Agile and Scrum. Both these managers told the developers that there was no chance to hire and train new testers for the team given the delivery date. This was brilliant in that they didn’t simply say “solve it yourself” but gave the developers a real constraint that required the team to find an alternative.
The Scrum Master and Team Lead needed to lead change by example
The next thing was the development team needed a slight nudge in the right direction. This was done by myself as Scrum Master and by the team lead. Together we both began doing some testing tasks. We provided by example, a way forward for the team. This setup everything for the next step.
Get the team to be involved with a passive approach: get volunteers
At the next daily stand-up, we both gave our accomplishments from the previous day but asked for help from the remaining team members. As with any good group of people, when they’re asked for their help they provided it. Our team sat down after the daily stand-up and took on all the outstanding testing tasks. The reality was that testing didn’t take too much time, a day or so, and the value of finding problems during the sprint meant we could provide a higher quality product at the end of the sprint.
Behavior change starts with how we think
Positive team thinking usually starts with the confidence that the development team can solve their own problems. This means that the team must be empowered to solve a problem and feel confident that they have the necessary tools and skills to solve it. Building these two attributes won’t happen overnight. Making a strong deliberate effort to achieve both makes good business sense, especially if you think about the reduction of waste and a newfound enlightenment of the team.
One goal of Scrum is to harness the power of the team to make quick and better decisions. One foundation for this is the team’s confidence in itself to make decisions without relying on outsiders too much. This means the team working together to make choices on architecture, design, and implementation based on their collective product knowledge and within boundaries set by management. Fear usually exists and swirls around things we don’t know about. We are reluctant to make decisions while in the dark about a subject (most of us anyway). To build this decision-making capacity we start with building team knowledge so we can leverage the cumulative power of the team.
Before the team can become self-organizing, they must first be and feel empowered.
We’ve all worked in offices where the business declared teams are empowered but this lofty claim does not jive with reality. Should you expect the company to say, “do what you want, when you want to do it”? No, of course not. What the Scrum Master or Agile Project Manager need to do is get the business to establish boundaries from which the development team can operate. Give the development team some space to operate independently in.
I’ve recently worked closely with a manager to help him move from the company’s Command & Control model to following a Servant Leadership model. I used two tools, a camera for filming his interactions with the team and listening to the conversations he had. Using these two tools, I was able to show him how he made most of the decisions, big and small, for the team. He hadn’t realized how often he was making decisions, he believed the team made the majority of the decisions. But the camera doesn’t lie. To change this around and give the team decision-making power, he followed the practice of pushing decisions to those who had the necessary information to make it. In this case, the development team. He followed the “intent based leadership” style of David Marquet, author of “Turn the Ship Around!: A True Story of Turning Followers into Leaders“. When a team member discussed options or choices with him, he recognized that they were actually asking him for direction. He found that he could answer most questions with, “what do you think?” This got the desired effect of team members now talking among themselves to discover the best way forward.
Establish boundaries for the team
In management’s role of supporting Scrum, they pass to the Scrum team business rules and establish boundaries for teams to work within. Part of empowering the team includes whatever limits the business feels comfortable with. In general, a Scrum team is given a free hand to build a product that solves the business or customer problem. However, there might be business or technical restraints, (non-functional requirements), placed on the team. For example, the Scrum team can’t arbitrarily decide to stop supporting a certain web browser because they don’t like it. It’s possible the company will go crazy with rules and restrictions but this should be balanced by having the team and managers drawing up the boundaries together. This is how our Servant Leader above created boundaries with his team to great effect.
Team strengths & weaknesses
It is sometimes thought that Agile development team members strive to become generalist but this is a false goal. It is not about everyone on the team learning how to do everyone else’s job but it is about everyone on the team feeling equally responsible for getting all the work required done, even if it isn’t your specialty. A good team acknowledges their individual strengths and plays to their strengths. While playing to the team’s strengths, a weakness might be uncovered. For example, if only one person on the team can code in Ruby, the potential weakness in the team is when Ruby work is required but the one person who knows it is sick or otherwise not available. In the past, the absence of one person could lead management to acquire another Ruby programmer from a lower priority project or, more likely, Ruby work would be postponed until the right person is back.
The Scrum Master can use a portion of the team’s retrospective to bring to light any shortcoming of skills or control noticed during the sprint. The team can together develop the appropriate actions to make this weakness go away or at least mitigate it.
Reduce waste by reducing hand-offs: Building T-Skills to make work-flow more fluid
When the development team worked within the hierarchy of a Waterfall environment, their job was to get tasks done as quick as possible. Once the unit tests passed, they would release the code to the test team. However, if you were to apply Value Stream Mapping techniques, you’d almost certainly discover that there are many zero or non-value adding periods within the Waterfall lifecycle. This would be most evident in the hand-offs between specialized teams. In an Agile team, these hand-offs can still occur: when the teams’ work moves from one specialist to another, when decision points are reached and the team cannot independently make the decision, or when one person has a particular skill and the team waits for that person’s availability. The solution is for the team to improve their ‘T-Skills‘. This will probably ruffle some people because their own sense of self-worth might be centered on a unique skill they alone have. Here’s where the Scrum Master works their magic.
Building ‘T-Skills‘ means we don’t slight or forget the person’s key skill (the vertical line of the T). The goal is to create the capacity of having a second opinion when necessary and to still move work forward without the specialist. We want the team to have enough skills to step in and do the work if needed, even if it takes 3 times longer (the horizontal line of the T). The point is that work does not stop; it might slow down but it doesn’t stop. To build T-Skills will require a skills matrix.
The team goes through all the skills within the team and answers yes or no the these three questions for each skill:
- I am an expert
- I want to learn more
- I’m not interested
If you use a skills matrix similar to the example above, there is probably a need to address any skill that does have two or more people rated at 3 or above. When I’ve done this in the past as Scrum Master, I would arrange for any external training or setup an internal training session for those who wanted to learn more. The skills matrix is the beginning of an action plan to build ‘T-Skills’.
Here’s one example: With sufficient T-Skills, when code and unit test are done, the same team member begins higher level testing. They do this not as a specialist but as someone who can contribute. Once the test specialist is available, the testing will proceed faster. This practice removed the hand-off and made the transition from code to test fluid and easy.
These ideas don’t guarantee success because once started, these behavioral changes must persist forever or until the next best thing comes along to replace Agile. It is far too easy to fall back on old habits, ask anyone who has quit smoking for the fifth time. The best thing to do is create metrics and monitor these for continued improvement or a relapse.
Empowerment and team boundaries can also erode over time. Once the team and management have defined boundaries, everyone should sit down once a month or once a quarter to re-work these. In the normal course of experience and time, team boundaries should be seen expanding. This indicates a growing trust of the team and the team’s growing understanding of the business. If the boundaries are shrinking then there’s probably a [big?] problem.