You are currently browsing the archive for the Agile category.

Fresh Start

Welcome to Always Agile Consulting

I am pleased to announce my new independent consultancy Always Agile Consulting, which will focus upon Agile and Continuous Delivery opportunities in Central London. My existing blog will now redirect to this website.

I would like to thank my colleagues at Sky Network Services for an amazing 3 years, in which we proved that eXtreme Programming practices can evolve across multiple teams, and Continuous Delivery can be applied to 100+ applications in an enterprise organisation. I look forward to sharing techniques such as Consumer Driven Contracts, Cost of Delay, and Release Testing alternatives with the clients and partners of Always Agile Consulting.

Agile is undergoing renewal, and Continuous Delivery is continuing to grow – it’s an exciting time in the IT industry.


Projects kill teams and flow

Given the No Projects definition of a project as “a fixed amount of time and money assigned to deliver a large batch of value add“, it is not surprising that for many organisations a new project heralds the creation of a Project Team:

A project team is a temporary organisational unit responsible for the implementation and delivery of a project

When a new project is assigned a higher priority than business as usual and the Iron Triangle is in full effect, there can be intense pressure to deliver on time and on budget. As a result a Project Team appears to be an attractive option, as costs and progress can be monitored in isolation, and additional personnel can be diverted to the project when necessary. Unfortunately, in addition to managing the increased risk, variability, and overheads associated with a large batch of value-add, a Project Team is fatally compromised by its coupling to the project lifecycle.

The process of forming a team of complementary personnel that establish a shared culture and become highly productive is denied to Project Teams from start to finish. At the start of project implementation, the presence of a budget and a deadline means a Project Team is formed via:

  1. Cannibalisation – impairs productivity as entering team members incur a context switching overhead
  2. Recruitment – devalues cultural fit and required skills as hiring practices are compromised

Furthermore, at the end of project delivery the absence of a budget or a deadline means a Project Team is disbanded via:

  1. Cannibalisation – impairs productivity as exiting team members incur a context switching overhead
  2. Termination – devalues cultural fit and acquired skills as people are undervalued

This maximisation of resource efficiency clearly has a detrimental effect upon flow efficiency. Cannibalising a team member objectifies them as a fungible resource, and devalues their mastery of a particular domain. Project-driven recruitment of a team member ignores Johanna Rothman’s advice that “when you settle for second best, you often get third or fourth best” and “if a candidate’s cultural preferences do not match your organisation, that person will not fit“. Terminating a team member denigrates their accumulated domain knowledge and skills, and can significantly impact staff morale. Overall this strategy is predicated upon the notion that there will be no further business change, and as Allan Kelly warns that “the same people are unlikely to work together again“, it is an extremely dangerous assumption.

The inherent flaws in the Project Team model can be validated by an examination of any professional sports team that has enjoyed a period of sustained success. For example, when Sir Alex Ferguson was interviewed about his management style at Manchester United he described his initial desire to create a “continuity of supply to the first team… the players all grow up together, producing a bond“. This approach fostered a winning culture that valued long-term goals over short-term gains, and led to 20 years of unrivalled dominance. It is unlikely that Manchester United would have experienced the same amount of success had their focus been upon a particular season at the expense of others.

Therefore, the alternative to building a Project Team is to grow a Product Team:

A product team is a permanent organisational unit responsible for the continuous improvement of a product

Following Johanna’s advice to “keep teams of people together and flow the projects through cross-functional teams“, Product Teams are decoupled from project lifecycles and are empowered to pull in work as required. This enables a team to form a shared culture that reduces variability and improves stability, which as observed by Tobias Mayer “leads to enhanced focus and high performance“. Over a period of time a Product Team will master the relevant business and technical domains, which will fuel product innovation and produce a return on investment that rewards us for making the correct strategic decision of favouring products over projects.

Tags: , ,

No Projects

Projects kill flow and teams. Focus on products, not projects

Since the Dawn of Computer Time, enormous sums of money and embarrassing amounts of time have been squandered upon software projects that have delivered little or no return on investment, with projects floundering between segregated Business and IT divisions squabbling over overestimated value-add and underestimated delivery dates. Given Grant Rule’s assertion that “studies too numerous to mention show that software projects are challenged or fail“, why are software projects so prone to failure and why do they persist?

To answer these questions, we must understand what constitutes a software project and why its delivery model is incongruent with product development. If we start with the PRINCE 2 project definition of “a temporary organization that is needed to produce a unique and predefined outcome or result at a pre-specified time using predetermined resources“, we can offer a concise definition as follows:

A project is a fixed amount of time and money assigned to deliver value-add

The key characteristic of a software project appears to be its fixed end date, which as a delivery model has been repeatedly debunked by IT practitioners such as Allan Kelly denouncing “endless, pointless discussions about when it will be done… successful software doesn’t have a pre-specified end date” and Marc Lankhorst arguing that “over 80% of IT spending in large organisations is on maintenance“. However, the fixed end date of a software project is invariably a consequence of its requirement for a collection of value-adding features to be simultaneously delivered, suggesting an augmented definition of:

A project is a fixed amount of time and money assigned to deliver a large batch of value-add

Once we view software projects as large batches of value-add, we can apply The Principles Of Product Development Flow by Don Reinertsen and better understand why so many projects fail:

  1. Increased cycle time – a project might not be deliverable on a particular date unless either demand is throttled or capacity is increased, e.g. artifically reduce user demand or increase staffing levels
  2. Increased variability – a project might be delayed due to unpredictable blockages in the value stream, e.g. testing of features B and C blocked while testing of feature A takes longer than expected
  3. Increased feedback delays – a project might incur significant costs due to slow feedback on bad design decisions and/or defects increasing rework, e.g. failures in feature C not detected until features A and B have passed testing
  4. Increased risk – a project might have an increased probability and cost of failure due to increased requirements/technology change, increased variation, and increased feedback delays
  5. Increased overheads  – a project might endure development inefficiencies due to increased requirements/technology change, e.g. feature C development time increased by need to understand complexity of features A and B
  6. Increased inefficiencies – a project might encounter increased transaction costs due to increased requirements/technology change e.g. feature A slow to release as features B and C also required for release
  7. Increased irresponsibility – a project might suffer from diluted responsibilities, e.g. staff member has responsibility for delivery of feature A but is unincentivised to participate in delivery of features B or C

Don also provides a compelling explanation as to why the project delivery model remains prevalent, by explaining how large batches can become institutionalised as they “appear to have scale economies that increase efficiency [and] appear to reduce variability“. Software projects might indeed appear to be efficient due to perceived value stream inefficiencies and the counter-intuitiveness of batch size reduction, but from a product development standpoint it is an inefficient, ineffective delivery model that impedes value, quality, and flow.

There is a compelling alternative to the project delivery model – product development flow, in which we apply economic theory to Lean product development practices in order to flow product designs through our organisation. Product development flow emphasises the benefits of batch size reduction and encourages a one piece continuous flow delivery model, in order to reduce costs and improve return on investment.

Discarding the project delivery model in favour of product development flow requires an entirely different mindset, as epitomised by Grant urging us to “accommodate the ideas of flow production and lean systems thinking” and Allan affirming that “BAU isn’t a dirty word… enhancing products is Business As Usual, we should be proud of that“. On that basis the No Projects movement was conceived by Joshua Arnold to promote the valuation of products over projects, and anointed as:

Projects kill flow and teams. Focus on products, not projects

Tags: , , , ,

Bodart’s Law

Uniformity != Efficiency

Within any software organisation, there will be sporadic attempts to establish uniform processes, tools, and/or practices. Examples might include:

  • “Every team must use the same hardware/OS/IDE”
  • “Every application must use the same in-house commons/utilities API”
  • “Every application must use the same infrastructure – application  server/container/configuration/ORM/database”
  • “Every application must use the same release mechanism”

Such efforts are largely well-intentioned and arise from the belief that reducing variation will reduce waste. But is this assertion evidence-based?

Based on my own experience, I would say the answer is a resounding no. Consider the following:

  • At Company A, I was tasked to write a generic transport API to encapsulate all data protocols used between in-house and third-party applications. As I could not modify the published interfaces of the external applications or adapt the internal applications to those interfaces, the API was abandoned
  • At Company B, I owned 2 protocol drivers in a suite of 20. A driver SDK was rolled out to ease development of new drivers, but retrofitting legacy drivers proved so time-consuming that new features were delayed
  • At Company C, a generic journalling platform was developed upfront in anticipation of future journal-based applications. The platform had some initial success, but when my application was forced to use a radically different content structure an enormous integration effort was required

A cost-benefit analysis would conclude the above attempts were doomed from the outset and delivered little or no customer value. Customers value features over technical uniformity, and even then standardisation cannot be achieved when interfaces are not owned, when conformance costs are unconsidered, or when the uniformity is designed upfront.

Despite the limited availability of Great Developers, I am fortunate enough to work with Dan Worthington-Bodart. In addition to evangelising Crazy Fast Build Times of sub-10 seconds at QCon earlier this year and authoring the excellent TotallyLazy functional Java library, Dan is renowned for exposing flawed technical strategies – for example, in 2009 he buried Feature Branching with the pithy

Feature Branching is a poor man’s modular architecture

In the same vein, Dan once commented on a well-intentioned, ill-fated standardisation push by off-handedly saying

Making everything uniform will not automatically make everything efficient

Therefore we can summarise Bodart’s Law as

Uniformity != Efficiency

Bodart’s Law tells us that the cost of imposing uniformity upon a sufficiently large variation will permanently outweigh the value introduced by the homogeneity, and that ultimately the siren’s song of uniformity should be a byproduct of success as opposed to an un-evidenced requirement.