Sunday, May 25, 2014

Safety - the perquisite for Leadership

Many coaches suggest that teamwork starts with trust.  Simon Sinek would have us believe that there is a perquisite for trust: followers feel safe.


That feeling of safety builds trust, and that trust sets the environment for teamwork.

Do your team members feel safe?  If the project succeeds or fails do they still have a job on your team?  Answer no to that one simple question and you have your answer to why collaboration and teamwork is a challenge in your organization.

Work toward changing that and you are demonstrating leadership.

Did your software development organization follow the lead of many Agile companies and create a large open space floor plan with rows of cheep tables and expensive chairs?  Did this environment create the collaboration that it was intended to?  I've been in several companies recently that believe they have an Agile environment - this is far from the truth.  Let's look at what they really have and what they desired (or assume would arrive magically).

The desired behavior was the high collaboration that a team room space fosters.  Those team rooms are a success because the team is protected from outside influences, have autonomy of action (such as displaying team artifacts on walls/boards), have alignment of purpose from the environment to the culture to the project's goals.

When organizations try to scale this localized behavior to a large group - what is the first thing to be destroyed?  Safety!  Humans will not feel safe in a group of 100 - 150 strangers.  I've experienced this in a recent company.  We had small team rooms that were too crowded for the 6-9 people, yet they were functioning well and gelling as teams, collaboration was increasing, alignment and focus was driving good team work behaviors.  Then it all changed.  We moved to a new building/campus across the street.  The new space for engineering was one large floor open space with managers and directors in glass offices surrounding the table and chairs of the developers.  All safety was lost, trust dropped, teamwork came to a screeching halt.

CEO Rich Sheridan removed the fear and ambiguity that typically make a workplace miserable. With joy as the explicit goal, he and his team changed everything about how the company was run. The results blew away all expectations. Menlo has won numerous growth awards and was named an Inc. magazine “audacious small company.”


Do you enjoy NPR All Things Considered style deep dives into a topic? If you also love more avant garde story telling -- try the Agile Path - In Search of Safety podcast.

"A journey to define safety; we intersect story telling, interviews and in-depth research, talking us on a journey through abusive environments to improvisational theatre.  Learning about safety, engagement and what happens when they don't exist."


See Also:
book by Stephen Covey (the younger) The Speed of Trust
book by Richard Sheridan  Joy, Inc.


Friday, May 23, 2014

Book: How to Create a Mind

I've been reading the futurist Ray Kurzweil's latest book (book's web site).

I find his theories fascinating.  He has quite a record for predicting the future (see ch. 10  The Law of Accelerating Returns - How my predictions are fairing at KurzweilAI.net).

Kurzweil's model of the neocortex described in detail in this book, The Pattern Recognition Theory of Mind, may be sufficient to build a Artificial Intelligence.  This computer mind system may be capable of demonstrating the emergent property of intelligence.  And then by extension the emergent property of consciousness.

The sections on hidden Markov models, hierarchical architecture, and evolutionary genetic algorithms are worth reading if your into software design.  If you wonder why Apple released Siri before it was perfect, this book will give you the reason.  Kurzweil and company are the innovators of speech recognition.

Apple Had No Choice But To Release Siri As An Imperfect Product by Seth Fiegerman (2012)

"The reason I became interested in trying to predict certain aspects of technology is that I realized about thirty years ago that the key to becoming successful as an inventor (a profession I adopted when I was five years old) was timing.  Most inventions and inventors fail not because the gadgets themselves don't work, but because their timing is wrong, appearing either before all of the enabling factors are in place or too late, having missed the window of opportunity.
Being an engineer, about three decades ago I started to gather data on measures of technology in different areas.  When I began this effort, I did not expect that it would present a clear picture, but I did hope that it would provide some guidance and enable me to make educated guesses.  My goal was -- and still is -- to time my own technology efforts so that they will be appropriate for the world that exist when I complete a project -- which I realized would be very different from the world that existed when I started."
  -- Ray Kurzweil 

Kurzweil is now a fellow at Google working on building a mind.  Did he time this project start at Google for the world that will exist in 2020?
Ray Kurzweil Plans to Create a Mind at Google—and Have It Serve You by Will Knight
Ray Kurzweil TED talk on How Technology will Transform Us.

Thursday, May 15, 2014

One sentence does not make a User Story

I'm working with a large client that has adopted the classic user story format for the backlog.

"As a user, I want some feature  so that I receive this benefit."


Yet, I'm sure that it is not delivering the desired shared understanding that throwing out the classic business requirements document and adopting the scrum/XP user story practice is designed to deliver.

So if your groups user stories have become just a piece of boiler plate language to satisfy some agile coach's requirement - maybe you should reflect upon the desired reason for user stories rather than requirements documentation so many years ago.  User stories do work.  But you have to tell a story.  Few authors are good enough to tell a story in one sentence.

Here Ron is pointing to one of the XP practices that were very successful in replacing the big upfront requirements documents with the concept of stories.  In XP this was the Card-Conversation-Confirmation technique.  In this technique the card and the label or title written upon the card is the place-holder used in planning.  In this way the card becomes a token for the planning game (XP practice similar to Scrum's Sprint planning).  The Conversation is the part of the practice that may be missing if your groups don't find the one sentence description (in classis form) to be sufficient to plan, estimate, design, develop, test, and deploy the user story.


Another group behavior that I've noticed is that the Confirmation aspect of these user stories may be a bullet point list of statements that are not recordings of a dialogue (as described in Ron's XP article).  To improve efficiency of requirements gathering some groups have people working independently and ahead of the development teams to write user stories and acceptance criteria.  This practice can sometimes improve communication and sometime harm the shared understanding that is required for highly productive development teams.  In the C-C-C technique of XP the team and the customer wrote the confirmation statements together, a technique for validating that a shared understand had been reached during the conversation.   This also served as reminders during their demo of the application behaviors that would be observable with working software.

Learn to Tell the Story

The common reframe today is the distinction between telling stories and writing stories. Which is your team doings?  We all are much better at telling stories than at writing stories - it's just how much individuals practice telling stories.  We start at the early age of 3 or 4 and continue to practice for our entire life.  Few of us actually practice writing stories.  Can you see the powerful distinction between these two practices?

When telling stories a great practice is to have one or more people capturing the important points and themes as the teller spins the tale of the feature and the value it will bring to your customers.

User Story Mapping
A higher level abstraction from telling stories occurs in the Story Mapping practice as described by Jeff Patton - Story Mapping is a better way to work with Agile User Stories.

"User Story Mapping is a dead simple idea. Talk about user’s journey through your product building a simple model that tells your user’s story as you do. But it turns out this simple idea makes working with user stories in agile development a lot easier."

The behavior of teams that are being helped by the practice of writing detailed user stories is quite different than the behavior of teams that are being harmed by the practice.  The great thing about Scrum is that this difference should become apparent in a short amount of time - say one or two sprints.  When the shared understanding is being communicated by the written story and the conversation and the team is delivering working tested software that meet the confirmation aspects (acceptance criteria) of the story then one can easily observe the behavior in the demonstration of the working application each sprint.  If that is not happening, then perhaps the story is not being communicated, there is more to a great story than just one little sentence.


You also may want to reconsider the format of the classic user story - because they lack the obvious title that all great stories must have.  Try this alternative format:
<What I Want>
so <Role> can <Business Value>
This format creates a nice handle or title in the "What I Want" phrase.

See Also:
Definition of Done vs. User Stories vs. Acceptance Criteria by Mark Levison of Agile Pain Relief a consultant with lot's of wise content and great practices to teach.
Names should not be needed for user stories - by Mike Cohn
Advantages of the As a User I want - user story template - by Mike Cohn
User Stories Applied - book at Amazon
10 Tips for Writing Good User Stories - Roman Pichler
Good Stories have Great Titles - Lance Kind
6 Brilliant ways to slice user stories by Dominic Krimmer

** Telling User Stories vs Writing User Stories **
A Story About User Stories - The real intention behind user stories - by Ebin Poovathany
Focus on telling user stories -  Charles Bradley
Story Mapping concepts (PDF) by Jeff Patton