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.


Today I read… (10/6/2017)

Why Isn’t Agile Working?

  • Agile works if applied correctly 
  • It isn’t a silver bullet
  • Unplanned work and multitasking will kill Agile teams
  • Agile teams should eliminate waste and focus on delivering value

Today I read… (10/2/2017)

Coaching Agile Teams by Lyssa Adkins

Chapter 3 – Master Yourself

  • Coaching starts with you, but is not about you.
  • Agile coaching is about what you can bring to the team to help them unlock the potential hidden even from themselves.
  • Bring yourself completely prepared, ready to coach.
  • Become uncluttered, grounded, open to ideas, and ready to coach.
  • Coaches don’t take over.
  • Conflict Response Mode: Assertiveness – Satisfy your own concerns, Cooperativeness – Satisfy others’ concerns.
    • Competing: Assertive and not cooperative
    • Collaborating: Assertive and cooperative
    • Compromising: In the middle on both dimensions
    • Accommodating: Cooperative and not assertive
    • Avoiding: Neither cooperative nor assertive

How violent is your communication?

  • Pay attention to your language and take responsibility for your emotional wake.

For a leader, there is no such thing as a trivial comment. Something you might not even remember saying may have had a devastating impact on someone looking to you for guidance and approval. (Fierce Conversations, Scott 2007)

  • Don’t diagnose, judge, sidestep, or manipulate.

When we focus on clarifying what is being observed, felt, and needed rather than on diagnosing and judging, we discover the depth of our own compassion. – Dr. Marshall Rosenberg

Can you be their servant?

Make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: do those served grow as persons; do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? (The Servant as Leader, Greenleaf 1991)

  • How do you feel about the duty of growing people?
  • How does it fit into your idea of coaching agile teams?
  • Do people leave the teams you coach better then they arrived?

A true servant leader listens first:

  • In saying what I have in mind will I really improve on the silence?
  • What percentage of the time do you listen first?
  • Do people have room to speak when they are around you?

Empathize and accept people as they are:

  • How likely are you to accept people as they are and honor where they are on their journey?
  • When you coach, do your judgments create a barrier between you and them?

Strength in others leads to strength in the team.

Will You Respond Intelligently?

What is your emotional intelligence quotient or EQ?

Facets of who you are as a coach:

  • How you react to conflict.
  • How you communicate.
  • How well you embrace being the team’s servant.
  • How you bring choice to emotional responses.

Be detached from outcomes – Stay at the process level.
Take it to the team – Don’t be a problem solver, take observations to the team.
Be a mirror – Reflect observations without judgement.
Master your words and face – Practice non-judgment and practice nonviolent communication.
Let there be silence – Do not fill silence. Let others fill it.
Model being outrageous – Give them wild ideas.
Let the team fail – Teams that recover together are stronger and faster.
Always be their biggest fan, but be careful – Don’t praise, but tell them how they are better as a team.

When you recognize a judgment, instead of speaking it to the team, write it down. Then , look for an agile practice, principle, or value you can reinforce with the team to help them do agile well and address the matter that caused your judgment. Write what you offered down next to the judgement. Keep this “judgment vs. agile” list going while on your judgment fast and see how much trust your can build – trust in them, in yourself, and in agile.

Choose one top thing you care about. Don’t teach any and every lesson that comes along.
Sometimes the team needs you to remain unfiltered – to see your reaction as a reflection of what just happened. More often, though, your reaction is about you and has no place in the coaching.
Treat people as people, not objects.

Are you listening?

  • Levels of Listening
  • Level I – Internal listening – Filtered through the coaches lens.
  • Level II – Focused listening – Listening from the speaker’s perspective.
  • Level III – Global listening – Listening to the speaker and the environment.

Score your listening after each interaction. Which level are you using?

Are you speaking?

  • Don’t speak because you want to appear smart or add value.
  • Ensure your words are aimed at helping them get better as a team.
  • Don’t speak first.
    • Wait for someone else to express your thought.
    • If necessary, speak with clarity and simplicity.
  • Don’t speak at all.
    • Silence can be fruitful.

Are you with them?

  • Simply be with the team.
  • Be in the present and mindful of what is really happening with the team.

Support yourself.

  • Can you extend the same compassion to yourself that you extend to others?
  • Can you laugh at “failures” and forgive yourself so you can get back to practicing?
  • Will you balance your needs with your team’s needs so you remain true to what you want from the relationship?
  • Pick a practice to keep in mind all week and use reminders to practice it.

Always work on yourself.

  • Keep learning and applying new ideas.
  • Inspect and adapt.


Today I read… (9/28/2017)

Coaching Agile Teams by Lyssa Adkins

Chapter 1 – Will I Be a Good Coach?

  • Agile coaching matters because it helps teams produce products that matter in the real, complex, and uncertain world, and adds meaning to people’s work lives.
  • Teams need coaches who bring to them a clear view of agile done well.
  • Coach from the center.
  • Disciplines of an Agile Coach:
  • Facilitator
  • Teacher
  • Coach
  • Mentor
  • Conflict navigator
  • Collaboration conductor
  • Problem solver

Agile coaching is 40% doing, 60% being.

  • An Agile Coach models Agile all the time.
  • You won’t hit the mark all the time.
  • To face your mistake is to model the Agile value of openness.

An Agile Coach should have coached multiple teams and seen a range of possibilities, limitations, successes,and failures across a variety of situations.

Wired to be an Agile Coach:

  • Ability to read a room
  • Cares about people more than products
  • Cultivates curiosity
  • Believes that people are basically good.
  • Knows that plans fall apart
  • Thirst for learning
  • Believes that any group of people can do good things
  • Low tolerance for institutional reasons
  • Believes that disequilibrium is essential
  • Risks being wrong

Chapter 2 – Expect High Performance

Motivation comes from autonomy, mastery, and a sense of purpose.

The High Performance Tree

  • Roots:
    • Commitment
    • Focus
    • Openness
    • Respect
    • Courage
  • Leaves:
    • Self-organizing
    • Empowered
    • Can solve any problem as a team
    • Team success
    • Consensus-driven
    • Constructive disagreement
  • Fruit:
    • Get business value faster
    • Get the right business value more often
    • Astonishing results
    • Team can truly do anything
    • Room for team and individual growth
  • Challenge:
    • Where are our roots weak?
    • What fruit do you want to get now?

Alternative metaphor for a strong foundation:

  • Empiricism
  • Self-organization
  • Collaboration
  • Prioritization
  • Rhythm

The team’s journey toward high performance never ends. Teach the team to honor their ability to fully and quickly recover from setbacks.



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.


Today I read… (9/12/2017)

The New New Product Development Game

This article is considered to be the original motivation for Scrum.

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.