About-Berkeley

About Berkeley

We’re about being there for our clients when it really matters. When it absolutely has to be right. Doing the right thing is both our ethos and sweet spot. And it’s why clients turn to us again and again

 

Careers

Find out how you can make a big change to your career by joining one of the best small firms in the UK.

 

I started out in Management Consultancy in 1997 having graduated from the University of Durham with a Masters degree in Astrophysics.  I have worked with some fantastic clients over the last fourte...

Hadley Baldwin, Partner

Hadley Baldwin

View Hadley now

The people

It's the people that make Berkeley different to other consultancies. Bright, friendly, down-to-earth people who are both thinkers and doers. Working by your side, as consultants and colleagues, to get the right results.

Articles

Our Partners and consultants share their perspectives and thinking on topical issues.

How agile can better enable your IT projects

Agile can really enable your IT projects to deliver business results more responsively and more quickly 

While “agile” methodologies (and “rapid” before them) have been around for decades, the ubiquity of consumer-facing mobile applications, SaaS alternatives to on-premise software, and the increased accessibility of cloud infrastructure and DevOps has meant that traditional, “waterfall” delivery approaches are often viewed as old hat…


…But doing agile right is far from easy. The Berkeley Partnership has had 25 years of experience delivering large, complex technology-enabled change using both waterfall and agile approaches. Here are some lessons from our experiences:

Recognise what “agile” is - and isn’t

IS: both a philosophy and a series of tools and techniques:

Agile-article-Image-1-(1).png
 

 

ISNT: a replacement for good programme and project management discipline.  Agile philosophies emphasise ‘self-managing teams’ - and certainly, trust, and appropriate levels of delegation within teams is key to a successful Agile project.  But in our experience, delivering enterprise solutions inevitably involves teams who are structured around more traditional waterfall phase gates. Project management involves ensuring that - all aspects of the project - including business readiness, data migration, - user training, audit and regulatory compliance, legal and commercial issues, etc - are dealt with adequately.


ISN'T: a project without any documentation - agile control systems need to be just as - if not more - sophisticated and rigorous as on a waterfall project.  Documentation needs to be developed as each requirement is delivered, and work cannot be declared “done” until it is documented, tested and formally handed over.

The Product Backlog 

…is the list of requirements, sequenced in the order in which they will be delivered - factoring in both business priority / value, delivery dependencies (you can’t build a roof before the walls) and risk (don’t leave it until the end to discover you’ve underestimated the time required to deliver the complicated stuff).

Requirements are often documented using “User Stories”, a technique which captures the requirement and the desired benefit, along with the criteria against which successful delivery will be tested.

Agile-article-Image-2-(1).png

Story points and consensus-based estimates

At the start of each sprint, the team should review the backlog, and estimate the amount of work that the delivery of the next story in the sequence will take.

Techniques such as “planning poker” are used - where each team member independently estimates the amount of work (in “story points”) that a story will take - and the estimates are reviewed and discussed by the team as a group before the estimating exercise is repeated until all team members agree on the same consensus estimate.

The Minimum Viable Product and the 50% rule

The Minimum Viable Product is the subset of requirements which are absolutely critical for go live.

Think of the MVP as a line drawn on the sequenced Product Backlog; if anything ABOVE the line is not delivered by go-live, there’s a “NO-GO” decision. If everything above the line is there, it’ll be a “GO”.

The 50% rule states that when you embark on the project, you should plan the delivery so that no more than half of the capacity (in story-points) you have available is used to deliver the MVP. The remaining 50% is scope contingency for new functional requirements that crop up during the project, and to account for things that turn out to be trickier / more complicated than first thought…

For example - if you have an MVP that you think will consume 50 story-points to deliver- and you have a team with a velocity of 20 story-points per sprint - youshould plan for at least 5 sprints (100 story points delivered).

Agile-article-Image-3-(1).png

You can’t buy agile projects in the same way you buy waterfall projects

It is critical that procurement teams understand the concept of Agile = Variable Scope. That means that there is no pre-defined specification that can be referenced in a fixed-price contract. There is no one simple answer to best-practice agile contracting, but in our experience, contracting for “velocity” - getting the supplier to underwrite the number of story points their team will deliver in each sprint – or buying a fixed number of story points are alternatives that have worked well.

Agile-article-Image-4-(1).png



 

 

 

We’ve got extensive experience of working in ‘hybrid’ project environments – integrating agile working practices into large organisations with complex legacy systems and support functions geared to waterfall ways of working.

Dave Machin

Dave Machin
Partner

Contact Dave Machin

We have placed cookies on your computer to help make this website better. You can change your cookie settings at any time. Otherwise, we'll assume you're OK to continue.
Close cookie warning