|Do We Need Points To Generate a Release Burn-up Chart?||2016/02/16 13:06||Hans Peter Samios|
|Why Should We Work Harder to Eliminate the Effect of Dependencies?||2016/02/12 09:43||Hans Peter Samios|
|Why a Plan Based on Average Velocity Will Fail?||2016/02/11 11:19||Hans Peter Samios|
One thing we talk about with agile is the idea of continuous or relentless improvement. Most organizations want to improve, but like a lot of things it is sometimes hard to feel good about the improvements you are making. Further it is hard to establish a continuous practice where the whole organization is doing these improvements and feeling good about it.
One tool that I've seen helps organizations is to treat improvements as experiments and talk about them this way. The traditional approach to capturing improvement is to set up SMART goals. The problem I have with this approach is that we are treating the improvement as a conclusion (it will result in the improvement we expect - its deterministic) rather than recognizing that the new approach might in fact result in no improvement. And when this happens the thinking is that you have “failed” because you did not meet your goal.
Learning is not failure. And to capture this instead of talking about a change or an improvement we set up an experiment.
To define a good experiment we need a definition of what the experiment is, what the expected result is, what the result actually turned out to be, what we learned, and what we will do as a result. This is the scientific method.
And I would then maintain a list of experiments we have run somewhere in order allow others to learn from our experience.
So, for example, during a transformation to agile, we might want to understand whether the idea of a “True Team” (see Why Do We Form Teams When We Transition To Agile?) actually is a concept that works in our organization. We could setup and experiment as follows:
Then, when the time box is finished, we collect the result, and determine what we learned and what we do next. (Hopefully in this case you got the expected, positive result:-))
Experiments can be done at all levels. Teams can set them up as part of a retrospective. Transformation coalitions can set them up as a result of their retrospectives. If you are doing SAFe experiments would be generated as part of a the Inspect and Adapt. And so on.
Using this approach at whatever level you operate at helps you become a “learning organization” where experiments are seen as a normal part of the work you do. The vocabulary will help and assists by making change less threatening (more “try it and see” and less “you will do it this way”). In particular we want to treat new understanding as a “success” (and publish it as a “win”) to aid the momentum. It also like to encourages a spirit of experimentation beyond just “lets try it!” (said in giggly tone). Experiments should be aimed at generating useful knowledge.
I came across this article by Mary Poppendieck recently called "The End of Enterprise IT". Mary is truly a thought leader - I find that she is able to cover topics that I am thinking about with tremendous transparency and focus. Mary tells the story of an agile transformation at ING Bank. ING Bank went to Agile in their IT organization and while they saw benefits, they did not feel like they were getting the transformative results they really needed. In particular, they felt that while their business people were “involved” with the IT organization they were not really aligned in the mission.
The leadership of ING Bank looked at their organization and came to a startling conclusion. We all know that according to Marc Andreessen "software is eating the world". From Mary, ING Bank took this to the next logical step:
“The leadership team at ING Netherlands had examined its business model and come to an interesting conclusion: their bank was no longer a financial services company, it was a technology company in the financial services business.”
What this meant was that in order to compete, in order to be the bank they wanted to be, they needed to set themselves up more like a technology company where good engineering is a necessity. “Engineering is about using technology to solve tough problems; problems like how can we process a mortgage with a minimum of hassle for customers? How can we reduce the cost of currency exchange and still make a profit?”
They found that technology companies did not have Enterprise IT organizations. And “even though they were much bigger than any bank” they did not “have much of a hierarchical structure.” “Instead, they were organized in teams – or squads – that had a common purpose, worked closely with customers, and decided for themselves how they would accomplish their purpose.” Business, engineers, everyone, all aligned.
As a result, ING Bank “chose to adopt an organizational structure in which small teams – ING calls them squads – accept end-to-end responsibility for a consumer-focused mission. Squads are expected to make their own decisions based on a shared purpose, the insight of their members, and rapid feedback from their work. Squads are grouped into tribes of perhaps 150 people that share a value stream (e.g. mortgages), and within each tribe, chapter leads provide functional leadership. Along with the new organizational structure, ING’s leadership team worked to create a culture that values technical excellence, experimentation, and customer-centricity”
When I work transformations with organizations, too often we see it applied just to the IT shop. Now don't get me wrong, things usually improve when you do this both in terms of the business results and the way people work. But the issues that then remain are often where the business intersects with the IT shop. To me, ING Bank thinking represents a way to address this. More importantly if you are in a business where a lot of what you do is driven by computers or programs, then perhaps you need to look a little closer at your business and determine if your thinking needs to shift to be “a technology company in the X (e.g. financial services, insurance, etc) business.”
One of my favorite quotes about an agile transformation is “If you think Scrum (/ Agile / SAFe) is easy, just try it”. I have no idea who said it first, but it captures a lot. Done right, the move to agile will make visible all the problems you currently have, and then gives you a couple of weeks to make progress on them. While this is all going on there are subtle shifts in the thinking process that you have, which adds to the confusion (for more see What Are The Changes in Culture That Need To Happen with Agile?)
But under all this, I think there is something more subtle going on and that is the difference between “knowing” something and truly understanding that thing. A colleague recently sent me a video that really helped me understand the difference:
Clearly “knowledge” is not the same as “understanding.” But I think there are a number of other interesting lessons from this video:
Since most of us have been working software development for a lot of years, is it any surprise that we have difficulty changing how we think about the problem?
This is what I got out of the video - what else did you learn?