Frog thinkers and bicycle thinkers.
A delightful metaphor that cuts to the heart of systems thinking.
Thanks to Richard for sharing!
There are two types of thinkers in the world, frog thinkers and bike thinkers
This to me is the heart of systems thinking Read more at www.richarddurnall.com
As a manager define outputs, not process
Liz haz written a great post here describing a situation where the deployment team needed to learn for to leverage the development team to achieve a more effective rout out of development into QA and live environments.
The line that made me smile was -
Ask for consistent outputs, not consistent processes
This is a big leap for many managers and senior stake-holders. I worked with a team recently who had been told to do daily stand-up meetings. They were told that each must answer three questions (you know the three, what yesterday, what next and what’s blocking). The teams manager had a team member minute the meeting and send him an e-mail to save time.
I was asked to have a chat with the team about why they seemed unhappy with this new “agile” approach. The first step was to invite the manager to write a contract in terms of his information requirements and agree that so long as the team could fulfil the contract he would accept their approach.
A short retrospective later and the team are posting key information on a board for all including the manager to see, the minuting of the meeting has stopped and they have taken back their stand-up whic it turns out they quite liked now it could move faster without minuting.
So thanks for the reminder Liz and thanks for sharing.
Ask for consistent outputs, not consistent processes
Read more at lizkeogh.com
The lean manager
Some insights from Jim Womack on the nature of a lean manager.
Tools — for process analysis and for management — are wonderful things. And they are absolutely necessary. And managers love them because they seem to provide short cuts to doing a better job. But they can’t achieve their potential results, and often can’t achieve any results, without managers with a lean state of mind to wield them.
the lean manager eagerly embraces the role of problem solver.
no manager at a higher level can or should solve a problem at a lower level
the lean manager believes that all problem solving is about experimentation by means of Plan Do Check Act
the lean manager knows that no problem is ever solved foreverRead more at www.lean.org
Valtech UK Blog
Valtech now have a blog that aggregates from my own blog and those of a number of colleagues.
There are some smart guys on there and more have promised to contribute so I suggest you take a look and stay in touch as more consultants are added.
5 wrong reasons to adopt Kanban
All true!
I see a significant risk that Kanban becomes a new and exciting way for teams to fail.
I do believe that there are good reasons to apply a Kanban approach but more on that another day.
#1. User Stories Diversity
#2. Failed Iterations
#3. Failed Retrospective Meetings
#4. Shared People / Functional Departments
#5. Simplicity
5 Wrong Reasons To Apply Kanban
Read more at www.targetprocess.com
Scrum meeting late fees
It’s good to see someone speaking out against this practice.
Also nice to see Rachel and Tobias chiming in.
Punishing lateness avoids the root cause and can breed resentment as the team feel that the process is being imposed.
In order to deter people from showing up late to their daily “Scrum” or “stand-up” meeting, some teams charge the culprit(s) a fine, or make them do some embarrassing activity (such as singing) for the team. Some teams use the money to buy lunch for the team once a month or so. (If that’s you: Please stop it! You’re rewarding the wrong behavior.)
Tweetboard up and running
I’m experimenting with tweetboard. Take a look here if you’re interested or follow the link above.
Drop me a line if you visit, if only to let me know if the thing is working 
What is Agile?
I met with a potential client last week and found my self answering the question, “what, in a nutshell, does agile mean?”.
To date I’ve never had a canned answer to this and can come from various directions perhaps talking about the history and how it’s an umbrella term for a whole bunch of things or maybe talk about what it’s like working on an agile team. On this occasion I was quite pleased with the answer that fell out:
Agile is about delivering business value!
Businesses tend to exist in a state of constant change so if we want to deliver something valuable to them then we need to be willing and able to embrace that change and deliver quickly.
In order to deliver quickly and deal with change we have found that quality is a necessary. This is particularly true if we want to continue to deliver over a sustained period.
At the bottom of this stack, underpinning all the elements mentioned so far is the need to treat workers with respect and empower them to do the right thing. Without this you wont achieve the quality or speed that you need.
So:
Value <- Embrace Change <- Quality <- Respect & Empowerment.
Is there any more to it?
To SCRUM or to Kanban? – Which one fits.
SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find that Lean Thinking can both help me communicate Scrum and help teams to become more effective in applying Scrum. This way of thinking led to me becoming interested in Kanban a year or so ago since when I’ve being most concerned with where I ought to recommend Scrum and where Kanban.
Recently I have spent time with maintenance groups for whom Scrum would be a poor fit. Kanban offered me an alternative when the client was leaning towards a ScrumBut implementation.
There are some fundamental differences between early project / product development work and the later stages and I don’t see this as a problem. Toyota themselves hold two separate approaches. The Toyota Production System (TPS) is the most widely known Lean Manufacturing implementation. This is the world of work cells, standardised work, Kanban boards and Andon lights. However, when Toyota want to create something new they use the Toyota Product Development System. This approach focuses on a chief engineer holding a vision and rallying a team around him. High bandwidth communication, discovery and experimentation are the order of the day.
So back in a software development context Scrum was designed to manage uncertainty and complexity, to foster high band width communication and seems a valuable fit for early development.
Corey Ladas in his ScrumBan Book declares the following Axiom for applying his application of Lean to software development
Axiom 2: It is possible to develop any value adding increment in a continuous flow from requirement to deployment
Corey makes it clear as he progresses that this well defined workflow is critical to his desired approach. In a new development that workflow is often not known and usually not linear. Rather the team swarm over the requirement often returning to the customer for feedback before offering a completed deployable feature.
My suggestion is this, Scrum is a powerful approach to managing uncertainty as well as being a supportive environment for building a team. I believe that one goal of product development should be to reduce the uncertainty and evolve the workflow. As adding features becomes more straightforward we may find that we are in a state akin to production and can take advantage of a Kanban approach to further optimise for reduced cycle time, increased throughput and just in time scheduling.
Prioritisation with MMFs
For the majority of agile teams user stories are the preferred tool for requirements management. User stories provide numerous benefits including; a focus on the business problem being solved, a just in time approach to specification, amenability to splitting that supports working in short time-boxes.
The problem with user stories in practice is that the desire to work in short cycles drives teams to split stories to a degree that they can loose sight of the value element from the perspective of a customer or product owner. This is often alleviated through themes or story hierarchies but maybe there is a better way.
The minimum marketable feature (MMF) provides a connection between the high level vision of the project and the detailed user story.
According to Software by Numbers a Minimal Marketable Feature is:
… a chunk of functionality that delivers a subset of the customers requirements and that is capable of returning value to the customer when released as an independent entity.
I have found that this construct offers a powerful approach to assessing, understanding and prioritising feature sets. I believe that the benefits of considering MMFs applies to both software projects and product development activities. Due to the focus that is placed on the need rather than the solution this technique continues to apply where we consider projects with little bespoke software.
In essence given some form of need we must pursue it’s decomposition repeating the challenge; “is the described feature or feature set really so minimal as to be un-deployable should any aspect be missing”. We gain further benefit by asking; “is there any aspect of this specification that is over specified”.
I guess at this stage an example is called for. Imagine for a moment that I am a traditional retailer considering gaining a web presence. I have a vision to develop an online presence in order to increase revenue by attracting a wider customer base.
I can begin assessing my need and decomposing features while ensuring that the resultant chunk remains marketable.
MMF 0
Help prospective customers find out about the business through basic online presence.
MMF 1
Enable online purchasing of restricted set of products
Offer a single form of payment
MMF 2
Broaden product range
MMF 3
Increase payment options
MMF 4
Make special time limited offers
MMF 5
Provide vouchers to encourage repeat custom
I am still experimenting with this approach, however, it seems that as a product increases in maturity MMFs can reduce in size (probably to the point where stories would be adequate). It is early in the process where we can get the most value.
In my experience release planning is an area of weakness for many organisations. Releases are large for a variety of reasons including funding, deployment effort and fear of not getting what you really want. I believe that an aspect of this is that once assigned a project it’s team want it to live on independent of the rest of the organisations portfolio. Applying an MMF approach should ease the job of portfolio management since MMFs have a very tangible value proposition.
