A collection of incredibly impressive thinkers and leaders from around the world has converged in Boston for the Lean Software & Systems Conference. This issue covers some of the many takeaways ….
News
Sunday’s Lean Camp (facilitated by Jim Benson) provided some amazing eye openers. First, an opportunity to study two large Kanban implementations and discuss why one saw viral spread and the other didn’t. Next, we played Russell Healy’s new Kanban system design game for Operations teams. Lastly, Jason Yip facilitated a well attended session on learning. Takeaway - put yourself in uncomfortable settings to learn - else you risk falling back into your comfort zone.
Day 1
The opening keynote with Steven Spear focused on achieving greatness through learning.
Spear suggests, “Find out what’s wrong with what you are doing and go tell a friend.” An appealing storyteller, he demonstrates the need for senior leaders to demonstrate their need for more knowledge to motivate people to learn.
David Joyce kicked off the Kanban track Monday morning with a talk on moving beyond the traditional PMO to 21st century portfolio management. Takeaway – Include a “Study” column at the beginning of the board.
Lightening and Ignite talks enlightened us all quickly! Simon Marcus, @lycaonmarcus voiced his concern on the current trend of management bashing. Between @stevenspear’s keynote and Simon’s lightening talk, my interpretation is the following if then statement:
if management is asking why
and not dictating
then don’t bash
Videos from talks will be available through lssc. In the meantime, slides from some talks have been posted on slideshare
Day 2 Troy Magennis incited discussions on how teams can work with upper management to get reliable estimates using the monte carlo simulation. Takeaway – The average is the worst value to use.
Mary Poppendieck’s talk on continuous feedback included an engaging and interactive discussion followed on set-based decision making versus Multiple Viable Product and a/b experiments.
Takeaway – These are not mutually exclusive, we just know when to do one or the other.
Day 3 Don Reinertsen rocked the main stage with his talk on decentralizing control. Taking examples from the US military and the forest fire service, there are too many takeaways to list, but here are my top three:
The important communication is lateral, and not from the top.
You have a duty to disagree if you believe otherwise.
If you think you can eliminate uncertainty, you’re delusional.
Next week the Lean Software and Systems conference in Boston will undoubtedly supply a plethora of buzz. Until then, here’s a series of blog posts from some prolific writers.
Four, yes that’s 4, new blog posts by David J Anderson on topics ranging from extending core Kanban practices to lack of roles to “certifying” trainers. Check them out. http://agilemanagement.net/index.php
Yesterday’s post was inspired by my recent bike rides around my home neighborhood in Clallam County, Washington. I typically ride the last few miles home on the Discovery Trail - a bike path crafted out of an abandoned railway line that ran from Port Angeles to Sequim and on toward Discovery Bay. About 5 miles from home, the path is cut by a gravel road inside the Carlsborg, WA, industrial park. Recently, the road was resurfaced with rather course gravel, some of the small rocks measuring 1”-2” in size - fine for trucks, not so easy for a racing bike with 25mm tires. When I hit the road spinning at about 20 mph, I had only few seconds before hand to recognize the resurfacing work. I didn’t anticipate how chunky some of it was going to be. As I hit it my bike started to shake violently and bounce left and right.
My instinct was to grip tighter - to force more control. Instinctively I wanted to keep the bike moving forward within a very narrow band of variation to the left or right. But I had to fight that instinct, to loosen my grip and let go of the handle bars. I had to let the bike shake left and right - i had enough momentum to get across the rough gravel and safely onto the smooth bike path on the far side. To grip too tightly, to fight the wild oscillations would be to risk making the bike unstable and tipping over - a nasty road rash awaits the unlucky cyclists who tries too hard. Sometimes we have to loosen our grip. We need to be tolerant to variation. We need to ride with a loose rein.
Parents reading this will recognize the parental advice - children controlled too tightly react unpredictably and ultimately rebel. We have to learn to let go if we want our organizations to be stable. We need to recognize that we’ll get knocked left and right in the short term but it’s the longer term trend that interests us. Loosen your grip and ride the bumps - don’t crash and burn in a vain attempt at control!
My father was a real engineer. He used to get his hands dirty with machinery. He was a machinist (a turner) by trade. He spent much of the latter part of his career commissioning plant and machinery at an explosives factory. Often he or his colleagues would hand craft some of the manufacturing tools with their own machine tools. He spent a lot of time thinking about tolerances. The tolerance in the actual size of a machined part, or a manufactured component, from its specification. These are typical measured in microns, or in his younger days, fractions of an inch. In his broad Glasgow brogue he’d talk of “thous.” Precision was important but like all engineers he was a pragmatist. Perfection wasn’t necessary - near enough was good enough. I worry that recent trends in the Agile community are losing sight of the inherent pragmatism seen in engineers like my father…
Over the last four or five years, I see ever greater focus on planning and estimation and ever more elaborate methods for sizing, prioritizing and planning work. We seem to be trying to be very precise about commitments. We’re not embracing the natural variation that is inherent in software development. We are creating specifications with very little tolerance and the band of acceptable tolerance is almost certainly too tight to be practical.
Software development has inherently large amounts of common cause variation. I see velocity trend reports that commonly show variation of a factor of 2 above and below a mean, e.g. a mean of 20 story points per sprint may exhibit a variation from as little as 10 to as high as 40. However, we persist in making commitments that are not tolerant to the nature of our work. We relentlessly pursue precision in order to make better plans to improve our chances of delivering on our commitments.
I see the Agile community pursuing a vicious spiral and ironically aping the mistakes of an earlier era - it’s just the practices and techniques that are different. New tribe, new set of tribal rituals, same old mistakes! These elaborate estimation and prioritization methods are an attempt to bring a level of deterministic planning to Agile development, with a level of precision that is not possible given the nature of the work. Making commitments with a narrow tolerance is setting ourselves up for failure and attempts to drive out the variation through every more elaborate methods of planning is simply waste. The variation cannot be eliminated. It must be embraced!
Meanwhile, I predict many will spend more time in training learning these elaborate techniques. Already there are certifications in such activities and doubtless more will emerge. More and more time will be spent planning Agile software development. More time will be spent analyzing user stories, though this activity is disguised by calling it “estimation.” And perhaps it won’t be so long before we’re back where we started, asking ourselves, “When are we actually going to build some software?”
When we announced the Accredited Kanban Training program in Lean Kanban University in February some people initially believed we were announcing a certification scheme for individuals taking Kanban training. We were not! Instead we were introducing standards into Kanban training by introducing a defined curriculum and accredited training material against that curriculum. We were also providing a professional designation of Accredited Kanban Trainer (AKT) to those individuals that we believed to be qualified to teach the curriculum adequately. We were “certifying” trainers.
Certification of a Role
Certification schemes tend to attach to roles played by individuals. Certified Scrummaster is an acknowledgement of some level of knowledge for playing the role of Scrummaster. Scrum has two roles, Scrummaster and Product Owner and two widely offered certifications - Certified Scrummaster and Certified Scrum Product Owner. There are also Certified Scrum Coach and Certified Scrum Trainer. I’m picking on Scrum as an example but many other methods and professions certify roles played at some level of proficiency or capability.
Certification in Kanban
There are members of LKU who wanted to introduce a certification scheme for individuals. In the current economy, all of our businesses need something to make it a little easier. Certifications do attract customers. People like to have professional recognition and a certification and some letters to put after your name, is one way of achieving such recognition. Under pressure in the meeting at the Hilton Royal Parc in Netherlands, I simply replied, “What are we certifying?” And that was the end of the discussion. Kanban defines and prescribes no roles. As I explained last week, this lack of roles is a strength. So, I will not be adding roles for the convenience of creating a certification scheme to make training companies money. Without roles, how do you create a certification scheme for individuals taking Kanban training?
As I stated last week, there is a role to played in the change management approach called the Kanban Method - the role of change agent - the person who leads the Kanban initiative and either facilitates or takes responsibility for the kanban system design. Might we be able to certify change agents who use the Kanban Method? Food for thought!
