Christmas lights from afar

Sneaking up on the holidays!

As we enter the holiday season, we are going to shift gears a bit and try something a bit out of the ordinary.  Starting next week we are going to start a process of picking both the most overused (or hackneyed) and the favorite agile saying of the SPaMCAST readers and listeners.  Over the year I have been asking (or some variation) the following questions to generate a list:

  1. What is your favorite agile saying? (ie stop starting and start finishing)
  2. What is the saying that you dislike the most?

The list (below) has some of the most common sayings and a few that I have never heard.  There is still time to add to the list. Please review the sayings below and suggest additions.  We will work through a process of judging whether the saying is naughty or nice (just like Santa’s list) and then prioritize the list.  If you have additions please add it to the comments for this blog entry or email it to tcagley@tomcagley.com.

The unedited list is below  – some are some duplicates (or are close) and there needs to be some grouping before we begin our journey.  What would you add to the list (good or bad)? (more…)

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.

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

Now on Spotify!

SPaMCAST 524 features the return of Matt Heusser.  Matt and I talk about the nuts and bolts of being a tester in today’s software environment including agile testing.  Matt and I covered difficult areas that anyone that is interested in quality and risk needs to think about.

Matt’s bio:
The Managing Director of Excelon Development and a member of the board of directors for the Association for Software Testing, Matt Heusser leads test training and change efforts while making as many contributions as he can to active projects. Learn more about Matt at www.xndev.com follow him on twitter at @mheusser or check out the testing show podcast on iTunes or online at https://www.qualitestgroup.com/resources/the-testing-show/   

Re-Read Saturday News
We are re-reading 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 9, titled Wellness Play, continues the focus on overpromising and the toxicity overpromising generates inside and outside Theranos.

Week 7 – Wellness Playhttps://bit.ly/2rqUYk6 (more…)

This week the fallout from overpromising the on the ability to deliver the miniLab spreads to Safeway in our re-read of Bad Blood, Secrets and Lies in a Silicon Valley Startup.  Overpromising is a problem every team and organization faces. Almost all humans want to say yes and make people happy. As trained problem solvers, we rarely meet problems that we can not overcome, and hence we are optimistic in what we promise.  The shenanigans at Theranos might not have the same root cause. Buy the book and read along!   (more…)

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…)