We all know the manifesto but why do so few know the principles?

Agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan[6]

Principles behind the Agile Manifesto

We follow these principles:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity—the art of maximizing the amount of work not done—is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. [6]

Oxford Assignment

I recently completed an Agile module for my Oxford masters and though I’d share the essay with you all.

Please compare and contrast the different adoption paths taken by the BBC on the iPlayer project and Sapient on their Project with the Office of Naval research. 

There are a lot of myths that prevent companies adopting Agile, including claims of lack of planning, quality, documentation, predictability and control.  In reality Agile has a number of techniques to diminish the issues surrounding traditional methodologies and one study showed Agile initiatives actually fail in “two-thirds of cases due to a failure to integrate the right people or to teach a team-based culture.”[9] The other reasons are also people related such as executive sponsorship and training.

Clearly people are important and the common denominator between Agile methodologies, the Agile Manifesto, states “individuals and interactions over processes and tools”. This means that process must not be forgotten but must take second place to people interactions. “A common misconception is that Agile is about a new process – no; the difference are in the values and philosophy” [4]. Jeff Patton stated “Agile development is a culture, not a process.”[13] “We would rather use an undocumented process with good interactions than a documented process with hostile ones”. [4] It should be noted, however, that Agile is not a “Silver Bullet” and is often oversold. A comparison of Agile methodologies is provided in Appendix C

Two differing cases studies, and further interviews with the authors, were used to see if a “one size fits all” approach could ever be agreed upon.


The companies could not have been more different.

The BBC study describes nine teams divided by functional areas reporting into a, non Agile, central team to deliver the iPlayer application. In my interview, Mike Lowery stated that the BBC, a publicly funded company, had a non-compete rule. If another company were to develop a similar or competing project the BBC would have to stop. They also didn’t have a financial budget. People were paid to be there for the year so it was less critical what they did, in fact the BBC sought to create jobs [1]

“Sapient is a global services company that helps clients transform in the areas of business, marketing, and technology.”[7] In my interview, Andy Takat confirmed that Sapient were ideally placed, and heavily incentivised, to identify the optimal agile adoption strategy’s due to their massive and diverse client base, projects, technologies, budgets and systems. [2]


Agile is often used to deliver early to customers but the BBC built 3 different versions of the iPlayer. Mike states the first version was very amateur. The Second used an external design agency with big design up front but suffered poor user feedback.  Only the third version was a success when Agile techniques were used. [1] Clearly they were not “failing” fast.

Sapient’s customer was the US Navy’s Office of Naval Research project “to develop an entirely new set of naval logistics command and control capabilities that can be rapidly transitioned to the operating forces”. [8]. Given that this was post September the 11th this was a life and death project. There was no option to fail or not deliver which is often incorrectly cited as a reason not to use Agile.

Like the companies, the projects were very different. The BBC were free to use a “lightweight” process as opposed to the more prescriptive patterns used by Sapient’s critical project.


On joining the BBC, Mike was given the “black book” and was then sent on the scrum master course with ken Schwaber. Mike Cohn performed an estimation course for them. Rachel Davies was his mentor and co-author Liz Sedley was a project manager, which made a “massive difference”. As a scrummaster Mike then coached his team. [1]

Sapient have a single consistent induction for all staff but different business areas customise their detailed ramp up approaches based on the work they undertake which varies tremendously. Sapient also have an open online community based on Jive software that allows everyone to contribute new ideas and patterns. [2]

Given Agile is a mindset, the BBC approach should be preferred but given the global consistency, maturity and criticality of Sapient’s approach this better suited them.


The BBC management did not listen to the scrum masters and hired a building site project manager who soon realised he was out of his depth and left. Mike’s team would often be criticised for not being able to plan, due to the lack of a Gantt chart, but his team delivered on time whilst the core team were regularly late despite using a Gantt chart. This indicates an immaturity which allowed Mike to be experimental. [1]

Sapient have a very mature management team, heavily focussing on customer involvement and are keen to be seen as facilitators and not the owners. Sapient state that a “Dictatorial approach is almost always doomed” “The customer whose requirements are snubbed will no longer support the initiative”. [8]

Sapient focused on “Customer collaboration over contract negotiation” [6] with customer involvement, strong stakeholder buy in and timely decision making. They are however very prescriptive which is not always beneficial.

Customer and Requirement gathering

A main theme with both companies was their challenge with customer representation. In the BBC it was scaling the Product Owner, with Sapient it was accessing a customer who would change and be sent to hostile situations. The customer is a critical part of any Agile team to ensure software solves actual business problems and prioritises work correctly. Used correctly the customer can make decisions which reduce effort for example by removing functionality which will never be used from the backlog. There are obstacles, however, such as managing their existing full time job and only lending junior staff.

 The BBC  report states that when the Product owner (customer representative in Scrum) was not able to provide adequate input the team went ahead without them and saw this as an improvement for a while. This is at odds with Agile thinking.  This may be because it was a technical project and the technical staff, who are also likely end users, thought they knew as much as the Product Owner.

Sapient’s customer was the US Navy who were at war. Whilst the BBC continued without the customer Sapient refused to allow this. The report stated that “Collaboration… is perhaps the most critical aspect of making our clients successful.” [8] embodying “Customer collaboration over contract negotiation.”[6] Sapient built trust by gathering requirements face to face in a truly collaborative, iterative, cross functional  manner with people ignoring the job titles to ensure the work is completed such as minute taking to establish client solution ownership . Time-boxing prevented wasting time on finding perfect solutions. The results were then replayed like retrospectives in light one pager documents, embodying “Working software over comprehensive documentation”[6]. They also used visual models and aligned terminology. Work was prioritised by benefit using a force ranking pattern to quantify them then investigated in priority order as with a backlog and iteration planning. They did however have limited time to up front to gather requirements and may have benefited from test driven requirements, using a framework such as Fitnesse, to reduce ambiguity. Patterns could have been too prescriptive but Andy stated that Sapient realised the limitations and enforced “use right one at the right time”[2]


The BBC filled all the Scrum roles with scrum teams, scrum masters and product owners. The BBC also used coaches in advisory roles due to some practises being unintuitive coming from waterfall. Mike defended the large number of scrum teams as synchronising the sprints meant they were able to create a deliverable in the first sprint. Seven of the teams were already using Scrum+XP [1] As scrum master, Mike ensured scrum values and practises were enforced. He therefore voiced concerns about the Product Owner who could not fulfil his role. Two product owners, against Scrum recommendations, had benefits but they still had too much work and did not align so the teams ignored them. A Development producer (based on a Product owner) was assigned but lost the big picture. They returned to a single product owner again but kept in team product owners. [5] In hindsight this is logical as it mirrors the scrum of scrum roles for the scrum master.

 The Sapient requirements team was cross functional with The Project Manager, Technical Architect and developers. “For the workshops, they took on different roles: lead facilitator, two facilitators and two note takers. Sapient also had a steering committee of shareholders conducting regular meetings to checkpoint the progress of the deployment work. Given the Project Manager, shareholder reviews and facilitated workshops this indicates a Prince2/DSDM influence, appropriate where rigour is required, but that roles were allowed to change.

Methodology and adoption

The need for Agile differed between the two companies. As such they adopted different styles.

A lack of communication and collaboration encouraged the BBC to adopt scrum. “It was not hailed as the future, and Scrum was even not mentioned… Rather than applying practices by the book, teams at BBC embraced principles and that influenced their internal culture “[10]. The iPlayer project established the Agile working practises which worked well in isolation including synchronising the sprints to deliver working software, daily scrum, scrum of scrum, focus on impediments and cross functional needs. Scrum was a good choice given its management friendly approach and its simplicity [appendix C]. Whilst it requires the team to commit to deliverables which management did not appear to require, aligning releases from 9 teams did. Blending it with XP gave  additional engineering rigour but given the issues with the core team they may have been convinced to adopt DSDM which is the only one to have a traditional project manager and has more rigour, although it is unlikely the scrumteam would have accepted this. Kanban may also have helped them spot where the bottleneck with the Product owner was occurring. The BBC therefore focused on technology and forgot the Product Owner and didn’t get buy in from the central team.

Sapient sought to “collect requirements … as early as possible” [8] which appears at odds with Agile but Sapient were, in effect, building their backlog. Sapient adopted traditional agile patters with strong proprietary “Patterns” to ensure that projects are right first time. [8] Andy stated that the Sapient sales team are mature to the point that they have a detailed process to capture basic information about companies up front. They have identified that different verticals have greater levels of adoption of agile practises but each project always has needs to customise (from terminology, reporting frequency to wholesale changes to methodologies and processes). Sapient also have core reporting and risk management but there is a lot of flexibility. Sapient therefore have a small set of mandatory patterns with a number of other ones that teams use unless there’s a good reason not to. From a team perspective it’s best to keep a consistent set of rules so people don’t have to continually re-learn new ones. [2]

Sapient had a very mature model based on experience and a need to be right first time. The BBC had the luxury of continuous improvement.


Comparing the two cases, Agile was right for them for different reasons so they followed different adoption patterns. They both prove, however, that size, criticality, management support, geographical location, whilst important, are not blockers. In deciding which method to use it’s therefore important to consider the readiness and willingness of the company. What tools, roles and cultures exist? Most importantly what issues are they looking to address?

Could one adoption pattern work for all? Crystal and Sapient’s patterns appear to meet this in many cases but Alistair Cockburn wrote That job was to produce a set of policies and documents that could be used by all consultants worldwide, and I couldn’t do it. I still can’t.” Jim Highsmith and Alistair Cockburn both emphasise “ Being agile on a 100 person team is different than being agile on a 10 person team”  [12].

Like religion, there is still yet to be a single global agreement, so Agile, whilst more quantifiable, still relies on human choice. It took a while for Micheal Keeling to convince me to adopt Pair Programming based on insignificant data.[3] So, in closing, Mike Lowery responded to my question ”could one size could fit all” by replying “No, Context is king”.