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.    

When the term Scrum moves into Politics and Media

While it is commonplace to see the term “scrum” in either Agile circles or when discussing the sport of Rugby, I have recently noticed that the term scrum is being used in political and media circles more and more (see three recent news articles below).  While I suspect that the usage of scrum is really coming from those familiar with Rugby, I wonder if there are those in the media or politics that have an affinity with those who work in Agile and Scrum related circles?  What do you think?

• Senate in last-minute scrum for deal - http://bostonglobe.com/news/politics/2012/12/30/senate-leaders-scramble-find-formula-avoid-fiscal-crisis/tCAbkkZhesZD5cq5vdN7BJ/story.html  - Dec 30
•  Judges scrum over 'double-dipping' for pension  - http://news.cincinnati.com/article/AB/20121224/NEWS010801/312240014/Judges-scrum-over-double-dipping-pension - Dec 22
• Chinese Media Digest includes the statement, "This media scrum should not develop into a political show" said the article..." - http://www.globaltimes.cn/content/752191.shtml - Dec 25
• Media scrum is now a Wikipedia entry - http://en.wikipedia.org/wiki/Media_scrum 

Scrum

It would be interesting to see if more and more Scrum and Agile related terms become infused into our political, media, and other lexicon.  In any case, I wish you all a very happy and successful New Year!

Cheers to one and all!

The Importance of Language in a move to an Agile Culture (with Polling Results)

In my experience in helping teams transform toward an Agile culture, moving away from the traditional terminology and adapting Agile terminology is very beneficial.  At the same time, I have sensed reluctance in organizations in removing from their traditional language.  I believe the language you use matters a great deal if you are attempting to achieve a certain culture.  A prime example is moving from the language of certainty in a more big-upfront Waterfall culture to discovery and hypothesis driven language in an incremental Agile culture.

If you are trying to change culture, the change in language highlights that something has changed and provides folks with a learning opportunity assuming that there is true meaning behind the language and a commitment to change. It makes everyone pay more attention. If you think about it, when you travel from one culture to another, the language does indeed change.  Using the proper language helps you inform and communicate needs more effectively while a common language provides a bond within our community.

Maybe the key is to use language that is most efficient and effective for the culture you want to get to. If you want to change your culture, you need to ensure that the language is not tripping you up and dragging along its baggage of prior meaning.  When you move from a big-upfront Waterfall to an incremental Agile culture, using the same waterfall language will trip you up.

Why? Because people in the organization still think the definition of the term is stemming from the 'old' culture. Attempting to change culture is hard enough and when you have language from the old culture still around, you can be sure that those people within the org are still interpreting the language using the old world context. This can impact your success to advance your new culture. 

With all of that being said, this is the opinion of one person.  So what of the opinions’ of others?  With that in mind, I embarked on a poll via LinkedIn to gauge other’s thoughts on how important is it to use Agile terminology to get to an Agile culture.  I present you with the following results:

Within a period of a month, there were 83 votes cast along with 26 comments.  The poll results revealed that 65% percent (or close to two-thirds) of the participants felt the use of Agile terminology was either ‘Very Important’ or ‘Important’ for an Agile culture.  Another 12% felt it were neutral.  The remaining 23% felt that the use of Agile terminology was of ‘Little Importance’ or ‘Not important at all’.

In order to more fully understand other opinions, I have included a paraphrasing of some of the comments.  They include: there is a need for specialized vocabulary; there are fundamental differences amongst various practices and methods so terminology should be considered; the terminology contributes to language precision; and the words used should work for the culture.  You can see one of the threads within the “Agile” Linkedin group for specific comments from others.

Some took my examples literally.  I didn’t really mean to imply that the term ‘sprint’ and ‘phase’ are the same, but I have seen teams use those terms interchangeably.  So I do agree that one term is not necessarily better than another but that you should ensure the language you use does not get in the way of learning and advancing within your culture.   Also, I’m not clear that there needs to be a standard “Agile” terminology across the industry.  However, with that said, if you are applying Scrum, you should use Scrum terminology (and the same for XP, Kanban, etc). There is a value of having a common Agile terminology within an organization so that there can be a more effective platform for Agile related discussion across teams.  

Also a few people mentioned that the meaning is more important than terminology.  I do favor this line of thinking because there should be an effective meaning behind all terminology used.  Terminology without meaning is babble.  So yes, it is important, dare I say critical to have a well understood and clear meaning behind all the terminology used in order to gain an effective Agile culture. 

Ultimately if you are truly trying to initiate a culture change, then the language should reflect the change you are looking to make.   In this case, if want to establish an Agile culture, utilize the terminology that provides an appropriate and clear meaning which drags little or no baggage.  This will help you get to the Agile culture you may be seeking.  Cheers!

Note: another article that discusses Agile terminology focusing on the terms 'size' vs 'estimate' may be found at: http://cmforagile.blogspot.com/2012/10/size-matters-using-size-instead-of.html

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

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

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

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

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

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

Agile Problem Finder

I occasionally hear that Agile is the silver bullet and will solve all engineering problems. In some cases, someone in management heard about Agile and figured it could be a quick fix to solve the challenges within their organization. Unfortunately this is far from the truth. While Agile mindset and methods can help you adapt to customer needs and deliver more effective customer value, one key benefit that I find is that Agile shines a bright spotlight on existing problems within an organization or team.

This is where Agile methods such as Scrum, eXtreme Programming (XP), Kanban, Test Driven Development (TDD), and others can be very effective problem-finding tools. While this is not what most people think about when adopting Agile, it is a side benefit. It is important to understand that Agile methods won’t necessarily help you solve the problems that are being uncovered but they really need to be removed to achieve the value delivery and speed you are looking for. 

More often these challenges have been around for quite some time, well before Agile was introduced. In fact, management and team members have known about these issues, risks, and dependencies, but they conveniently get buried under the organizational carpet. In the Agile world, every impediment can impact the value and velocity of Agile.  Once Agile comes along, the spotlight focuses brightly on anything that gets in the way of efficient and effective delivery of customer value. What are some of areas where Agile shines the halogens onto existing problems? In my experience, I have encountered numerous challenges during the deployment Agile. Here are some examples:

• When moving to a 2 week cadence of delivery, the team bumped into organizational processes like approvals and alignment of priorities that slowed the team's ability to delivery on a faster cadence. We talked with these approval groups, shared what is agile and asked if they could work with us on a more regular basis (e.g., bring approval groups in earlier and add a Scrum of Scrums to gain alignment with dependent groups).  
• In setting up Scrum teams, it became clear that there is a lack of QA resources on the project (7 developers to 1 QA engineer). We assessed that our development to QA ratio really needs to be 5 to 3, then replaced some developers with QA engineers. Until we could hire the level of QA engineers needed, we had a few of the developers play the QA role.
• We learned that teams often don't stay together long enough to perform effectively.  Project-based company didn't allow bonding time. When the project ended, the employees are reconstituted to other project teams. We worked to have a long lived team allowing them to go through the stages of forming, storming, norming, and then performing and then stay together. 
• The team lacked trust and psychological safety. There is often a culture where trust is damaged by management actions as teams are not trusted enough to make decisions. Teams don't feel safe enough to bring up vulnerable points to more easily get over team hurdles. We implemented bounded authority so teams own their own decision-making.  
• In running incremental QA processes, it becomes clear that there is a lack of automation and, in fact, very few unit tests were ever written. We then spent some time building unit tests to provide at least 80% test coverage (we built this into our Definition of Done), then began automating the tests.
• In running continuous integration, there was a lack of understanding the branching and merging process. Developers were unaware of the importance of refreshing the private workspace with latest successfully built and approved code and also continued to retain local objects and executables in their private workspaces. An effective Checkout/Checkin process (with refresh and build and promote) was established and workspace education was conducted by the Configuration Management (CM) engineers for the team.
• In working with a legacy team, it became clear upon sizing and building functionality on existing code, that we were continually breaking other parts of the code since there was tremendous technical debt within the code base. It was learned that there was no coding standards since the beginning. We initiated a refactoring strategy with coding standards to help us reduce some of the more problematic code modules.
• In working with Product Owners (aka, Product Managers), it became clear that requirements were poorly written which led to a lot of churn between the Product Owner and the developers/QA engineers. The existing requirements list had requirements at multiple levels and it was hard to discern who the requirement was meant for. I educated the Product Owners and Scrum team members on how to write requirements in a canonical form (persona + action + business value) and the POs rewrote the requirements over time in a priority order.

For some teams that move to Agile, they can get overwhelmed by the problems that are identified by the Agile spotlight. In some cases, prior to deploying Agile, it is worth identifying the existing challenges so folks realize they are not caused by Agile. One way to do this is to understand your full end-to-end "idea to release" process. The key is to add the challenges to your issues list, prioritize them, then address them in priority order. Remember, the Agile spotlight can help you identify some of your problematic areas on the product or in the organization. Take advantage of this but be prepared to address the challenges.  What existing problematic areas have you identified when you were implementing Agile?

Who makes the Best Product Owner?

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

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

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

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

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

Business Analyst as Product Owner?

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

Product Manager as Product Owner?

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

Project Manager as Product Owner?

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

Technical Manager as Product Owner?

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

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

Summary

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

Applying the Agile Canonical Form to write Performance Goals

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

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

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

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

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

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

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

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

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

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