Wednesday, June 29, 2011

Robust Agile Organization - Core Roles and Beyond!

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 Development Team. I prefer to use the term Agile Team (or something similar) since I really want to ensure folks understand that it is not just development or development-centric but includes other key cross-functional roles/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), 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.  Another important role in regards to the Development or Agile Team is the Product Architect.  This role may not be considered full-time because it can support more than one team related to a product or solution.  However, it should be committed to the team(s).  This person ensures that the architectural related decisions are established and discussed with the 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.  Learn more about the PO in the Who makes the Best PO article.

The servant leader for the team is the Scrum Master. The Scrum Master educates the team around the Agile processes and practices, and helps the team apply those practices. The Scrum Master takes the responsibility of a 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, the 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.

If a product or 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 or three of around 7), then there may be a need for an Agile Project Manager (APM).  The APM can manage the dependencies and risks across teams, remove roadblocks, and ensure they work in a concert.  This could be in the form of 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.

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 the product 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.

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.  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 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: