Agile


A Map

Map!

In response to the recent articles on story mapping, I was asked, “When don’t I use a user story map?” As with many powerful tools, it is easy to want to use story maps in almost every situation; however, there are a few scenarios where story maps are at best overkill or at worst might be wasted overhead.

Small, low complexity efforts. Work that only impacts a small piece of functionality rarely needs the overhead of a story map.  While every team/person has a different perspective on what is small or low complexity, I suggest one basic rule, if the output of the work is a product, feature or application, however small, create a story map to guide the work.

Disjoint accumulations of work. A classic approach in many development organizations is to gather several pieces of work together (often only loosely related) and then to call that work a project.  The whole package might be large and/or highly complex; however, the lack of cohesion between each piece of work is a problem. Creating a story map in this scenario makes little to no sense.

Operational work. A story map for installing servers or scanning documents does not make sense.  In operational scenarios value stream or process mapping are significantly more useful.

A request to all blog readers and podcast listeners –
Starting next week we are going to start a process of picking both the most overused and favorite agile saying.   I have a list, but before we start, if you have a favorite please add it to the comments or email it to tcagley@tomcagley.com.

A life cycle is a series of floors!

Story mapping is a technique for visualizing and organizing a product backlog.  Story maps are useful for identifying a minimum viable product, for planning releases, for finding holes in the features product management needs and even for finding extraneous functionality that finds its way into every grouping of work. Story maps are so useful that they often thought of as a silver bullet. However, they are not a tool for every scenario that a team (or team of teams) might find itself facing.  All software products follow a fairly typical product lifecycle. Software products are created, enhanced and extended, maintained and then retired. While every piece of software follows this path, not every team participated in every stage of the life cycle. Story maps are not equally useful in each stage. (more…)

Story Map

Information Radiators are one of the most powerful concepts championed in agile as communication vehicles.  In many organizations, the use of information radiators has waxed over the past few years as more and more tools have locked data into monitors and tablet screens.  As electronic tools have replaced paper, putting radiators where people can see information, as they work or walk by, has been replaced by instant access (which is code for never looked at).  Product and sprint backlogs locked away into tools have the same problem as burndown charts, cycle time scatterplots or work in process aging charts that are in a tool and never looked at. Instead of locking backlogs away, create and use agile story maps to increase transparency and improve access to information. The goal of a Story Map is to present the big picture of a product or feature for everyone on the team. The Story Map’s ease-of-use and transparency increase the likelihood of collaboration and feedback within the team. The Story Map is also a tool to visually plan releases.  Like other information radiators, the use of story maps has changed over over the last decade as the use of agile has become more mainstream and less tied to the principles in the Agile Manifesto. Over the next few entries, the Software Process and Measurement blog will revisit story mapping and explore several usage issues in today’s software development world. Before we dive into the hard parts, though, we need to revisit creating a story map.

Story mapping is a relatively simple process for visualizing and organizing a product backlog (the hard part is generally getting the initial set of features and stories). Story mapping was identified and popularized by Jeff Patton. The story map is a multidimensional representation of a product (we will talk later in this series about whether story maps work if you are not working on a product).  Looking at a map from top to bottom, large items—epics or features—are placed at the top of the map. TIme or the user’s journey through the product is used to arrange the epics or features from left to right. For example, some of the features in a users journey for a product to sell books might include book search, book page, shopping cart, and shipping. This is sometimes known as a walking skeleton.

After the features have been arranged across the top of the map, user stories and enablers are arranged below the feature in “priority” order. Priority can be influenced by value or the order in which product owners and product managers want the software delivered (minimum viable product and/or release planning). For example, the epic “buy a book” might include a feature “shipping” which might include stories such as “search for shipping methods”, “display estimated shipping cost”, and ‘select shipping method’.

In July 2013 we described a simple process for capturing epics and building a story map.  Story maps are a simple visual representation of work. Real life adds significant complications to the mix, such as distributed teams and work that is less product or feature-oriented.  Deciding the right scenarios to use story maps should be part of every agile team’s workflow.

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 523 features our essay on story points.  Story points were a tool designed to give teams a rough understanding of their flow of work. It was a great idea at the time, but that time has passed. Unfortunately, story points now are being used improperly creating more problems than they solve.

In addition, Jon M Quigley brings his Alpha and Omega of Product Development to the cast. In this installment, Jon discusses the risks of Centers of Excellence.  They are another great idea that can and has been ill-used by many in the industry.

Re-Read Saturday News
We are back with Chapter 7 of Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!). Chapter 7, titled The miniLab, focuses on overpromising and continues to layer on toxicity to the Theranos story.

Week 6 – The miniLab –  https://bit.ly/2rfmwJh (more…)

Today we have a guest post from Anthony Mersino. Anthony and I have worked together numerous times.  I respect his vision, wisdom and dry humor.

Many organizations create an organization to help with their agile transformation. Various names have been given to these groups. Two that I really don’t like are the Agile Center of Excellence and the Agile PMO. The name is not inconsequential. Here is why I think that establishing a Center of Excellence for Agile is a really bad idea.

The intent of a group like the Agile Center of Excellence is often described as ‘to promote agility in the organization’. That sounds like a good thing, right? What often happens is that the way they go about it actually inhibits agility. What frequently happens is that the Agile Center of Excellence (CoE) focuses almost entirely on standardizing processes and tools, and leveraging scale and efficiencies. What could go wrong? (more…)

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 522 features the return of Jeff Anderson.  Jeff returns to discuss scaling agile and getting to a minimum viable product. Many teams and organizations struggle with the concepts of scaling and getting to an MVP, Jeff provides advice for not going crazy!

Jeff’s Bio

Jeff is the President of Agile by Design.  Over the last decade, Jeff has played a leadership role on a large number of enterprise-scale agile transformations, providing program management, operating model design and change-management services. Jeff frequently blogs about and presents on lean and agile adoption, and is the author of The Lean Change Method, which guides organizations through the application of lean startup techniques. His mission in life: to help knowledge workers be awesome at what they do.

LinkedIn:  https://www.linkedin.com/in/thomasjeffreyandersontwin/

Website:  http://agilebydesign.com/

Twitter: @thomasjeffrey


Re-Read Saturday News
The Software Process and Measurement Cast and Blog crew is still on the road this week.  We will publish our thoughts on Chapter 7 next week. Please jump into the re-read of Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!).   

Previous Entries:
Week 1 – Approach and Introductionhttps://bit.ly/2J1pY2t   

Week 2 — A Purposeful Life and Gluebothttps://bit.ly/2RZANGh

Week 3 — Apple Envy, Goodbye East Paly and Childhood Neighborshttps://bit.ly/2zbOTeO

Week 4 — A Reflectionhttps://bit.ly/2RA6AfT

Week 5 — Sunnyhttps://bit.ly/2AZ5tRq

 

Next SPaMCAST
SPaMCAST 523 features our essay on Story Points.  Story points are a tool to help teams manage their flow of work.  Unfortunately, story points aren’t always used properly and can create more problems than they solve.

We will also hear from Jon Quigley who brings his Alpha and Omega of Product Development to the cast.

Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

SPaMCAST 521 features our essay on user stories and legacy code.  A common question is how user stories can be developed for legacy code or for problems that crop up in production.  The implication is that creating user stories is too hard when dealing with legacy code changes or too slow when dealing with production problems.  User stories are a core tenet for most agile approaches.

This week we also have a visit from the Software Sensei, Kim Pries!  Kim talks about training in a column titled, “Software Catechism.”

Can you help keep the podcast growing? Here are some ideas:

  1. Tell a friend about the cast.
  2. Tweet or post about the cast.  Every mention helps.
  3. Review the podcast wherever you get the cast.
  4. Pitch a column to me. You are cool enough to be listening; you deserve to be heard.
  5. Sponsor an episode (text or call me to talk about the idea).
  6. Listen.

Whether you do one or all six, being here is a big deal to everyone that helps get the podcast and blog together. Thank you!


Re-Read Saturday News
The Software Process and Measurement Cast and Blog crew is on the road this weekend so we are going to take a day off from our re-read of Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!)   Today we re-visit an entry from 2013, In 2013 we ran a series titled “Motivational Sunday”. In this entry, we talked about the relationship between commitment and habits. I have tweaked the works a little but the sentiments are no different.

Habit and Commitmenthttps://bit.ly/2KbKq13 (more…)

Next Page »