February 4, 2012

BigVisible Blog

Validated Learning in Agile Projects

A recent question about sprint goals got me thinking about the lean startup concept known as “validated learning” and how something like this applies to agile projects. Eric Ries describes the concept of validated learning as:

 

“not after-the-fact rationalization or a good story designed to hide failure. It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow. Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects.”
Ries, Eric (2011-09-13). The Lean Startup (p. 38). Random House, Inc.. Kindle Edition.

At first blush it seems this concept is just made to be utilized by teams working in an iterative manner. They can define sprints, validate learning, and adjust course. The challenge is that validated learning is more than just conjecture or forecasts, this means we must align the product of sprints with empirical, measurable goals. Enter the sprint goal.

[Read more...]

Candy Driven Development

Ever walk into the kitchen of a technology company? Chances are you’ll find a mind boggling supply of candy, snacks, treats and a variety of caffeinated drinks. One could just pass this off as the bad eating habits of pale geeks who go home after work and live in their parent’s basements, but I’m beginning to believe something deeper is at work here.

New research leads me to believe that we may be collectively suffering from ego depletion.

Ego depletion is the idea that self-control or willpower is an exhaustible resource that can be used up. Interestingly enough, sugar (or glucose) intake helps us prolong our ability to make decision after decision throughout the day.

Initially it sounds far fetched, until you think about all of the decisions you make throughout a work day and how they correlate with your sugar intake.

Consider the number of decisions you had to make in order to get to work this morning. Now once you’ve sat down and booted up your machine, imagine how many decisions you make before you start to even code. After you’ve started coding (or writing your tests if practicing TDD) imagine how many decisions you continue make in the span of just 1 minute.

If you do the math you begin to realize that you make a staggering amount of decisions throughout the course of just one work day. Many of these decisions are under pressure with serious implications.

In addition to ego depletion, research has found that these decisions can be broken down into pre-decision and post-decision processes.

A prolonged period of pre-decision is not ideal for a team that thrives on quick feedback loops.

I believe we can use this new found research to help our teams be in situations where they can make the best decision possible.

Daily Standups - Urge agile teams to have the daily standup in the morning if possible. It is our daily plan and we need our team focused as we make decisions on what we are about to do.

Retrospectives - Bring candy or snacks into the retrospective. Team members are more likely to forget their manners when suffering from ego depletion. It isn’t just people, it even happens with man’s best friend too.

Iteration Demos - Schedule these early and bring muffins, donuts or pastries along with some form of juice. If the Product Owner is accepting the work, he or she needs to have the mental fuel to make the tough decisions.

Feedback Loops - How long does it take to compile and run tests locally? How long does it take to deploy a build to test or production? How long does it take to get an answer from the business on feature question? All of these affect pre-decision time spans and deplete willpower.

I believe if we can align our agile and scrum coaching techniques with these findings, the result will be a team that is in an environment where they can repeatedly make good decisions.

The Journey from Analyst to Product Owner

I owe a special thanks to my colleague Jason Novack for pairing with me recently on a presentation to the Boston International Institute of Business Analysts (IIBA) about making the leap from business analyst to a product owner. It was a great experience that really got me thinking about some of the journeys I’ve seen analysts go through as they moved into Agile teams and began playing the role of Product Owner. This blog encapsulates some of the concepts we came up with in that discussion and the archetypes I’ve seen for behaviors that these people go through, specifically analysts from large organizations that find themselves dropped into the role of product owner.

[Read more...]

Business Analyst to Product Owner – Making the leap

The Product Owner is a key player in Scrum, yet there is confusion around the true value and responsibilities of this important role. Many companies have difficulty staffing it. Oftentimes Analysts are called upon to assume Product Owner responsibilities, without much clear direction. Some think of the PO role as “an analyst on steroids”. While there is indeed some common ground, in reality, the two roles face drastically different sets of expectations. Part of the challenge isn’t just successfully taking on the role, but how to succeed at building great products. With roughly 60% of the features in the average product rarely if ever used, as an industry we have an obligation to figure out how to build better products.

This presentation was given at the Boston chapter of the IIBA on November 2 and covers some important common experience that good Product Owners have, 5 Archetypes of Product Owners and the growth opportunities for each of them and 4 areas to focus on to grow as a Product Owner to help not only transition to a new role, but to truly make the leap and place innovation front and center.

The slides are available here.

One Week Down, Two Weeks Behind

“Hey, man! One week down, two weeks behind…” -Kirk Lazarous, Tropic Thunder (2008)

While not a terribly serious movie, I have always enjoyed this quote from the comedy movie about the ill fated making of a war movie. The concept of being only one week into a project, and yet somehow already two weeks behind seems so absurd as to be impossible, and yet it has been the reality for a lot of projects encountered. Invariably, ambitions around projects can get so high, with so many stakeholders that our definition of success rapidly becomes so great we watch the possibility of completing our project recede into the horizon. Properly defining and then managing project success is a critical activity in any project. There are a number of excellent resources I’ve drawn upon over the years to do this. This blog post is more a compilation of my thinking on this topic threading through some of these techniques. [Read more...]

The Product Backlog, an Agile WBS

As one of the community leaders for the PMI Agile Community of Practice – unfortunately nicknamed “COP” – I’ve found myself writing articles that end up behind their log on. This article is one of those such instances. For those of you who are members of the PMI, I would encourage you to join the community of practice, as it is becoming a very vibrant online community of project managers looking to apply Agile values and principles to their craft. For those of you who aren’t, I will cross-post here from time to time. Articles like his I find to be very important in helping to establish that much of the material presented by the PMI is not so much incorrect as frequently poorly applied. In this case, we see that there is nothing in the formal definition of a WBS that would prevent it from being used as a product backlog [Read more...]

The Building Blocks of a Project Pipeline

Scrum is a great framework for building systems, it is simple, elegant and effective. However, it has one limitation that most teams quickly run into: small team size. Invariably, most major initiatives and programs require more than 7, plus or minus 2 people, in order to complete the work in a reasonable amount of time. Or, some organizations face the flip side of this where they run so many projects that the idea of dedicating half a dozen people full time to one initiative is overwhelming. In either case, these organizations are facing the challenge of managing a product pipeline. Let’s take a look at some of the techniques available to manage this within an Agile program.  [Read more...]