In the last month, two widely different events reinforced a few things I had been thinking about. The first was my going to Virginia to help a small startup. The second was a presentation at our monthly meetup by Jeff Schwalb, a computer scientist with 20+ years of experience in software systems.
The organizations surrounding these events could not be more different. The startup consisted of four people, two in the UK, two in the US. The second is from a gentlemen associated with a large government institution, NAVAIR. The NAVAIR job site tells me they have, “…[a] team of more than more than 37,000 civilians, military members and contractors in nine major sites across the U.S. and Japan…”.
Before I go on, let me be clear that Jeff Schwalb was NOT speaking on behalf of NAVAIR. So why did I bring up the organizations? Answer: Stereotypes and our biases.
We are tempted to see these organizations as lean and focused, or large and bureaucratic and to some extent, that may be true. However, our stereotypes and biases may cause us to begin implementing processes and procedures that add little or no value. And that is what I found in common.
When we analyze our organizations needs, we must avoid allowing our preconceptions to color our judgement. In the good old days, we called this a gap analysis. The steps are pretty simple.
1. Talk to and listen to the people involved – What are the problems they perceive and what are you noticing?
2. Compare what you have heard directly with the Agile Manifesto and the 12 Agile principles and do a “retrospective” – what’s going well, what’s not going well? How can this inform our next steps?
These steps bring us back to basic truths and sound principles. The 20-year-old book and Agile documents contain truths and principles that withstand fads. Real truth centers us. Tools and techniques may come and go and may or may not be valid for an organization at any particular moment.
By directly mapping what we are hearing to the philosophies of the Manifesto and Principles behind it, we anchor what are we doing and why are we doing it in the proven realities of Agile. We move from opinion to grounded facts. It separates the noise of circumstance from the basics of Agile.
3. Talk to and listen to the client – What processes do they follow now?
4. Talk to and listen to the client – What is the culture of the organization and what needs to change in the culture to get us to the next steps?
Here is the upshot. Implementation of any change is the tough part. Agile Coach Dave McKenna reminds us, “It’s that icky human stuff that is so hard.”
And now common sense.
Part of Jeff Schwalb’s presentation cautioned about collecting data and calculating metrics that will not be used as well as a one size process does NOT fit all.
There were a lot of things the startup might have done. Communications, process, and metrics were amongst them. Yes, we talked about Scrum as a framework for delivering value, Sprints to time box their efforts and roles to help clarify who was ultimately responsible, but the most important thing for them at that moment was deliverable prioritization.
By putting up all the product functions AND keep the lights on activities, we prioritized the
highest business value work and set up some sprint goals for the next two sprints. We took
some pressure off of delivering less valuable work. The discussions about Scrum and roles
were important in that it gave a bit of structure. That said, the focus was on firmly on business value of the deliverables.
Did we accomplish every change we discovered when we mapped against our principles?
Nope. And never would. People don’t (can’t?) change and adjust that fast. Will we start
looking at data gathering and metrics in the future? Sure. I can assure you when we do, we’ll
apply Mark Twain’s advice, “Data is like garbage, you should know what you’re going to do with it before you collect it.”