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.
Invariably, when presenting or teaching about applying Agile principles in organizations, someone always asks me, “are there places where you can’t be Agile?” or ”how do you decide whether or not you want to be Agile?”. These questions trouble me, as it seems like we’re offering a false binary choice. Either you are “Agile” or you aren’t. This perspective fails to communicate the nuance that, when considering an organization, there is a spectrum of Agility and the question really becomes, “how Agile can we make our organization?”
[Read more...]
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.
The Agile Super Coach
Of all the abused words in the Agile domain, none seems to be more abused than the simple word “coaching”. There are numerous people out there professing to be “agile coaches”, and while I don’t mean to denigrate what any of these people do, there is a very broad latitude in the types of things that they do. This can further confound our ability to work with organizations as there may be a disconnect between coaches and clients about what exactly they are doing.
Unfortunately, in the absence of a clear understanding, I have seen people begin to expect that the “Agile Coach” is nothing short of a super human being. The can swoop into any project, turn around the results, and simultaneously coach that group into effectively preventing all those problems from ever occurring again. Or they may have an unnecessarily narrow view of the role and try to put an Agile Coach in a box by insisting they only do training, for example. To be fair, when I encounter these missed expectations, they are usually my own fault. I did not do a good enough job of articulating what the role is I, or anyone else, would potentially be playing in that organization as an Agile Coach.
I can’t profess to be the keeper of truth on this topic, but here’s a model I’ve used to help organize my own activities and to make sure I’m articulating clearly what role I see myself playing.
|
||
| © 2012 BigVisible® Solutions, Inc. All rights reserved. | About BigVisible | Integrated Coaching | Training Classes | Blog | Contact Us | Careers | Subscribe | Events |