The Forgotten Agile Role – the Customer

Many Agile implementations tend to focus on the roles inside an organization – the Scrum Master, Product Owner, Business Owner, Agile Team, Development Team, etc.  These are certainly important roles in identifying and creating a valuable product or service.  However, what has happened to the Customer role?  I contend the Customer is the most important role in the Agile world.  Does it seem to be missing from many of the discussions?

While not always obvious, the Customer role should be front-and-center in all Agile methods and when working in an Agile context.  You must embrace them as your business partner with the goal of building strong customer relationships and gathering their valuable feedback.  Within an Agile enterprise, while customers should be invited to Sprint Reviews or demonstrations and provide feedback, they should really be asked to provide feedback all along the product development journey from identification of an idea to delivery of customer value.

Let's remind ourselves of the importance of the customer.  A customer is someone who has a choice on what to buy and where to buy it. By purchasing your product, a customer pays you with money to help your company stay in business.  For these factors, engaging the customer is of utmost importance.  Customers are external to the company and can provide the initial ideas and feedback to validate the ideas into working products.  Or if your customer is internal, are you treating them as part of your team and are you collecting their feedback regularly?

As you look across your Agile context, are customers one of your major Agile roles within your organization?  Are they front and center?  Are customers an integral part of your Agile practice?  Are you collecting their valuable feedback regularly?  If not, it may be time to do so.  

What Colors are on your Agile Career Palette?

For those that advocate for Agile within their organization or help organizations adopt Agile, often times your career path is opportunistic based on what opportunities appear before you. This helps the Agile advocate at one level gain experience but can prevent the more methodical thinking of where you want your career to go.  At some point, isn’t it good to be in the driver’s seat of your own growth? 

For example, if the Agile advocate (e.g., Agile Coach) only has team level coaching opportunities, they will never gain the experience and skills needed to coach at a management or organization level.  If the Agile advocate only has Scrum based opportunities, they will not gain the experience of working with Kanban, Lean Development, or scaled frameworks.  Instead a methodical aspect to their career must be incorporated.  This is where the Agile Career Palette can be useful.  

The Agile Career Palette provides a colorful approach to better understand what Agile capabilities and experience an Agile advocate currently has and then provides an incremental approach to explore, learn, experience opportunities in the future based on gaps and interest. An Agile Career Palette provides the Agile advocate with what is artistically known as the colors they bring to their work.

These colors represent several key facets (IMHO) of what it means to be an Agile advocate of any type.  The key facets include the agile experience acquired, levels coached, agile roles played, fields where you apply agile, agile processes implemented, business and technical practices applied, agile training delivered, agile change management and soft skills applied, agile certifications acquired, and giving back to the agile community in the form of articles and seminars.  While there may be other areas of focus, I have found that these tend to cover most of the important Agile areas. 

Those who benefit most from the Agile Coaching Palette are the Agile advocates who play a role as Agile Coach, Agile Champion, Agile Sponsor, Team level advocates (e.g., ScrumMasters, Product Owner, etc), and Agile leaders of any kind who are looking to advance in their Agile journey. The Palette approach reminds those on their agile journey of the many areas they may desire to experience, learn, and play along the way.

Based on real experience, the Agile Career Palette is a methodical and incremental approach in helping you consider what you may want to do next, depending on where you’ve been and more importantly where you would like to go.  The “where you would like to go” is meant to be applied in an incremental manner.  Usually about 6 months gives you enough time to make progress but short enough to reflect on where you’ve been and where they want to go next.  

If you are an Agile advocate, consider trying an Agile Career Palette approach to help you better shape and color your future.  First start by establishing your current state of the key facets mentioned about.  Then, commit to an increment of improvement based on your interests or gaps.  It will help you be more laser-focused on building your future!

Agile Success Measures to answer the question "How do I know when I'm Agile"?

I often get asked, “How do I know when my company is Agile? ” While I have various answers, it led me to construct an Agile measurement framework that helps you guide your Agile transformation toward success.  

    

I start by asking, “What outcomes an organization would like to see when they go Agile?”  Agile asks that you consider your outcome instead of output as a measure of success.  I would suggest that being Agile should only occur if your outcome is some type of better business results.  In other words, Agile shouldn't be the outcome of being Agile.  The good news is that organizations are looking for better business results.  This could be in the form of shorter lead times, reduced whip, or an increase in revenue.  Sometimes it can be all three. It is important to understand that outcomes are lagging metrics.   Now that we have highlighted the importance of outcomes, let’s add two ingredients to give us perspective and help us build the framework.

For the first ingredient, I will take a page from the book Being Agile in Chapter 2 “Crossing the Agile Chasm”.  When we discuss Agile adoption, we are talking about a change to the organizational culture.  This is because adopting Agile is more than learning skills or understanding a procedure.  It is about adopting a set of values and principles that require change in people’s behavior and the culture of an organization.  This mindset and culture change involves the most time for an organization to adjust.  According to Paul S. Adler and Aaron Shenhar, “Adapting your Technological Base: The Organizational Challenge”, a culture change is measured in years.   

For the second ingredient, I will take a page out of the article Agile Lagging to Leading Metric Path.  This article highlights that an Agile lagging to leading metric path recommends that for every outcome (aka, lagging indicator), you supplement it with corresponding leading indicators that provide you with visibility during an Agile transformation.  Capturing the leading indicators helps you steer toward a successful Agile transformation.  The leading indicators are effectively feedback loops that help you understand if you are leading toward your outcome.

Now that we have the two key ingredients, the goal is constructing an Agile lagging to leading metric path that recognizes that change takes time and provides us with feedback to adapt toward a more successful Agile transformation.   Lets start with the outcome.  For my Agile transformation, the key outcome is that we are seeing better business results for our products, translated into increased revenue for our business.  From this, I need to consider what leading indicators help guide me toward better business results.   From my Agile transformation experience, I will suggest that the two broad leading indicators are adopting Agile mechanics and embracing the Agile mindset.   This is illustrated within this lagging to leading framework.

This illustrates several conventions.  The first is that from an Agile perspective, in order to get to better business results, we must educate folks on the Agile mechanics and Agile mindset.  As we do this, we gain feedback so that we can adapt the Agile journey to ensure more success in our Agile transformation and achieve the better business results we are looking for.  The second is that applying Agile mechanics tends to be easier and takes less time since it involves learning skills and understanding procedures.  Adopting an Agile mindset takes more time since it requires changes in people’s behavior and the adaption of the organizational culture.  The end result (outcome or lagging metric) is that we hope to see better business results by first implementing Agile mechanics and adapting to an Agile mindset. 

The last task at hand is to create measures within each indicator to gauge progress.  For the Agile mechanics, capturing a training metric is helpful.  In order for people to mechanically adopt Agile, they need some form of education in their role (e.g., Scrum Master, Product Owner, etc.) and education in the process (e.g., Scrum, Kanban, etc.).  Then you can assess if the mechanics are being applied.  If education doesn’t occur or the mechanics aren’t being followed, this can impact your success.

For the Agile mindset indicator, you need to gauge if there is a shift in ways of working. You can assess if the Scrum Master is exemplifying servant leadership, you can gauge if management are allowing for self-organization, you can assess if the team believes in the Agile values and principles, and you can determine if the product owner and organization are adapting to customer needs based on actual feedback and to delivering early and often.  You should also gauge if the team is incrementally improving the mechanics, meaning are they applying the retrospective for the team to improve their ways of working. If the behaviors behind the Agile mindset are not occurring, how do you expect to be Agile?   This is why they are all leading indicators to getting better business results. 

I hope this article may provide you with a framework to help you more effectively gauge “How do we know when we are Agile?”.  It highlights that if you are looking for the business benefits that Agile can bring, then establishing an Agile measurement framework based on lagging to leading indicators can help guide you achieve a more successful Agile transformation. It is then up to you to identify what is your outcome, then your leading indicators to know if you are heading in the right direction.  Many end their journey with adopting Agile mechanics without adapting their culture toward an Agile mindset.  Stopping at the mechanics is why many organizations fail at Agile.  Hopefully this framework can help you see the bigger picture toward Agile success and the business benefits it can bring.  

The Role of Middle Management in an Agile World

When discussing Agile roles, there is much written about the ScrumMaster, Product Owner, Development Team, and Customer.  But there is less written about what the Middle Manager should do in an Agile World.   Note, when I talk about Middle Manager, I am talking about the Line Manager, Functional Manager, Manager, and Director level manager. 

I recently discussed the middle management roles within an Agile context to several different middle managers.  They each had an interesting perspective on what it was like when their teams became Agile. Here are two excepts:  

• The Functional Manager who was also the team's Line Manager noted that they spent much less time on directing the team on what to work on since the work was now coming out of the Product Backlog.  I told him that yes this is big adjustment.  He needed to focus on ensuring that his team members had the right skills, team impediments were removed, the Agile principles were understood, and the team were given the education they needed to become a fully cross-functional team.
• In talking to a Director who now has 3 self-organizing teams, she was telling me that she was having a hard time knowing what to do since she felt she had to get more hands-on.  She needed to help educate the team members around their new roles, and then allowing the teams to self-organize around the work was the right thing to do.  I told her by backing off, she could better provide more strategy level guidance to connect the organization’s strategies to the team or product visions.  She commented that this was very different from the more traditional management role she had been used too.  

Ultimately, it is important to understand that middle management are critical to the success of an effective Agile deployment.  They are the lynchpin between the executive’s vision for Agile and the team's ability to apply Agile as Middle management's willingness to allow Agile can help make it flourish or fail on a team. If they are engaged and buy into Agile, then the change may succeed. Even when executives buy in, if middle management does not do likewise, they can block a team's ability to succeed with Agile.    

If middle management don’t understand their role in the new order or feel threatened by the change, they may become Deceivers or Deniers and block the success toward Agile. Because of this, it is critical that middle managers are educated on Agile at the same time their teams are.

Middle management must adapt their role and learn to gently back away from their functional leadership, act more as a servant leader who trusts their teams, helps them remove roadblocks, and supports the agile principles and practices. They may attend the Sprint Review to see progress of the working functionality and the Daily Stand-up to gain a sense of team progress.   Middle management must also learn how to establish the concept of bounded authority where teams can make their own decisions and commit to their own work. The balance is that managers keep limited responsibilities to provide a vision and support their staff, while allowing teams ownership of their work.  Finally, middle management must be willing to be transparent about what is going on in the organization and be willing to communicate this information to the team. 

Other Roles that may suit Middle Management

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 Manager, 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 (i.e., not direct reports), a PO helps shape the product by collecting and grooming the requirements and collaborating with the team.   They may also move to another Functional Manager role where there is still a need for this role.  And some will remain their current middle management leadership roles.  If they continue to want to do the more traditional middle management roles, they may consider looking for companies that continue to look for the more traditional roles.  

How Middle Management can evaluate themselves in an Agile World

Here are a few questions  middle managers can ask themselves to see how aligned they are in managing teams in an Agile World.  These questions are based on material from "The Manager's Role in Agile" by Michael Spayd and Lyssa Adkins.  

• Are you allowing for self-organizing teams while still providing servant leadership? 
• Are you removing command and control elements while providing bounded authority?
• Are you supporting the Agile values and principles starting with marshaling a culture toward delivering value?
• Do you remove the language of false certainty, big-up-front planning and requirements, and big batches?
• Do you remove the significant roadblocks that hinder an agile team’s progress?
• Do your teams perceive you as a coach and leader more than as a manager?
• Are you helping the team with supporting their people and equipment needs?
• Are you adapting the performance objectives to support team accomplishments to ensure they are delivering the highest value?
• Do you help the teams when they have external team dependencies in order to get their work done?
• Are you fostering a learning organization?  Do you provide teams the time to get educated (training, coaching, etc.)? 

Agile Requirements - A Promise for a Collaborative Conversation

Most topics surrounding the establishment of requirements revolve around how to write them (including my recent article entitled User Story Writing Starter Kit).  However, not enough is written about the key ingredient of a robust requirements process.  Some will say that when you document the requirement, you are done with the requirements process.  I content, that this is just the beginning.  The real value of a requirements process is not just writing it down, it is to begin the collaborative discussion. 

In an Agile world writing down a requirement begins the discussion between the business and engineering side.  Whether this is between the Product Owner and Development team or the Customer and Programmer/Tester, the importance is that a shared understanding begins.  This discussion initiates the learning amongst the business and engineering side where the engineering side more thoroughly understands the business value of the requirement and the business side better understands the technical options of the requirement.

It goes much deeper than this.  In the old world, there is a typically only a one or few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘thrown over the wall’ to development.

I would suggest a much more robust approach starts with writing down the requirement and then continues with the fleshing-out of the requirement in a collaborative manner with the whole team.  This utilizes the brainpower of the whole team whereby each member may contribute to the understanding of the requirement and how to best provide a working solution for that requirement. 

From a process perspective, the discussion first begins when the requirement gets introduced by the Product Owner to the Development team.  As an example, this could be in a grooming, refinement, agile release planning, or sprint planning (depending on your approach) where the highest priority requirements are discussed and fleshed-out with the team’s input.  During this session, the collaborative discussion may focus on the following: 

• Understanding why it is a high priority
• Validating/updating the User Story is in Canonical Form (or defined form)
• Understanding the business value and customer perspective
• Describing acceptance criteria
• Considering high-level technical details
• Identifying unknowns and risks (each should have an action to investigate and mitigate)
• Identifying what is out of scope
• Identifying dependencies
• Decomposing epic to user stories or each user story to tasks
• Providing high-level sizing (e.g., t-shirt sizing, story points, etc.)

As the collaborative discussion ensues (usually in a time-boxed manner), the requirement gains more clarity and robustness, where there is a team understanding of the work.  As details are discussed, the Scrum Master, Product Owner, or anyone on the team, captures the details within the requirement.  At some point, the Product Owner and team will decide that it is ready to go into the sprint or work queue.  There is no ‘throw it over the wall’ to folks who have little understanding or context of the requirements.  Instead, when it is time to build, the developer and tester are fully aware of the requirement since they have collaboratively provided input into it. 

Whether you work in a more traditional world or an Agile world, consider adapting to a more collaborative requirements discussion approach.  Gaining the brainpower of the team and moving to a pattern of learning can achieve a much better understanding of the customer need and ultimately a better solution for the customer.

A great Agile book - Being Agile: Your Roadmap to a Successful Adoption of Agile

Being Agile is your roadmap to successfully transforming to an Agile culture. In this unique book, veteran Agile Coach Mario Moreira advises new and current adopters how to implement a robust Agile framework that emphasizes Agile values and principles over the mechanical elements. This book focuses on the business benefit of implementing Agile which focuses on delivering customer value and having a positive impact on revenue. 

This book begins by explaining that in order to truly cross the Agile chasm, there must be a transformation to the Agile culture that focuses on delivering customer value.  Mario shows maturing early adopters how to bridge the chasm between going through the motions of “doing Agile” and genuinely “being Agile.” 

It then delves into the business benefits of Agile and the often missing discussion that Agile supplements your strategy to help your business succeed.  The book highlights the important objectives of customer and employees matter, another area that often is underserved.  It briefly discussions some of the methodologies (including Scrum, Kanban, DSDM, Lean, VFQ, and XP), and the roles a team and organization can play within an Agile context. 

After a high-level synopsis of Agile, Mario reminds us that Agile is nothing more and nothing less than a set of values and principles.  This book delves deeply into a focus on the Agile values and principles.  This book dissects each value and principle that conveys whether they are really exhibited within a culture.  These values and principles must be observed, believed, and translated into actions as an important to precipitate a cultural shift. The book emphasizes the importance of keeping the values and principles always in mind.

The author then plunges into the nitty-gritty of the deploying Agile in a manner that will better achieve an Agile transformation.  He does this by introducing the reader to the Ready, Implement, Coach, and Hone (RICH) Deployment model.  The rubric of readiness engages and begins conditioning the mind toward the Agile mindset as well as focusing on the areas that need to be considered as you are embarking on your Agile journey.  He asks you to consider such factors as:

·         Evaluating team candidates for skills, behavior, and willingness 

·         Assessing Stakeholder buy-in and engagement

·         Determining Suitability for applying Agile

·         Identifying measures to see if you are Agile and if you are deriving the business benefits

·         Establishing a customer validation vision to engage in the critical customer feedback

·         Implementing Agile roles and identifying those best for these roles

·         Establishing an adaptable and scalable Agile framework

·         Determining your User story writing and grooming approach

·         Understanding story points for sizing and establishing a relative sizing framework

·         Establishing Educational needs and building an Agile community

·         Constructing Done criteria and how it helps with quality

Implement focuses on the timely application of agile elements within a team or organization while still maintaining emphasis on the Agile values and principles. Coach focuses on on-boarding teams, coaching teams and management through initial implementation, grooming in-house talent, ensuring Agile values and principles are a focus, while acting as a navigator on the path to Agility. Hone emphasizes the inspect-and-adapt model where periodically the current state is reflected upon and opportunities for improvement identified and acted upon.

This book is geared toward Agile Coaches, Scrum Masters, Product Owners, Team members, product managers, project managers, middle, senior, and executive management in software engineering and development divisions and enterprises.  Learning opportunities include:

·         Comprehending Agile values and principles with an in-depth discussion on each principle and how they may be exemplified within an Agile culture.

·         Advocating a framework in which values, customer engagement, employee engagement, and an Agile framework can lead to an increase in sales and productivity, incorporated in the Agile Value to Incentive Differentiator (AVID) framework.

·         Presenting a methodical yet adaptable approach toward Agile transformation, encapsulated in a Ready–Implement–Coach–Hone (RICH) deployment model that can help establish an adaptable roadmap toward your Agile destination.   

·         Introducing the importance of an Agile Customer Validation Vision that emphasizes a disciplined approach to engaging customers and gaining their valuable customer feedback

·         Providing a mechanism for evaluating your level of alignment to the Agile values and principles, encapsulated in the Agile Mindset Values and Principles (Agile MVP) Advisor.

·         Promoting a special focus on value-added work (VAW) that features customer work as valuable and an accompanying value capture metric.

·         Introducing Gamification concepts to engage and motivate employees toward Agile behaviors with the goal of achieving an Agile transformation

·         Advocating a change in your IT governance toward collaborative governance and performance review process places a focus on team rewards. 

This book ends with three case studies—stories of a smaller colocated project, a medium distributed project, and a large distributed team—to help you understand how the readiness activities, deployment approach, and commitment to Agile lead to different results. This book can help you focus on truly “being Agile” and gain the business benefits of doing so.  What will your case study look like?  Let this material in Being Agile help you achieve a successful one.

What happens in the Retrospective stays in the Retrospective!

The Sprint Retrospective is the last event in Scrum occurring at the end of the sprint.  It is a private and safe session for Scrum team members only and facilitated by the Scrum Master. It is used to identify what went well, what did not go so well, and what can be improved.*  It is important to discuss what went well so that you can celebrate successes and when the team feels certain things are going well. 

A sprint retrospective promotes continuous team improvement.  The areas that did not go so well are rated by the team as to which were the most problematic.   The team takes the top 2 or 3 of these problematic areas and identifies the root cause.  Root cause analysis ensures that the real challenge is uncovered so the team crafts a solution that will resolve the problem.  An improvement action is established for each problematic area. Then the team commits to a couple of these improvement actions to be worked on in the next sprint. 

The retrospective is an opportunity for the Scrum Team to reflect on the past sprint’s activities including team dynamics, processes, tools, and culture.  It supports the Agile principle of self-organizing teams.  In order to really get to the nitty-gritty of the problem areas, sometimes “dirty laundry” needs to be discussed. This includes taking a hard look at the problems.  

In order for the team to feel comfortable in airing problems, the team needs to feel that they can trust each other.  Team members must believe they can discuss problems knowing that anything said will stay in the room.  If what is discussed in the retrospective gets communicated outside of the room, folks on the team will be less likely to raise and discuss problems.  And discussing and resolving problems is what the retrospective is all about.  This is why it is important to discourage outsiders, particularly any managers of the team members from attending these sessions.  When outsiders attend, you often see far fewer real problems get raised.  Outsiders may not understand the context of why a team made a decision or did something a certain way which can lead to inappropriate judgments.

The retrospective only has value when the team discusses problems in a sincere manner, has a safe environment to discuss problems, and provides a strong commitment to resolving the problems to the benefit of the whole team.  So keep all of this in mind when you hold a Sprint Retrospective and remember, what happens in a retrospective stays in a retrospective!

* An alternative approach is to discuss what we should stop doing, continue doing, and start doing.  

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.