Today I read… (10/17/2017)

Safety Stories in Agile Development


  • I like the idea of formal testing for safety issues in mission critical software.
  • I’m concerned about using multiple stories for the functionality and safety checks.
  • This doesn’t seem to follow the INVEST principle, especially the idea that stories should be independent.

Is there a reason why the functionality and safety checks can’t be included in one story? I assume that if the stories can be refined to be small, then the safety checks could be included in one related story. And then they could be independent.


AgileFall-ish, or How To Look Agile But Keep Your Waterfall Roots!

So how do we look Agile while maintaining our Waterfall roots? By building a predefined set of features through months of successive Sprints without getting customer feedback.

It’s often said that to be successful as an Agile organization you need to change your mindset. This cannot be repeated too many times. Agile is NOT Waterfall with new words and catch phrases. Unfortunately some companies miss this completely and don’t change their mindset. They simply continue their Waterfall processes in Sprints.

Keep Your Options Open

To be truly Agile you need to keep your options open. You may have a framework of features you want to build. But you won’t really know if customers want those features until they see them. And putting your features in front of customers sooner rather than later is one of the keys to being Agile. This helps you validate real customer needs and redirect as needed.

Gabrielle Benefield speaks about keeping our options open and targeting outcomes instead of output in a presentation given at GOTO 2012 called “Stop Building The Wrong Product Righter, Build The Right Product”. Her discussion leads me to two questions:

Are we using Agile techniques to effectively deliver what the customer wants?
Or are we perpetuating a Waterfall mindset in an Agile setting?

There are two versions of her video presentation. The first is more polished:
“Stop Building The Wrong Product Righter, Build The Right Product”
“Frankenbuilds; if Agile is so good, why are our products so bad?”

Don’t be put off by her early comments. At first it seems she is against Agile and Scrum. But she isn’t. She’s saying that we aren’t getting the full benefit of Agile if our teams limit options and lack customer feedback.

Again, the danger is committing to create a list of features without getting customer feedback along the way. Sometimes our leaders will have a strategy for a list of features and there really is value in creating all of them. But sometimes there is no strategy, it’s just a laundry list.

Don’t commit to a pre-determined list of features (or outcomes) unless we already know (really know) they are the outcomes we want.

Here are the key points I got from the presentation:

  • Outcomes over output
    • On time and on budget are meaningless if you build the wrong thing, at the wrong time, for the wrong people.
    • Output isn’t necessarily a good thing. Outcomes are more important.
    • Stop building the wrong thing ‘righter’.
  • Keep your options open
    • Outcomes are the destinations we want to get to.
    • Options are the potential ways you get there.
    • Target outcomes set a direction, and there are many ways to achieve it.
    • Outcomes break down into multiple options and the options are represented in the product portfolio and roadmap – flexible as opposed to linear.
  • Use experiments to determine direction
    • There are no product requirements, they are product guesses.
    • Set based design – run options concurrently to increase speed to market.
    • Features are not the experience.
    • Target outcomes validate the investment.

References for related topics:
A3 thinking
Target Outcomes Framework
Set based design

Here are my full notes from the presentations:

  • On time and on budget are meaningless if you build the wrong thing, at the wrong time, for the wrong people.
  • Output it’s necessarily a good thing. Outcomes are more important.
  • Stop building the wrong thing ‘righter’.
  • Build outcomes over output.
  • Measure value, nothing else matters. – Tom Gilb
  • Possibility – The most features you deliver, the worse the UX gets.
  • First, focus on performance and usability.
  • Target Outcomes Framework
    • Outcomes are the destinations we want to get to.
    • Options are the potential ways you get there.
    • Gather data: it lies (a little) less than people.
    • Become the method actor of UX.
      • Never ask your users what they want.
      • Never ask the developers what they think the users want.
      • “If I had asked people what they wanted, they would have said faster horses” – Henry Ford
      • Get out of your chair and find out what they need.
      • Create empathy, build personas to remind us that real people use our products.
      • Create strategies for getting to the right people at the right time.
    • Data gathering
      • Once you know where you are, figure out where you want to be.
    • Impacting mapping
      • Choose the outcomes by measuring the severity of the problem or size of the opportunity.
      • Optimize for the 20% that’s used the most.
    • Set the target outcomes
      • Make it easy to do the right thing, hard to do the wrong thing.
      • Target outcomes need to be clear and measurable.
      • If you don’t measure how will you know when you get there.
      • Target outcomes set a direction, and there are many ways to achieve it.
      • When you plan based on outputs, you commit to a certain future.
        • “This is what we think we are going to build.” You’re missing the customer input.
      • Stop pretending you can see the future.
        • Once you give a feature a name or document it, it has life and people think you are killing it if you decide not to do it.
    • Create options
      • Keep your options open, be ready to execute rapidly.
      • Responsible moment thinking
        • Make decisions as reversible as possible.
        • Make irreversible decisions as late as possible.
        • Options thinking is about setting up potential ideas and being able to execute on them rapidly.
      • Outcomes and options are fractal, each one leads to another.
        • Outcomes break down into multiple options and the options are represented in the product portfolio and roadmap – flexible as opposed to linear.
    • Simply go and build the right thing
      • How do we know what the right thing is?
        • We don’t know.
      • There are no product requirements, they are product guesses.
        • They are options and experiments we should run, never thinking far in advance.
        • Stop guessing, start testing.
        • Run multiple options fast, make the unknowns known.
          • Get features in front of users early and often.
      • Set based design – run options concurrently to increase speed to market.
      • Seeing is believing, research is too important to leave up to the researchers.
      • Features are not the experience.
        • More features, incrementally adding features, can be the problem.
        • Remove the inessential so the essential can speak.
        • Hit the target with as few bullets (features) as possible.
        • Build the minimal viable, not maximum possible.
      • Measure as you go.
        • Setup automated metrics frameworks.
        • If your metrics lag, your product will lag.
        • Share the data with the entire development team.
        • Why test with 5 people in a room when you can have thousands test real time.
        • Visual progress indicators tell you if you are on track.
        • Target outcomes validate the investment.
    • How do we know we have succeeded?
      • We get to where we are going, the target outcomes.
      • If we are not hitting the target outcomes, adapt.


OMG! Another Meeting…

Is this your meeting calendar? How does this effect your productivity?


In The Case for Investing More in People, Eric Garton talks about the various ways to invest in employees and increase productivity. I encourage you to read the full article, however I want to focus on time lost in meetings because I think each of us has the power to immediately increase our productivity by attending (or scheduling) fewer meetings.

Regarding time, Garton says the following:

Our careless treatment of time represents a shocking level of underinvestment in human capital. For knowledge workers, time is incredibly scarce. Our research suggests that, on average, managers have fewer than seven hours per week of uninterrupted time to do deep versus shallow work. They spend the rest of their time attending meetings, sending e-communications, or working in time increments of less than 20 minutes, a practice that makes it difficult to accomplish a specific task and in the worst cases can lead to employee burnout. We know that great ideas that drive breakthroughs in productivity come from human beings with the time, talent, and energy to innovate.

One step in reversing this trend is to start treating hours like dollars, with a real opportunity cost. Companies should seek to systematically eradicate organizational drag — all the internal complexity that leads to inefficient and ineffective interactions.

Unfortunately, many of our meetings are ineffective interactions. And I think many of you probably have too many meetings on your calendar. This is counter to the Agile principles we subscribe to and reduces our ability to increase productivity.

For those of you on Scrum teams, I am not saying we should eliminate the Scrum ceremonies. (Although we should work to make them efficient.) Underlying the Agile tenets is the idea that we should only do things which add value. Many of the meetings we attend don’t add value. So let’s eliminate them and instead have valuable communication, planning, and time for work.

Most of us, maybe all, want to spend less time in meetings. And I think we can if we make an effort to change bad habits. So how do we know if we have too many meetings, what are some of the associated problems, and how do we change?

Signs there are too many meetings:

  • Calendars are full – we’ve lost control of time management.
  • Lots of “Tentative” meetings on calendars – we have so many invites we can’t even reply to them all.
  • Multitasking during meetings – how else are we going to do “real” work?.
  • No meeting goals or agendas – we don’t have time to define them, or we aren’t sure why we’re meeting.


  • People think work gets done in meetings.
  • Invites include too many people.
  • People don’t reply to invites so we don’t know if the meeting goal can be met.
  • People are late.
  • Meetings are used to schedule phone calls.
  • Meetings become a form of procrastination.

Challenge – Do the following for at least the next week:

  • Decline at least 1 meeting invite.
  • Reply “Accept”, “Decline” , or “Tentative” to all invites.
  • Ask 1 meeting organizer the following questions:
    • What is the goal of the meeting (if not already stated)?
    • Am I absolutely necessary to meet the goal?
    • Can the goal be met with an immediate phone call instead?

If this helps, continue indefinitely, and continue to find ways to eliminate more meetings. Regardless of which Agile framework we use, they each use some form of continuous improvement to increase productivity, such as the retrospective or Kaizen events. Use these to find alternatives to meetings.

If we spend too much time in meetings, then we have to change our thinking about how we do work. Valuable work usually doesn’t happen in meetings. Once we embrace this, I think we will accomplish things sooner and be more productive.

Things will only change for the better if we make them change. Hold yourself and your coworkers accountable to have fewer, more effective meetings.

Writing User Stories Is Easy

“Writing user stories is easy.”

“You should be able to write 10 user stories per hour in a story writing session.”

“Refining user stories should only take a few minutes each.”

I’ve read or heard statements like this and they make me wonder if there’s something wrong with me. Writing stories always seems to be harder than it sounds. I was sitting in a Scrum training course and suddenly realized, maybe people mean different things when they say “user story”.

One of the usual descriptions of a user story is the 3 C’s – Card, Conversation, Confirmation. The Product Owner writes his/her ideas for a story on an index card or sticky note – the Card. The information on the Card spurs the development team to have a Conversation with the Product Owner for clarification and details. Confirmation is the Conditions of Satisfaction (aka Acceptance Criteria) the Product Owner uses to determine if the work is complete and acceptable.

Now, user stories don’t always start with all 3 parts. Stories evolve over time and a feature-sized story might start as a simple idea – the title on the Card. These large stories go by different names like themes, epics, or features. And the Scrum team works together to break down these larger stories into smaller stories and add details during user story refinement.

So what exactly are we referring to when we say “writing stories”, or “stories in a story writing session”, or “refining stories in a story refinement session”? Are we referring to simply the initial idea, the title? Or all 3 parts? It depends on the context, but I’ve found most of the time people are referring to a story with the 3 C’s. This is especially true when we are pulling stories into a sprint.

Why is “story writing” easy for some teams? “Easy” may not be the best word, but some team are better at it. From experience, I can tell you that it starts with the Product Owner. PO’s that have learned to write good story titles, clear value statements, and reasonably complete conditions of satisfaction make things easier for their teams. This gives the team a better starting point and makes story refinement and refinement sessions more efficient.

A regular cadence for refinement sessions also helps. I prefer to see these sessions scheduled at a regular time well in advance. Of course, there will be conflicts at times. But when we put off refinement sessions, or neglect a regular schedule, it will be reflected in longer planning sessions (where we’re actually refining stories) and fewer successful sprints.

Team members also help make story refinement more efficient by using spare time to review user stories at the top of the product backlog. Prior to the next refinement session, add to those stories comments, notes, or questions that will help the team gain shared understanding. Doing this will reduce the time spent on each story in the refinement session.

I like to refer to story refinement as a pipeline of work. New stories enter the pipeline with a few details. Over time the Scrum team works together to break down and refine stories to move them through the pipeline so they are ready for a sprint. This process might span several sprints for stories that start as nothing more than an idea, or that are complex and require the team to use multiple refinement sessions to gain shared understand. It’s important for teams to find efficient ways to keep the pipeline flowing.

How do you define “user story”? And if you find writing them easy, what techniques do you use?

Daily Scrum – Person-by-Person or Story-by-Story?

Is your daily scrum conducted person by person? Do you jump back and forth from user story to user story because people working on the same story don’t speak one after the other? Does this context switching make it hard to understand the progress of that particular story?

I think the standard, and most obvious, way of conducting the daily scrum is to simply go around the room person by person. But, there is another way – going story by story through the sprint backlog.

I have tried both ways. When I was new to Scrum, it just seemed obvious that you would go around the room. This method will probably work fine for small teams or teams who take on a small number of user stories in their sprints. In other words, if there isn’t much context switching in the scrum, then going around the room should work fine.

But as your team grows the opportunity to switch context back and forth between stories will grow. And this is where the second scrum method, going story by story, can help.

With this method, you’ll ask who is working on a particular story and those team members will answer the scrum questions. That way you get a full picture of the progress on that story at once. Mike Cohn describes it this way:

For some teams, conducting the daily scrum by product backlog item can make much more sense than going person by person. When going item by item, someone on the team (often the Scrum Master) says, “OK, let’s talk about this product backlog item next. Who worked on it yesterday? Who is going to work on it today? And is anyone stuck on anything to do with this item?” When a team conducts its daily scrums this way, there is less lost context.

I used this method for a large Scrum team and everyone preferred it over the person by person method. However, I did notice some problems that you need to watch for.

The first was that the scrum can become mini status reports for each story. Because you now have multiple people talking about a story, it can be tempting to drill into details. Instead of each person answering the scrum questions and moving on, a discussion can start. So be careful about that and if necessary remind people to avoid status reports.

Another potential problem can occur if some team members are working on multiple stories. Those team members will have to get accustomed to only talking about the story being addressed instead of all their stories at once.  This isn’t a huge issue as long as they stay focused on the story currently being addressed.

Have you tried the story by story method? Let me know how it worked for you.

Scrum Master Mistakes

We all make mistakes as Scrum Masters. As we say “Scrum is easy to learn, but difficult to master.” We do our best and learn from our mistakes.

Mike Cohn talks about some mistakes he sees in his blog post “Three Mistakes Scrum Masters Make and How to Correct”.

I could have guessed the first and third mistakes he writes about. But, the second surprised me. Basically, Mike says the Scrum Master should not run the daily scrum.

I definitely have a take-charge personality and I do keep the daily scrum moving along by calling on people. And I think Scrum Masters need a leader personality in order to encourage the team to follow the Scrum principles.

I understand the desire to have a team which runs the scrum itself, but I’ve always seen my role as a facilitator. Now, I’m not trying to take over the scrum, but I’m making sure it doesn’t bog down, instead of being a silent observer. I regularly remind team members that they are sharing information for the benefit of the team, not for the benefit of the Scrum Master. Also, each Scrum team I’ve been on has had some remote members and calling on people was necessary at some point during the scrum.

However, I can see that a more hands-off approach will help the team become more independent and self-reliant. So this is something I will work on. I’ll ask the team to start the scrum and give the input without being prompted.

I can see another possible benefit. I mentioned earlier that the information shared in the scrum is for the benefit of the team itself. I tell my teams that the scrum’s purpose is to plan the work for the day so it supports the completion of the sprint goal. Although, I struggle to drive that ideal home to some team members. Sometimes input for the scrum can be too brief and not very helpful, or sometimes it’s more like a status report. Maybe a more team-driven scrum will help improve on this.

Let me know your what you think and what works best for you.

Today I read… (8/10/2017)

Reasons to Estimate During Planning Poker with the Whole Team

Three Mistakes Scrum Masters Make and How to Correct Them