Adapting to Agile Roles and Responsibilities
Culture does not change because we desire to change it. Culture changes when the organization is transformed; the culture reflects the realities of people working together every day.
—Frances Hesselbein
When moving to an Agile world, there is a significant shift in roles and responsibilities. In a more traditional project, decisions are typically made in a hierarchical manner, and roles are specifically established to support this structure. If you are serious about moving to Agile and gaining an Agile mindset, then maintaining traditional roles will get in the way of this change. In the Agile world, there is a purposeful focus away from hierarchy and a strong focus on getting people to work together every day.
To get to a fully robust agile organization, it is important for everyone to play a role. Although managing a successful project from an Agile perspective requires three core roles, there are many others in the organization who must play a role to ensure success. Everyone from customers, executives, and management to sales, marketing, finance, and HR must understand the Agile mindset. It takes an organization to get to an agile culture.
Because it is takes a very concerted effort to adapt to an Agile culture and move away from a hierarchical culture, adapting to new roles that are not easily recognizable offers awareness that change is occurring and provides everyone with an opportunity to ask, “What is the change in the role and responsibilities?” As part of the RICH deployment model, gaining an understanding of Agile roles and then beginning the steps of implementing those roles is a good starting point. I have provided details on the Agile core roles and beyond. As you read this section, consider what your organization’s product teams may look like.
Core Agile Roles
The core roles within Agile represent the group of people who are focused on directly building the product. Because Scrum is the primary Agile process that is used within many organizations, I align the Agile roles with Scrum. If you plan to follow a specific agile method, consider following the roles specified by that process.
Scrum Team
The Scrum Team is the group of professionals on a project who work together to build the customer value they have collectively committed to complete within a sprint. The Scrum Team is a self-organizing group with enough cross-functional skills and experience to build working software independently. The Scrum Team includes the roles of Scrum Master, Product Owner, and Development Team.
- The members are committed full-time team members, focused on completing the work for the product release.
- They are equally accountable and empowered to make decisions, determine sizes for stories, contribute in identifying risks, and articulate roadblocks.
- The team size is seven (± two) members with a healthy balance of development and test skills.
There will be other skills needed on the team focused on architecture, user experience, documentation, and configuration management. Though it would be good for these roles to be full-time, often there is not enough work involved for them to be continuously engaged.
Scrum Master
The Scrum Master acts as a facilitator and servant leader for the team and an enabler for Scrum, ensuring that it is understood and followed. This role may act as Coach to ensure that the Scrum roles, events, artifacts, and rules are understood and implemented effectively on the Scrum Team. The attributes of servant leadership include listening, empathy, healing, awareness, persuasion, and foresight. 1 It is important for a soon-to-be Scrum Master to read more on what is expected of a servant leader.
Agile Pit Stop A Scrum Master should have the attributes of a servant leader, which include listening, empathy, healing, awareness, persuasion, and foresight.
A Scrum Master facilitates the Scrum events. This does not mean that they direct the activities but that they ensure the events are occurring along with the behaviors of an Agile mindset. In addition, the Scrum Master removes roadblocks or finds the right people to remove roadblocks to ensure team progress. The Scrum Master also does the following:
- Helps the Product Owner enact effective backlog grooming techniques.
- Establishes and produces the Sprint Burndown, velocity, and other metrics that help the team improve.
- Facilitates Sprint Planning, the Daily Scrum, and the Sprint Retrospective.
- Facilitates the Sprint Review with the Product Owner.
- Manages risks, issues, and dependencies for the team.
- Gauges the health and well-being of the teams, ensuring they are following a sustainable pace.
- Builds a trusting environment where problems can be raised without blame with emphasis on healing and problem solving.
- Liaises with architecture and operations when there are dependencies to systems and infrastructure.
- Acts as a shepherd for the team, moving them down the general path instead of telling them what to do.
- Coaches and trains the team on the agile behaviors and Scrum events, including how to self-organize.
Anyone who is desires to be a Scrum Master should take the Certified Scrum Master (CSM) training. This will help them understand their role, events, rules, and artifacts and gain understanding of the servant leader role they will be playing. The CSM training does not make you a seasoned and experienced Scrum Master. It is the first step in a lifetime of truly understanding what the role of the Scrum Master is really about.
Who Best Plays the Scrum Master Role
As teams consider adopting Agile, one of the most important decisions is who can make a good Scrum Master. Because the Scrum Master is the promoter of Agile values and principles, it is critical that this role be filled with someone who is dedicated to implementing the Agile mindset.
So who makes the best Scrum Master? The short answer is that anyone can become a Scrum Master if they believe in the Agile values and principles and can act as a servant leader. Some will ask if there is a traditional role that plays the Scrum Master the best. Here are some options.
Project Manager as Scrum Master
The traditional role that seems the obvious choice to play a Scrum Master is that of project manager. On the positive side, a project manager has experience in being part of a team and so may already have a trusting relationship with the team. Some project managers have gained facilitative skills to lead work in a nondirective yet influential manner. Many already have the skills and the insight into an organization to appropriately remove roadblocks. On the negative side, some project managers had success using command-and-control attributes and the more traditional project management practices, which will not work well in an Agile environment. It can also be hard for some project managers to eliminate their traditional mindset of detailed project planning and control.
Functional Manager as Scrum Master
Quite possibly the most problematic role to play the Scrum Master is a functional manager ( aka line manager or technical manager). Anyone who has played a role in which they have successfully directed people must make a major concerted effort to remove their command-and-control behavior. On the positive side, they may have skills and 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, they may have issues with the team trusting them as a peer because they are used to being judged by managers. A functional manager may have been successfully using command-and-control attributes. These will not work well in an Agile environment. They must strive to remove their directive attributes and instead build facilitative skills.
Technical Lead as Scrum Master
One of the better traditional roles to play the Scrum Master is a technical lead (aka QA lead or development lead). By lead, I do not mean a manager who has direct reports, but someone who is considered a lead by his or her peers and has no interest in directing people. Such people have a balance of leadership skills while wanting to get the work done. On the positive side, they have technical experience in the product and their specific field (development, QA, technical writing, etc.) and so can appropriately aid the work by providing meaningful insight without direction or coercion. They have experience at being part of the team, and thus may already have a trusting relationship with their peers. On the negative side, they may have to build their facilitative skills to lead work in a nondirective yet influential manner. Also, they may not yet have the skills or insight into an organization to appropriately remove externally facing roadblocks.
The best answer to the question of what role best plays the Scrum Master is not a role at all. Instead, it is which person best exemplifies the Agile values and principles, possesses the attributes of servant leadership, has a good grasp of navigating his or her organization, and can help remove roadblocks.
Product Owner
The Product Owner (PO) represents the voice of the customer. He or she is the customer liaison and is responsible for understanding what is considered valuable from the multiple customers who may need or are using a product. The PO must straddle the responsibilities of being continuously available to customers to identify value while being continuously available to the Development Team to communicate customer value to them. Most POs I have worked with find this both challenging and quite rewarding when implemented well.
The PO is the owner of the Product Backlog, where value is initially expressed (e.g., as requirements). A PO must digest the various customer needs and stakeholder demands and establish a meaningful list of user stories into the backlog for the development team to work from. A key skill that the PO needs to acquire is the ability to decompose large requirements or epics into stories that can be built within the time-boxed period of the sprint.
The most challenging role of the PO is to rank the Product Backlog items according to value. As depicted in Figure 12-2, a PO talks with multiple existing customers, potential customers, sales, marketing, management, and more, all of whom are attempting to get their need highest in the ranking. A PO is beholden to many but is the final arbiter, and everyone must respect the PO decisions. This can be quite challenging in cultures where a more hierarchical and command-and-control approach rules. The PO also does the following:
- Parses customer problems and needs into meaningful requirements that highlight business value.
- Grooms, prioritizes, and ranks the Product Backlog items.
- Removes roadblocks and rules on issues where disagreements arise.
- Coordinates the Sprint Review, invites customers and stakeholders, solicits customer feedback, and updates the backlog with feedback provided by the customers.
- Attends Sprint Planning and provides details, answers, and clarification to the Development Team.
- Adapts requirements when customer needs and market conditions change, to ensure that what is built and delivered aligns with customer needs.
- Works with sales and marketing to get their requirements into the backlog.
Figure 12-2. Product Owner beholden to many
Who Best Plays the Product Owner Role?
The PO role is very important to a successfully running Agile team. In fact, when a team considers adopting Agile, deciding who will be the PO is critical to gaining the benefits of Agile, owing to the importance of the customer value and validation activities to ensuring that the team is building something the customer actually wants. So the question arises: is there a traditional role that plays the PO the best?
Business Analyst as Product Owner
What does a traditional business analyst (BA) do? A BA is someone who analyzes business needs, works with stakeholders to understand their needs, and recommends solutions that meet these needs. At a deeper level, a BA focuses on eliciting, documenting, and managing requirements. The BA act as a liaison between business and technical groups. It is because of the work a BA already does and in particular the focus on requirements and the liaison role between the business and technical groups that this role a good candidate to be the Product Owner. However, a traditional BA may not have the experience in working in an agile manner. He or she may not have experienced the continuous requirements elicitation process (per the sprint cadence) and Sprint Reviews to gain feedback, so skills and experience in these areas would have to be earned. The BA would need training in the agile process used and the PO role.
Product Manager as Product Owner
What does a traditional product manager do? A product manager examines the market, the competition, and customer needs and then establishes the product direction that is considered valuable to the market and the customers. A good product manager focuses on the financial considerations including the return on investment. In addition, the product manager is involved in the requirements gathering and management process. Because of their work focused on what is valuable to the customer, a product manager makes a good candidate for the PO role. However, a traditional product manager may have little experience in the Agile space. Skills and experience in the continuous requirements elicitation process and Sprint Review areas may have to be built. A product manager may need training in the PO role and agile process used.
Project Manager as Product Owner
What does a traditional project manager do? A project manager is responsible for planning and managing a project from the beginning to closure. He or she focuses on project costs, schedule, and scope. A project manager may also help build the project objectives, help manage the requirements management process, and manage project risks, issues, and dependencies. Because there is little customer involvement within the project manager role, this person may not be a good fit for the PO role. Although there are some abilities a project manager brings that can help in the PO role, there is very little direct customer focus, which is a big part of being the PO.
Those who have played either a traditional BA or product manager effectively may have the best chance of becoming an effective PO. In general, anyone who has played a role in which they work with customers to collect needs and then work with teams to build products or solutions that meet those needs can became an effective PO. I suggest that anyone who is interested in becoming a PO should consider taking training, reading related books and articles, and gaining guidance in this area with an Agile Coach to help them better understand this role and the activities they will need to perform to play this role effectively.
Development Team
The Development Team is a cross-functional group of engineers who build the product functionality. The team should be made up of personnel with different skill sets. This means that the team has the capabilities to build the product without having to rely on others outside of the team. In Scrum, the team size is typically seven, plus or minus two members. If you have too few, you may not have all of the cross-functional skills you need on a team. If the team becomes too large, it becomes too hard to self-organize.
The skills within the Development Team include but are not limited to analysis, design, programming, configuration management, testing, and technical writing. Because this team will be working closely together, the various members must learn to collaborate and cooperate well. To build this collaboration, Development Team members must respect each other’s values and opinions. They do this by breaking user stories into tasks together during Sprint Planning, crafting and honing done criteria, and establishing acceptance criteria together as a team.
Agile Pit Stop The development team must learn how to decompose stories into tasks, which they can build into working software within a sprint. They must respect each other’s values and opinions to become a collaborative self-organizing team.
Members of the Development Team must be committed to the work as well as empowered and self-organized so they can make the best decisions to move forward because they are the closest to the challenges and work to be accomplished. I prefer to call this team the “engineering” team because “Development” Team seems to imply that it is only development-focused, whereas it is really a cross-functional team.
A key skill that Development Team members need to acquire is the ability to decompose stories into tasks. This can be difficult when you are used to working with large requirements and never having to break them down. Team members must also have the ability to build working software within a time-boxed period aligned with a sprint. This can be hard for some team members who have previously had the luxury of having months to build software.
Those with a testing focus must have the ability to help the PO in crafting acceptance criteria. The testers on the team may identify techniques such as test-driven development and initially have the ability to rapidly build test cases for the user stories at the same time that developers are building functionality from the user stories. Often, I see too much focus put on development and too little on user experience, testing, configuration management, and technical writing. There will be a realization that all capabilities in good measure are needed to complete working software within a sprint. Development Team members also do the following:
- Participate in the Daily Scrum, communicating progress and roadblocks.
- Engage in Sprint Planning, gaining clarification, decomposing stories into tasks, and sizing the stories.
- Assist in the Sprint Review, demoing working software on behalf of the Product Owner.
- Contribute to the Sprint Retrospective, identifying what went well and what could have gone better, and committing to actions for improvement.
- Focus on the daily work of converting stories into functional working software.
- Maintain a sustainable pace of work to avoid burnout.
- Apply the quality criteria known as “definition of done” as they build their working software .
It is strongly recommended that each Development Team member has both primary and secondary skills to volunteer on any task that needs to be completed (realizing the true meaning of team). The goal is for the team to think of themselves in a more holistic way to optimize throughput and continually increase their velocity.
Agile Roles beyond Core
Gaining the business benefits of Agile implies that everyone within an organization plays a role. In addition to the core roles, other roles can significantly contribute to success within an agile context.
Customer
The customer is the primary driver of business value. The customer role represents buyers and users of the product. This role represents the business interests who are paying for the product. The customer provides business knowledge, input, and feedback to the Product Owner to help determine priority and rank order of the stories and goal setting for a release.
The most important responsibilities the customer enacts are contributing requirements and attending the Sprint Review to provide the feedback that helps the PO adapt the product toward the direction of value. The customer also contributes in establishing acceptance criteria.
There are several customer target groups. There are current customers and potential customers. Current customers are buyers of your product, must be treated well, and are your highest priority. Within the potential customer group, there are the potential buyers and the browsers. As you identify customer value, knowing what the current customer wants, you will keep them satisfied and loyal. Knowing what potential customers want helps you increase revenue and grow your business. (Learn more about customer target groups in Chapter 17.)
Agile Pit Stop Customers are the drivers defining business value. As you build products, you must consider value from current customers and potential customers.
It may be challenging to get the customer fully engaged on a continuous basis. Most customers have been used to providing requirements up front and not revisiting the product until the user acceptance period at the end. Agile asks for continuous interaction. Finally, if no customer or customer representatives are available, then you are really not performing Agile. How can you adapt to customer needs when customers are not available?
Executives/Senior Management
Executives and senior management have key roles to play if they want to transform the organization to Agile. The key role for the most senior-level executive within the scope is to become the sponsor of the Agile initiative. They must buy in to the Agile values and principles and understand the behavioral changes that are needed for an effective transition to Agile.
They should know that those within their organization will only take Agile seriously based on the executive level of visible support. They should periodically provide public support for Agile. Once a communication plan is formulated, portions can be executed over time to keep employees aware of the progress and accomplishments of the deployment. Further discussion on communication planning and the sponsor role is found in Chapter 11.
Part of the executive or senior management role as sponsor is to get introduced to the Agile values and principles and educated in the business benefits Agile can bring, including more revenue for the company. They should understand the language that Agile brings and be conversant in agile values and principles. Executives should look at their own behavior and align it with the Agile mindset.
A key responsibility is ensuring their staff, middle management, and leads understand that the organization is moving away from command-and-control and toward a self-organizing team model. Executives should act as mentors to their staff as they help management adapt to Agile. It is strongly recommended for executives to bring in Agile Coaches to help teams not only move to Agile but also help their staff shift to the behaviors that exemplify an Agile mindset. Executives may also need to be involved with making adjustments to staff members who cannot make the switch away from command-and-control. This can be hard to do, but if they don’t, then those around them will not take the change seriously.
An executive should learn how to read agile metrics and measures of success. Gaining an understanding of Sprint Burndowns, release burnups, value capture, release frequency, Agile Mindset, Values, and Principles (MVP) Advisor, and other Agile-related metrics can help ensure the organization is moving in the right direction. Further discussion of agile metrics can be found in Chapters 13 and 14.
Executive should also initiate an effort to adapt the employee compensation model toward agile behaviors being sought and away from rewarding command-and-control attributes. To change behavior, they should recognize the behavior they want to change, evaluate the reward system, and adapt it to the behavior that is needed for Agile. Without aligning the reward system to Agile, you will not get to behavior you want.
Agile Pit Stop Remember, if you don’t align the reward system toward agile behaviors, you will only get the behavior you reward, not the behavior you want.
The executive should form an Agile Deployment Team of Agile Coaches who have experience in the scope of the deployment that is needed and Agile Champions within that scope of the organization that is committed to adopting Agile. More information on an Agile Deployment Team follows.
Executives should also be invited to attend the Sprint Reviews of their top products within their organizational scope. They will gain a genuine sense of progress and see actual working functionality of their products.
Middle Management
Middle management are critical to the success of an effective Agile deployment because they are the lynchpin between the executive’s vision for Agile and middle management’s willingness to allow Agile to thrive on a team. If they are engaged and buy into Agile, then the change may succeed. Even when executives and senior management buy in, if middle management does not do likewise, they can block a team’s ability to succeed with Agile.
Middle management is often made up of direct managers of many of those on Agile teams. Many are functional managers who are used to directing and assigning the work to their team members. If they don’t understand their role in the new order or feel threatened by the change, they may become Deceivers or Deniers. Because of this, it is critical that middle managers are educated on Agile at the same time their teams are.
Middle management must learn to gently back away from their functional leadership and act more as servant leaders who trust their teams, help them remove roadblocks, and support the agile practices. Their direct reports are now on Agile teams, so they cannot assign them any work. They may attend the Sprint Review to see the working functionality, which is better than a status report in gaining a sense of progress.
Often middle management have less to do in an Agile world. The good news is that they may consider options such as changing their role to resource management, where they manage more people but do not own an organizational functional area. They may consider a Product Owner role if they have been engaged in collecting requirements and interacting with customers. Although this role should no longer be managerial, a PO helps shape the product by collecting and grooming the requirements.
A big adjustment and learning opportunity for middle management is to help Agile teams become self-organizing. This requires a change in behavior. Middle management must also learn how to establish the concept of bounded authority where teams can make their own decisions, organize, and commit to their own work. It does not mean that teams can do whatever they want. The balance is that managers keep limited responsibilities to provide a vision and support their staff, while allowing teams the ownership of their work.
Agile Pit Stop Management have bounded authority whereby they provide their teams a vision and the ability to be self-organizing, so that communication and trust can thrive.
Management needs to allow the employees to feel that they own the team decision making and can make their own commitments to the work they do at the team level. Management must also be willing to be transparent about what is going on in the organization and be willing to communicate this information to the team.
Agile Project Manager
If a project is made up of more than one Agile team, then there may be a need for an Agile Project Manager (APM). An APM does not play the tradition project manager role within an agile framework. There is little need to create a large project plan because planning occurs every sprint, when a Sprint Backlog is used as the artifact to identify and manage the work.
An APM can help the multiple Agile teams associated with one project in three ways. First, the APM can help manage risks and dependencies across teams and help teams remove roadblocks. This can be in the form of a project Scrum of Scrums. Although there are various forms of Scrum of Scrums, the basic version is a periodic meeting among Scrum Masters and Product Owners to discuss project progress and dependencies across the teams, resolve issues, and mitigate risks. The APM can be used to help provide support for Scrum of Scrum sessions.
Second, an APM can provide project-level reporting that may be required by management. This may involve providing a release burnup from the teams. The challenge an APM may have is that Agile teams work very lean from a reporting perspective, whereas those on the outside of the project will expect more traditional project-reporting detail. The APM must educate those outside of the Agile team toward understanding metrics geared toward Agile.
Third, the APM can be the touch point between the product team and the IT governance within the organization. When an organization has a governance process that approves projects, the APM can help the Scrum Masters and Product Owners pull the necessary vision information together for discussion within the governance sessions.
Agile Coach
The key attributes of an effective Agile Coach include experience in deploying Agile, in organizational change, in playing agile roles on a team, and in working with the business benefits of Agile.
If you don’t know what an agile culture and effectively running agile practices look like, then how do you learn to recognize it? This is one of the key values of having an Agile Coach to help you. A Coach possesses deep agile deployment knowledge to ensure the product teams are implementing Agile effectively. This includes helping teams both mechanically do Agile and behaviorally be Agile.
Another benefit of an Agile Coach is that they help sustain the adoption of Agile practices and mindset. Agile training provides initial knowledge for teams. However, team members can easily revert back to traditional habits. An Agile Coach reinforces agile values and principles and ensures that the team continues both the expected practices and behaviors.
An Agile Coach can provide consistency when multiple teams are adopting Agile at the same time. The Agile Coach also understands both the short-term and long-term pitfalls that can occur when a hierarchical organization is moving to Agile. They can help mitigate the challenges ahead of time.
Non-Agile Pit Stop A coach can help an organization avoid the following situations: “We don’t need to document anything because we are Agile”; “We don’t need any management support because we are self-organized”; and “We can’t tell you what we’re building until the end of the project because we are using Agile.”
A special quality of a great Agile Coach is the ability to enable a team to achieve Agile while being “behind the curtain.” Although the coach will motivate and influence the team, he or she wants the team to feel the ownership of the change to Agile. Other talents that a coach should bring to an Agile team are the ability to be a mentor, a facilitator, teacher, problem solver, conflict navigator, and collaboration conductor. 2
Agile Deployment Team
If Agile is being adopted across all or a large part of an organization, it may make sense to form an Agile Deployment Team to help guide the desired transformation to Agile. This team may also be called the Agile Leadership Team or Agile Transformation Team.
This team should be made up of the sponsor, who is typically the top executive within that organization scope; an Agile Coach, who has experience in enterprise-level deployments; and local Agile Champions within the organizational scope where you are looking to deploy Agile. The Agile Coach may act as the Agile Deployment Team lead. The objective is to include a combination of Agile-experienced, enthusiastic, and committed folks to help guide the organization and product teams toward Agile and remove roadblocks.
When you find yourself in the situation where there are some in your company wanting to adopt Agile, or if it is already happening in an ad hoc manner, an Agile Deployment Team can help lead the organizational change. Michael Spayd recommends that an “effective change team” be established. 3 The combination of Agile Coaches with local Agile leadership can provide the framework for Agile adoption but still allows for adaptability and decision points so teams feel ownership of their working process.
What are some of the benefits of the Agile Deployment Team? This team can help you establish and manage the following:
- Agile deployment roadmap: design activities to help a product team deploy Agile based on the Ready, Implement, Coach, and Hone (RICH) Deployment Model (discussed in Chapter 7) with emphasis on readiness.
- Agile framework and practices: collaboratively establish an adaptable set of agile methods and practices with the rest of the organization.
- Agile training: establish a common set of Agile training aimed at various levels of the organization, which can reduce the cost of using multiple vendors.
- Agile communities: establish an enterprise agile website with links to resources and Agile communities.
- Agile coaching: provide coaching to product teams across the enterprise that need it most. Coaching can significantly increase Agile adoption success and ensure teams do not regress into traditional habits.
- Agile measure of success: establish a common set of agile success measures to see what progress is being made in the Agile adoption within the company.
- Agile challenges point of contact (PoC): establish a PoC to manage internal challenges via the website, email, and Agile FAQ allowing for mitigation and awareness.
- Agile vendor liaison PoC: use a PoC for managing relationships with the Agile vendors to ensure the organization gains leverage from negotiations for volume discounts of Agile-related materials and tools.
Finally, when a team is ready to go Agile, it can be comforting to know there is ready support for their deployment. Conversely, it is problematic when the employees are seeing wide variations of “agile” being deployed, with little support surrounding it. It can be a benefit to have an Agile Deployment Team with Agile Coaches and local Agile Champions available to help you navigate to a successful adoption of Agile.
More Roles
Within an enterprise perspective, peripheral roles like sales and marketing, finance, and human resources should be brought into the agile fold. Although they do not need to work in an agile manner, they should embrace the same concepts of leadership, self-organizing teams, collaboration, and eliminating waste.
Sales and marketing are actively involved with bringing a product to market. They can work with the Product Owner by contributing requirements and gaining clarification to ensure you are building something the customer needs. They need to understand that the Product Backlog and prioritization are owned the Product Owner. Also, they need to learn that requirements should be funneled to the Product Owner and avoid making commitments without the Product Owner’s agreement. Those in sales and marketing of should consider attending the Sprint Review to gain an understanding of what the new functionality does as well as the progress being made.
Within a company going Agile, the finance organization must enable the level of agility and flexibility that is asked from the people and the agile processes. Finance should be flexible in understanding that while they can still manage to cost, the scope is the important variable for delivering customer value.
If performance objectives are part of the organization’s processes, then it is important for HR to establish a performance review process that supports team goals. This helps support the principle of self-organizing teams. You will learn more about adapting performance reviews for Agile teams in Chapter 23.
Product Team and Organizational Restructuring
It is best to apply Agile at the product level. The effort to move a team to Agile may not be cost-effective on a single project because a project typically has a short life and once it is done, the practices and disciplines gained may be lost. However, if you make the commitment of moving to Agile at a product level, then each project can get the benefit of Agile and subsequent projects can become more effective at using Agile over time. It takes time to fully grasp the concepts of Agile and apply them effectively. When a team gets a chance to learn Agile together and then hone it over time, their productivity and accuracy in sizing improves, particularly as retrospectives are implemented and the resulting improvement ideas are put into action.
Bringing the Agile mindset to organization hierarchy often requires a restructuring of the organization toward a flatter organization. The effect on a traditional organization is twofold. First, there is a reorganization to Agile teams. Agile motivates a move from functional groups into Agile teams as illustrated in Figure 5-3. For example, Scrum Teams are designed to remove hierarchy and gain collective commitment, leading to flatter organizations.
Second, because of the agile principle of self-organizing teams, there tends to be less of a need for management who typically direct the team. The move to Agile teams involves moving away from a single point of leadership, often a functional manager, to a flat team model in which everyone is a leader when it is appropriate and no single person tells others what to do. The group that is affected the most is middle management. But as already mentioned, there are options for middle managers who may be affected depending on the skills and experience they may have.
Although some of the structural change is driven by self-organizing teams, other change is driven by who prioritizes the work. In an agile framework, the person who prioritizes the work moves from functional management role to the Product Owner, who is the key contributor in making Agile successful. The Product Owner contributes insight from the marketplace, customers, product roadmap, financial implications, current negotiations, and other details. This broader view and additional information ensures that the product teams build the right product.
What Does Your Team Look Like?
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 adapting roles and responsibilities toward Agile helps in making this shift. If an organization is serious, then the top executive within the organizational scope should become the sponsor. Having an Agile Coach and Agile Deployment Team can help you adapt product teams and involve management. The question to you is who will become the Product Owner, who will be trained to become the Scrum Masters, and how will you balance your teams to ensure they have a healthy balance of cross-functional skills? Understanding agile roles and responsibilities and the change in behavior that it brings will move you in the right direction.
1 Larry C. Spears and Michele Lawrence (eds.). Practicing Servant-Leadership: Succeeding through Trust, Bravery, and Forgiveness. Jossey-Bass, 2004.
2 Lyssa Adkins. Coaching Agile Teams. Addison-Wesley Professional, 2010.
3 Michael Spayd, “Evolving Agile in the Enterprise: Implementing XP on a Grand Scale,” Agile Development Conference, 2003.