The Goal Is Not Agile

You hear about and read about agile transformations, like this article about ANZ

“We need to break with some of the traditional 20th century approaches to organising and working to ensure we are more responsive to 21st century customer expectations.

“Moving to implement the agile approach at scale in our business is an important evolution in how we run ANZ which will allow us to respond much more quickly to customer needs, create higher staff engagement and make further improvements in efficiency” – ANZ CEO, Shayne Elliott

But what does agile transformation really mean? From the article, the goal of ANZ’s agile transformation is to specifically target customers which is a hopeful sign. If we look at the agile principles we see customer focus is essential:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

ANZ seems to be looking to improve employee engagement. This can be achieved by recognizing the agile team as equal business team members. They bring a different talent set to the table but they’ll be closer to the customer problem and potential solution than anyone else.

And lastly, ANZ describes their goal to be more efficient. This doesn’t just mean doubling output but doubling the value of each outcome.

ANZ has announced they will use agile as the tool to achieve the objectives. One can interpret from the article that the goal is not to be agile but to use an agile approach to improve and be better. Easy, right?

Although there are several aspects of an agile transformation, I’ll mainly look at it from the agile team’s perspective and how they can effectively change their working environment to embrace the agile culture.

Agile culture

Agile is a mindset or cultural phenomenon that is hard to quickly adopt when the culture is Hierarchical and Command & Control. The ANZ article says, “The transformation program will … shift to a less hierarchical organisation, relying on small, autonomous teams.” I’ve seen companies who take a different road in adopting agile practices to improve. They adopt agile without having a ‘agile transformation’, instead they test and experiment (see this blog post) with new ways of working and discover agile ways worked better than most. The common activity whether doing large-scale ‘agile transformation’ or using a gradual adoption is experimentation.

In the book, “Blue Ocean Strategy,” W. Chan Kim and Renee Mauborgne cite four hurdles a company will face trying to institute broad change:

  1. Cognitive – people must understand why the change in strategy and culture is needed
  2. Resources – changing an organization will require shifting resources
  3. Motivation – workers have to want to make the change
  4. Institutionalized politics – overcoming the way we do things around here

So where does agile fit into this picture? If your organization is doing waterfall or is rigidly hierarchical in nature or is Command & Control, all four hurdles will be a challenge. Agile as a tool won’t solve any of these challenges, in fact, it’s the opposite, these four hurdles will need to be overcome for agile to work best.

How agile transformation happens

Let’s assume for the moment that the organization is a typical C&C waterfall environment. Businesses can be successful with waterfall but that success can have limitations. These limitations primarily center around taking advantage of opportunities requiring speed and the ability to fine tune the product as you go through continuous customer engagement. When we choose to do agile it isn’t because we want agile, it is because we know the waterfall methodology we’re using won’t always work for us.

Why the need for change

Change can be driven for strategic or tactical reasons. The ANZ initiative seems strategic by drawing the customers and the business closer together. Another way agile finds its way into an organization is tactical, like when an important business opportunity comes along requiring very quick results with specific functionality and quality.

For either reason, agile and scrum may seemed the only way forward. There are rumors and anecdotal stories about how great scrum and agile are and for some businesses, the decision to try agile re-enforces one hard truth, “Necessity is the mother of invention” or simply:

Necessity drives innovation

The first hurdle in cultural change, Cognitive, is met: we understand the need to do something different to be more successful. In other words, can the waterfall business cite an instance where a new product is created and delivered in weeks, not months (or years)? With a win here, the business, will be competitively better positioned. The agile team, product, and the executives are convinced a change in strategies and culture are necessary but this understanding is not enough to cause change. Trialing any new idea or new practices is a good way to build confidence that a change will result in success.

Get the right people

For a trial project the business doesn’t engage all developers but only a select group. This trial project has a clear goal and a definite release date, neither can be changed. What can change is the scope (as long as the goal can still be met).

The Resources chosen for the first scrum team are special in their experience and talents. Although there are whole product teams that might be used for this new business opportunity, the business decides to build a new development team by cherry picking people from existing teams. The team might be hand-picked for a number of reasons which may include:

  • Years of experience – with experience comes confidence they’ll be successful.
  • People who are self-motivated – these are not people who sit around waiting to be told what to do.
  • People who are innovative – these people are known for their new ideas and abilities to think around problems.

Selecting people for the first agile initiative is often driven by technical expertise and their ability to solve problems. These people are asked to do something very different from their waterfall paradigm but they are more goal driven than most and change is less stressful to them. After a minimum amount of agile training, 45-minutes feels about right, they’re off.

The idea of shifting resources to get lean will happen without much thought. The initiative to be agile in this trial means traditional reporting lines are cut and the agile team reports directly to the agile sponsor.

The only real casualty will be middle managers who traditionally told the developers what they needed to do. With agile, we push this responsibility onto the team. But agile needs managers to clear away obstacles that slow down or prevent the teams from being successful. It’s only when managers can’t let go of their control over people that they become the obstacle.

Motivation for change

One ingredient used as a motivator is the challenge to be more successful. Using your business’s own track record might be the best evidence that change is required. It’s probably already clear that current processes and practices are not given to quick wins. A long decision chain slows things down. If the decision maker doesn’t like the choices available there could be lots of back and forth negotiations. All of this results in delays. What might not be clear is agile cannot change these circumstances. Agile is more mindset than physical and therefore it takes people to push for change. Agile becomes a guiding set of principles that you aspire to achieve. Arguably the most important of the agile principles after satisfying customers will be getting the development team and business in sync and working together as equals.

One very successful agile transformation I was involved in started with the business leaders meeting with the development team and restating the business problem not as leader-to-subordinate but peer-to-peer; the business has this problem and we need to work with you to solve it. We’re not intending to create an elite team but a team with strong mission understanding. This team wants to be successful and given the business or customer problem, business leaders are asking the team to solve these as best they can. In my experience, this will super-motivate the team to try new ways and explore new ideas. The best part is when the team completes the mission, they become the seeds in other newly formed agile teams. They’ll bring with them stories of both successful and failed adventures, but more importantly, they are the seeds to start institutional change.

Institutional change

“One of the things that limits our learning is our belief that we already know something.” ― L. David Marquet, Turn the Ship Around!: A True Story of Turning Followers into Leaders

Changing the way ‘things are done around here’ is hard. If being successful is a motivator for change then it’s clear that the business needs to understand what processes, practices, and decision paths are slowing us down. It’s likely that processes created for a specific reason have bloated or the original problem has itself changed or disappeared. One way to make this work is to drop everything, then analyse each process or practice to get the essential value of it. For example, if a previous practice had the chief architect review the detailed design once completed, you might change this to the team does the detailed design together with the chief architect. Or maybe an architect needs to be a member of the team. Either way can eliminate a hand-off and a potential delay. The point is to streamline existing processes to capture the essence and intended value, not necessarily throw them away. Of special note are those practices and requirements which are generally non-negotiable such as security, quality, and regulatory. Adopting agile doesn’t mean putting the company or customers at risk. Be cautious and review & streamline these with the right people.

There may also be processes that can be made part of the team’s definition of done (DoD) checklist. For example, we had a governance requirement for high-level designs to be reviewed by a ‘design steering committee’. We made updating the high-level design part of the DoD. We didn’t have a written process for this but did have a checklist that served the development team. High-level designs were decided upon during grooming with the chief architect. Once these were documented the chief architect worked with the steering committee, allowing the team to get on with the business of solving customer problems.

Changing institutionalized practices will be a challenge. Changing institutionalized management structures and practices can be impossible. Changing management often means changing the way human beings see themselves. If you’re the manager of a product team and the team is now empowered to make some decisions you once made, or owning practices you once controlled, you might feel a loss, even if you know:

  • Decisions are best made by people who have the knowledge to make that decision.
  • Keeping practices current, efficient, and relevant is best done by the people who use them the most.

By empowering the agile teams to make some decisions and giving teams the responsibility to continuously improve their work practices doesn’t mean managers are obsolete. Managers are critical in setting the boundaries from which the teams operate. Management are the enablers for the agile teams. It’s management’s responsibility in an agile world to ensure the agile teams understand the boundaries, what decisions they’re empowered to make, what processes and practices they own, and, most importantly, management ensures the agile team has the knowledge and support they’ll need to be successful.

Success is about being better, not being agile

My first scrum team was successful beyond all expectations. So successful in fact that the CEO asked afterwards, why aren’t we doing this “agile thing” with all our teams? With that comment from the CEO, comes the first truth about agile transformations: it’s not about agile, it’s about being better. I would wager most CEO’s are less concerned with how or what you do to be successful than they are about being successful. The article about ANZ says “implement the agile approach at scale” which can mean many things.

In my situation, what agile meant to the CEO and the rest of the business was a different approach that included:

  1. quick feedback loops to make decisions,
  2. high visibility of progress and setbacks,
  3. highly motivated teams,
  4. the agile team’s focus on business goals,
  5. the agile team’s continuous engagement with customers, and
  6. the teams desire to solve customer problems with the customer.

All these things made the teams better, made the business better, and made the customers happy. These agile things could not have happen at the scale it did without change.

The Big Picture Through Agile Inception Planning

When I was a kid, our family would go for drives out of the city to the countryside. These were more often a prison sentence for me in the crowded backseat with my two sisters. The only consolation was sitting next to a window but being the youngest, well, you can imagine I had the middle seat a lot. If there was a specific destination I was not aware of it until we got there. I was not happy sitting in the middle, the seat was hard as a rock and my sisters pointing out to me that they had the windows. It was sometimes miserable. So when the car got to a special place like the lake, I was already determined not to enjoy myself or at least, I took a while to lose the attitude. But I wonder what would have happened if in the beginning, my parents told me we were going to the lake for a picnic?

When the business starts a project, the project too can be either a prison sentence or an exciting adventure. While there’s no guarantee that everyone will be happy, there are steps the Agile Project Manager can take to help bring everyone on board, answer their questions, and give them an opportunity to participate and contribute toward a successful project. Giving the project team a complete picture of the business reasons for the project is good for business. To make the project goals be meaningful and effective in motivating the project team, they must be tied to larger business ambitions.  Team members who don’t understand the role they play in the business’s success are more likely to become disenchanted and look upon the project as a prison sentence. If however, the team members understand the business goals and how the project will help achieve them, they are more likely to be engaged and equipped to make better trade-off decisions when the project doesn’t go as planned.

An inception workshop is an ideal event that can help give everyone the big picture. The workshop gets the project team members thinking and can set the groundwork for them to make good decisions throughout the project.

Setup the Big Picture Workshop

An inception workshop can be thought of as a two part event. The first part is understanding the ‘why’ of the project from a business and customer perspective. The second part of the inception workshop will deal more with the planning aspects. Setting up understanding the Big Picture happens in the first half of the workshop.

There are several questions that everyone on the team will need to be able to answer at the beginning of the project to give them a better, more complete big picture. These questions are:

  • Why are we here?
  • What will we do?
  • What won’t we do?
  • What trade-offs will we have?
  • Who are our customers/users?
  • Who are our stakeholders?

The inception workshop attempts to get the project team to answer these questions without intimidation. The project team’s participation is essential. To maximize that participation requires openness, trust, respect, and courage to speak one’s thoughts out loud and to listen while others speak.

The inception workshop brings the project team into a large room where people can easily move about. They do not need to bring laptops, pens, paper, or books; they only need to be physically there. The facilitators bring tons of sticky notes, sharpies, flip charts, lots of wall space, phones to speak with customers or stakeholders, projectors, and strong time-boxing skills.

Why are we here

When the project team understands why they are working on the project, it can help make teams do the following things better:

  • making informed decisions
  • making trade-offs
  • being innovative

Getting the CEO or other business officers to describe why the business wants the project and what they hope to achieve, it helps focus the project. If for example the intent is to increase the number of people buying the product, it’s useful to know why they’re not buying it now. Depending on your business, the inception workshop facilitators bring in the CEO, head of Marketing, Sales, HR, Product, Development, and Support to discuss their business goals and outcomes the project will bring them.

When the team understands the intent of the project, they can make decisions based on that intent. To increase the number of buyers might require that customer  testimonials be made more prominent on the home page. If the user story comes up to add additional ad space, the team can decide that this story doesn’t immediately contribute to increasing the number of paying customers and prioritize it lower. Without knowing the intent, they probably would not make good decisions on priorities.

What will we do

During the inception planning workshop, the project team prioritizes business goals and objectives. Creating the elevator pitch is a lean way to get everyone sharply focused on the business intent and be very clear on what’s important.

Source: Dave Gray, Sunni Brown, and James Macanufo. “Gamestorming”. O’Reilly Media.

An elevator pitch is a description of the problem you’re solving, who you’ll solve it for, and the one key benefit that distinguishes it from other ideas. The project team collaboratively defines this pitch during the inception planning workshop. The product manager and Scrummaster/Agile Project Manager, get the group to answer these questions:

  • Who is the target customer?
  • What is the customer need?
  • What is the product name?
  • What is its market category?
  • What is its key benefit?
  • Who or what is the competition?
  • What is the product’s unique differentiator?

The full group starts by brainstorming ideas on sticky notes for each of the categories. There’s no discussion at first but everyone shares their ideas freely and largely silently. Use a large wall or whiteboard for the project team to stick their ideas for each category.

Once the ideas are up, break into smaller groups of 4-5 to develop an elevator pitch sentence. This is complete when the group reaches consensus. Each blank in the sentence contains at most one idea.

The last step is to finalize the pitch from the group inputs. Although important, it’s not critical to finalize this now, especially if there’s a large number of groups. The important part is the group as a whole have decided what the pitch consists of. The product owner can create the finalized version off-line if necessary.

What won’t we do?

When thinking about the project, we usually think in terms of the future product and new product features. We usually don’t think about what the project won’t do. Listing what features or capabilities the project will not do sends a crystal clear message to customers and stakeholders alike. What the “not in scope” list does is help define and manage expectations in an open way. The “not in scope” list can be the catalyst of conversations for future projects.

This is best achieved if the group uses a prioritization tool such as the MoSCoW prioritization method (Must have, Should have, Could have, and Won’t have). The group is asked to identify the features and capabilities the project could do and place these into one of the four columns. The elevator pitch would have identified the benefits and potential benefits of the product. The product manager will have a list of high-level feature work from the roadmap for the project. The project team spends 10-15 minutes sorting through the items silently or creating their own ideas of what should or shouldn’t be done, placing them into one of the four columns. What results is an MVP from the “Must have” column. The “Should have” column items can be considered for inclusion in the MVP but probably require more information before a decision can be made. The items in the “Could have” and “Won’t have” columns are considered out of scope for now. All of this may change over the course of the inception workshop but initial focus is placed on the “Must haves”.

What trade-offs will we have?

Trade-offs at the project level can become strong influences on how the project team approaches their work. It places priorities on those things that matter and de-emphasizes those things that matter less.

Get the project team to first decide what the sliders are. The example sliders above are probably the most used but the team may have others. The group then silently spends 5 minutes placing sticky notes on the sliders where they feel the trade-off is. “On” means most important and less negotiable while “Off” means less important but more negotiable. The consensus opinion will drive the results. After all the sliders are annotated, there is a discussion of the meaning of each slider selection for 10-15 minutes.

Who are our customers/users?

Understanding who your customers are means more than just having a customer’s name. It’s about understanding their motivations, desires, and pain points. Creating an Empathy Map is a quick and easy way to build a persona and get “inside your customer’s head.”

The product manager starts by conducting customer interviews live or plays recordings of customer interviews prior to doing this empathy map. Most likely these will be recordings as a live interview might be difficult. However, having live interviews with your sales or support team members might help a lot. They can bring to the project team their own experiences and understanding of customers and users. Once these interviews are complete, the group is ready to build empathy maps.

The person in the empathy map is fictional but based on understanding of the business’s customers. Ask the group to give this person a name and define their role with the product. The group will describe what the customer’s experience in each of the categories. Not everyone in the group will define something for each category but if a category is left blank, have a quick group discussion to try and fill it. It should take about 10-15 minutes for each customer/user profile.

The goal is for the project team to form some degree of empathy for the person, understanding at some level: What does this person want? What forces are motivating this person? What can we do for this person?

 

Who are our stakeholders?

Although the project team has met some stakeholders at the opening, the team will now identify all the stakeholders that have a direct interest in the project and those people needed to make the project successful. This can be by individuals or roles.

The project team members build a list of ‘Who’ and what they do or need to do to help make the project a success.

The group will spend 5-10 minutes defining this list. Have people fill out sticky notes and place these on the wall. Ask a volunteer to do some affinity mapping to group the item by the do’s.

Summary

The steps above can be reordered to suit your specific inception workshop need and your team’s baseline knowledge levels. If for example, the team knows nothing about customers, getting a base understanding of the customers through user journeys or empathy mapping before developing the elevator pitch might be the appropriate thing to do.

The steps above define the first half of the inception workshop. The second half has the team using the information gathered here to add detail for project planning and will include: Story Mapping to define the releases, provide high level estimates, identify areas of concerns and risks in Speedboats and Anchors, and provide the project team’s presentation back to the business leaders of what they can expect (and not expect) to happen during the course of the project.

Getting everyone on the same page and understanding the big picture doesn’t guarantee success but doing this can reduce truck loads of risk.

Some resources that can help you include:

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.