AgileInnovation

Doesn’t Agile mean ‘No Documentation?

admin — Wed, 25 Apr 2012 17:54:49 +0000

One of the most common questions I get from folks looking at agile for the first time is ‘Does agile mean I don’t have to do documentation?’. I think this ‘myth’ stems from the agile manifesto value of ‘Working Software’ over ‘Comprehensive Documentation’. But the manifesto doesn’t say documentation is bad, just that working software is better.
I use two ideas to explain where documentation fits in with agile teams:
1) differentiate between ‘process’ or ‘project’ documentation and ‘product’ documentation. The first is used within the project, and once the project is over, is generally discarded or at least of little value. Requirements docs, technical specs, etc fit in here – they are expensive to develop and they need to be updated regularly to reflect emerging realities. ‘Product’ documents, on the other hand, are a deliverable from the product – they describe the product that was actually built, they have a long and useful life as part of the product, and they can be less comprehensive as they merely augment the working software.
2) differentiate between documents that ‘replace’ conversations and collaboration and documents which ‘record’ conversations. Using documents to communicate between project members is intensely expensive, laborious and ineffective (the written word is exceedingly bad at communicating complex, tacit or nuanced knowledge). People talking at a whiteboard is a much more efficient and effective form of communication. However, documents can be useful to record decisions made in such conversations – the valid characters in a field validation, the calculations to be performed to generate a report column, etc. But these are specific, explicit bits of knowledge, relatively stable, and given context by the conversation that led to them.

So in summary, I recommend confining documentation to product rather than project oriented purposes, and to write it after the fact as a record of conversations, rather than a replacement for them.

#aleireland #agileireland Agile/Lean MeetUp in Dublin Next Thursday 1st Mar 6pm Leopardstown Inn.

admin — Mon, 27 Feb 2012 15:17:06 +0000

Alan Spencer (Agile leader D&B), Frederic Oehl (Agile Coach Cerner and AgileTour organizer) and Colm O’hEocha (Agile Trainer/Coach at AgileInnovation) will be meeting 6pm next Thursday, 1st March. We’re hoping others interested in chatting about agile/lean, sharing war-stories, or even just curious on what its all about, will come along for a cuppa (or pinta!) and a chat. There’s no agenda for the meetup. Anything related to agile and lean product/software development (why or how) qualifies. Whether you’re a veteran practitioner, a complete novice, or somewhere in between bring along your ideas, questions, challenges, problems, suggestions, experiences, or just bring yourself. You might learn something from the conversation, or you might help someone else. You might discover something totally unexpected. ALE Ireland We will have this meetup under the umbrella of the Agile Lean Europe network – a network for collaboration of Agile & Lean thinkers and practitioners who are based in Europe. Last September’s ALE2011 Conference in Berlin was a great success, and the philosophy of sharing knowledge and bringing people together is appropriate. We’re interested in meeting like-minded people who are enthusiastic about improving their workplaces and lives through agile and lean thinking, and maybe changing the world along the way. We would like to see a community emerging where we can learn from each other and share experiences. How do we know who else is coming? We decided to forgo any sort of formality, including a registration system, for this meet up. If you are thinking about coming along, or just want to chat or introduce yourself, please log a comment below, or Tweet using the hashtag #aleireland so we have some idea who might show up. If you want to just show up on Monday, that’s fine too. We hope to see you there! Who’s in charge of this? You are! I’m just sending out an invite. Others are free to send out invites too. There is no centralized ownership. This meetup, and any future meetups, will go in whatever direction decided by the people who show up. Date and Time Thursday 1st March 6pm. Location The Leopardstown Inn , Brewery Road, Stillorgan Co Dublin

AgileIreland is the place!

coheocha — Tue, 22 Mar 2011 11:18:42 +0000

After founding AgileIreland a couple of months ago, I’ve moved by blogging activity there – take a look at www.agileireland.org

Attack Risk before it Attacks You!

coheocha — Thu, 10 Feb 2011 11:45:24 +0000

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.

Public Presentation – Lean Implementation at BBC Worldwide

coheocha — Tue, 25 Jan 2011 13:05:10 +0000

On 25th February there will be a public lecture with Dr. Peter Middleton from Queens University Belfast reporting on one of the most successful, large scale deployments of lean software development in BBC Worldwide. More details to follow….

Nice Summary of Demings 14 points

coheocha — Tue, 11 Jan 2011 12:33:31 +0000

Many of E. Demings key points underlie agile and lean approaches to work – this summary well worth the 5 minutes it takes to read it

Moving from Authority to Responsibility

coheocha — Fri, 07 Jan 2011 09:30:56 +0000

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.

Lean Enterprise Software and Systems

coheocha — Wed, 05 Jan 2011 11:49:50 +0000

EU Centric Lean Software Development Conference – Exact date to be confirmed

Lean Software and Systems Conference

coheocha — Wed, 05 Jan 2011 11:48:09 +0000

Leading US centric Lean Software Development Conference

How agile are you?

coheocha — Wed, 05 Jan 2011 09:59:24 +0000

One of the big culprits in failed agile teams is the tendency to cherry pick those practices that seem to ‘fit with the way you work’, ‘with the way we do things around here’. Agile explicitly calls for methods to be customised depending on context. But often this can be misconstrued as selecting those bits that are compatible with how you work now – thereby leading to no fundamental change in the way you work. Examples are iterations as long as the release cycle, calling the project manager a ScrumMaster without a change in role and considering a feature or story ‘done’ when it has been coded and passed to QA. This leads to a Cargo Cult adoption where the team adopts the language and some ceremonies of agile, without understanding the fundamentals of how it works. No wonder the benefits are elusive…

When assessing how well teams have adopted agile methods like scrum, the approach is usually compliance based – an evaluation of how closely the team follows the defined method – whether customised or not. There are two fundamental difficulties with this:

1) The way in which agile practices are implemented in a team has a great bearing on how they support or constrain agility – for example, a daily stand-up meeting that spends 45 mins getting status updates from everyone is really not going to help a self-organising team co-ordinate their actions for the day. Even a stand-up of 10mins where the three standard questions are posed can be ineffective if the team doesn’t engage and feel ownership of it. Therefore, assessment by compliance evaluates, well…, compliance – not agility which is probably what you want to know.

2) Since each project & team implements their development method differently (a scientific fact from extensive research), and since that implementation evolves over time, using compliance as the basis for assessment hinders inter-team comparisons – akin to comparing apples and oranges. A lot of the value in assessing a team is so you can benchmark and compare to other teams as a way to identify possible paths to improvement. Without the ability to effectively compare, the assessment just isn’t all that valuable.

3) Most methods already used by teams have some really good aspects. Moving to agile should preserve these (unless replacing them with something even better). If attempts to be compliant with some textbook method causes these to be lost, then we’re really ‘throwing out the baby with the bathwater’.

To overcome these, my colleagues and I have been developing an assessment that looks at agility from first principles – regardless of what method is being used by the team. Of course agility is a complex concept with many facets such as creativity, responsiveness, simplicity and quality. By focusing on how any given method contributes to these facets, we can assess how it contributes or detracts from agility as a whole. We can also compare very different methods, like scrum, XP or indeed waterfall. And we can make recommendations which preserve whats valuable in what you do today while tackling those areas promising improvement.

In another post I’ll discuss an alternate assessment technique I use – rather than assessing agility, this one identifies barriers to adoption and helps map out an adoption strategy tailored to a team, project and organisation.