Tag Archives: linkedin

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.

How agile are you?

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

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.

Losing and Finding the big picture

  By coheocha | January 4, 2011 - 5:57 AM | ,
Leave a comment

Working with agile teams I see a common underlying issue emerge time and again: Keeping the big picture in mind. Here are some examples:

  • Agile looks to emergent architecture – its illogical to define architectural design at the beginning of a project if you accept that the requirements (business and technical) cannot be determined reliably up front. Attempts to do this usually lead to over-specification – to avoid any constraints emerging due to the architecture we tend to engineer a highly complex solution to cater for all eventualities.  Agile has a notion of emergent design – because software is ‘ soft’ we can change it (eg refactoring) – we don’t have to get it ‘ right first time’  like in the construction  industry where the architecture metaphor came from. Although there is a cost in reworking architecture as we go along, there is also a saving in getting it right, in not over-specifying it, etc. But agile doesn’t call for no architectural design (as Christopher Alexander – creator of the design pattern concept, puts it: “good design requires keeping the big picture in mind”). Instead, agile looks to late elaboration, keeping our options open as long as possible, and allowing us learn as the project progresses. Remember, we know least about the project at the beginning – so why lock in our architecture prematurely? Perhaps the term ‘ architecture’ has outlived its usefulness….
  • Agile expresses requirements as small fragments – user stories are the common basis for expressing requirements in agile projects. But user stories are explicitly independant, small, specific (see Bill Wakes INVEST criteria for effective user stories). Other approaches to Agile/Lean requirements are Minimum Marketable Features (MMFs), Minimum Valuable Features (MVFs) and Business Value Increment (BVI). All these are attempts to delineate a “manageable” slice of functionality to be delivered in a short cycle time which will deliver value to the customer. But how these small units of functionality link to the bigger picture can get lost. How does my story contribute to this epic, or theme, or goal? Jeff Patton proposes the User Story Map as a mechanism to tie stories to the bigger picture. Another approach is to ensure stories are derived from the bigger picture – epics, themes – rather than being defined first and then grouped into larger areas of functionality.
  • Agile doesn’t make it easy to scale to big projects – methods like Scrum and XP are specified at the small team level – its hard to scale to big enterprise projects (though there are more and more success stories emerging). Small teams working on a sub-set of a big project can lose sight of the big picture.  Whats often forgotten here is that scaling problems are not specific to agile – no method makes it easy to scale system development. While traditional methods address scaling by freezing design early and relying on documents to communicate details between teams (both techniques rife with problems), agile relies on face to face communication (eg in a scrum of scrums) and continuous integration/automated test (where the code for the entire system is built, deployed and tested many times a day). From my experience, the agile approach holds far more promise, especially where the extent and rate of churn is increasing, and the ability to rapidly deliver of software is becoming a strategic capability.

In summary, focusing on the small bits (as agile does) does not mean losing sight of the big picture. This is not an either/or situation. We can work incrementally while keeping an eye on the big picture.

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.

Hand-offs kill agility

  By coheocha | October 18, 2010 - 9:44 AM | ,
Leave a comment

I’ve been working with several large organisations recently, all interested in adopting agile in new development groups. But not before they build in the barriers that make agile exceedingly difficult, or even impossible.  I’m talking organisational structure here.  Once an organisation is formed, it can be very difficult to change. Once employees have been carved up into different functions/departments (ie fiefdoms) if can be a real bun-fight to get them working together effectively.

The traditional organisation has a business organisation, developers, QA, maybe data architects, DBA, UI design, SOA expert group, etc. But delivering a feature requires all these groups work together. And if you have an iteration cycle of 2 weeks, that means they all need to work together with no time wasted handing-off work to each other. As each group wrestles with its own priorities (driven by their own metrics and reward systems) they generally fail to gel as a cohesive team, with miscommunication, queuing and differing priorities the norm.Finger-pointing and increasing CYA bureaucracy are often the result.

Some say the matrix organisations are the answer – bring the necessary experts together on a project by project basis. But this means a lot of chop/change as projects start & finish, grow and shrink, etc. Research shows teams reach optimum performance when they’ve been working together for 4 years – much longer than the average project.

So why do we divide people up into distinct ‘departments’ – is there more to it than ease of centralised management? And if we are pursuing self-organisation, is there still a good arguement for it? Theres certainly a significant cost…

Where am I?

  By coheocha | October 18, 2010 - 7:56 AM | ,
Leave a comment

In developing a strategy for adopting agile, its important to understand where you’re coming from and the barriers you’ll face. These can be organisational, cultural, technical, and so on. To help develop realistic and pragmatic adoption strategies, I’ve developed an assessment framework to look in depth at factors such as team dynamics, technologies and performance management to track down where adoption might falter. The assessment can be conducted on its own or integrated into coaching and support services. As well as giving a deep understanding of agile in the organisation, it can help set targets for improvement by mapping where you are to where you want to be.

Motivation and agile teams

  By coheocha | September 29, 2010 - 4:17 AM | ,
Leave a comment

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!