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.