Sunday, July 26, 2015

Story Telling with Story Mapping

Once upon a time, a customer had a great buying experience on a website.  The customer loved how from the moment the customer was on the site to the moment they checked out a product, the process was intuitive and easy to use.   The process and design of the customer experience was not by accident.  In fact, it was done very methodically using story mapping. 
What is Story Mapping
Story Mapping is a practice that provides framework for grouping user stories based on how a customer or user would use the system as a whole.   Established by Jeff Patton, it helps the team understand the customer experience by imaging what the customer process might be.  This promotes the team to think through elements of what the customer finds as valuable. 
Benefits of Story Mapping
Story Mapping is a way to bridge the gap between an idea and the incremental work ahead.  It's a great way to decompose an idea to a number of unique user stories.  What are some additional benefits of story mapping?
  • It moves away from thinking of functionality first and toward the customer experience first. 
  • It provides the big picture and end-to-end view of the work ahead
  • It's a decomposition tool from idea to multiple user stories. 
  • It asks the team to identify the highest value work from a customer perspective and where you may want the most customer feedback.
  • It advocates cutting only one increment of work at a time instead realizing that feedback from the current increment will help shape subsequent increments. 
Getting started with Story Mapping
How might you get started in establishing a story map?  It starts by having wall space available to place the customer experience upon.  Next you educate the team on the story mapping process (see below).  Its best to keep to a Scrum team size (e.g., 7 +/-2), where everyone participates in the process.  Then as a team, follow these high-level steps:
  • Create the “backbone” of the story map.  These are the big tasks that the users engage with. Capture the end-to-end customer experience.  Start by asking “what do users do?”  You may use a quiet brainstorming approach to get a number of thoughts on the wall quickly
  • Then start adding steps that happen within each backbone.  
  • From there explore activities or options within each step.  Ask, what are the specific things a customer would do here?  Are there alternative things they could do?  These activities may be epics and even user stories. 
  • Create the “walking skeleton”.  This is where you slice a set of activities or options that can give you the minimum end-to end value of customer experience.  Only cut enough work that can be completed within one to three sprints that represents customer value. 
As you view the wall, the horizontal access defines the flow of which you place the backbone and steps.  The vertical access under each contains the activities or options represented by epics and user stories for that particular area. Use short verb/noun phrases to capture the backbones, steps, and activities (e.g. capture my address, view my order status, receive invoice). 

Next time your work appears to represent a customer experience, consider the story mapping tool as a way to embrace the customer perspective.  Story mapping provides a valuable tool for the team to understand the big picture, while decomposing the experience to more bite size work that allows for optionality for cutting an increment of work.  Its another tool in your requirements decomposition toolkit.  

Monday, July 6, 2015

Mario Moreira is speaking at Agile2015!

Mario Moreira will be speaking at Agile2015 on August 3rd (Monday at 10:45 am) in Washington, DC.  He will be speaking on "Customer Vision for better Feedback and more Product Success!" Notes: if you are on twitter, follow Mario (@AgileMario) and get updates on Agile 2015 activities.    

The abstract includes:  Effective customer feedback is both critical to adapting to customer needs yet elusive to capture well. Blundering into customer feedback activities continue to be a weakness in many Agile implementations.  How do you ensure you identify the right customers, get customers to attend feedback sessions, and capture the most effective feedback?  Keep in mind that without effective customer feedback, inspect-and-adapt become moot.  How can you elevate your customer game?  This session will help you establish a Customer Feedback Vision focused on gaining the elusive customer feedback.     

--------------------------------------------
Mario's past Speaking Engagement include:


Agile New England (July 2015) - "Customer Feedback Vision - Persona to Requirements to Demonstration to Product Success!" - "https://www.youtube.com/watch?v=ZU1E6-lQaLU" - Boston, MA USA

- MassBay PMI Professional Development Day (June 2015) - "Vistaprint's Agile Transformation and the Education that helped with their Journey" - "http://www.myeventguru.com/events/PDDAY2015/" - Boston, MA USA

- Software Quality Group New England/SQGNE (May 2015) - "Agile - Bringing Testing to the Forefront" - http://sqgne.org/presentations/2014-15/Moreira-May-2015.pdf - Boston, MA, USA

Agile New England (November 2013) - "The Importance of Agile Readiness - Success Factors for a Transformation to Agile" - "https://www.youtube.com/watch?v=e9AHTA9v_JM"- Boston, MA USA

Agile Development Practices East (November 2013) – “Getting Ready for your Agile Journey” - http://bsceast.techwell.com/sessions/agile-development-conference-east-2013/getting-ready-your-agile-adventure - Boston, MA, USA

Boston SPIN (January 2013) – “Writing Effective User Stories for Agile or Waterfall” – http://www.boston-spin.org/meeting_archive/boston_spin_topic_2013_01.html - Boston, MA, USA

 Give Thanks for Scrum (November 2012) with Ken Schwaber and Jeff Sutherland – “Getting the Most from the Sprint Review” - http://newtechusa.net/wp-content/uploads/2012/12/GettingTheMostFromTheSprintReviewGTFS.pdf - Boston, MA, USA

Grace Hopper Celebration of Women in Computing (October 2012) – “Go Lean, Go Agile: Are we there Yet?” – Panelist - http://anitaborg.org/wiki/images/b/b0/F1000-Theme4_Yunling_Wang.pdf  - Baltimore, MD, USA

Agile Development Practices East (November 2011) – “Minding the Gap: Project Governance vs. Agile Flexibility” - http://www.sqe.com/ConferenceArchive/agiledevpracticeseast2011/ConcurrentThursday.html  - Orlando, FL, USA

- Nashua Scrum Club (March 2011 ) - "Starting your Project off right with Agile Release Planning" - http://archive.feedblitz.com/675280/~3988328 – Nashua, NH, USA

Boston SPIN (Sept 2010) - "Agile - The Basic Roles and Beyond" - http://boston-spin.org/meeting_archive/boston_spin_topic_2010_09.html – Boston, MA, USA

- AccuRev & Book Launch (April 2010) – “Adapting Configuration Management for Agile Teams: Building Sustainability and Speed” - http://accurev.com/blog/tag/agile-teams/page/2/  – Boston, MA, USA

- Agile New England (April 2010) -  "Building the Right Product and Building the Product Right" - http://tech.dir.groups.yahoo.com/group/extremeprogramming/message/153460 – Boston, MA, USA

- Enterprise Software Development Conference (ESDC) (March 2010) – “Adapting to Continuous Integration and Build: Considerations for Deploymenthttp://www.sdtimes.com/link/34043  - San Mateo, CA, USA

- ALM Expo (Oct 2009) - Keynote speaker - "Agile and ALM" - http://www.agilejournal.com/blogs/community-member-blogs/keynote-speaker-for-alm-expo-2009.html/blogger/ckarpovich/  - Worldwide Webinar 

- Boston SPIN (May 2009) - "Modern Approaches to Infrastructure: On Premises or In the Clouds" - http://boston-spin.org/meeting_archive/boston_spin_topic_2009_05.html – Boston, MA, USA

- AccuRev Software Configuration Management Seminar (May 2004) “Systematic Process for Selecting a Valuable Configuration Management Product” - http://www.businesswire.com/news/home/20040520005471/en/AccuRev-Host-Software-Configuration-Management-Seminar – Boston, MA, USA

- Swedish Configuration Management Summit (November 2001) – “Crawl, Walk, Run! - Challenges in Implementing Configuration Management in a Complex Environment” – Stockholm, Sweden


- System Configuration Management : 9th International Symposium (SCM-9)  (September 1999) – “The 3 Software Configuration Management Implementations Levels” Tutorial - http://link.springer.com/chapter/10.1007%2F3-540-48253-9_18 - Toulouse, France

Sunday, June 21, 2015

How Value Stream Mapping can help your Agile Journey

Would you be surprised to learn that many people who participate in getting an idea to market are not very aware of all of the steps it takes to get it to the customer?  People know their sliver of work well but when asked if they know where in the full process their slice lives, it can be a bit challenging to pin it down.  One solution is to apply Value Stream Mapping (VSM) to gain that end-to-end view. 

Value Stream Mapping is a lean method for mapping an end-to-end flow of a product or service from the idea to the delivery to the customer.  It represents all of the activities required to transform a customer request into a product or service.  More importantly it is a way to optimize your flow through understanding what the state is today and then incrementally improving it over time to reduce waste and achieve faster delivery.  It is a means to help you optimize the value being delivered to the customer by creating a value stream that indicates what is value and what is waste.

Having applied Value Stream Mapping a number of times, the first benefit is it makes people aware that they are part of a much larger value stream than they thought.  People start to realize that there are more upstream and downstream steps and interdependencies than they thought.  It can be quite an eye-opener for some. 

The next benefit is that it highlights the end-to-end flow of work, not just the development work.  Some folks like to highlight only the development work and fail to realize that there are activities occurring prior to and after development.  An example is that if you are applying a yearly planning process, an idea or customer request may sit in the planning pipeline for upwards of half-a-year.  This is a very slow way to get an idea to market.  An end-to-end view ensures we visualize the full picture starting with an idea or request and then understand the amount of time it can take to get it to market. 

Another benefit is that now we visualize the end-to-end view of the work, we can identify the value-added and non-value added steps as well as the waste (e.g., wait) states.  It becomes much easier to become aware of the value and non-valued steps and waste when the big picture is in front of us. 

And most importantly it provides us an opportunity to incrementally improve.  Now that we are aware of the end-to-end value stream and we know what steps are value and where is there waste, it is time to experiment with incrementally improving the process.  The primary goal of the incremental improvement is to increase the process cycle efficiency and reduce the lead-time from the idea or customer request to delivery. 

Process cycle efficiency is a number that represents the efficiency of your lead-time (concept to cash).  It is a summation of all value-added time divided by that same value-added time + all of the wait/waste time.  A process efficiency example is while the value-add steps takes 115 minutes and the full processing time takes 2275 minutes, then you divide 115 by 2275 or 5%.  The goal is to look for those incremental areas of improvement.  

How does this help in an Agile environment?  If a goal in Agile is to get an increment of value to market quicker, then by identifying waste in your end-to-end value stream, and removing it, can reduce the time to get that value to market.  Value Stream Mapping is yet another tool in your Agile toolkit.  Consider learning more about Value Stream Mapping and experimenting with it for incremental improvement.

Sunday, May 10, 2015

Bounded Authority in an Agile World

Much is written about self-organization in an Agile world.  For some, the notion of self-organizing teams scares folks.  Does this mean that a team can decide everything?  Of course, the short answer is no.  I suggest the concern is due to not having boundaries for self-organization.  I call the framework for this context, bounded authority.  Bounded authority is defined by the information, experience, and decisions a group has control over within their context. Within a hierarchical structure of a company, bounded authority can work at multiple levels.  For simplicity, let us focus on the team level, middle management level, and senior management level. 

But first, let’s spend a few minutes to define what self organization means at a team level.  A self organizing team is a group of motivated individuals who have a common purpose, owns their work, and has the authority to make decisions on the work they are doing.  Within an Agile context, the goal is to push decision making to the lowest possible level and to the level in which the most information and experience dwells.  For a Scrum team, they self organize around the work that has been prioritized by the Product Owner that lives within the product backlog.  Once that work is available at the team level, the team has the authority to make architecture, design, programming, and coding decisions and can self-organize around the work.


So if the team’s work is defined within the product backlog, what does middle management do?  Can they assign work to the team?  The short answer is that this is not within the bounded authority for the middle management since the team gets their work from the product backlog.  While the team self-organizes around the work, middle management helps optimize flow for their teams and enables the team to be its most effective. By optimizing flow for their organization and teams, this includes removing impediments for their teams to enable them to work faster.   Middle Management may also focus on helping their teams with their career management goals. 

Above the middle management are the senior management (or executives).  Should they be reaching down and telling the teams how to build the product?  To answer this question, another question should be answered.  Does senior management have more knowledge and experience in what should be built or is this knowledge most known at the team level?  While the answer is the latter (team level), senior management has a bounded authority and duty to provide a strategy for the organization. This means they must help the teams understand the strategy and help them align strategy with their work.

Another example of bounded authority is relating it to your requirements hierarchy.  Consider who has the authority over the strategy, who has the authority over the ideas, who has the authority over the user stories.  This could be senior management who makes the decision to decide the top strategies, the chief product owners who makes the decision on prioritizing the ideas, the product owner who owns the decision to prioritize the backlog, and the and team who makes the decision on how to self-organize around the user stories.   
  

The key to bounded authority is that each level knows what they can self-organize around, what they have the authority to change, and areas in which they can make decisions.  Within an Agile context, that level of ownership and decision-making should be pushed down to the lowest possible level.  This can be an exercise that occurs at both the senior management and middle management levels. 

Sunday, April 19, 2015

Have you Crossed the Agile Chasm?

In 1991, Geoffrey Moore refined the classic technology adoption model with an additional element he called the “chasm.”[1] He advanced a proposition specific to disruptive innovation that there is a significant shift in mentality to be crossed between the early adopter and the early majority groups. Disruptive innovation is the development of new values that forces a significant change of behavior to the culture adopting it. In this case, Agile is that disruptive force that insists on applying a set of values and principles within a specific culture of “being Agile” to be successful and for the organization to realize the full business benefits of Agile.

At first glance, it would appear that many companies have adopted Agile. I believe, however, that this perception is specious, in view of the further observation that the majority of companies that are “doing” Agile have not actually adopted the new values and principles and not made the cultural shift to actually “being” Agile. Such companies look at Agile as a set of skills, tools, and procedural changes and not the integrated behavioral and cultural change it truly is. In other words, they think they have crossed the chasm, but they have not made the significant change of behavior required to make the leap.
My experience in the field leads me to posit a refinement on Moore's chasm concept as applied to Agile. First, there is the real Agile chasm between those on the left side who have made the organic behavioral changes consistent with the values of being Agileand those on the right side who are just doing” Agile mechanically. Second, there is a fake chasm, which many organizations pride themselves on having crossed by virtue of adopting some mechanical features of Agile, whereas they have not been willing or able to make the behavioral changes and adopt the values required to cross the real chasm. Although many companies say that they are doing Agile in some form, a large proportion of these are actually doing Fragile ("fake Agile") or some other hybrid variant that cannot deliver the business benefits of Agile.

I cannot overstate this point: many companies and their teams are mechanically doing some form of Agile without having actually crossed the Agile chasm, not discarding the behavioral baggage that is keeping them from behaviorally and culturally being Agile. Until a team attains the state of being Agile, the business benefits that Agile can provide will be elusive. I contend that the industry has barely entered the early majority of true Agile cultural transformation, and many companies continue to struggle to leap the Agile chasm.  What have you noticed across the Agile landscape?  Have companies crossed the Agile chasm?

Note: If you are looking for more insight in crossing the Agile chasm, consider reading the book Being Agile. This book lays the foundation for those who want to cross the Agile cultural chasm, understand the behaviors that need to change, and gauge progress along the way. It provides an Agile transformation roadmap to the destination of achieving better business results.



[1] Geoffrey A. Moore, Crossing the Chasm (New York: Harper Business Essentials, 1991).