Today I read… (9/14/2017)

5 things about programming I learned with Go   http://mjk.space/5-things-about-programming-learned-with-go/

The Observer Pattern in JavaScript explained   https://pawelgrzybek.com/the-observer-pattern-in-javascript-explained/

Advertisements

Today I read… (9/13/2017)

How to bridge the gap between Design and Development   https://medium.muz.li/how-to-bridge-the-gap-between-design-and-development-b10c5f41f5d7

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
http://leanconstruction.org/public-docs/TDC-CH40-A3-Thinking.pdf
https://en.wikipedia.org/wiki/A3_problem_solving
Target Outcomes Framework
http://www.gabriellebenefield.com/mobius/how-to-measure-value/
Set based design
http://www.scaledagileframework.com/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   https://hbr.org/1986/01/the-new-new-product-development-game

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

Today I read… (9/11/2017)

The Best Youtube Channels for Developers – Hacker Noon   https://hackernoon.com/the-best-youtube-channels-for-developers-4a08677f1ac1

I watch two of these – Fun, Fun, Function and Computerphile. I also watch Numberphile and Objectivity which are companion channels to Computerphile. Learn To Code is good for learning golang.

 Event Sourcing: What it is and why it’s awesome   https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome

OMG! Another Meeting…

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

Full_Calendar

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.

Problems:

  • 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.

Today I read… (9/8/2017)

C.S. Lewis on Equality and Our Core Misconception About Democracy   https://www.brainpickings.org/2016/11/29/c-s-lewis-equality-democracy/