Tag Archives: lean

Attack Risk before it Attacks You!

  By coheocha | February 10, 2011 - 7:45 AM | ,
Leave a comment

Risk undermines predictability in software development – every development effort includes some unknowns. Some development is relatively risk free – for example, writting another driver that is 90% the same as one done previously, but just using a different interface signature. But most involve considerable risk – technology you haven’t used before, or a new domain, or a backend system you’ve never had to integrate with previously. Often these unknown aspects are left to late in the project – we naturally tend to do the easiest things first – it gives us a feeling of progress, and puts off the ‘hard’ work till another day. But this approach just stores up risk in the project. We often see this at the end of a project or release cycle, where the problems getting our system working only appear when we try to integrate all the individual bits at the end of the project, or tackle that tricky feature we’ve been avoiding. Thats when the risk in the project attacks our schedule – so many projects seem to be progressing fine until the last 10-20% when the slippages begin to show.
Agile and lean attacks the risk before it can attack you – by including risk as well as value in your prioritisation strategy, risky bits are addressed early in the project. And by insisting potentially releasable, working software is delivered from every iteration/sprint, you ensure that risk is dealt with as early as possible.
While plan-driven, waterfall methods attempt to improve predictability by ‘planning’ away risk, incremental approaches like agile and Kanban improve it by attacking it early in the cycle. They swop what can be an illusion of predictability with a more pragmatic approach to managing risk.

Moving from Authority to Responsibility

  By coheocha | January 7, 2011 - 5:30 AM | , ,
Leave a comment

Lean Thinking, which underlies Agile methods like Scrum and XP, has as one of its central pillars “respect for people”. Agile reflects this in terms of ‘whole team’ accountability, collaboration and self-organisation. All these factors lead to agile seeing team members from a more ‘humanistic’ point of view – they are more than just resources that can be swapped in and out of projects – the sort of ‘bean-counting’  mindset giving rise to the ‘mythical man-month’.  Agile takes teams and individuals much more seriously, calling for long-life, cross-functional teams that are allowed the time, latitude and autonomy to gel into a high-performing whole. This change is well summed up by the phrase ‘Move from Authority to Responsibility’. Where organisational structure is based on individual authority rather than joint responsibility, it leads to fragmentation, isolation of roles, hand-offs, friction and ultimately poor organisational performance.

Its great to have really simple and memorable phrases to guide our day to day decisions and I think this is one of those: Build Responsibility, not Authority.

Stop Starting & Start Finishing

  By coheocha | December 31, 2010 - 8:58 AM | ,
Leave a comment

Words are worlds. Using different words to differentiate things can mask their many similarities. Distinguishing between agile and lean software development methods is a case in point – these are seen by many as distinctly different approaches to organising development, when in fact they are underpinned by the same philosophies and theories, and share more similarities than differences.

But, pigeon-holing things with a label can also be a powerful tool for gaining focus and for communicating. Take the title of this post – Stop Starting and Start Finishing – for me this is a powerful phrase for communicating the essence of lean – reducing WIP. As an agile coach I’ve found I can talk for hours about kanban, WIP, value streams, flow, pull, etc. But the ‘ ahaa’ moment often comes when I use this phrase. I think its power lies in not only exposing the heart of lean in common language, but it also acts as a real easy decision rule for the team – it captures the key action the team must make to start reducing that pile of WIP, get value flowing, get to DONE, move towards pull, etc.

If I had 5 seconds to teach agile/lean, I’d just say this phrase. If I had 50 seconds, I’d say it 10 times!

Think I’m DONE, so I’ll finish.

What is our goal?

  By coheocha | October 6, 2010 - 4:38 AM | ,
Leave a comment

Reading E. Goldratts famous book “The Goal” last night (a novelised – is that a word? – explanation of Theory of Constraints) and reflecting on some recent discussions on the agile manifesto, it seems the idea of what we are trying to achieve as agile developers is still not resolved.
1) In the Goal, Goldratt argues the Goal of any business is to make money – anything that contributes to that is productive, anything that doesn’t is non-productive
2) Lean thinking focuses on creating value – but value for whom is a little vague. If it is customer value, then the customer gains – but not necessarily the business (offering products below cost might be great for customer value but detrimental to the business). So should we interpret lean value as ‘business value’ – which may have constituent parts such as customer value, strategic value, employee value, etc?
3) The agile manifesto values “working software over comprehensive documentation” and states its “highest priority” is delivering “valuable software”. But valuable to whom? Working software isn’t necessarily valuable, and valuable software doesn’t necessarily make money.

This argument may seem pretty esoteric but aligning software development with the end goal of the business is essential to success. There are many corporate skeletons out there who were renowned for their technology but failed commercially (eg Digital Equipment Corp). So how do we integrate “making money”, “delivering value” and “valuable, working software” into a robust, operationalised framework for running our software development operations? Food for thought….

Agile is more predictable

  By admin | May 12, 2010 - 3:57 AM |
Leave a comment

In a series of posts I’m going to examine some of the claimed benefits of agile methods – are they justified? My first post looked at the cost of development with agile, the second discussed speed. while the third addressed quality. Here I look at claims of un-predictability of agile.

What do we mean when we say agile methods sacrifice predictability for adaptability? Here I want to explore this commonly held belief – is it true?
In this context, predictability normally means the ability to deliver to a predetermined plan – predictable from the customer point of view.  The scope agreed is delivered with the necessary quality at the time and cost agreed.

But research shows that waterfall very rarely achieves this objective – in fact the record for plan-driven approaches is woeful! A now famous Standish report states that 31% of projects were cancelled before completion, while in 53% costs nearly doubled the  original budget. In fact only 16% came in on time and on budget. This report was from 1995 – when plan-driven was well established and agile methods had yet to make their appearance.

I would argue that in contrast agile methods bring predictability in several ways:

1) Timeboxed – Because agile treats scope rather than time as variable, ‘something’ will be delivered at the pre-determined milestone – the schedule does not slip.

2) Agile addresses high risk items early, like testing and end to end integration. These often prove to be the reasons plan-driven methods are so un-predictable.

3) Even if some scope is not delivered at the planned milestone, agile uses prioritisation by value to ensure the most important features are delivered (45% of features are never used according to the same Standish report)

4) Agile borrows from queueing theory to devise techniques to reduce variability in the development process – smoothing work flow through small, equally sized user stories greatly reduces queuing time and bottleneck formation in the process, delivering more reliable throughput.

5) By delivering potentially releasable code in each iteration, agile provides more visibility into real progress compared to the plan-driven approaches – this provides a more reliable basis for stakeholders to revise plans based on the reality of the project rather than any now incorrect plan.

6) Agile methods use inspect and adapt to adjust plans to emerging reality – regular reality checks mean more reliable predictions of milestone deliveries are possible.  In systems engineering terminology, such closed-loop systems are less reliant on every component of the system working in order to be predictable – instead they can compensate for unreliable components.

7) Agile methods encourage parallel work on various tasks and user stories – rather than analysis preceding development followed by test, these are performed concurrently.  Again, queueing theory shows us that this greatly reduces the variability of any process thereby increasing predictability.

Plan-driven methods can lend an illusion of control and predictability – and can serve political or covert roles by avoiding ‘whole-team’ accountability. But both experience and theory highlight that predictability is, contrary to common belief, not their strong-point.

Judging a book by its cover

  By admin | May 6, 2010 - 7:04 AM | ,
Leave a comment

In his now infamously named book “Balancing Discipline and Agility”, Barry Boehm, creator of the Spiral method, juxtaposed plan-driven and agile methods in terms of their discipline. His main point is that both planned and agile are valid methods depending on the context. His criteria for deciding which to us include the experience and skill of the developers, the criticality of the application, the culture of the organisation, the size of the team and the stability of the requirements. Many critics have suggested that what makes agile methods, or indeed any methods based on lean thinking (I believe agile is a lean method) work precisely because of their disciplined application. Although they must be modified to a certain context, that does not mean you can just cherry pick those practices that allow you continue with your current method pretty intact. That approach leads to a superficial adoption of agile when the underlying method does not support the core principles and values of lean and agile. However, I have another two critisisms of the ‘discipline or agile’ approach:

  • It assumes planned methods are more disciplined, or enforce discipline more effectively than agile ones – this is a fallacy. Research suggests that where planned methods are employed, a mere 6% of projects follow the defined method closely, whether that method is customised to a certain context or not  (see Fitzgerald, B. (1996). “Formalised systems development methodologies: a critical perspective.” Information Systems Journal 6(1): 3-23.)
  • It assumes there are only two basic types of method – a false dichotomy.  A recent Forrester Survey 2010 shows that only 13% of projects use waterfall methods, and 35% use various agile methods. But another 30% do not follow any method (ad-hoc) and 21% use iterative methods like RUP. Are methods other than agile and plan-driven ever valid? Boehm does not explicitly exclude them, and I see situations where they are valid in certain contexts.

Boehm has contributed hugely to the development of software engineering over the decades. But this book title gave rise to myths such as “agile can’t be relied on to produce quality and therefore critical systems” and “agile only works for experienced teams”. These myths are gradually being deconstructed as agile is scaled across enterprises composing large as well as critical projects, novice as well as expert developers. By focusing on the roots of agile in lean thinking, first generation agile methods can be extended to work effectively across a much greater array of contexts.

Agile Product Management

  By admin | March 30, 2010 - 6:45 AM |
Leave a comment

Agile is reaching a stage of maturity in some companies where attention is turning to how it can be scaled up from projects to products, portfolios and the whole enterprise.

In classic agile, where the focus is on one small, co-located team, product management is carried out by the ‘product owner’ role. In scrum, this role is responsible for the value being delivered to the customer, for the ROI. The tools they use include the product backlog, release planning, iteration planning and iteration review.  The product owner should have an intense interest in ensuring a common ‘Definition of Done’ is agreed across the team or multiple teams,  and work with the scrummaster to ensure it is always met. By ensuring each iteration only delivers ‘Done’ features gives transparency into progress as well as enabling various product release options at the end of each iteration (for example if a user story has been developed but not integrated and tested, it cannot be included in a release and so constrains the product owners options).

Each agile project must have one, and only one, product owner. Although this role can be supported by various domain experts (eg marketing, customer operations) or ‘Area Product Owners’ for large products, final decision making power must reside with one person.  With ownership of the product backlog, the product owner must work with teams to ‘groom’ the high level user stories, breaking them into small, even sized stories that can be implemented independantly and deliver ‘minimum marketable value’. They also work with the team in selecting the stories that go on each iteration backlog and in serving as or facilitating access to the ‘on-site customer’ for story elaboration. The product owner is also responsible for defining acceptance criteria and reviewing and accepting stories at the end of each iteration.

Many see agile as an implementation of lean principles in software development, and so talk of enterprise scale often refers more to lean than to agile. Here I discuss some of the emerging themes in organisational level agility:

  • Cadence: Agile introduces the idea of timeboxed iterations which are repeated over and over, each including planning, executing, delivering value and reflection and improvement. Methods like scrum recommend that these iterations are of constant duration, eg 2 weeks. This introduces a ‘cadence’ into the project – a smooth rythm which helps establish a continuous flow of value and facilitates ongoing coordination between project stakeholders.  This basic rythm of iteration development is also supplemented by sub-rythms, such as daily stand-ups, or hourly builds, and by meta-rythms, such as production releases every couple of  months. Just as these cadences provide a placeholder for synchronisation and communication between individuals in a team, they can also serve the same purpose for multiple team programs, multiple program portfolios and multi-portfolio organisations.
  • Options: Agile uses the idea of a prioritised backlog to ensure only the features that are most important at a particular time are worked on. Lean uses the ideas of delaying committment to the ‘last responsible moment’ and set based design. These mechanisms have similar aims – don’t constrain future options by what your doing today unless you really have to – that is, keep your options open.  This is especially powerful at the product, program or program management level – imagine if the program could be re-directed, or even terminated, at any point according to how market, technology or other contexts evolve.  By only investing resources in what can deliver value in the short-term, the program retains control of potential future expenditure. This is a compelling reason to move from projects to increments as a system development metaphor, as described in a previous blog.
  • Pull: Lean philosophy introduces the idea of pull, with the ‘kanban’ or ‘just-in-time’ material control mechanisms the most common examples.  Where traditional planning approaches schedule the pushing of materials, parts, customer requirements or software features to where the plan says they will be used next, pull systems use signalling built into the process to co-ordinate production and consumption along the value chain.  In manufacturing, a part isn’t produced until its needed by the next operation on the line. In software development, requirements aren’t elaborated and fixed until just before they are developed. In test driven development, code isn’t developed until a test fails. Effective pull relies on the even flow established by a cadence. And pull and associated in process signaling are core to self-organising teams and value chains – it eliminates the need for an ‘out-of-band’ signalling system represented by a ‘management layer’ assigning tasks, providing visibility through status reports, etc. Pull and the self-organisation it enables are key to scaling up agile development and are therefore essential to product, program and portfolio management that uses multiple teams.
  • Unified Build: In large enterprise development, many teams may be involved. Detailed coordination of multiple technical teams has always been a difficult and costly management task, with significant overhead in terms of meetings, documentation, negotiation, etc. With agile approaches, inter team coordination moves from the planning level to the code level – continuous integration and automated test are essential coordination mechanisms both within and between teams. Where products are being developed by multiple teams, continuous integration must build the entire end product, not just a subset of it.

Lean philosophy has been proven to scale effectively over decades in the worlds largest companies, the most famous example being Toyota. In the 80s’ and 90s’ western companies adopted many of these techniques in their manufacturing operations. Now there are moves to leverage the same underlying philosophies in development, with agile being a well progressed example in software development. Higher level organisational roles such as product management continue to evolve to the new philosophy and specific approaches will emerge over the coming years.

Agile and SMEs

  By admin | March 26, 2010 - 3:50 AM |
Leave a comment

I’ve been reading some material on attempts to implement agile methods in small companies and a recurring theme is that such firms don’t have the resources to invest in training & coaching and yet can’t afford to make mistakes when adopting an innovation like agile. Unlike larger companies, small organisations can’t launch process re-engineering and improvement programs, can’t run pilot projects which could fail, or experiment and learn by their own mistakes.
It got me thinking about how small and large firms are agile in seemingly different ways. Christen Claytonson introduced the idea of The Innovators Dilemma in his book of the same name which, simply put, says that the strategy of listening to your customer and innovating your product to move up the value chain is doomed to failure. This approach was espoused for decades with the tagline “the customer is always right”. The belief was that by delivering what the customer asked for made sure you were delivering what they wanted.
But Christenson showed through several examples that the customer doesn’t always know what they want, or even what its possible to get. He uses the example of mini steel mills in the US which undercut the larger mills by cheaply churning out simple steel products, while the established firms ignored them and focused on the higher margin work – following their strategy of moving up the value chain. But the mini mills gradually ate into the market, becoming more sophisticated themselves and aiming for higher value work. By the time the large mills realised what was happening their high cost, high margin business was collapsing. They had experienced “disruptive innovation”.
A more recent example, and one closer to home, is the rise and rise of low cost airlines like Ryanair – I don’t think any customer asked the airline to charge them for peanuts, or fly them to an airport an hour outside town, or charge them for luggage. But by listening to their customers, established airlines had missed the opportunity for low cost, mass air travel.

So what has this got to do with agile & SMEs? For small companies, business agility has been a powerful weapon – the ability to sense and exploit emerging opportunities, leverage their small size, co-location and lack of bureaucracy to move quickly has given them a competitive advantage versus the scale and resources of larger firms. But recently big firms have begun to invest in agility. Agile and lean philosophies are helping large firms transform from high overhead, hierarchical command and control organisations to more loosely federated small units with increased autonomy and their own sense and adapt mechanisms. If larger firms succeed in developing business agility (and I believe they are)  it will dilute a major competitive weapon of the small firm.

SMEs need to find a way to counter this movement before they get beaten at their own game.

Agile vs. Lean – Timeboxes vs. Flow

  By admin | March 22, 2010 - 6:16 AM | ,
Leave a comment

Agile uses the idea of fixed timeboxes where the scope of work completed for an iteration is estimated based on a duration such as 2 weeks. Importantly, even if all the planned work for an iteration isn’t complete, what has been developed is built and delivered anyway – the iteration is timeboxed and the schedule does NOT slip.  This ensures there will be some value delivered to the customer, even if it falls short of what was planned. But in lean thinking, the focus is on flow – the continuous flow of value rather than the incremental flow. In a discrete production context, this manifests as a striving to reach a batch size of 1 – rather than a ‘production run’ on a machine making 1000 widgets, it makes just 1 as it is pulled from the subsequent operation. This move to smaller batches and therefore towards continuous flow is possible because of new manufacturing technology – for example a machine that can be instantly reprogrammed can easily switch from making one type of widget to another. Similarly, in software development, we strive for ever smaller increments, ever shorter iterations.  And, like production, this is enabled through technology such as automated testing and continuous integration. These technologies reduce the cost of testing, building and deploying and allow us deliver value in a way approaching the ideal – continuous flow – advocated by lean philosophy.