Agile Team High Performance Communications

What is it that makes a development team successful? Is it their ability to accurately predict the delivery date?  Is it their ability to keep bug counts to a minimum? Or is it something else? Could it be how well the team communicates and works together?

Years ago the measure of a great development team wasn’t the team at all but the individual. This person would meet their schedule as shown on a Gantt chart and, maybe more importantly, did so without much intervention or guidance from their manager. They could make quick technical decisions and they knew the product and how it was used. These people were known then, as they still are today, as high performers. So Agile comes along and celebrates the Team, does this mean high performers are no longer wanted? Silly question, of course they’re still wanted. It’s really about definitions and what’s best for the business and for business growth.

The high performer of the past was always about the individual and less about the team. The appraisal systems in use then and for the most part still in place today, focuses on the individual’s performance. If the team results were less than stellar, the high performer was said to be held back by the other members of the team. Clearly it wasn’t the high performer’s fault the team sucked.

Now assume for the moment your business doesn’t wish to go Agile but wants to build teams made up entirely from high performers. This is exactly what Netflix has done (see the Harvard Business Review article, “How Netflix Reinvented HR“, for an eye opening insight on how this works). Now the kind of openness and honesty that Netflix has won’t work in all companies, especially if the company uses performance reviews as a weapon to elicit certain kinds of behaviors. So for those companies unable to go the Netflix route, Agile seems a good choice for company growth and building teams of high performers.

Agile is about teams and teams are made up of individuals. The high performer in the Agile sense is someone who helps make their team a high performing team. High performers in Agile are Servant Leaders, they serve the team first. They do this not by doing the work for those who need help, not by ignoring those who are weaker, not by telling the manager that this person is no good and needs to be trained elsewhere, but by showing the person a better way to work, by devoting time and energy to help those challenged, by working with management to train and build up the competencies of those in need. But how do these high performers learn the techniques and skills of helping, of being selfless, of being a servant leader? Enter the Scrummaster or Agile Project Manager.

The Scrummaster by virtue of training, study, reading, networking, and experience, is ideally suited to help those willing team members become great servant leaders. I say willing as some people will be pre-disposed to resist anything that distracts them from their first love, being developers. These people will need personal coaching to help them help themselves and grow their own servant leadership behaviors. The very first thing needed for any team to be successful is open and trusted communications. Below are 4 ways the Scrummaster can help build stronger communication links within the Agile team.

Team Communications

Most Scrummasters spend a considerable amount of time observing the team, how they behave toward one another, and how they communicate. Listed below are some of the behaviors I’ve observed and some suggestions on how to improve team communications. None of these are a one-off thing to do but will need to be repeated many times to change the team’s behavior. None of these are mandated but can easily be accepted by team member to varying degrees. Given time and patience, team members will build up toward being a high performing team.

  1. Development team members wearing headphones. This can be a bad situation as people are generally very courteous and often reluctant to disturb someone who’s wearing headphones. There’s no real good answer except to discourage, not necessarily eliminate, the behavior through team and one-on-one conversations. Some teams have set aside a “quiet hour” to solve this but this reaction can have a detrimental affect on open lines of communication and collaboration. Strike a balance where the team’s ability to collaborate and communicate are not stifled by someone wearing headphones. Make efforts to create tasks that easily allows pairing. Watch for the team member who appears to looking for help but doesn’t attempt to interact with headphone wearers.
  2. Team members who don’t stop working to listen. (This is about conversations within the team, not interruptions from outside the team.) Good face-to-face communications usually requires people to be face-to-face. The ability to make eye contact and observe facial expressions is important to help gauge emotion but it is also a sign of respect. When you stop and devote your full attention to someone while they talk, you are showing respect to them and the thing they’re talking about. I find that people are generally not aware of this behavior so I would suggest filming, with the team’s permission, how the team interacts during the day. When I’ve done filming in the past, people were very quick to see flaws in how they communicated and were able to make immediate and lasting changes.
  3. Team members who don’t know very much about each other. This may seem unnecessary to some but it’s really an essential ingredient for trust, empathy, and understanding. I was once helping out a Scrum team where there was constant fighting and bickering. This had a lot to do with people having their ideas and opinions ignored by everyone else. It mattered little that the person with the idea might be the subject matter expert because no one else knew that. I asked different team members what they knew of their fellow team members and it was shockingly little. One way to introduce people to one another is to do Journey Lines. I started a new project with several teams and we all did journey lines of our work careers to great success. People walked away saying they never knew or understood the depth of experiences some of their team mates had. I can’t emphasize enough the value of the Journey Line tool. It gets to the heart and soul of everyone on the team and once learned, you can’t go back. Below is an example Journey Line from Lyssa Adkins‘ book, “Coaching Agile Teams”.

    Source: “Coaching Agile Teams” by Lyssa Adkins
  4. Getting the team out of the office once a week. In my talk, “The Journey to Servant Leadership”, at Scrum Australia 2016, we encouraged people to do a team off-site once a week. Although our Scrum Australia talk was focused on transforming a manager into a servant leader, one important tool for getting the team members talking about decisions instead of the manager making decisions was this once a week meeting in a coffee shop. Part of the journey to servant leadership requires the team take on additional responsibilities and make more and more decisions. During these weeklies, the formality of the office hierarchy and structure disappeared and these team members spoke openly and honestly. The team members not only spoke about issues and problems they had in the office, they also talked openly about their families and weekend plans. But for the Scrummaster (or coach), this is a great opportunity to listen and observe how the team interacts and arrives at decisions. Back to the Servant Leader talk, my observation at the coffee shop was the team was unable to commit to a team decision even when it was overwhelmingly obvious they understood exactly what that decision should be. In talking to the team members later, the primary reason they didn’t make the decision was they feared backlash from the product manager. The decision involved fixing a problem the team had introduced in the previous sprint. The team needed to hear from the product manager that it was ok. This is all well and good in the Command & Control environment but is not the desired behavior in Agile. It wouldn’t fly at Netflix either. The team had to learn that collectively, they know more than the product manager and are better suited to made a quality decisions. The Scrummaster can use these off-site meetings to listen and understand team dynamics to spot areas for improvement. The team was having a conversation in the coffee shop they would normally not have in the office. Also, make sure the right people are there. If the team had the product manager in the coffee shop, the team decision would have been endorsed by the PM.

Summary

Building an Agile team of high performers starts with the individuals in the team. The Scrummaster can help build up their communication skills which is an important first step. Scrummasters will do and redo the above steps often as it will take time to get the team anticipating and understanding the wants and needs of everyone else on the team. This can take 3-6 months for most people in the teams to change although it could take longer.

Communications opens up many doors of opportunities not only for Agile teams but also for companies and company growth. A Forbes article, “Why Communication Is Today’s Most Important Skill“, author Greg Satell gives some historical background to great communicators. He also gives us some current examples of how business can flourish using communications.

The sooner people in your team and company are communicating, the sooner they can all be on the same page.

 

Environment for Better Agile Teams

One secret to a great Agile/Scrum team is the environment where they work and will spend a large portion of their daily life. This environment is made up of many things but arguably, the most important are communications, physical environment, and management support.

Communications

Communications is critical for the success of any team: waterfall, agile, military, or sports. Scott Amber has a great article, Communication on Agile Software Teams, which includes the graph below showing the effectiveness of various communication channels.

Face-to-face communication is essential to:

  • communicate bad news e.g. Honey, I don’t have any money
  • communicate sensitive information e.g. I lost all our money at the dog track. I know I said I’d stop gambling.
  • communicate anything that would benefit from eye contact, a reassuring nod, and other body language e.g. do you forgive me?

Phone or video communication is appropriate to:

  • come to a quick, clear understanding e.g. Honey, tell me again why you kicked me out
  • removing small bits of confusion e.g. I can come home when what freezes over?
  • make a personal introduction or ask a favour e.g. Mom, could you lend me some cash for food?

Email communication is appropriate to:

  • to share complex Information that does not require discussion e.g. From: Dewey, Cheatem & Howe, Attorneys at Law. Dear Sir, What follows is exactly why you lose the house, the BMW, and the dog… 
  • to confirm the details of a face-to-face or phone conversation e.g. Mom, as I said earlier, I don’t have any money for food
  • to pass on information without interrupting someone e.g. Dear Sir or Madam, I need a job. Will you hire me?

Communications and the scrum team

Communication behaviors to and within the Scrum team is probably the single most important team asset a Scrum Master can cultivate. Communications lays the groundwork for trust, team engagement, and team empowerment. It is no surprise that communications is one of the 12 Agile principles.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Let’s break this down this principle into its components:

“most efficient and effective method of conveying information”. One big advantage for face-to-face communications is observing facial expressions and body language. This means that one can read the other’s body language to see if there’s understanding, discomfort, boredom, or something else. For example a product owner is discussing a user story, are the team members understanding the concepts or do they look confused or bored? Face-to-face communications gives a product owner an opportunity to show they care by asking probing questions of the team and actively listening to understand the team’s perspective.

“to and within a development team”. This means that outsiders as well as team members use face-to-face communications. The product owner uses face-to-face communications to demonstrate respect for the development team. This is accomplished through direct interactions and active listening to the team’s feedback. Face-to-face communications establishes shared experience that can enhance all future communications.

Management uses face-to-face communications to build trust, share their strategy, explain it clearly, and answer questions honestly. Face-to-face communications helps create camaraderie that is the basis of cooperation and success across the organization. This can make the development team feel valued and gives them a chance to contribute to organizational strategies.

Face-to-face communications gives both the product owner and managers a chance to confirm the team’s understanding of key issues, identify gaps and encourages ongoing feedback and engagement.

“is face-to-face conversation.” This means that you should not explore alternative methods of communications unless absolutely required. Bug tracking tools, paper documents, and email are not an acceptable alternatives to face-to-face communications. However, video or Skype call, or old fashion phone calls may be the best if face-to-face isn’t possible.

Encourage your team to speak to each other even when working. This allows others to overhear and can provide them an opportunity to contribute. I’ve observed most companies use IM tools, Slack being the predominate tool. The down side of these tools is dominate personalities can prevail and quieter people often times do not give their voice. Quieter people will often need prompting to get their thoughts, ideas, and opinions out and IM tools can fail in this regard. The team includes everyone and everyone should be encouraged to participate in important decisions the development team is making as they solve the customer’s and product owner’s problems.

And the very best way to conduct a face-to-face conversation is in front of a white-board (see physical environment below).

Physical environment

The physical environment and management support go hand in hand as the environment is usually provided by management. In the best environments I’ve seen, the Scrum team (development team, scrum master, and product owner) sit together to foster better communications, building a sense of team, and limiting outside distractions.

The value of a team space is the sense the team gets with ownership, which is not too far removed from a family’s first home ownership: it ours! This is a comfortable place for the Scrum team to live and work 8 hours a day. A place where daily scrutiny is (hopefully) absent. The first Scrum teams I helped form were given a cubical that could easily seat 6 with lots of room to spread out. There were partitions that gave a strong sense of privacy and a double-sided whiteboard on wheels was just at the entrance. I also ‘found’ some small round tables that fit nicely inside so the team had a place to huddle. I don’t remember anyone saying it was heaven but it was quite good. Management really wanted these teams to be Agile and even offered to redesign the team area if the team wanted.

InfoQ has additional reading on developing an ideal Agile work space in the article, “Designing Collaborative Spaces for Productivity“. It’s a little dated but you’ll get the intent for team space with a lot of ideas.

Co-located teams

The prime ingredient for the co-located team, other than a place to put their computers, is a big wall or whiteboard for the team the ‘think’ with. When I was setting up multiple Scrum teams I had purchased double sided whiteboards on wheels for each team (there wasn’t much wall space available for all teams). After a while some teams acquired two of these whiteboards. These boards were used as the Sprint Board, software designs, component designs, and system architecture designs. They also held the team’s metrics, customer names, business contact names, and most anything the team needed documented.

Another item that helped was a conference room for the team’s exclusive use. This made impromptu meetings possible when needed. This quiet space was very beneficial during customer interviews and user testing. It had a whiteboard, table & chairs, a computer and a phone. Nice private spot for the individual or teams use.

Another item was a dedicated test environment, configured as customers would. When I was at a product company, the Quality team set this up to mimic customer environments as close as possible. The Quality team created simulators and the development team made use of off the shelf simulation tools. All this allowed the team to better build in quality. For a digital product team, this would be a fully functional A/B testing site or staging area.

And finally, what development team is happy with their computers or workstations? Here the company went to great lengths to keep the development team up to date with the latest technology and software packages. However, as Scrum Master, I bought SSD drives and software for the team when they needed it and the company couldn’t act fast enough. I was usually reimbursed but not always.

Distributed teams

When you have team members or whole teams off site, the effort you put into communications will determine how well it goes. Here are some tips I gathered from Vodafone on their communications with off site teams.

  • Spend a minimum of 3 weeks with the full team, either at their site or have the team on your site – Vodafone does 3-6 weeks leaning toward the longer time
  • Communications order of precedence: Face to Face -> video (Skype, Google hangouts) -> voice -> text – Vodafone uses a 24/7 video feed to communicate with their off site teams
  • Set up a camera and microphone in each distributed team area so people can casually communicate anytime
  • Bring in an outsider to observe your communications so they can objectively rate it – listen for silences or no questions, these can indicate a communication problem
  • Take special note of when the off site team works, their time zone, their start time, end time, lunch time, break time(s) – have a big clock set to their time
  • Provide context, give the big picture of the business and the details of where a story/task fits – Macro & micro details are important
  • Understand the culture of the team – how they work and what they expect are very important – are they waiting for direction and decisions by you?
  • Stylize your communications to cater to the off site team’s culture – say thank you for small things and smile
  • Finally and most importantly, the off site team is not a partner, they are an extension of the local team – don’t get into the habit of us and them

When working with distributed teams in other countries, check out www.worldbusinessculture.com to gain some insights to their culture. For example in the Philippines, it’s extremely important to be aware of the sense of ‘face’ of every member of a group because an insult to one could be construed as an insult to all.

Management support

From the Agile principles:

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The Scrum Guide doesn’t list any roles for managers but this doesn’t mean there isn’t a strong management presence and influence. The Scrum team and product owner are the link between the product and customers/users. Product managers and line managers are the link between the Scrum team and the company. Without the company there is no product and without a product, there is no company.

Hire the right team members

Management starts by hiring people who will eventually become members of the Scrum teams. A while ago I asked Gary Swart, then CEO of oDesk, how he hired team members. His answer was attitude mattered more than their skills. Heresy you say, how will the work get without all the heroes? Managers like their heroes, those super productive people with whom they can count on in a pinch. Of course the heroes don’t go away but, as Ilan Goldstein, managing Director of AxisAgile, has written about Scrum team members:

We prefer Attitude over Aptitude
That is, while there is value in aptitude, we value the right attitude more.

Gary Swart used three attributes when hiring a new team member, in order of importance, are:

  1. Motivation – is the applicant driven to succeed in their chosen field?
  2. Personality – will the applicant work well with the culture and the people there i.e. brilliant jerks may not make it in
  3. Skills – do they possess the basic skills necessary to do the job and are they eager and willing to learn more, even outside their specialty?

Getting the right people is important and this responsibility usually falls on management.

Support the team

My early experiences in software development was in the defense industry. We had a matrix organization where, as project manager, I would need to speak to several managers each day on progress and other statuses. These managers were well within their rights to tell me or the team what to do or which tasks to work next. This was a waterfall environment and all dates, capabilities, and deliveries were agreed to when the contracts were signed. The managers’ responsibility and accountability was to get the project in on time, within cost, and with the contracted scope. It all worked but did take its toll on people. This relationship has changed with the introduction of Agile but maybe not as much as you might think.

Managers in an Agile environment are thought to possess qualities of a Servant Leader. Today’s manager serves the team, helps the team manager their project and project tasks. Today’s manager supports the team by helping the team find their own successes. And in the process, the manager becomes more successful. The goals of management in an Agile environment is to deliver high value software to the customers as quick as possible. They do this by empowering one or more Scrum team to determine which features are of the greatest value to customers and allowing the teams to implement & deliver these features in their own way.

Summary

Setting up and maintaining the optimal team environment is hard and requires effort by both the teams and management. If you do nothing else, strive to perfect communications between the business and teams and within the teams. This open communications will pay off with not only having people knowing what they need to know to be successful but allows for the possibilities of new ideas and innovative solutions.

When setting up team spaces, if possible, involve the teams in the layout decisions. Most companies will probably run with an existing office layout but a whiteboard wall to divide up team homes is relatively cheap and is remarkably useful in achieving greater productivity. By any and every means possible, give each Scrum team ample wall or whiteboard space to help productivity.

And none of the above can happen without management support. Management comes to recognize that the Scrum teams pull together to satisfy the customers with the highest valued products first. Management’s role is to support the Scrum teams in ways that help these teams be successful. They accomplish this by hiring the right people with the team’s involvement and by ensuring the Scrum team has every scrap of information needed to increase their chances of success.

 

Is Your Business Ready for Scrum?

If you’re thinking adopting Scrum for product development will improve your business, you would not be alone. According to VersionOne’s latest State of Agile Report, Agile adoption continues to rise with Scrum being the most popular. The top reasons for adopting Agile have remained constant over the past 3 years:

  1. Accelerate product delivery
  2. Enhance ability to manage changing priorities

The top three real benefits of adopting Agile has remained steady over the past 5 years:

  1. Ability to manage changing priorities
  2. Increased team productivity
  3. Improved project visibility

However, the number one reason Agile adoption fails remains:

  1. Company philosophy or culture at odds with core agile values.

What’s clear is a number of businesses take on Agile without considering the impact and the challenges facing the business environment. Before you and your company launch yourselves into the subtleties and complexities of Agile and Scrum, consider these two points:

  1. Are you clear what business problems Scrum will solve and
  2. What corporate or cultural attributes could stand in the way.

Here are three scenarios:

Company A

When the company decided to run a project using Scrum, the decision was based on previous track record of failure to deliver on schedule, at cost, and with the agreed to scope. The company felt they had nothing to lose by going Scrum. After successfully running an experiment with one team, all teams soon adopted Scrum.

Company B

The company wanted to start a new project using Scrum, based on the promise of faster and predictable results. Agile implementation was ultimately unsuccessful for a number of reasons including Command & Control culture and product decision-making not pushed down to the Scrum teams. Management couldn’t give the Scrum team autonomy or empowerment.

Company C

A company thought themselves as an Agile organization but the business and business culture was top down Command & Control. Product decisions were in the hands of management and not pushed down to the Scrum teams. Management needed to maintain control of the Scrum teams and couldn’t give them autonomy or empowerment.

All three of these companies are successful and all have good products and good people but not all could fully adopt Agile values and principles. For Agile to be successful, it’s best if the company has a culture and environment to support Agile, or at least a culture and environment that doesn’t clash with Agile values.

Agile and Scrum isn’t the answer in all cases and isn’t necessary for company success. However, Scrum can help a company be more successful. Scrum is particularly hard since many behaviors and cultural changes might be needed. If the business is willing to change the way it works then adopting Scrum may be easier but still does not guaranteed a happier outcome.

To help guide your move to Scrum, here are some questions that need to be answered. The idea isn’t that the corporate culture and environment be perfectly aligned with Scrum but that you have a clear understanding of what impediments and huddles you can expect.

  1. Do the executive officers of the business (CEO, CFO, CTO, …) believe Agile is a viable way forward?
  2. What business needs are to be fulfilled by adopting Agile?
  3. What core business assumptions (cultural or ‘way we do things around here’) are challenged by adopting Agile?
  4. Beyond the ‘nuts & bolts’ of Scrum, what business processes need to change to adopt Agile?
  5. Does the [new] business strategy support Agile?
  6. How well will Scrum fit into the current Product Lifecycle?
  7. How well does Scrum fit into the business’s current planning and budgeting processes?
  8. How much effort (training/coaching) is involved bringing product management, development, marketing, sales, and executives along on the Agile journey?

Do the executive officers of the business (CEO, CFO, CTO, …) believe Agile is a viable way forward?

In general, executives need to have a compelling reason to try new methodologies. If they already believe Agile is the way forward you’ll have an advantage to start but they may not recognize the efforts necessary for success. It’s up to you to make a compelling case for Scrum or do as I had done, run an experiment using Scrum and let the results speak. In either case, there must be a real business problem to solve. Solving a real problem drives innovation and inspires an innovative spirit. Tying company growth e.g. sales, profitability, customer base, to Agile is crucial but may be hard in your organization. There exists lots of anecdotal evidence of the value of Agile but hard evidence of a specific formula is elusive.

VersionOne 10th Annual State of Agile Report states:

“The top three benefits of adopting agile have remained steady for the past five years: manage changing priorities …, team productivity …, and project visibility”.

If the experimentation route is open for you then take advantage of this to demonstrate Scrum. I wrote a post, Agile: Don’t Sell It, Demonstrate It, describing how experimentation was used to help the company recognize the value of Scrum and what results could be achieved.

It will help too for you to have an understanding of why Agile might fail. Here’s an article in InfoQ that can give you some insight on problems that may arise including understanding what Agile is about. Forewarned is forearmed.

What business needs are to be fulfilled by adopting Agile?

Do your homework to determine what business challenges or needs can be fulfilled by introducing Agile. Change usually requires a motive force and in business this usually lies in the company’s strategy and goals. For example, let’s say the company wants to increase their sales to customers 35-55 years old. Using Scrum and weekly releases, the Scrum team can run growth experiments and get prototypes (or real products) in front of the targeted people for user experiments. The team can quickly determine if they’re building the ‘right product’.

In another example, the business goal is to gain more positive testimonials from customers. The Scrum sprint review is an ideal event that involves customers and elicits customer feedback.

This business connection might be the difference between management allowing Scrum into their shop and having management enthusiastically embrace Scrum. As mentioned in the post, Agile: Don’t Sell It, Demonstrate It, full acceptance of Scrum might require tangible evidence.

What core business assumptions (cultural or ‘way we do things around here’) are challenged by adopting Agile?

It’s is important to ‘know your enemy’. By far the biggest obstacle to Agile adoption or expansion in your organization will be the company’s culture.

In VersionOne’s 10th Annual State of Agile Report respondents cite

“organizational culture and a general resistance to change as their biggest barriers to further agile adoption.”

In their book “Blue Ocean Strategy,” W. Chan Kim and Renee Mauborgne cite four hurdles that face a manager trying to institute broad change in an organization

  1. people must have some understanding of why the change in strategy or in culture is needed
  2. changing an organization will require shifting resources away from some areas and towards others
  3. workers have to want to make the change
  4. institutional politics.

If you’re a member of the company’s corporate management team, you need to work toward solving for these hurdles. If you’re a Scrum Master, Product Manager, Agile Project Manager, or mid to lower level manager, you’ll probably need to seek an executive sponsor.

Beyond the ‘nuts & bolts’ of Scrum, what business processes need to change to adopt Agile?

Do an audit of current business processes and make a determination of which of these support your Agile adoption and those that can slow down or inhibit Agile adoption. Some of the process changes I did with the first Scrum project:

  1. How is was: The business’s initial full list of requirements defined the release content. Change: Review requirements with the Team Lead and Product Manager to remove requirements that didn’t add immediate value i.e. remove all the ‘nice to haves’.
  2. How is was: Product Architects dictated how to implement stories to the developers. Change: Developers held responsible for implementation and consulted with Product Architects if needed.
  3. How is was: Developers/UXD approached Product Manager to decide if display changes should be done. Change: Developers/UXD would make display changes based on acceptance criteria and demo to Product Manager at end of each day.
  4. How is was: Business was not involved day-to-day with the development team. Change: Senior managers attended the daily standup meeting to show support and to understand what problems the team had.
  5. How is was: The development team’s daily progress wasn’t available to the business. Change: Place the sprint board on a big wall in a prominent viewing area.

None of these changes occurred without some trauma but they were each done. Their cumulative effect was the successful adoption of Scrum.

As Scrum Master, Product Manager, or Agile Project Manager, changes need to be explained but often this will not be enough as people resist change on the emotional level. For example, one developer said he was working a task but the task wasn’t on the sprint board. When asked to put it on the board and explain it he wasn’t able to do so. What actually happened was the introduction of the Sprint Board with all its visibility was highly stressful to a development team who, until then, operated in the dark so to speak. If the developer was confused on a way forward, it was OK because no one would know. What saved the day was the lack of blame and recrimination from management and the Scrum team’s overall desire to progress and be successful.

Does the [new] business strategy support Agile?

Richard Rumelt in his book, Good Strategy/Bad Strategy: The difference and why it matters talks about company strategy as having three distinct components. These are:

  1. A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical.
  2. A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.
  3. A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.

Agile and Scrum neatly falls into the ‘Guiding Policy’ step, the overall approach towards solving a business problem.

I’ve never been in a position to define a company’s strategy but that doesn’t mean I couldn’t influence it. As Scrum Master, Product Manager, or Agile Project Manager, if you have access to the executive team, you can help make Scrum part of the strategy. However, getting an Executive Agile Coach for your industry might prove a better way forward. An Executive Agile Coach can better speak and understand the language of the executives. Without Scrum being part of the business strategy it can quickly become a sideshow.

How well will Scrum fit into the current Product Lifecycle?

A while back I wrote the Product Lifecycle document for a waterfall organization. Along with describing dozens of processes, it identified the decision makers for each step. For these gates in the lifecycle, one or more department (development, product, sales, marketing, support, executive, finance) would need to sign-off before proceeding to the next. Lots of decision makers but no one responsible. The Lifecycle document is based on good intent to guide a project but the detail was such that deviation, even slightly, was hard. Very unagile.

With Scrum, be prepared to rewrite the Product Lifecycle document (or remove it entirely) to accommodate the shift in responsibility to the Scrum team. In general, the Scrum Guide’s descriptions of the Scrum framework will replace the waterfall Product Lifecycle. The Scrum team takes center position with making product decisions and solving customer problems to grow the business.

How well does Scrum fit into the business’s current planning and budgeting processes?

If your organization has traditionally followed a waterfall paradigm, it’s likely that a single individual managed the project and was held accountable for cost and schedule. In Scrum, the Scrum team collectively becomes the project manager and as a team, is held responsible for delivering value to the customer. Many businesses have the board and shareholders to answer to. Part of that is predicting revenue and profits based of medium to long-term plans, often aligned to quarterly, semi-annual, or annual reports. Being able to accurately predict deliveries beyond 4-6 weeks is hard. It’s better to have growth targets and adopt Scrum practices that support achieving these. Enter Growth Hacking.

Growth hacking is a process of rapid experimentation across marketing channels and product development to identify the most effective, efficient ways to grow a business. Growth hackers are marketers, engineers and product managers that specifically focus on building and engaging the user base of a business. Source: Wikipedia.

By adopting Growth Hacking as a business strategy, you and the team are working in the near term where you’ll have better visibility and control. You still work toward growth targets, the stuff the shareholders and business managers care about, but you and the team are focused on immediate value and goals.

Take a look at this site for some successful Growth Hacking stories.

How much effort (training/coaching) is involved bringing product management, development, marketing, sales, and executives along on the Agile journey?

Scrum cannot exist for long if only the developers follow it. The Agile values and Agile principles clearly require the entire business to support and respect Agile for it to be successful.

VersionOne 10th Annual State of Agile Report states that barriers to Agile success include:

The availability of personnel with the necessary agile experience

Other important factors included: externally attended classes or workshops, company-provided training program, online training and webinars, and full-time internal coaches.

When I first introduced Scrum, I provided training to everyone in the company. I somewhat tailored the training for teach department to make clear of their ongoing responsibilities to the Scrum teams. For example, Marketing attended the daily standups so art could be collected for brochures.

Summary

Adopting Agile is a serious undertaking where there are no guarantees of success but by getting the business managers behind you, your much more likely to succeed.

  • Use experiments to showcase the possibilities of adopting Agile.
  • Address your Agile adoption to specific business problems.
  • Get executive sponsorship for adopting Agile.
  • Expect to change existing business processes. Expect resistance and understand the emotional state of those who are being asked to change.
  • Tie Agile to the business strategy and goals. Get an Executive Agile Coach to help the business leadership team understand Agile strategies.
  • Prepare to change or discard your Product Lifecycle.
  • Maintain long-term growth targets for shareholders and business managers. Use near term Growth Hacking techniques to help achieve these goals.
  • Provide the necessary training to the business to help all facets of the business better communicate with the Scrum teams.