Monday, August 24, 2015

Virtual Teams – Agile or Bust


A collaboration by David Grabel and Mario Moreira

You’ve just been given a plum assignment, heading up a major new application development project. Congratulations! Your boss just got off the phone with a large off-shore contracting firm.  At the labor prices they are quoting, we’ll save a fortune and come in under budget. He knows that you’ve been experimenting with virtual teams; it’s time to kick this into high gear and really cut our labor costs. DON’T DO IT! By the time you factor in the extra costs for travel, the high costs of the locally based support personnel (project managers, architects, etc.), the increased systems and telecommunications cost, the miscommunication caused by lack of face-to-face conversations, and the rewrites this will require, the cost savings will evaporate. They will never complete it on time and the missed revenue alone will eat up all of your savings.


There are good reasons to rely on virtual teams. Cost savings is not one of them. Real world constraints can make virtual teams unavoidable. Your company might have a liberal “work from home” policy. Your development centers could be scattered about a large campus, across the country or around the world. You may have a strong relationship with an off-shore development company that has delivered high quality software on time in the past. You might be partnering with a company from another state. All virtual teams are distributed, whether it’s a single member working from home or dozens of teams scattered around the world. Co-located teams will almost always be more efficient and effective than virtual or distributed teams. When virtual teams are unavoidable, the key to success is to Be Agile. If you follow the agile values and principles you can successfully deliver valuable working software, quickly, with high quality, even with virtual teams.  Let us explore how the Agile values and principles can be put into action to help with virtual teams.
  • Value people and interactions over processes and tools by enabling virtual and physical face-to-face conversations. If team members are in different time zones, encourage flexible hours and provide high quality video conferences for stand-ups and other ceremonies. Supplement the teams with collaboration tools. Bring the teams together periodically to learn each other’s business contexts, cultures, and individual needs. Virtual teams necessarily need to rely more on electronic tools like agile project managers and collaboration software. These tools help, but virtual teams need to nurture the interpersonal relationships that allow trust to develop. Trust within and across teams is vital to agile success.
  • Value working software over comprehensive documentation by writing stories about the users experience and by delivering small increments quickly based on those stories. The traditional wisdom has been that virtual teams require very detailed requirements and design documents. These heavyweight artifacts don’t exist on agile projects. Very detailed requirements create the illusion of completeness and accuracy. All those details about what they system shall do obscure the problems we are trying to solve
  • Value customer collaboration over contract negotiations by scheduling regular demos with customers to get their feedback and deepen the understanding of the business problems to be solved. This is more important than checking the boxes on a requirements document. This is a case where virtual meeting tools can bring remote teams and customers together even when they are physically apart.

The agile values and principles are the best guiding lights available today to make virtual teams work. If you have to use virtual teams, please consider using agile practices and staying true to the values and principles. To learn more about virtual teams and best practices to make them successful consider attending the webinar “Virtual Teams- Future or Fiction”.  For more information go to http://www.eckfeldt.com/virtualteams/grabel

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 spoke at Agile2015 this week!

Mario Moreira spoke this week at Agile2015 (Monday, August 3rd) in Washington, DC.  It was a packed room.  He spoke 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.