Sunday, September 7, 2014

Are you Ready for your Agile Journey?

The common pattern in approaching an Agile deployment is to begin by conducting Agile practices training typically on Scrum or another Agile method.  While this will allow the team to begin mechanically applying Agile practices, it doesn’t address the culture shift that must occur, a culture shift that helps to inform the mind and shape behaviors, a shift toward "being Agile".  I term this approach of focusing on the cultural aspects of Agile as “readiness”. 

Readiness is the beginning of the process of acclimatizing the mind toward Agile values and principles and what they really mean.  It includes making decisions on the elements for your implementation. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic deployment or iterative deployment of certain elements.
This first starts with the premise that Agile is a culture change.  The implication is that Agile is more than a change in procedure or learning a new skill.  A culture change is a transformation in belief and behavior.  It requires a change by more than one person, and instead by a number of people within your organization.  As you can guess, this takes time. 

Over the years, I’ve established what I term the Ready, Implement, Coach, and Hone (RICH) deployment framework specifically focuses on readiness activities that help you prepare not only to adopt the mechanical aspects of agile practices but more importantly, begin a meaningful transformation of behavior toward an Agile mindset. 

Readiness starts the moment someone asks the question, "Is Agile right for me?” The goal is to work through this question, understand the context, and figure out how Agile might be deployed. Readiness can start weeks and even months before you really get serious about moving down the agile path. However, it can also begin when you are ready to commit.

What are some of the “readiness” activities?  These activities can help you shape the implementation according to the context and need of an organization. Readiness provides us with an opportunity to:
  • Assess the current environment and current state of agility
  • Lay the educational groundwork of agile values and principles
  • Understand and adapt to self-organizing teams and away from command and control
  • Shift the focus to delivering customer value and away from an iron triangle mentality
  • Discuss the agile business benefits
  • Gauge the team and management willingness

Readying the mind shouldn’t be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when.  It is important that the teams understand and really embrace the Agile values and principles.  Does senior management believe in the principles?  Do the teams feel they can operate in an Agile manner that aligns with the values and principles?  In fact, I will dare say that if the team acts in the manner that expresses the Agile values and principles and forgoes the mechanical application of agile practices, then there is a greater chance that Agile will survive and thrive within a company.  

Since there is already an overwhelming amount of material that focuses on “how to implement Agile” from a "doing" perspective, may I suggest that a different approach.  Provide the time to prepare the mind toward the Agile mindset and then incorporate this mindset into the culture, education, and decision-making process for your proposed implementation. With that goal in mind, let the readiness games begin!  How ready are you?

To read more about the importance of readiness and additional readiness activities in detail, consider reading the book Being Agile

Sunday, August 17, 2014

Agile Executive Playbook

Imagine that you are an executive of a company (and quite possibly some of you reading this are or have a direct line to an executive).  You’ve heard about this thing called Agile and some of you have experienced it.  However, Agile is still a bit confusing because in many cases, it appears to be occurring only at the development team level.  Some of you believe that Agile is a set of practices and tools and may be surprised to know that it is nothing-more-and-nothing-less than a set of values and principles.   Maybe some of you haven’t seen the connection between applying Agile and gaining the business benefits.  What exactly is your role and responsibilities in moving your company toward Agile?  Here is some guidance on what your responsibilities should be and what may increase your chances in deriving the business benefits of Agile. 

Strategic Shifts           
The key responsibility for the executive within the organizational scope is to become the sponsor of the Agile initiative.  This highlights to the employees that Agile is important and increases the chances of buy-in.  But simply proclaiming “make it so” isn’t sufficient.  The executive must continue to be a key player in this on-going sponsor role.  Here are strategic shifts that are beneficial:
  • Study the Agile values and principles.  Knowing this language helps you become more conversant in Agile and to the teams and organizational players that are involved.  Studying the values and principles will also help you ascertain if you really believe in them (or not). 
  • Move away from the iron triangle of schedule, cost or scope and move to a framework focused on value.  Prioritizing ideas via cost of delay will provide a much better value-driven pipeline of ideas.  These ideas can be decomposed into increments that can then be validated with fast feedback loops. 
  • Measure and adapt the flow of your end-to-end concept to cash pipeline.  There is a tendency to focus on just development, but it is often other parts of the pipeline where ideas wait much too long.  Consider value stream mapping to better understand waiting states and no or low value steps. 
  • Adapt the organization from a hierarchical organization to more of a self-organizing organization.  When employees feel that they have more ownership and decision-making of their work, they will apply much more brainpower and bring passion to their work.
Key Sponsor Activities
Now let’s take a look at the more in-depth activities that you as an executive should consider playing and why.  These are more tactical, but since becoming Agile doesn’t happen overnight, they help keep the engagement and interest along the way. 
  • Treat your Agile initiative as a journey.  Because this does take time, it would benefit you to build an adaptable roadmap.  This may be best handled with a small local team of Agile champions who are committed to adopting Agile and an Agile consultant who has experience in this area.  To get a good understanding of what an Agile roadmap may look like, consider reading the book Being Agile: Your Roadmap to Successful Adoption of Agile.
  • Build a learning culture.  Consider establishing an education vision on how to best educate your organization. Infuse the education with experiments and experience. I suggest starting with the Value, Flow, and Quality materials that provide the reader with great insight into many of these new concepts and ideas, along with case studies and activities.
  • As an executive, examine your own behavior and align it with the Agile mindset of Agile values and principles with a focus of delivering customer value.  Are you speaking the language of Agile and the strategic shift that you are looking to achieve? 
  • Provide funding for the Agile initiative.  Funding should include meeting education needs, bringing in talent (coaches) as needed, and providing tool support. This may occur incrementally or per the budget cycle.  
  • Periodically provide public support for Agile. Establish an Agile communication plan, of which portions can be executed over time to keep employees aware of the progress and accomplishments of the deployment.  This may also include providing 'air cover' to the Agile deployment team and the coaches and champions and mitigating the risks that could prevent a move to Agile.  
  • Consider your staff.  Ask yourself, “are they Agile minded and aligned with the cultural shift that is needed?”  You may 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.
  • Learn how to read agile metrics and measures of success. Gaining an understanding of the lagging to leading metric path, sprint burn-downs, release burn-ups, 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.
  • Adapt the employee compensation model toward agile behaviors being sought and away from rewarding command-and-control attributes. To change behavior, recognize the behavior you 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.
  • Attend the Sprint Reviews of your top products within your organizational scope. This will give you a genuine sense of progress and see actual working functionality of your products.
The intent of this article is to provide highlights of what an executive can do to get the most business benefits from their Agile initiative.  There can be other perspectives and further details.  As an executive (or those who have supported executives), what have you found helpful in your Agile journey?

Sunday, July 6, 2014

The Role of Middle Management in an Agile World

When discussing Agile roles, there is much written about the Scrum Master, Product Owner, Development Team, and Customer.  But there is little 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, understood the Agile principles, and 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.  I told her by backing off, helping 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.  She needed to provide more vision level focus to connect the organization’s strategies to the 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 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 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 servant leaders who trust their teams, help them remove roadblocks, and support 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.
  • 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.)? 

Monday, June 16, 2014

Robust Agile Requirements - Its about the Discussion

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, but 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 better 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 a very few folks who attempt to capture the whole requirement in a documented form.  This forms the basis for a requirement specification that may get ‘throw over the wall’ to development.

I would suggest a much more robust approach starts with writing down the requirement but then the fleshing-out of the requirement occurs 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 event 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
  • Considering technical details
  • Describing acceptance criteria
  • 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 sizing (e.g., story points, etc.)

As the collaborative discussion ensues, the requirement gains more clarity, 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.

Sunday, May 18, 2014

User Story Writing Starter Kit

Prior to Agile coming into existence, I was fortunate to learn how to write requirements by Elemer Magaziner (i.e., business requirements) and Alistair Cockburn (i.e., use cases).   They provided various alternatives to writing clear requirements that were irrespective of methodology.
 
From this I learned that there is a strong benefit to establish what I term as the “requirements language construct”.  This construct helps you consistently document your requirements focusing on key requirements elements. One common requirements language construct in the Agile world is the canonical form. It is important to realize that elements of the canonical form have been around for years.   With that being said, the three basic elements of the canonical form provide a good framework for establishing requirements. 

First I will discuss the user story that is typically expressed within the three-part canonical form.   Then I will introduce the enhancement of a requirements language construct that can adapt the canonical form.  The language construct for a user story in canonical form looks like this:


The persona is the user type who will receive the value.  The action is what the user type desires.  The business value is the benefit to that user type.  Note: you can learn more about personas in the article Personas – Do you really know your Users?   The following are examples of user stories in canonical form:
  • As a learner (persona), I want to set up my profile to include my photo (action), so that my distributed team members know what I look like (business value).
  • As a prospective buyer (persona), I want to search on homes (action) so that I know what properties are available in my price range (business value).

As enhancements to this construct, you may consider adding the system that will be used or interacted with and the receiving entity which identified the expected output from the requirements.  If applying these, the requirements language construct would look something like this:

As a (persona)
I want (action) from (system) to the (receiving entity) 
so that (business value)

The following are examples of user stories with these enhancements.  The first example below takes the second example from above and enhances it with the system and receiving entity.
  • As a prospective buyer (persona), I want to search on homes (action) from MLS (system) to a separate window (receiving entity) so that I know what properties are available in my price range (business value).
  • As a quant analyst (persona), I want a derivatives report (action) from the asset management application (system) in the form of a pdf (receiving entity), so that I can distribute it to my fund managers (business value).

There is no “right” requirements language construct.  It is important to craft one and then experiment with it.  I would suggest starting with the canonical form and work from there. 

Finally, the Product Owner, Business Analyst, Product Manager, and anyone who writes requirements should be trained in writing user stories in whatever form is used to articulate requirements. The Agile Team should be educated in understanding what to look for in a user story and asking questions regarding the elements of the canonical form. You may also want to train stakeholders and customers on how to provide their needs in your requirements language construct for consistency and clarity. 

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 18 of Being Agile

Sunday, April 13, 2014

Agile Lagging to Leading Metric Path

Even in an Agile environment there is a benefit to applying measures to understand progress.  It can be tempting to apply the same iron triangle metrics (based on cost, schedule, and scope) that may have been used in a more traditional mindset to Agile projects and initiatives.  Instead, I suggest removing all of those metrics and start with a clean slate.  On the clean slate, consider your outcomes.

An Agile mindset asks that you consider outcome instead of output as a measure of success.  This means we should first start with understanding our desired outcomes for an initiative or project.  Within a business context of building products, one measure of success an increase in revenue. Having a customer revenue metric helps you understand whether the products being built are increasing revenue upon release. While capturing revenue is a good starting point, it is a “lagging” indicator meaning you don’t recognize the evidence of revenue movement until after the release is in production and has been in the marketplace for a period of time.

To supplement lagging measures, you need corresponding leading measures and indicators that provide you with visibility during development to gauge if you are moving the product into a position of increased revenue. I call this framework the Lagging to Leading Metric Path.  This visibility is important because it provides input for making decisions as you move forward. Making the right decision leads to improved results. As you consider measures, think about how they help you gain visibility and information for decisions in building a product that helps you lead toward an increase in revenue.
For a hopeful increase in customer revenue, what leading metrics can we put in place to ensure we are moving in the right direction?  Let’s say in this case that increased revenue is the hopeful lagging metric based on expected customer sales.  Examples of leading measures or indicators to achieve an outcome of this lagging metric for increased customer revenue include:
  • Customers attending Sprint Review: a leading metric where you capture how many customers are actually attending the sprint review and how much feedback they give. This indicates engagement and interest. 
  • Customer satisfaction from Sprint Review: a leading metric is capturing customer satisfaction from the functionality they viewed within the sprint review.  This indicates levels of satisfaction with the functionality as the product is being built. 
  • Customer satisfaction of product usage: an indicator of the most recent release highlighting a level of satisfaction on the usage of the current product including commentary.   

When applying Agile to product development, the outcome that matters most are often represented by lagging metrics.  Therefore you will need leading indicators to ensure you are moving in the right direction, to provide visibility, and to help you with decision-making.   Within your own context, consider constructing a lagging to leading metric path so that you know you are moving in the right direction during your Agile journey.

                    ------------------------------------------------------------------------
Note: the lagging to leading metric path really isn't specific to Agile and I would suggest applying this to an initiative or project aligning with any mindset, process, method, or practice of delivering value.

To read more about establishing an Agile Lagging to Leading Metric Path and Agile Measures of Success, consider reading Chapter 14 of Being Agile

Sunday, March 23, 2014

Gamification for your Agile Journey

Gamification adapts game concepts to nongaming situations to engage employees and motivate them to improve their performance and achieve a beneficial behavior. It rewards employees for completing performance levels with points, badges, privileges, and sometime monetary incentives. Gamification can be deployed as one of the possible techniques to engage employees as part of your Agile Journey.

The key to gamification is that it must be driven by a clear business goal with a clear outcome.  With the context of Agile, the goal with gamification is to encourage employees to become engaged in Agile, with the outcome of ‘giving back’ to the Agile community.  While your Agile journey may start with training and coaching, you eventually would like employees acting as Agile Champions to give back and start sharing their knowledge and experience within their colleagues.


As an example, let’s say you have established an Agile Education Vision with the goal of getting employees to give back to the Agile community.  As one technique, you decide to use gamification to motivate and engage employees to become Agile Champions and give back to their local community. Let's posit five levels of Agile Champion and the points needed to achieve each level:
  • Steel: 5 points
  • Bronze: 25 points
  • Silver: 50 points
  • Gold: 100 points
  • Platinum: 250 points

By achieving certain levels, a precious medal badge is earned which the employee can add to their signature line and receive an award to support the behavior, both to recognize this achievement. The vision lays out the following education elements, together with the points earned by completing each one:
  • Take the online “Agile Overview” for awareness: 5 points
  • Attend Scrum Master, Product Owner, team, or manager training per your role: 20 points
  • Take a variety of short online courses such as “How to Write User Stories” to build skills: 5 points each 
  • Attend a 45-minute seminar/webinar on various Agile topics such as “Lessons Learned from Sprint Retrospective” to understand process: 5 points each
  • Write an internal blog article and share with the internal Agile community: 25 points
  • Create and present a webinar and share with the internal Agile community: 50 points

Notice that by taking the “Agile Overview,” the participant immediately becomes Steel level. This gets them into the game which may motivate them to keep playing. Also notice that the bigger point items promote giving back to the internal Agile community. This preferential valuation aligns with the goal of giving back while building their Agile knowledge along the way.

If you use gamification, ensure the achievement is real, that it helps the employee with their work, and is aligned with your Agile goals.  Finally, please remember that gamification is just one technique within your Agile toolkit in building an Agile community and having a successful Agile journey. 

PS - to read more about how Gamification can help you in your Agile journey, consider reading Chapter 16 of the new Agile book entitled Being Agile.