What is our goal?

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….

Motivation and agile teams

Love this video summary of Dan Pinks great book – DRIVE. Explains a lot about why agile teams get so much valuable work done, and feel so good doing it (of course it relies on agile being implemented in a ‘genuine’ manner with real autonomy & empowerment – not just as a facade or means to micro-manage). Watch it – well worth the 11 minutes!

Agile Tour 2010 comes to Dublin

The Agile Tour is coming to Dublin October 14th – great chance to network with other local practitioners, get feedback on your experiences with agile and learn from others. I’ll be talking about adopting agile at the enterprise level – how do you justify it, what does it mean for the organisation and how do you develop a cohesive adoption strategy.

UPDATE: Agile Tour event was a great success! So much so we’re considering running it again in other cities around Ireland.

My presentation slides are available on Creative Commons License

The Wests Awake!

Three interesting events in the West over the coming weeks:

1) Feile Icarus, Letterfrack – a chance for entrepreneurs & creatives to get together and discuss what they are trying to do, how they the might do it, and build a support network to help them

2) Blogtalk 2010 Galway – all about social media

3) Bizcamp Galway – a great chance to present your ideas, mingle and learn

Great to see such a high level of get up and go – theres hope for us yet!

Agile is more Transparent

In a series of posts I’m examining some of the claimed benefits of agile methods – are they justified? Here are the posts so far:

  • My first post looked at the cost of development with agile
  • The second discussed speed.
  • The third addressed quality.
  • The fourth looked at claims of un-predictability of agile.

This post will examine the transparency of agile vs.  other methods. The main contention is that because agile delivers potentially releasable, working software at the end of each iteration, there is implicit visibility of actual progress in delivering business value – there is no need to rely on other metrics derived from the process, such as lines of code, defect counts, hours worked, story points executed or features coded.

In waterfall or ad-hoc development, there are no iterations (other than major milestones such as a product release) where the real value delivered can be measured – therefore, proxy measurements like those mentioned above are necessary. But there are several issues with using these:

  • The numbers can be ‘gamed’:  The old adage ‘measure what you manage’ is well recognised, not only by managers but by development teams too. As managers try to manage the team by measuring them, the team will often try to manage the managers through those same measurements! In effect, the numbers may not reflect the full picture where there are delays or other issues – these still may not become apparent till its too late to react to them.
  • Many metrics are confined to measuring inputs, when its output that is of more interest: Managing a project based on the effort expended, rather than the value generated, is always going to lead to problems. Traditional project management focuses on time, resources and cost expenditure. Although the hours spent coding, the lines of code generated, the defects found, etc may all be linked to the value generated, they can be highly unreliable in this regard, and are often just downright misleading.
  • Defining, collecting and reporting on these derived metrics can be pretty time consuming. There are many project and portfolio managers who spend the majority of their time on such work.
  • Because these metrics are intrinsically linked to the ‘plan’, it becomes more difficult to measure them if the plan changes. For example, if I plan 100 hours work for a feature, and a requirements change means it takes just 50 hours, how do I account for that in my metrics – when we deliver the feature, are we running behind?

There can be little argument that the most direct, reliable measure of progress is business value delivered, normally in the form of value to the customer. But there are some things to watch for when moving in this direction:

  • Output vs. Outcome:  Even by delivering working software on a regular basis, there is no guarantee it is of VALUE.  Measuring outPUT may just drive faster, more regular delivery of software with little value. It is the outCOME we should ideally measure – the actual value derived from the software. But as this can’t be reliably measured till the product is on the market or in use – a conundrum for sure.
  • Iterative methods like RUP deliver features in increments – however, there isn’t the focus on delivering working, POTENTIALLY RELEASABLE software at each iteration – therefore proxy measurements must still be substituted for measures of real VALUE – the software hasn’t any value until its working.
  • This approach underscores the importance of the ‘Definition of Done’ (DoD) in agile – the development team must adopt an agreed definition that really does result in potentially releasable software at the end of each iteration. I often see iterations where the coding and feature testing are complete, but code review, integration, performance testing, etc are delayed so they can be done more efficiently for multiple features at a time.  This is fine once they are completed within the same iteration – and if the story points ARE NOT credited until they are done. Only after all steps have been complete, and a strict DoD is adhered too, has value been delivered and credit can be taken.

As focus shifts from management by effort to management by value, and as iteration costs decrease through automated test, build, integration and deployment, delivering real value, in the form of potentially releasable software, becomes more achievable and leads to much needed transparency.

Agile is more predictable

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

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.

The Agile Innovation Dilemma

One the seminal events for the development of the agile software development movement was the 1986 publication in HBR of “The New New Product Development Game” by Nonaka and Takeuchi. Describing lean production principles applied to new product development, the paper introduced the metaphor of a rugby team where a clear goal, overlapping skill sets and joint accountability allow teams dynamically adapt and self-organise to achieve their objectives despite unforeseen setbacks and challenges. From this, the term scrum was used by Sutherland and Schwaber in 1995 to describe an incremental, team based approach to software development. In this way, agile development and innovating new products share a common lineage.
Agile methods have long been advocated in supporting innovation. They explicitly call for self-reflection and improvement of the method through retrospection. Close customer contact and an understanding of the business problem to be solved can help the development team develop more innovative solutions than if they were coding to a static functional specification. Proponents have written of ‘hyper-productive’ scrum exhibiting ‘punctuated equilibrium’ leading to discontinuous or radical innovations. However, agile practicioners offer an alternate view – the intense focus on delivering small increments of customer centric features in the immediate future undermines their ability to seek out alternate solutions, to ‘think outside the box’. This is what I refer to as the “agile innovation dilemma”. So what has gone wrong?

Agile methods promise, first and foremost, agility – that is, flexibility in responding to changing requirements, technology and markets. But in promoting agile, more traditional values such as productivity, quality and time to market are often to the fore.  In efforts to realise these benefits, agile implementations often become exercises in micro-managing development teams, with local optimisations coming to the fore. These are reflected in many of the ‘patterns of failure’ seen in agile projects, and I’ll be describing some of these in future posts. Unfortunatly, these tend to mitigate against innovation, resulting in ‘pressure cooker’ development environments where all focus is on delivering the next increment of functionality, where the product owner is breathing down your neck, and where doing the simplest thing can take precedence over doing the ‘right’ thing.

When did you last hear of agile being introduced to enhance the innovation of a team?

Agile delivers better Quality

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, while the second discussed speed. Here we address quality. Commentators often say agile methods are not suitable for life or mission critical systems – for some reason they believe the quality cannot be delivered reliably using agile. But there is a growing opinion that agile methods can deliver even better quality than planned approaches. I believe it’s not anything inherent in agile methods that can lead to lower quality, rather it is a lack of discipline in applying the method. Discipline is required to ensure high quality in any method, agile or not. Unfortunatly agile is perceived by some (unjustly) as not demanding discipline, and hence not ensuring consistent quality. Here are some reasons I think an informed, mindful and disciplined agile method can be considered more reliable in terms of quality than planned methods:

  • Quality is built in – not added afterwards: Iterative development encourages continuous test – at a minimum every iteration. In agile methods with automated test, this is increased to daily, or even hourly, or every time the code base changes. With test driven development, tests are developed and executed even before the development begins.  This encourages quality coding from the outset, and the repeated and up front emphasis on testing engenders a quality culture in the team
  • Waterfall methods seperate responsibility for development and test – they encourage an antagonistic relationship between developers under pressure to churn out features and QA who have the lonely job of policing the quality of the system.
  • QA is normally the last major task in a waterfall model, following requirements, analysis, design and development. Therefore, it is usually conducted in limited time and under severe pressure at the end of the project – conditions not conducive to rigorous and insightful test.

But quality is not confined to the coded implementation itself:

  • The quality of requirements are improved through close customer collaboration and face to face interaction. Detailed requirements are determined only when required, just before implementation, and therefore involve less ‘future gazing’. Requirements are described in a user centric fashion, and can be better understood by the customer than more technology centric descriptions usual in traditional methods.
  • The quality of the plan, and therefore the predictability of the project, is improved through continuous replanning for each iteration, by addressing high importance and high risk items early on (eg integration) and by the transparency offered by measuring progress through ‘done’ features and the value they represent to the business.
  • The quality of experience for stakeholders is improved: customers who get what they want earlier, sponsors who get happier customers, product management who get better visibility and more options for managing the development, and developers and testers who get a more motivating and sustainable work experience.

Taken together, I believe agile can deliver better quality software than planned methods. Agile is rooted in lean thinking, a set of philosophical tools that helped Japanese companies reach new levels of manufacturing and product development quality over several decades.  However, discipline in their application, as with any method, is not optional.

Extending the Scrum and Sprint Metaphors

Scrum uses the metaphor of a rugby team to convey the ‘directed autonomy’ of a ‘whole team’ working together to get the ball across the try line. Each member of the team has a role such as out-half, fullback or forward, but once the ball is in play, any member does whatever they can to progress towards the objective, regardless of their speciality. This is contrasted to a relay race team, where each member runs part of the race on their own, passing the baton at pre-determined points. This echos a waterfall process, with distinct roles and responsibilities and hand-offs between task specialities.
Another metaphor used in scrum is that of a sprint. During a sprint, distractions and interuptions to the team are minimised – the ScrumMaster has a specific responsibility to ensure they can focus purely on acheiving the preset sprint goals. This minimises context switching and multi-tasking which have been shown to be very wasteful, and increases the predictability of what will be delivered at the end of the sprint. But no-one can sprint all the time – if they try, then they are really just jogging. I like the sprint metaphor – there is one immediate, overwhelming objective and all distractions and other concerns are ignored until the sprint ends.  And during a sprint, ‘moving’ the goalposts is not allowed – no changes to the sprint goal or user stories and tasks is allowed (if this is necessary, then the sprint is cancelled). Just like a play in rugby, all focus is achieving one objective until the whistle blows.

But the ‘classic’ scrum method (Schwaber &  Beedle),  recommends each sprint is followed directly by another – sprints include ‘bookend’ events at the start and end, such as iteration planning, reviews, retrospectives, etc. Classic scrum also calls for just a little bit of distraction sprinkled throughout the sprint such as spending 5-10% of the time on ‘grooming’ the product backlog – allowing the next sprint backlog be prepared in advance of the subsequent sprint and therefore no need to dilly-dally before rushing into development again. Activities such as these require the focus of the team be diverted from the immediate sprint goal to focus on future stories and tasks.

I have a number concerns with this model.

  1. Distractions, multi-tasking and the consequent context switching are very disruptive to concentration and sap energy from a team. Try doing some real, focused work like writing a report or some complex code with constant interruptions such as calls and meetings about different topics – its very difficult to progress rapidly and steadily with the primary task. But people in the real world have to do ‘other’ stuff in the average workday: office communication sessions, performance appraisel with their boss, arrange or attend a presentation to another department, participate in the mentoring program, file travel expenses, attend the mandatory office security training session…..the list is looong. Sometimes a team will count on only 6 hours out of 8 being available for ‘real work’ because of these distractions. But how can you sprint efficiently if your not running 25% of the time? If you have to slow down, attend to something else, and then build up sprint speed again it is very wasteful.
  2. Agile purports to be an empirical control process – rather than planning the future based on experience of the past it instead uses an ‘inspect and adapt’ paradigm to continually refine the short-term plan based on present reality. In agile methods, this takes the form of getting feedback from stakeholders (customers, users) at the end of each iteration, and, based on that, building a plan for the next sprint. In many real world cases, the next sprint has already been substantially planned by the time the previous one is finished – team members have been grooming the backlog, breaking down stories and tasks, estimating, etc. Although this model impinges on the pure inspect-adapt model, many would see it as pragmatic – a sensible compromise to optimise utilisation of the team. However, I have seen this quickly lead to local optimisation (great for getting more work done, but not necessarily delivering more business value), premature investment in story elaboration, and erosion of team ownership of stories and estimates (since often one or two team members will work on stories for the next sprint while the remained deliver the current tasks). Reverting to the rugby metaphor, its like some players disengaging and setting up the next set piece before the play has ended.
  3. I discussed the idea of cadence in a previous post – cadence across teams and projects is a great basis for synchronising inter team communications. For example, in a multi-team project if one team is sprinting while the other is between sprints, there is little opportunity for joint reflection. If there is time set aside between sprints to synchronise between teams, and if the sprints start and end at the same time, it gives an opportunity for this communication. It also gives an opportunity to go ‘off-project’ and do all that ‘other stuff’ not directly related to the project. For example, what if performance reviews, training, presentation of company quarterly results, etc could only be scheduled between sprints – this would involve a cadence at the company level operating across all functions.

Again, like the rugby metaphor, I think a break from the flurry of play to take stock, tie your boot laces and plan the next move is an essential element of working effectively.