Psychological Safety leads to High-Performing Agile Teams

There are two types of safety that factor into a healthy and productive enterprise environment and high-performing teams.  The first is physical safety. This is where employees have an environment where they are free from physical hazards and can focus on the work at hand. This type of safety should be part of the standard workplace promoted by company and government regulations.

The second is psychological safety that is core to enterprise effectiveness. According to Google research, high performing teams always display psychological safety.  This phenomenon has two aspects.  The first is where there is a shared belief that the team is safe to take interpersonal risks and be vulnerable in front of each other.  The second is how this type of safety along with increased accountability leads to increased employee productivity and ergo high-performing teams. 

Psychological safety helps establish Agile in that it promotes a safe space for employees to share their ideas, discuss options, take methodical risks, and become productive.  An Agile mindset promotes self-organizing teams around the work, taking ownership and accountability, and creating an environment for learning what is customer value through the discovery mindset, divergent thinking, and feedback loops. Agile with psychological safety can be a powerful pairing toward high-performing teams.   

However, accountability without psychological safety, leads to great anxiety.  This is why there is a need to move away from a negative mindset when results aren’t positive or new ideas are seen as different. If this occurs, employees are less willing to share ideas and take risks.  Instead consider ways to build psychological safety paired with team ownership and accountability of the work. This can lead to high performing teams. 

Everyone has a role to play in establishing a psychologically safe environment.  Agile Coaches and ScrumMasters can help you evolve to an enterprise where psychological safety and accountability are paired. Leadership has a strong role to play to provide awareness of the importance of a safe environment, provide education on this topic, and build positive patterns in the way they respond to results of risk taking by teams.  Team members must adopt an open, divergent, and positive mindset that is focused on accepting differences and coaching each other for better business outcomes.  Employees at all levels must be aware of the attitudes and mindset they bring.   

Benefits of Agile Coaches for your Agile Transformation

Many companies begin their introduction to Agile by trying it on a project or two.  If they believe they have ‘enough’ success with Agile, then typically more projects deploy Agile.  The challenge is that at some point the company is unclear on what level of Agile deployment has occurred and what type of Agile is really being adopted.  Senior Management may hear things like “we are Agile” and not really sure what that means.  Worse yet, because of the inconsistency of understanding Agile, some teams will say things like, “we don’t need to document anything because we are Agile”, other teams will say “we don’t need any management support because we are self-organized”, while others will say “we can’t tell you what we’re building until the end of the project because we are using Agile”.  Now what do you do? 

This becomes even more challenging when the company begins to realize the amount of effort they are haphazardly spending on Agile adoption.  Sometimes the company learns that they are spending twice for the same thing like training and/or tools and often overspending because they are not leveraging the volume discount strength of the whole company.  This is particularly relevant to medium and large companies.  

Whether you realize it or not, when you have multiple teams heading in roughly the same Agile direction, you have already embarked on an Agile transformation.  So the question is, do you want to let the change occur in an unorganized and ad hoc manner or do you want to manage that change in an organized way and gleam the most benefit from the effort.

I do not believe there should be a prescriptive way to deploy Agile.  However, there needs to be some way to ensure the teams are working on the highest customer value work. An enterprise level approach can help.  This ensures that the company reduces the muda (a.k.a., waste), leverages and reuses what it can, and ensures all teams are building the highest customer value work.      

When you find yourself in the situation where there are many in your company wanting to adopt a certain tool, process, method, and/or culture, or if it is already happening in an ad-hoc manner, it is highly recommended to initiate an organized approach to the enterprise change.  In Michael Spayd’s “Evolving Agile in the Enterprise: Implementing XP on a Grand Scale”, he recommends that an “effective Change team” is established.  In my experience, seasoned Agile Coaches and/or an Agile enterprise leadership team provides significant leadership for the change effort.  The Agile Coaches/Agile leadership team (aka, change team) provides the framework for the enterprise but still allows for adaptability and decision-points by the teams so they feel ownership of their working process.

The Agile enterprise leadership team should include talent that has experience in Agile enterprise change such as seasoned Agile Coaches and those who have organizational level change experience.  Some members can be matrix-ed in from internal organizations.  They should function as a team and can be distributed according to the areas within the organization that they will support.   It is often best to bring in either full-time regular talent or external long-term consultants to ensure that they don’t just make recommendations, but live through the challenges of the change as they help product teams, senior management, and others.

What are some of the benefits of Agile coaches and/or Agile enterprise leadership team?  This leadership can help you establish and manage the following: 

• Agile Vision - create a vision for where you can go.  A strong Agile coach has been to where you want to go. Without this experience, a company may never get there.  This may include a focus on the Customer to build the right thing and on the Employees to build the thing right" or similar.  By having a central Agile leadership team to focus you, you can better gain buy-in or at least get folks to understand why you are going in this direction.   
• Agile Transformation Roadmap - identify common activities to help a product team come up to speed with Agile.  This includes establishing a set of “ready for deployment” materials to help teams get ready for the change to Agile.  By having Agile Coaches help you, it will save time and effort from each product team having to figure out the adoption activities themselves
• Agile framework and practices - collaboratively establish an adaptable set of Agile methods and practices with the rest of the organization.  By having central Agile leadership coordinate this, it will save time and effort from each product team having to establish Agile methods and practices, although they will need to tailor them for their specific team. 
• Agile terminology – establish a common working language for Agile so that members from across the organization can communicate and interact effectively with each other.  By having central Agile leadership establish this, this reduces the miscommunication issues that will arise across the organization regarding various and sundry definitions of Agile terminology.   
• Agile training – establish a common set of Agile Training aimed at various levels of the organization (e.g., Scrum Team, Scrum Masters,  Product Owner, Middle Mgt, Senior Mgt).  By using a managed training deployment approach via the central Agile leadership team and education group, we will have consistent training and can get a better understanding of who has and hasn’t been trained.  By providing an in-house training approach, this reduces the cost of utilizing multiple vendors.  This increases common Agile understanding across the organization and product teams.
• Agile Communities – establish a common organizational Agile website with links to internal and external Agile communities.  Having the central Agile leadership team establish and support this, ensure that there is a managed approached to sharing online Agile related information and resources (framework, practices, etc.) across the company site that is kept up-to-date.    
• Agile Coaching - A key aspect of the leadership team is to provide Agile Coaching via the Agile leadership team to projects/product teams across the enterprise.  They may start with a small core of dedicated Agile Coaches and then can leverage existing Agile talent across the enterprise in establishing an Agile Coaching Circle.  Coaching significantly reduces the effort involved with “correctly” getting a team to adopt Agile and more importantly ensures they do not regress into their old traditional habits. 
• Agile Adoption measures – establish a common and reasonable set of adoption measures to see what progress is being made in the Agile adoption within the company.  By having the Agile leadership team manage this, we have common adoption measures to ensure that the leadership team and product teams are meeting the organization objectives for Agile adoption.  Senior management can more readily get a pulse of the Agile status across the organization.
• Agile Challenges Point of Contact (PoC) – establish a central point to manage Agile related challenges and issues.  This would include website, email PoC and the establishment of an Agile FAQ.  The benefit to having a go-to centralized Agile leadership team to manage this is that they can both become aware of these issues and then resolve the issues and challenges before they cause an impact.
• Agile Vendor Liaison PoC – utilize the Agile leadership team to become the PoC for managing the company relationships with the various Agile vendors.  By using a central Agile leadership team ensures that the organization or company is gaining the most leverage from the volume discounts and negotiations for Agile related materials and tools.  

Finally, when employees within a company see that many are going Agile, sometimes it is comforting to see that the organization is providing support in the adoption effort.  It is even more comforting when those employees that haven’t yet gone Agile see that there is ready support for their deployment.   It is particularly problematic when the employees are seeing wide variations of “agile” being deployed some of which is not really Agile, and they wonder when the organization may provide some guidance in this matter.  Introducing Agile really is a culture shift.  If you are thinking about adopting it or already are, then it can be a benefit to have Agile Coaches and/or a centralized Agile leadership team to help you navigate to a success adoption of Agile.  

Good luck on your Agile adventure!

Note: this was originally written in 2008 with minor updates in 2012.    

Size Matters – using “size” instead of “estimate” on Agile projects

When I help teams implement Agile methods, I find that some folks have a hard time getting their head around “estimating” user stories (aka, requirements) using story points. When I get to the discussion of Sprint Planning where we are scrubbing stories (aka, requirements) as a team, I used to say it is now time to “estimate user stories”. I would emphasize the importance of having the whole team estimate the story together. I also tend to apply the planning poker technique where each team member has a physical or virtual set of cards with the Fibonacci sequence (aka, law of distribution) of numbers on them (e.g., 1, 2, 3, 5, 8, 13, 21, 34, 55, etc.). When it is time to estimate the user story, each team member selects a card from their deck relating to the story points they think reflects their estimate of the work which should include their notion of complexity and risk for that story.

When I educate folks on estimating user stories, some folks ask me to align the story point with days or hours. That’s when it occurred to me… I realized that when I use the word “estimate” it would make some (many?) folks think of the traditional estimation that uses “schedule” as a measure (e.g., hours, days, weeks, months, years). However, in Agile the intent is to size the amount of work based on the functionality you are building for that story. So in effect in Agile, “scope” is the measure of progress. This is when I realized that folks were often trying to apply a schedule measure because of their familiarity with traditional estimation when in fact, story points is meant to represent the size of the functionality we are building or the scope of the work including the amount of work + complexity + risk of that work. In other words, it was like comparing apples and oranges.

With this in mind, I strongly advocate that in Agile it is much more meaningful and appropriate to use the term “size” as the verb to measure the user stories since this relates to the amount of functionality you are building. This is more than just semantics. This takes us a step away from the traditional mindset where schedule is “king” and moves us to the more important focus of scope since to our customers, the functionality is what is valuable. Now make no mistake, there will be trades offs between schedule and scope, but working software that meets customer needs and provides them value is IMHO slightly more important (e.g., working software over schedule).

It is also important to note that a team’s sprint velocity is a representation of how much functionality can be delivered within a sprint. This is yet another reason why I encourage you to use the term “size” since sizing individual stories relates to the functionality you are building and the sprint velocity relates to how much total functionality is delivered in a sprint.

So if you are having trouble understanding or explaining the concept of estimating user stories, think in terms of the scope of functionality and consider using the term “size” instead of “estimation” to break from the traditional mindset of schedule. So maybe size does matter after all…

Who makes the Best Product Owner?

In one of my recent articles entitled Who makes the best ScrumMaster?, I discussed the attributes needed to make an effective ScrumMaster and what traditional roles may play the ScrumMaster best. From the feedback, those who can best exemplify the attributes of a ScrumMaster made the best ScrumMaster and it did not appear to be strongly aligned with any particular traditional role.

In this article, the focus is the Product Owner role. Much like the ScrumMaster, the Product Owner role is very important to a successfully running Agile team. In fact as teams consider adopting Agile, who plays the Product Owner is critical to gaining the benefits of Agile due to the importance of identifying customer value and enacting the customer validation activities to ensure we are building something that the customer actually wants.

What are some important attributes of an effective Product Owner? A Product Owner recognizes what customers want and translates their needs into meaningful epics and user stories (aka, requirements). A Product Owner must intuitively adapt requirements (aka, user stories) when customer needs and market conditions change, to ensure what is built and delivered aligns with customer needs. This may sound obvious but the Product Owner must have the wherewithal to ensure that the organization in which the team works in will positively support and welcome change. A Product Owner must have the attributes to be a good voice-of-the-customer (VoC) and communicate the customer needs to the Team so they can build what the customer needs. It can be quite challenging to commit time to customers and team members.  Some attributes that an effective Product Owner must have include:

• Parsing customer and business problems and turn them into meaningful user stories  
• Working with sales and marketing to get their ideas into the backlog
• Establishing a directional Product Roadmap and Product Strategy
• Understanding the business marketplace
• Understanding and interacting with the customer domain 
• Establishing effective Customer validation (e.g., end-of-sprint reviews/demos, alphas, etc.) to ensure you are building a product the customer wants   
• Understanding that it takes a trusting environment where problems can be raised without fear of blame, retribution, or judgement, with an emphasis of healing, collaboration, and problem solving  
• Facilitating and influencing the work without coercion, assigning, or dictating

So the question arises, is there a traditional role that plays the Product Owner the best? Let’s examine a few of these roles.

Business Analyst as Product Owner?

What does a traditional Business Analyst (BA) do? A BA is someone who analyzes business needs, works with stakeholders in order to understand their needs, and to recommend solutions that meets these needs. At a deeper level, a BA focuses on eliciting, documenting, and managing requirements. They also act as a liaison between business and technical groups. It is because of the work a Business Analyst already does and in particular their focus on requirements and their liaison role between the business and technical groups that makes them a good candidate for the Product Owner role. A traditional BA would have to gain the experience in working in an Agile manner including the continuous requirements elicitation process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Product Manager as Product Owner?

What does a traditional Product Manager (PM) do? A PM examines the market, the competition, and customer needs and establishes the product direction that is considered valuable to the market and the customers therein. A good PM focuses on the financial considerations including the return on investment (ROI). In addition, the PM is involved in the requirements gathering and management process. It is because of the work a Product Manager already does particularly their focus on what is considered valuable by the customer that makes them a good candidate for the Product Owner role. A traditional PM may not have the experience in working in an Agile manner including a continuous requirements gathering process (per the sprint cadence) and applying iterative customer validation so skills and experience in these areas would have to be built.

Project Manager as Product Owner?

What does a traditional Project Manager (PjM) do? The primary responsibility of a Project Manager is to plan and execute a project from the beginning to closure. A PjM focuses on the project costs, schedule, and scope. A PjM may also help build the project objectives, help manage the requirements management process, manage project risks, issues, and dependencies. While there are some attributes a PjM brings that can help in the Product Owner role, there is very little direct customer focus which is a big part of the Product Owner role so this experience would have to be gained. A PjM may have to unlearn some "assigning work" and "driving the work" as this can inhibit the team's ability to become self-organizing.

Technical Manager as Product Owner?

I have found that some Technical Managers (TM) provide aspects of product ownership to their work. The Technical Manager may get input from Product Managers, Sales, and Marketing and then crafts them into meaningful customer needs.  While there are some attributes a TM brings that can help in the Product Owner role such as crafting a product or service direction, there may be little direct customer focus which is a big part of the Product Owner role. This experience would have to be gained. In addition, a TM will need to break from the "team are my direct reports" mindset and "assigning the work" as this can inhibit the ability for the team to become self-organizing.

Other Roles as Product Owner?
There are other roles that may be considered.  A select example are those in the marketing space (e.g., Market Researcher), service space (e.g., Service Consultant), user or customer experience space (e.g., UX Designer), and entrepreneurs. These are roles that understand the market, customers, and the continuous feedback from the customer.  As organizations have various roles in this capacity, it is worth investigating those current roles that are customer facing and understand how to translate feedback and strategy into user stories. 

Summary

IMHO, those who have played either a Business Analyst or Product Manager can become an effective Product Owner. However, anyone who has played a role where they work with customers to collect their needs and then work with teams to build products or solutions that meet those needs can evolve into an effective Product Owner. I would suggest that anyone who becomes a Product Owner (or is interested in doing so) should consider taking Agile Product Owner education, reading related books, and/or gaining guidance in this area through an Agile Coach in order to help them better understand this role and the activities they will need to perform in order to play this role effectively.

Applying the Agile Canonical Form to write Performance Goals

In most companies, employees have to do some level of performance management. This typically involves each person writing performance goals. For those of you in companies that are adopting Agile (or even if you are not), as you think about your performance goals, one of the things to consider is applying the Agile story writing canonical form as the approach to writing goal statements.

For those of you unfamiliar with the canonical form, it is a language construct that many in the Agile community use to document their requirements (aka, user stories). This includes the role (aka, persona or actor) you are playing, your action, and the business benefit.

In many cases, each of us has a primary role we play within an organization. However, we may also have secondary roles that we play. The canonical construct includes the role so the roles you are playing in your organization or your product team can be effectively added. This may help in describing your goal more effectively. For example:

• As a Scrum Team Member, I will size the work using story points with the team during Sprint Planning, so that we gain team buy-in for scope and size of the story

 • As a ScrumMaster, I will exemplify Servant Leader attributes (and not command-and-control attributes) in order to help my team become self-organized

 • As a Product Owner, I will continuously groom and prioritize the Product Backlog so that the Scrum Team has a solid list of stories in which to work through

 • As an Agile Coach, I will coach and mentor the product team so they can adopt effective Agile methods

 • As an Agile Educator, I will ensure effective Agile instructor-led training is occurring throughout the company

Once you have the performance goal written in this form, then you can list the tangible tasks that make up the goal underneath.  You may consider this another interesting way to use the canonical form (which is usually meant to describe User Stories within an Agile context) for other benefits.

In summary, it is a good idea within a performance goal to identify the role you will play in relation to that goal, what is the action you expect to complete, and why you plan to do that action (aka, business benefit).  Using the canonical form can be an effective way to articulate the performance goal. 

Who makes the Best ScrumMaster?

As teams consider adopting Agile, one of the most important decisions they can make is who will be the ScrumMaster. Because the ScrumMaster is the promoter of Agile values and principals as well as the coach for ensuring the Scrum is being practiced effectively, it is critical that this role be filled with someone who is dedicated to implementing the Agile mindset.

A good ScrumMaster must have the ability to be an effective Servant-Leader. If is important to understand that a servant-leader takes a facilitative approach and does not apply command-and-control. Some key attributes include:

• Building a trusting environment where problems can be raised without fear of blame, retribution, or being judged, with an emphasis of healing and problem solving.
• Facilitating getting the work done without coercion, assigning, or dictating the work.
• Ensuring the implementation of healthy Agile Scrum practices and values are followed on the project.
• Removing roadblocks or find the right level of personnel to remove the roadblock.

In the book “Practicing Servant-Leadership" by Larry Spears and Michele Lawrence, they share attributes for servant leadership. Some attributes include: listening, empathy, healing, awareness, persuasion, and foresight. Anyone who becomes a ScrumMaster should consider taking ScrumMaster training to help them understand their role and the activities they will facilitate. So the question arises, is there a traditional project role that plays the ScrumMaster the best?

Project Manager as ScrumMaster?
The seemingly obvious traditional role to play a ScrumMaster is the Project Manager. However, from my experience, there are pros with having a Project Manager become the ScrumMaster. On the positive side, the Project Manager has experience in being part of the team, so they may already have a trusting relationship with the team. Some Project Managers have built facilitative skills to lead work in a non-directive yet influential manner. And many already have the skills and the insight into an organization to appropriately remove roadblocks. On the negative side, Project Managers typically do not have technical experience into the product and cannot materially participate in technical discussions or provide meaningful technical insight. Also, some Project Managers had success utilizing command-and-control attributes and the more traditional Project Management practices which will not work well (and can be destructive) in an Agile environment. It can also be hard for some Project Managers to eliminate the traditional Project Management mindset of detailed project planning.

Functional Manager as ScrumMaster?
Quite possibly the most problematic role to play the ScrumMaster is someone who is a Functional Manager (aka, line manager, technical manager, etc.). Anyone playing a role where they have successfully directed people must make concerted efforts in removing their command-and-control behavior. On the positive side, they may have some technical experience into the product so can provide meaningful technical insight. They may already have the skills and the insight into appropriately navigating the organization and the ability to remove roadblocks. On the negative side, because they have been a manager of a team, so they may have issues with the team trusting them as a peer since they have been used to being judged by managers. A Functional Manager may have been successfully utilizing command-and-control attributes. However, this will not work well (and can be destructive) in an Agile environment. They must strive to remove their directive attributes and instead build facilitative skills. They must not assign work but instead enable and support team to become self-empowered. These are significant challenges.

Technical Lead as ScrumMaster?
Quite possibly one of the better traditional roles to play the ScrumMaster is someone who is a Technical Lead (QA Lead, Development Lead, etc.). By “lead”, I do not mean a manager or someone who has direct reports, but instead someone who is considered a lead by his peers. This person has a balance of leadership skills while wanting to get the work done. They typically have no interest in directing people. On the positive side, they have technical experience into the product and their specific field (development, QA, technical writing, etc.) so can appropriately aid the work (without direction or coercion and provide meaningful insight). They have experience at being part of the team, so may already have a trusting relationship with the rest of their peers. Because a lead does not have functional management responsibilities, they typically had to build their facilitative skills to lead work in a non-directive yet influential manner. On the negative side, they may not yet have the skills or the insight into an organization to appropriately remove external facing roadblocks.

Ultimately, the best answer to the question of what role best plays the ScrumMaster is not really a particular role, but instead which person best exemplifies the combination of the attributes of servant leadership, understands the Agile values and principles, embraces continuous learning, has a grasp of the technical aspects of the product under development, and can help remove roadblocks. In your organization, are there traditional roles that more often play the ScrumMaster role or best align with the servant leader attributes? If so, what is that role?  If not a role what attributes best exemplify a ScrumMaster in your organization?

----------------------------------------------------------------------------------------------------
PS - if you liked this article, consider reading "Who makes the Best Product Owner".

Daily Stand-up Starter Kit

The Daily Stand-up can be one of the easiest or hardest Agile practice to do well.  When introducing the Daily Stand-up (aka, Daily Scrum or huddle), the initial goal is to get people to share their progress in a brief manner.  The benefit of the stand-up is that it promotes transparency of what everyone is doing where you communicate your progress.  It can also be a place to help you understand your impediments where you can collaborate on addressing the challenges. The focus should be on:

• What I did yesterday (or since the last time the team met)?
• What I will do today (or until the team meets again)?
• What impediments have I uncovered?  

The daily stand-up keeps the team aligned as to what everyone is doing. The "What I did yesterday" keeps everyone in-sync on what progress has been made.  The "What I will do today" helps you plan for your day and helps you commit to a day's worth of work.  The "impediments" are to share what is slowing you down or stopping you from making progress. Others can help you address the impediment once the stand-up is over. 

One challenge is when either the sharing of these three questions are too vague (e.g., yesterday I work on the same user story) or too detailed.  The key is speaking with detail yet brevity.  Enough details should be shared to ensure people understand what was worked on (e.g., yesterday I worked on opening the port to allow communications to occur) or what will be worked on (e.g., today I will work on setting up the asynchronous protocol and set a test packet through the port).  To keep from going too long, an initial helpful instruction is for each team member to limit their progress to about 1-2 minutes (assuming a team of 7 +/-).

Part of the initial adoption of the Daily Stand-up is simply getting people to go from one person to another and provide your daily progress. A challenge is when the team members expect the Scrum Master to tell you when your turn is.  Instead, consider a round-robin approach where you identify an order amongst the team to share progress. This can be alphabetical by name or around the virtual table by site. Another helpful technique in a distributed setting is ensuring each person introduces themselves with their name (e.g., I am Mario…) and ending with a code-word such as “Thank you” or “I’m done”, to let the next person know it is his or her turn.  This is particularly useful in a distributed team setting.

Another challenge is that too many team members direct their progress to the Scrum Master (or leader).  Instead, the team should communicate to each other and avoid directing their progress to the Scrum Master. This allows all teams members to know what each other is doing and promotes cross-team communication.

Once the team has a good handle on the daily stand-up, it can be helpful to evolve the process via the Retrospective. This helps the team reflect on the Daily Stand-up and determine if it is satisfying the needs of the team. For example, you may want to view the stories in the sprint backlog in a priority order and ask those that are working on the highest priority work to share their brief status. The benefit of this is that the team can more readily be aware if the highest priority work is getting done. Because the Agile mindset focuses us on working on the priority work first, this ensures that the progress sharing is focused on the highest priority work first and then so on. This also provides more visibility when the highest priority work are not getting done especially when others are getting done. It then can help you rally resources around the higher priority work that isn’t done.

The key is to adopt, reflect, and adapt. Good luck on your Daily Stand-up journey. How do you conduct your Daily Stand-up and have you evolved it over time? If so, in what ways did you evolve it?

Robust Agile Organization - Core Roles and Beyond!

To establish to a fully robust Agile enterprise, it is important for everyone to play a role in Agile. I have found that being successful from an Agile perspective requires "core" roles and but must include the "across the enterprise" roles to ensure success.  Let's focus on each of these areas.

Core   

The core roles provide the nucleus for building customer value.  This starts with the Development Team. I prefer to use the term Agile Team (or something similar) since I want to ensure folks understand that it is not just development-centric but includes other key cross-functional roles and disciplines.  This cross-functional team is made up of around 7-9 members who can architect, design, develop, build, technically write, and test. This is commonly made up of developers (who can architect, design, and code, but preferably some who can do all three), QA/testers (who can build and execute tests), UX, DB, tech writers, and CM/build talent. The key is to ensure you have all of the roles you need to build an idea with sufficient skills to get the job done. You may also need a Product Architect which is a role that may not be considered full-time because they can support more than one team related to an idea.  However, it should be committed to the team(s).  This person ensures that the architectural related decisions are established and discussed with the team.

The servant leader for the team is the Scrum Master. The Scrum Master educates the team on Agile processes and practices, and helps them apply those practices. The Scrum Master takes the responsibility of a team coach ensuring the team stays true to the Agile values and principles as articulated in the Agile Manifesto including applying self-organization around the work. The Scrum Master helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, Daily Stand-ups, Retrospectives, and the Agile Release Planning session. Learn more about the Scrum Master in the Who makes the Best Scrum Master article.

Equally important is the role of Product Owner (PO), the driver of customer value. This Agile role should be played by someone within each product team that is customer facing to ensure everyone understands customer needs. This is often played by the Product Manager, Business Analyst, or someone who provides the business perspective and engages with customers to ensure the Agile Team is building something that is of value to the customer. Identifying the right customers for validation is the job of the Product Owner. To scale this PO role, the lead PO may introduce Product Owner Proxies (POP) who may be architectures, lead developers, or functional managers (the latter role may now have much less to do). The POP takes direction from the lead PO via the Product Owner Scrum of Scrum sessions to ensure all POs and POPs are on the same page. Then it is important to bring the customer into the picture to validate that what the team is building is something that the customer actually wants.  Learn more about the PO in the Who makes the Best PO article.

The final core role that is often forgotten in many Agile environments is the Customer.  The customer is core to determining what is value.  With the customer, you are not really enacting Agile. The customer is where many of the ideas of value come from.  The customer provides the valuable feedback along the way that validates (or adapts) what is considered value.  The customer may be in the form of multiple personas depending on their motivations and pain points. 

Across the Enterprise (aka, Beyond) 

If this is your first foray into the Agile space or you want advance in your state of Agile, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily revert back to old traditional habits. The Agile Coach understands both the short-term and long-term pitfalls of adopting Agile, that Agile is a culture shift and will take time, and can help the team move to Agile is a more effective and efficient manner.

We then turn to management. Middle Management must play their role where they gently back away from command-and-control and act more as servant-leaders where they trust their teams, help them remove roadblocks, and support the Agile practices. They must realize that their direct reports are now on Agile Teams so they cannot be assigned any additional work. They may attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality) vs. getting a status report. Often times middle management have less to do in an Agile world and may consider changing their roles to either more of a Resource Management or Product Owner Proxy.  Learn more about Agile and middle management by visiting the Agile and Middle Management article.

Executives/Senior Management needs to play a leadership role as Agile champion. They must support Agile and understand that its primary intent is to build customer value which can ultimately mean more revenue for the company. They must also understand that they must get the Agile teams to feel ownership of their work and this requires leadership and not command-and-control style managers. They may need to adjust their staff if it already laden with too much command-and-control. They may also attend the End-of-Sprint Review (aka, demo) to gain a more genuine sense of progress (seeing actual working functionality).  Learn more about Agile and the Executive role by visiting the Agile Executives Playbook article.

Then we bring in roles like Sales and Marketing, Finance, and HR. These roles should adapt toward the same concepts of agile leadership, self-organizing teams, collaboration, streamlining and eliminating waste. Sales and Marketing are involved with bringing a product to market. They need to help the Product Owner with requirements input and clarification to ensure we are building something the customer needs. They need to understand that the Product Backlog and Release Goals are owned by the Product Owner, they must funnel requirements to the Product Owner, and avoid making commitments without the Product Owner in agreement.

Finance needs to be flexible in understanding that they can still manage to cost because it is the scope that is the important variable.  Finance and Portfolio should adapt to a continuous budgeting approach where ideas are continuously added to an enterprise kanban prioritized by value instead of fixing the work at the beginning of an annual budgeting process. You can learn more in the book Beyond Budgeting. 

If performance objectives are part of the organizational processes, then it is important for HR to establish a performance process that allows for team goals. This is because as part of the Agile mindset, it is important to establish that it is the team’s responsibility to ensure the release is a success and not specific to individuals.  HR can also help the enterprise move from an annual performance review to continuous review and feedback. Learn more about this in the Agile is creating a new horizon for HR article. 

If an idea or product is made up of more than one Agile Team (e.g., for a team of twenty you would want to break them into three teams of around 7), then there may be a need for an Agile Project Manager (APM) to help manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert.  They may support a Scrum of Scrums (SoS) or similar.  The APM also handles the interaction with the business governance of the organization.  If your organization is large, you will need an Agile Portfolio Management Leader or team.  This leader focuses on providing visibility to the highest value work so that the organization (and teams therein) are building the highest value work to the customer.

Ultimately everyone within the organization should be focused on understanding and delivering customer value every step of the way. Getting to that value oriented mindset is critical to the success of Agile. It takes teamwork to get there and that team is the entire organization.

----------------------------------------------------------------

You can see a presentation that covers many of these roles at: http://www.boston-spin.org/slides/boston_spin_slides_2010_09.pdf