A big thing in software process improvement (urgh) is reducing waste. A great idea, but how do you identify waste?
One powerful method that I use is value stream visualisation. There’s a number of ways of getting information about the value stream ranging from physically walking the chain to simply asking people.
Sounds simple doesn’t it? But one of the best sources of information about wasteful processes and ways of working in a team is simply asking the team what they feel they shouldn’t be spending time on. By freeing up people to actually do their job they can reduce waste and improve productivity. One method I use is to ask each team member to identify a list of n items that they have to spend time on that they think are either entirely or partially wasteful. Basically a list of their impediments. I then anonymize the list look for commonality and then the top few are a reasonable target for improvement.
Alternatively actually walking the path of a piece of work through an organisation can really open the eyes to the sheer number of people and unnecessary waiting involved in some wasteful processes…
Anyway, having got some data I find it useful to visualise it in terms of waiting time and doing time. In Lean-speak cycle time is the time it takes to actually do something, lead time is the time it takes from the request being made to it finally being delivered. In many tasks the lead time far outstrips the cycle time, visualising it can make that very clear.
If you look at all of the tasks in your value chain you might find that many of them look more like this, with very large wasteful waiting times. There are many reasons why there might be a large waiting time, typically the team doing the tasks is over-subscribed, or a team might be protecting it’s SLAs, KPIs or other TLAs. These problems can have significant effects when looking at the system as a whole.
Even more interesting is looking at how these tasks might fit together in a value stream. If we imagine a business function that involves a request moving through a bunch of tasks across a number of teams that have different waiting and doing times a simple sequence of tasks, with a little buffering between them from the Project Manager to allow for schedule variance naturally, might end up looking like this:
Here we have 26 days of actual work spread over almost 60 days (12 weeks) of elapsed time = 40% waste. Even if the person planning the work is willing to accept some risk and try to optimise their workflow a bit without improving the waste inherent in the tasks involved there’s still a lot of waste in the system.
By visualising the value stream in this way we can see straight away (apologies to red/green colour blind folks) that there’s a lot of red, a lot of waste. In many cases planners aren’t willing to accept the risks inherent in overlapping activities as shown here, or aren’t even aware that they can leading to the more sequential path shown above. The result is a minimum time that it takes a request to get done, based on the impedence of the current value chain of, in this case, 38 days before we even start thinking about actually doing any work.
Surely that’s not right.
I’m not a big fan of metrics, measures, charts, reporting and data collection. I’m not terribly impressed by dashboards with 20 little graphs on showing loads of detailed information. When I’m involved in projects I want to know 3 simple things:
- How quick are we doing stuff?
- Are we on track or not?
- Is the stuff good enough quality?
There can be some deep science behind the answers to those questions but at the surface that’s all I want to see.
Organisations need to know that teams are delivering quality products at the right pace to fit the business need. To achieve this goal teams need to be able to demonstrate that their product is of sufficient quality and that they can commit to delivering the required scope within the business time scales. If the project goal may not be achieved then the business or the team need to change something (such as scope, resources or time scales). This feedback mechanism and the open transparent communication of this knowledge is key to the success of agile delivery.
The goal of delivering quality products at the right pace can be measured in many complex ways however, when designing the Project Forum agile at scale practice we looked at just 3 measures. In fact I should probably call them 2.5 measures as the throughput/release burnup can be considered mutually exclusive (if you’re continuous flow or iterative). The most important measure is people’s opinions when you go and talk to your team.
Note: in the measures section I often refer to “requirements” as a simple number, this could be a count, a normalised count, magnitude, points, etc. it doesn’t matter what’s used so long as it’s consistent.
I recently spent a little while thinking about an open, transparent and honest way to deal with innovation/staff objectives/supporting work in a small company. Note that this isn’t what my current employer does, just an idea for how these things can be done.
Firstly people need time to do this stuff, if it’s valuable for your organisation to spend time doing supporting work, intellectual property development or general innovation then they need the time to do it. People need the Google 20%. I’m very fortunate that in my job I get that time, or close to it normally.
Create a wiki page or similar somewhere (that everyone can see and everyone can edit) – a bit like the Google ideas wall. Start it with a freeform/categorised ideas list in the form, this is a bit like a backlog, once an ideas done/delivered/published it drops off this list
Ideas – Owner – State:
Idea for doing something – Mike – Identified
Idea for taking over the world – Unassigned – Identified
If someone like one of these ideas they can run with it, recruit a team of colleagues if necessary and get on with it. Once I’ve asked someone to help with my idea I can be fairly sure they’ll ask for reciprocal help on something. This improves teaming in distributed companies and provides a channel for autonomous action, critical for motivation.
In Progress Ideas:
When ideas are in progress they’ll have their own tracking and information in the appropriate technology. For example a blog idea probably goes from being picked up to being published without any tracking. Maybe there’s a review process if it’s a big position piece so it might go through Identified to In Review on the list above but that’s it. Another idea might be for the development of some software, in which case it’ll take some time and probably have a project web and bunch of tools and info to communicate.
Complete bits of work:
Once something has been done the owner can add it to the achievements table, a column for each person where they can list what they’ve done with links to the various bits of output.
|Person A||Person B||Person C|
|Blah Practice published||Blog series on X|
|Paper published on Y|
All bits of achievement aren’t the same size, but this allows people to see the creativity and production of their colleagues and find all of the useful things people have been doing. It also applies some peer pressure to Person C who on the face of it doesn’t appear to be adding much, although there could be a good reason for that.
Why did I say all this was agile?
Individuals and interactions over processes and tools
Individuals ideas are valued and encouraged, as are their achievements. People are encouraged to help each other and work together on ideas. There’s very little process and tooling involved, just a list on a wiki. If I had a co-located team I’d just use some whiteboard paint on a wall or some post-its.
Working software over comprehensive documentation
Well we’re not talking about software here, but achieving ideas. The emphasis is on the achievements table, not the detail of how people go there. In progress ideas can be tracked and reported using whatever info is relevant for the type of thing being done, which can be determined by the people doing it.
Customer collaboration over contract negotiation
This is an open and transparent process. Anyone can comment on the ideas on the list have a look at in progress ideas or question published/achieved goals.
Responding to change over following a plan
All this stuff is just written down, it would be easy to rewrite it if things changed. People, ideas, the environment etc. will all change so we need to be responsive to too and not plan the next 50 ideas to the hour.
Since the list at the top is a bit like a backlog, it could be managed with input from management to direct the backlog, prioritise and agree. But I’d be wary of applying that kind of governance to creative/innovative ideas. I’m not proposing this as a general work management process, just an ideas/ancillary objectives process. Remember, bad management kills great ideas and worse this kind of management intervention stifles bad ideas, which are necessary and valuable.
Also, there are few things worse in life than an “Ideas Process”
I’ve recently been writing an article on Governance in IT organisations and thought I’d publish the introduction here. The article goes on to discuss Strategic Frameworks and Processes, Governance Functions, Roles and Rights, Data Analysis and Remediation Mechanisms and will probably be made public sooner or later when I finish writing it!
“Governance” is defined as the means by which the leading authority guides and monitors the values and goals of an organization.
Because this definition uses some very broad terms such as “leading authority” and “organization” it is possible to apply the concept of governance recursively in IT organizations. There is governance in teams, projects, programmes, portfolios, departments and any other organizational unit.
Governance strategies are most effective when they are designed and explicit. In the absence of cohesive integrated governance between these various organizational layers the values and goals of an organization can become emergent due to the lack of a clear connection between the executive strategy and the work being executed at the coal face. This situation is typified by project practitioners being unaware of how their work relates and contributes to the global strategy and layers in between.
The “means” referred to in the definition above refer to practices, processes, procedures, standards, rules and criteria related to the execution of business decisions executed by real people within their tool environments.
Effective governance relies on known standards for strategic management, programme and portfolio management as well as project management and execution. This enables individuals in an organization to make the right decisions at the right time based on accurate data. Governance is often described as a mechanism for empowering individuals with the rights they should have and a clear delineation and integration of these rights from the rights exercised by other roles. Because governance strategies can involve a lot of data process management based on data analysis there is a strong case for automating parts of a governance strategy with tools.