To get to a fully robust Agile organization, it is important for everyone to play a role in Agile. I have found that managing a successful project from an Agile perspective requires three core roles and but must include the many adjunct roles to ensure success.
You start with the Agile Team. This is made up of around 7-12 cross-functional team 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), tech writers, and CM/build personnel. The key is to ensure you have all of the roles you need to build a product on your Agile Scrum team with sufficient skills to get the job done. If you need DB talent, UI talent, or other talent, ensure you include them on your team.
Equally important is the role of Product Owner (PO). 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.
The facilitator or servant leader for the team is the ScrumMaster. The ScrumMaster executes the Agile processes and practices, and ensures the team stays true to the Agile values and principles as articulated in the Agile Manifesto. The ScrumMaster helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, the Daily Stand-ups, Retrospectives, and the Agile Release Planning session.
If a project is made up of more than one Agile Team (e.g., for a project team of twenty you would want to break them into two Agile teams of approximately ten), then there is a need for an Agile Project Manager (APM) to manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert. The APM also handles the interaction with the business governance of the organization.
In addition, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure the product teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily resort back to old traditional habits. The Agile Coach also 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.
Now we come 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 road-blocks, 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.
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).
Then we bring in other peripheral roles like Sales and Marketing, Finance, and HR. While these roles do not need to work in an Agile manner per se, they use the same concepts of 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. If performance objectives are part of the organizations 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.
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
You start with the Agile Team. This is made up of around 7-12 cross-functional team 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), tech writers, and CM/build personnel. The key is to ensure you have all of the roles you need to build a product on your Agile Scrum team with sufficient skills to get the job done. If you need DB talent, UI talent, or other talent, ensure you include them on your team.
Equally important is the role of Product Owner (PO). 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.
The facilitator or servant leader for the team is the ScrumMaster. The ScrumMaster executes the Agile processes and practices, and ensures the team stays true to the Agile values and principles as articulated in the Agile Manifesto. The ScrumMaster helps the Agile Team and Product Owner remove roadblocks. This role also facilitates the Sprint Planning session, the Daily Stand-ups, Retrospectives, and the Agile Release Planning session.
If a project is made up of more than one Agile Team (e.g., for a project team of twenty you would want to break them into two Agile teams of approximately ten), then there is a need for an Agile Project Manager (APM) to manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert. The APM also handles the interaction with the business governance of the organization.
In addition, it is important to have an Agile Coach who possesses deep Agile deployment knowledge to ensure the product teams are implementing Agile effectively. It has been established that training will only provide initial knowledge but team members can easily resort back to old traditional habits. The Agile Coach also 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.
Now we come 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 road-blocks, 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.
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).
Then we bring in other peripheral roles like Sales and Marketing, Finance, and HR. While these roles do not need to work in an Agile manner per se, they use the same concepts of 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. If performance objectives are part of the organizations 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.
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
0 comments:
Post a Comment