A Survival Guide for New Agile Coaches - Are We There Yet?

I recall driving to Toronto one time with the kids.  It's about a 4 hour trip, and somewhere around 30 seconds after we left my son asked, "Are we there yet?".  Of course, I patiently responded, "No, we have about 4 hours to go!"

After another hour and several thousand additional queries about our arrival status, I decided to change things up.  When my son asked, "Are we there yet?", I cheerfully responded, "Yes!"  He answered, "No we're not!", to which I not-so-patiently responded, "THEN DON'T ASK AGAIN!!!".  He had nothing to come back with, and I basked in my victory for at least a few minutes.

Coaching Point

There are a number of points that can be taken from this story.

First is the need for releases that are as short as possible.  When you work away for months at a time and can't see the goal towards which you're working, your motivation can erode somewhat.  Imagine climbing a hill shrouded in fog - you just keep climbing and have no idea when you're going to reach the top.  You may eventually become bored with the climb and start back down, when in fact you were only a few metres from the top that you couldn't see!  Release cycles of 24, 18, 12 and even 8 months can have this effect, whereas cycles of 1 day out to 6 months are within "sight" of a team, allowing them to focus better.

Second, there are situations and or products that do require longer cycles (at least initially).  Visual management can help communicate your current and projected locations reasonably well.  For example,
I now like to use our GPS for any long trips even when the route is well-known and we don't really need a map.  Our GPS also shows Distance Remaining, Distance to Next Waypoint and ETA/Arrival Time.  Everyone in the vehicle can see this information and as a result the question in the title of this post is now rarely, if ever, asked.  What information could you display for your project or product that could achieve this?

Third, teams that have been using an Agile process for a good length of time can find themselves in a rut or becoming caught in the daily and iteration-length 'grind' of the process.  On several occasions I've heard team members and even entire teams speak of working away from Iteration Planning, through the iteration, performing a demo, holding a retrospective and then get right back into the next Iteration Planning.  The common theme has been, "We don't have time to catch our breath!"  This can be a symptom of a few issues:

• No slack built into the iteration to allow for unexpected work or work that was larger than expected
• No slack built into the iteration to allow team members to 'sharpen their saw' or to spend a small amount of time refreshing their minds
• This may sound silly, but the use of the term "Sprint" for Iteration - the words we use can and do affect they way we perceive the world.  If a team is constantly "sprinting", they can have the feeling that they're out of breath at a certain point

The key here is to understand that you can't simply fill every single minute of time within an iteration with work directly from the backlog.  Not only is that unrealistic, it will burn out the people on the team.  The excellent book Slack by Tom DeMarco says,

Slack is the lubricant required to effect change, it is the degree of freedom that enables reinvention and true effectiveness.

In other words, by giving teams some time where they aren't working on their regular work, they will be more effective and efficient.  They may also come up with new ideas and even products!  Regardless, look for ways to allow team members to recharge.  Ask the team for ideas, or suggest some team-building activities or even just some 'free' time off, i.e. not charged to their vacation.

Finally, you need to consider what questions are really being asked.  When my kids were asking, "Are we there yet?", the real question is, "When are we going to get there?"  I solved that problem somewhat by using the GPS which displays that information, although when the kids were younger the concept of 3 hours was as abstract as 3 days or 3 months!

If a team member says, "We're stuck in a rut... one sprint after another with no time to breathe", what's the real issue?  Do they have any slack?  Not enough slack?  Is there external pressure to do more, requiring communication with stakeholders?  Do they need to go out for a beer after the iteration demo and forget about the retrospective and iteration planning until Monday?  All of the above?  The point is to not necessarily take the question or statement at face value - try to identify the real question or the root cause of the statement.

While you can simply answer, "No" to the question, "Are we there yet?", that rarely appeases the person or people who ask it whether they're 3, 33 or 63.  Ask yourself what you can do or suggest to either find the real question, make the information required visible or even change the circumstances such that the question never needs to be asked in the first place!

Worth Repeating - XP Bills of Rights

While doing the electronic equivalent of cleaning the attic yesterday, I stumbled across an internal paper I wrote at a client back in late September 2001 describing Extreme Programming.  While waxing nostalgic, I did notice a section that remains important today and is worth repeating - the Customer and Developer Bills of Rights from XP Explained and XP Installed.  The text below is unedited from 2001 - you can substitute Product Owner for Customer and Team Member for Developer.

---

Since communication is a critical aspect of XP, the people involved must know up front
what they can expect, and what is expected of them. As such, the following are lists of
"rights" that the Customer and Developers are accorded in XP:

Customer Bill of Rights
As the customer, you have the right to:

• An overall plan, to know what can be accomplished, when, and at what cost;
• Get the most possible value out of every programming week;
• See progress in a running system, proven to work by passing repeatable tests that you specify;
• Change your mind, to substitute functionality, and to change priorities without paying exorbitant costs;
• Be informed of schedule changes, in time to choose how to reduce scope to restore the original date, even cancel at any time and be left with a useful working system reflecting investment to date.

Developer Bill of Rights
As the Developer, you have the right to:

• Know what is needed, with clear declarations of priority;
• Produce quality work at all times;
• Ask for and receive help from peers, superiors, and customers;
• Make and update your own estimates;
• Accept your responsibilities instead of having them assigned to you.

---

These rights resonated with me in 2001, and I believe we need to revisit them from time to time in order to ensure that the values of Agile are instilled within an organization.

A Survival Guide for New Agile Coaches - Patience, Persistence... and Ear Plugs

For the first couple of months after my son was born, we had a heck of a time getting him to sleep in the evening. After a couple of months I realized that I just had to let him scream until he fell asleep. Once he did he slept like, well, a baby! 

Getting to that realization was tough. He was literally screaming as loud as he could into my ear (I've been tested, and the hearing in that ear is diminished!), and he would wriggle away. I figure that he was ticked about having to go to bed! Regardless, the screaming became a routine, and once that routine was established it wasn't as stressful. 

After a few months the patience and persistence paid off. He screamed less and less, eventually going down to sleep without a fight. 

Coaching Point 

When a team is first starting their transition to Agile, you will hear a lot of screaming... mostly in the figurative sense, but sometimes literally. For most of the organizations with whom I've worked, Agile represents a fundamental change to how they think about their organization and their work. Any change that significant will create fear and stress. People will think that they may lose their job. There will be those who lose what they believed to be a prestigious title. Sacred cows may be slain in the name of moving to Agile.

Be prepared to put the team on your shoulder (figuratively, of course) and let them cry it out. Give them time to learn how to work in short cycles.  Give them the support and time needed to learn test automation.  Give them the support and tools needed to effectively inspect and adapt.  When the team has gripes & complaints and wants to give up, listen patiently and with compassion.

If that support is available to them, over time their need to "cry it out" will diminish and eventually disappear.

My Tribe ...or Herd

This past weekend I attended Agile Coach Camp Montréal, making and remaking many connections within the Agile Coaching community.  This was an Open Space un-conference, and during the opening of the circle facilitator François Beauregard asked the participants to picture ourselves among the community of coaches attending the event, and hold on to that image.

We then proceeded to open the sessions, and I participated in many interesting discussions.  One however, stood out from the others (even my session on Lean Startup!).

Alistair McKinnell & I crossed paths and started talking about how you can infer many things about an organization when you see the code they produce, a twist of Conway's Law.  Declan Whelan wandered by and offered up the notion that perhaps we could map code smells to organizational smells, and perhaps we could also similarly map the refactorings... Extract Manager, anyone?  Collapse Hierarchy?

This informal chat turned into a session of its own with about 12-15 people eventually participating.  An interesting thing I noticed, though, was that those among the group who seemed to really, really grasp the gravity of the problem with smelly code were those of us who came into Agile from the XP world.

When François closed the circle at the end of the day, he asked us to remember the image we had in our mind in the morning and for us to contrast that with what we now felt.  My image in the morning was cattle in a field with one cow alone, away from the others.  My image at the end of the day was indeed different - cattle in a field, with one large group and a very small group.  I was a member of that small group.

A Survival Guide for New Agile Coaches - Believe in It

My Dad wasn't one for giving lots of advice about life. Golf, yes, but life, not so much. One thing he did say, though, has stuck with me.

Dad was a partner in an insurance brokerage and estate planning firm. He arrived at that point in his life after joining the Personnel group of a very large insurance company in the mid-1950's. He stayed in Personnel, later Human Resources, right through until the mid-1970's. He finally decided to make the change to Sales after he could no longer be a person who had to fire other people. In fact, the stress of firing others almost killed him.

He joined the Sales organization of this company, and his people skills resulted in immediate success. After a few years, he and his boss left the large company and started their own brokerage. Many trials and tribulations ensued, but the company persisted and flourished (they're still in business and growing some 30 years later).

As Dad was winding down his career and preparing for retirement, he talked me about carrying on his legacy by being part of the company. I said to Dad that I really didn't feel that I was a salesman. His response was,

"If you believe in the value of what you're selling, you will have no problem selling it." 

I didn't join the company, but those words have stayed with me ever since.

Coaching Point

You may be the lone voice in the woods at your organization, telling anyone who will listen that Agile is the way to go!  You may be an independent consultant that has to market your services to potential clients.  Regardless of your circumstances, as a coach you are often put into the position of selling Agile to people within organizations.

This is where the rubber hits the road with respect to your passion and commitment. If you believe, and I mean truly believe that Agile Software Development values, principles and practices will bring benefits to your clients or your organization, the selling part will come easily and naturally. Of course, you have to know what you're talking about and you have to have used an Agile approach in practice more than once to be truly able to convey the process to others.

Remember, though, as much as you believe that Agile is beneficial your audience may not be ready, willing or able to listen to that message. A team or organization must be feeling enough pain that they are willing to be open to seeing the value in the approach you're suggesting.

Yes, those words have stayed with me.  Indeed, they have gotten me through some rather grim and frustrating days as an Agile Coach.

How many software projects have you been part of that were late, over budget, full of defects and took a human toll in terms of stress and burnout?  Agile is by no means a silver bullet, but it does represent insurance against many of those issues.

A Survival Guide for New Agile Coaches - Why?

When a toddler learns to speak, often his first recognizable word is "Mom" or "Dad" or some variation of those.  His second is "Why?"  If you were to take a teenager and, like, count the number of occurrences of "like" in their, like, speech, DOUBLE THAT and you would approach the frequency at which a toddler uses the word "Why".

The constant questions can drive you absolutely crazy - I truly believe the word "because" was invented to deal with an inquisitive toddler.  However, a great deal of patience is required to be able to help the child learn not only their language but how to use it and communicate with others.

Coaching Point

There's a very good reason why young children constantly ask "why".  It should come as no surprise that it has to do with learning about the world around them.  (As an aside, parents these days are blessed with tools such as Wikipedia to assist them in explaining why the sky is blue - those of us who had to raise children in the last century were forced to read books to learn such things!)

Asking "why" is a method for a child to learn, learn and learn while their brain is a veritable sponge for absorbing knowledge.  There's also a more subtle reason and mechanism at work, though.  By asking a question such as "Why?", the child has a tool to keep a conversation going.  The other person remains engaged and talking with the child which helps her expand her vocabulary, learn new patterns in the language and to actually use what she has learned.  In short, as children we are wired to ask questions in order to learn how to effectively communicate with others.

As a coach, you have tools for helping teams expand both their knowledge and their ability to communicate.  For example, and in keeping with the title of this post, there is the 5 Why's technique pioneered by Toyota.  The concept originated at Toyota with Taiichi Ohno and is considered a key tool for performing root cause analysis in Lean.

5 Why's is one method for performing the critical inspect and adapt function within any Agile process.  Teams and organizations must look at how their process is working, determine where and how it could be improved and actually carry out those improvements.   Most often this occurs in retrospectives, but it doesn't need to be limited just to that one meeting.  Following the Stop and Fix and Continuous Leanring concepts of Lean provides a perfect opportunity to apply 5 Why's.

While Inspect and Adapt may sound like common sense, I have seen too many teams give only lip service to the concept and simply live with their existing circumstances rather than attempt to improve them.  This is the equivalent of a child asking a single "why" and giving up - they don't really learn that much and they don't improve their communication skills.  As we mature we often become conditioned to asking fewer and fewer questions about issues we see.  People want to be good corporate citizens and not "rock the boat".

Similarly, I've seen many instances of people and even whole organizations where bad news is avoided at all costs.  Unfortunately, the answers that emerge from 5 Why's are not always what people want to hear.  In that sort of culture, problems are a sign of weakness, not impediments that need to be removed in order to improve how the organization does its work.

To be able to effectively ask "why" and process the results, trust needs to be built within the team and outside so that no one is afraid to state that there's a problem that needs to be dealt with.  Within the team is relatively easy to accomplish once they move to an iterative delivery model that shows results on a regular basis.  I once coached a group that was very distrustful and dysfunctional until after a single team leader left and an agile process was implemented.  Trust started to be built immediately once all team members started attending meetings and became involved in the process, and by the end of the first iteration the group had gelled very well, and wasn't afraid to ask the questions required to delve into some tougher to solve problems.

So, in order to be truly effective and continuously improve, you need to channel your inner toddler and ask "why" (among other questions) at nearly the same rate as a 2 or 3 year old.

Analysis and Design in Agile

A long time ago in a galaxy a dozen or so miles away, I learned about Extreme Programming.  I was actually doing Pair Programming when I heard about this crazy XP concept, so it wasn't really a stretch to do it on a regular basis.  Similarly, writing tests for my code seemed like a reasonable thing to do, although it took a few months to really wrap my head around Test-Driven Development

Within a year of that first contact, I was an outspoken advocate of using XP.  I successfully convinced a manager to try it out and it worked wonderfully for that group.  I started talking to more and more people, and in doing so started to encounter the first myths and misconceptions about what XP did and did not do.  That was 2001, and in 2011 I still hear many of the same things.  So, let's deal with a few of those myths now.

Let me go back to what I read in XP Installed, XP Explained, the C2 Wiki and on the XP Yahoo group in those days.  The 'genesis' of XP started when Kent Beck was faced with leading a restart of the Chrysler Comprehensive Compensation project in 1996.  As I understand it, Kent was a reluctant leader and knew that he had to do something different.  He reflected on everything and anything in his career that had 'worked',  and reasoned that if a practice worked you should amplify it, i.e. take it to the extreme.  To wit:

• Planning is good, so do it all the time (Planning Game)
• Analysis is good, so do it all the time (Planning Game)
• Design is good, so do it all the time (Planning Game, Test-Driven Development, Pair Programming)
• Testing is good, so do it all the time and automate it (Test-Driven Development, Customer Tests)
• Keeping the design clean is good, so do it all the time (Refactoring)
• Integrating completed code is good, so do it all the time (Continuous Integration)
• Feedback is good,, so do it all the time (Short Iterative Development)
• Releases to production are good, so do them all the time (Small Releases)
• Contact with the people for whom you're building the software is good, so do it all the time (Whole Team)
• Collaboration between team members is good, so do it all the time (Whole Team)
• Code inspections and reviews are good, so do them all the time (Pair Programming)
• Avoiding silos of knowledge is good, so do it all the time (Whole Team, Collective Ownership)

All of these are aspects of what was and is considered good software delivery practice and all are present in Extreme Programming.  They may look different in practice, but they are all indeed there.  What you avoid is the waste of speculative work that results in mistakes or following the wrong path because of an expensive prior decision that people don't want to undo.  Only enough work is performed in order to suit the current needs of the team and the Customer.

The key word there is "enough", which is very context dependent.  A smallish web application may not require much analysis, design and planning beyond a few iterations or outside of the current release.  The anti-lock brake management system for a car would likely need more.  A constant very-high-volume system like Twitter would have different parameters for "enough" than an eCommerce application handling a few dozen paying customers per day.  One lost tweet is no big deal, but a customer losing their cart on that eCommerce site could be lost business for that small company.  Conversely, the eCommerce site need only handle a few concurrent users whereas Twitter must handle thousands.  In the end, you always must be mindful of what constitutes "enough" in your domain.

Activities such as analysis and design happen in increments ranging from a couple of minutes to possibly as large as a couple of weeks:

• A pair of people may spend a few minutes at a whiteboard sketching out the work they're about to do to implement a story.
• A pair of people will use tests to guide their work and the design of the code while using Test-Driven Development.
• A team will spend a few hours to a few days doing Release Planning to map out work for the next few weeks to months.  This will include an overall view of the design vision of the system.
• A team will spend a couple of hours doing Iteration Planning to map out work for the next week or so. This will include breaking the work into much more detailed tasks, and further refining the design.
• A large group of people may spend multiple weeks working through the business problem, usage scenarios, personae, use cases, and overall high-level design for a large enterprise system.
• A small startup may iterate on multiple small experiments per week in order to quickly get validated feedback on their business direction.
• A team of any size on any project in any domain may hold ad hoc sessions to discuss and refine the design as required based on any new learnings or refined understanding of the business problem.

So, please remind me again why you think that Agile/XP means no analysis, no design, no documentation, no planning and just random hacking that will collapse after 3 iterations?

Fibonacci Must Die!

Leonardo Fibonacci died over 760 years ago but he had a profound effect on mathematics in western civilization.  He brought what he had learned from mathematician in north Africa back to Europe and authored the book Liber Abaci, which described such things as the Hindu-Arabic numeral system and place value of numbers.  In the book he also showed how a number of mathematical problems were solved using the techniques he had learned, one of which was the growth of a population of rabbits.  Although he didn't invent it, that sequence bears his name today, and is seen in many places in nature.

The use of the Fibonacci sequence in a slightly modified form has also been popularized in the Agile community as values which can be used to estimate the effort required to deliver work.  This is usually tied to the Planning Poker technique created in 2002 by James Grenning, and Mike Cohn's Mountain Goat Software sells decks of planning poker cards that use the values 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and infinity.

If you look, though, at James' paper and Mike's excellent 2005 book Agile Estimating and Planning, they both make a very similar point.  From James:

As the estimates get longer, the precision goes down. There are cards for 1,2,3,5,7,10 days and infinity. This deck might help you keep your story size under 2 weeks. Its common experience that story estimates longer than 2 weeks often go over budget. If a story is longer than 2 weeks, play the infinity card and make the customer split the story.

From Mike's Agile Estimating and Planning (pg. 52):

Because we are best within a single order of magnitude, we would like to have most of our estimated in such a range.  Two estimation scales I've had good success with are:

• 1, 2, 3, 5 and 8 [Fibonacci] 
• 1, 2, 4 and 8

In both of these cases, James and Mike recognize that as estimate size increases accuracy decreases rapidly, and they both use a very narrow range of values that can be used for estimates.

Why is that?  Well, I'm going to borrow a famous acronym from the Extreme Programming world: YAGNI... You Ain't Gonna Need It!

Yes, Mike's card decks have many more values.  I suppose that a deck with 5 values and infinity would be somewhat less attractive to buy, but the real point is how much damage is being caused by teams using values of 13, 20, 40 and 100?  Do those numbers really mean anything?

I assert that they are meaningless, and actually cause much more harm than good.  The harm comes from 2 sources.  First, it allows teams to get away with not splitting work down into pieces that can be estimated reliably.  Second, and as a consequence of the first, by providing inaccurate estimates for very large things teams/product owners/stakeholders can have a false sense of security about how much effort will be required.  Estimates that are wildly inaccurate will lead to incorrect decisions about whether to proceed with some work or not.  The smaller the piece of work being estimated, the higher the probability that the estimate is accurate enough to make reasonable decisions.

The Curse of Choice
Having too many choices is actually a curse, and limiting the choices available for teams to use for estimation forces them to really think hard about breaking the work down.  I personally have used the four values of 1, 2, 3 and "too big" with good success over the years, but I can certainly live with what James and Mike suggest above.

To go a step further, though, we should be applying Lean thinking and strive to eliminate the variability of the size of work completely.  This would mean that all items are broken down until they're the same size, obviating the need for any estimation at all!  That's a perfection vision that very few people have achieved, although it has happened.

In the end, we need to move away from using the longer modified Fibonacci series as if it were a law of nature.  Being modified, it really isn't a law, and actually provides very little value beyond the number 8.

Within Agile teams, Fibonacci must die!

The Power of Whining and the Evolution of Agile

It's somewhat amazing to think about the power of whining ("whinging" to those across the pond and in Oz & NZ!).  Back in February, I received a "Dear Dave" letter from the Agile 2011 conference saying that my "Survival Guide for Agile Coaches" session hadn't been accepted.  I whined publicly about it on Twitter, only to have the Agilemeister, Angeline Tan, suggest that I submit my proposal to the SFAgile conference she was organizing.  Lo and behold I found out a few weeks later that my talk had been accepted!

Now, that and a quick personal review of my session would have been somewhat interesting.  Add the following sessions and it'even more interesting:

• Lean Solo Leanpreneurship by Dan Neumann, showed a frighteningly similar career arc to my own, although mine occurred several years earlier.  It was about Dan's own evolution from an employee to an independent Lean/Agile Coach, focusing on his decision to become independent and how he subsequently worked to build his network.
• Lean UX & Product Stewardship by Tim McCoy & Zach Larson, was about the confluence of traditional UX processes with Lean, and focused on delivering what was required by teams as close to when they required it as possible.  While the concepts were all familiar to me, I have no trouble listening to people talk about the desperate need for shared responsibility between Product Management, Development and the UX community!
• How to Form Agile Teams by fellow Canadian Dave Sharrock, also covered material with which I'm familiar, but Dave did a terrific job of tying specific points such as cross-functionality to research both from and outside the software community, and went well beyond the standard "you have to have QA on the team" mantra.
• Improve Flow Through Prioritization was the "Buy a Feature" Innovation Game facilitated by Carleton Nettleton, and was a fun but informative look at the prioritization process that highlighted some very real world behaviours like "I'll cooperate once I get my pet project approved" even in a game setting.  Arguably the best one-liner of the conference came from Lanette Creamer in that session: "I'm surrounded by Libertarians and Republicans... I want to pollute their water!"
• The first day ended with the inspirational session, Enterprise Agile Evolution: How We Escaped Our Timeboxes by Ted Young.  In it he described how his group lived inspect and adapt, and over a few years evolved their Scrum/XP process naturally into something that worked very well for them.  It was a great story about how Agile and Lean are really supposed to be done!
• Day 2 began with Derek Wade's Uncover your Frame – Leadership for Effective Agile Teams. This was a session that illustrated how we infer "frames", or the motivation behind someone's actions and had an exercise on the use of the Advocacy/Inquiry technique to help discover the true motivation or meaning.  It was a technique for coaches, and an area where I'll be spending some research time in coming weeks & months!
• Dave Sharrock then led a panel discussion (filling in for an unfortunately absent Jurgen Appelo) around an open forum of Agile and Lean topics.  It was interesting that despite the advanced nature of many of the attendees, there was still a desire to discuss the steps for a long-term transition from traditional methods to Agile and Lean.
• The Agile Doctor: Five Riffs on Agile Inspired by The Doctor by Evan Cofsky was a fun session about how the current poseur for Dr. Who (we all know that Tom Baker was the only Doctor!) was actually quite Agile in his work, taking whatever he had available at the time and encouraging the people around him to work together to succeed.  While it was light-hearted, there were some rather powerful messages involved for people who are coaches, the main one being that you may have to fail in order for those you are coaching to properly succeed.  This session did have some criticism, because it required at least a passing knowledge of the Dr. Who series, although even mine from the late 70's was sufficient to know that anything involving Daleks was generally quite bad.
• I was happy with my session, A Survival Guide for New Agile Coaches.  It was fun, as I had intended, and the audience seemed very receptive to the format and the stories/messages.  I received from great feedback and do have ideas for how to improve the session for future iterations!
• The sessions concluded with Dollars and Dates are Killing Agile by Chris Sterling and Brent Barton.  This was another killer session about working within the traditional cost accounting business structures that we have to live with regardless of whether we want to or not!  One of the best sound bites came from this session: "Real enterprise agile is when you pull projects thru teams rather than form teams to handle projects"

Those sessions would have been enough to justify attending the conference, and I took away some great ideas and made some fantastic connections with other people in the Agile/Lean community.  But throw in the keynotes about Lean Startup from Eric Ries and Josh Kerievsky and my mind was officially blown.  I understand that someone talking away at the front of a room isn't exactly the best method for learning, but both Eric and Josh's talks were riveting, and certainly resonated with me.  Some key points:

• Validated learning is the unit of progress, not some intangible "business value" (Eric)
• A startup is by definition an experiment, which means that it can occur within an established business (Eric)
• Speed is critical, but not just in "getting stuff done" but rather in obtaining enough concrete knowledge to pivot successfully (Eric & Josh)
• Ideas to build, code to measure, data to learn, rinse & repeat (Eric)
• What's important is how quickly you get through that loop, not how well you do any or all of the steps, [although it's assumed that you are at least 'good' at them!]  (Eric)
• When experiments reach diminishing returns, it's time to pivot (Eric)
• "We keep having epiphanies every few days now!" (Josh)
• "We [Industrial Logic] shifted from 'lets try this idea' to 'what's the experiment we are going to do?' (Josh)
• Hypothesis to Happiness instead of Concept to Cash (Josh)

The feeling among many of us there was summed up quite well by Adam Yuret:

The problem with Lean Startup as presented by Eric Ries & Joshua Kerievsky is it makes scrum seem pointless & wasteful.

I believe that I was seeing, for lack of a better phrase, the future of Agile.  The SFAgile conference was the equivalent of the Olduvai Gorge - the evolution of how we organize, plan and do our work is occurring in the Lean Startup movement.

As Josh said in his closing keynote,

If you're riding the Agile Wave turn around and look at the monster wave behind you called Lean Startup.

I'm returning home with a new sense of purpose and direction.  A new world of possibilities has been opened up, and what I knew a week ago as 'mainstream Agile' now seems somewhat quaint.  Many of the 'good things' I learned from XP, Lean, Scrum and Kanban still apply but the philosophy is now different.  The rules and the way the game is played aren't just different - the whole game has been changed, and now we have to learn how to play.

All because I whined a few months ago.

A Survival Guide for New Agile Coaches - It Pays to Lose Sometimes

My son loves to play video games, especially hockey (hey, we're Canadian - the hockey gene isn't recessive here).  He also loves to win, and win big.  He sets up the game so that there's no salary cap and any and all trades among teams are accepted.  He then proceeds to create the most stacked team in the history of the sport, followed by putting the game at its easiest settings.  What follows is a constant stream of hugely lopsided wins.

That's great, right?  His self-esteem must be at an all-time high!  Yes, it is.  It's also complete crap.  In life, we don't always win.  We face constant challenges, and true self-esteem comes from overcoming those challenges and recognizing that even when you don't win you did the best you could.

Coaching Point
While it would be nice if everything went perfectly all the time, life isn't like that.  Software development is even worse - I remember actually experiencing fear when a program compiled the first time without an error!  We learn much more from our mistakes than our successes, and constant learning is essential to delivering the right software at the right time with the right level of quality.

So, if constant learning is essential and we learn more from making mistakes, shouldn't we make mistakes all the time?  Well, yes... sort of.  Big mistakes that aren't visible or acknowledged for a long time aren't good.  Very small mistakes that are caught very quickly and communicated with the team are OK, though, and are a fundamental part of learning.

Small mistakes are small User Stories built to the Product Owner's satisfaction that receive feedback during a demo that means a Story will need to be changed.  Small mistakes can be automated tests that fail because we haven't written the code yet to make them pass!  Small mistakes can be assumptions made about how to approach the development of a certain task that, while programming, are exposed as flawed.  Small mistakes are spikes that are used to determine if a certain technology or approach can even be used to build the software.  Small mistakes allow us to learn without really bad consequences... as long as we learn from them, of course!  Small mistakes are the nesting ground of innovation!

Teams must be empowered to make a constant stream of small mistakes!  They have to feel that it's safe to make a mistake or two without fearing for their reputations or even their jobs.  That's the only effective way that we currently know of for delivering good software without a huge overhead cost, and to deliver truly innovative solutions.

We have salary caps, we can't trade players at will and for the most part we can't tweak the settings of the software development "game" to make it easy.  So, we have a lose a few games along the way in order to learn and thus to be truly successful!

Velocity and Why You Shouldn't Watch It

(Updated June 9, 2011 to clarify relation between points and business value - thanks Mishkin!)

Back in the early mid-90s when I still had some dark hair, I started saving for retirement using the typical approaches of mutual funds and some stocks.  My advisor was my Dad's business partner in an insurance and estate planning company they founded in 1981, so I figured he wasn't going to steer me wrong.  One thing he said really struck me:

Whatever you do, DON'T look at the stock and mutual fund markets every day - you'll drive yourself crazy and make bad decisions!  You have to take a long-term view of your investments, and then you'll be fine.

Now, he wasn't saying don't look at your investments, but rather don't make rash decisions based on small sample sizes.

This same attitude should apply to how we view Velocity in Agile processes.  Velocity is very interesting - it shows value delivered in a certain time period.  Maximizing velocity is also interesting, since more points completed indicates more value delivered to stakeholders (although it's not a direct correlation), and that's a good thing, right?  Sure, but you have to take a medium to long-term view of a team's velocity rather than making decisions based on the velocity of an iteration or two.

Consider this velocity bar chart showing 17 iterations:

This chart shows constant fluctuations in velocity per sprint, which may lead people inside or outside the team to spend time & effort determining why they only achieved 8 points in iterations 1 & 6 and only 7 points in iteration 7!  Similarly, seeing 16 points in iteration 5 could lead to optimistic planning with the expectation of completing more in a release than a team is capable of delivering.

Contrast that view with this chart showing the same data in a line chart format:

You can still see small "ripples" in the line, but this long-term view of how a team is progressing towards a release doesn't show the large fluctuations of the bar chart.  In other words, the bar chart shows a short-term view while the line chart shows the long-term one.  If you were a decision maker for this project, which view would allow you to make better informed decisions about the overall direction?

The work that a team completes represents the investments of a project's stakeholders.  Watching those investments within a very small window of time will "drive them crazy and can cause them to make bad decisions".  Velocity provides an indication of the performance of those investments, but good investment decisions only come when looking at the medium to long term view of their performance.

Practical Agility in Top 200 Agile Blogs List!

I'm proud to say that Practical Agility was #114 in the Top 200 Agile Blogs, a list composed by Peter Saddington on the Agile Scout blog.  Other local (Ottawa, ON) agilists who made the list were Ellen Grove and Mark Levison, as local company Klocwork.

There was also a significant amount of CanCon in addition to the above:

• Leading Answers (Mike Griffiths)
• Agile Advice (Mishkin Berteig)
• Agile Buddy (Jack Milunsky)
• Developsense (Michael Bolton)
• Agilitrix (Michael Sahota)
• Helping Organizations Get Better (Jason Little)
• Analytical-Mind (Martin Proulx)
• The Agile Warrior (Jonathon Rasmussen)
• PlanBox Blog
• Winnipeg Agilist (Steve Rogalsky)
• Thinking Business (Joseph Hurtado)
• TastyCupcakes (Michael McCullough, Don McGreal, and Michael Sahota)
• (Special mention also goes to InfoQ, which originated in Canada)

That's almost 10% of the blogs and news sites originating in Canada.  Not bad, eh? :)

Microtests and TDD Aren't Sufficient

First a couple of clarifying definitions:

• "Microtests" is a term coined by Mike "GeePaw" Hill - it's a synonym for unit test, but avoids the baggage of that term which can mean anything from manual running of code to automated tests that take weeks to write.
• "Tests" in this context are synonymous to the term checks used by some people.

I remember back a decade ago when I was a neophyte in this radical new approach to developing software called Extreme Programming.  At this time in 2001, I had spent about 6 months applying what I had learned from the books Extreme Programming Installed, XP Explained 1st Edition, Refactoring, etc., and hanging around Ward Cunningham's C2 Wiki, and was becoming proficient at the radical new approach to design and development called Test Driven Development.  I have to admit that it took about a good 4 months of dedicated practice to first get over the complete change in paradigm of writing tests first, to being comfortable writing tests, to letting the tests lead the design.  Today, I can't imagine working any other way, although it has been a struggle in a couple of legacy code situations.

I also remember that there was a buzz in the small XP community of the time that we wouldn't need testers anymore because our microtests would solve world hunger, cure cancer and probably fix the southern hemisphere ozone hole as a nice side effect.

Prior to joining the project where I learned about XP, I had the privilege of working with some really, really good testers who worked directly with me - we paired without knowing that it was called pairing. :)  Those people helped me to think much more critically about what I was coding, and that translated directly to much better quality from my code.  Adding the automation aspect of frameworks such as JUnit only served to improve that further.  However, it wasn't enough!

It didn't matter how well I (or anyone I worked with) had tested an individual class or even small collection of classes, the higher level interactions in the system would still have some issues that the microtests may not have covered.  That wasn't a shortcoming of microtests, but rather it was never the intention of that level of tests to cover everything!  Microtests and TDD show that the code is doing what the programmers intended it to do, which of course is very good, but those tests don't and aren't intended to show that the system is doing what the Customer or Product Owner wants it to do.

Fortunately, there were voices in that "we don't need testers anymore" wilderness such as Lisa Crispin, who co-authored Testing Extreme Programming, and ensured that the "programmers only" attitude was as incorrect as the "no documentation" myth.

Microtests and TDD are excellent, excellent practices and enable teams to drive towards zero defects in a very cost effective manner.  You still, need, however, other levels of tests and testing to achieve that goal and to sustain a team's ability to be agile over any extended period of time.