How Agile helped deliver a 2-year project in 3 months

How To's
When I was first pulled into a project that intended to deliver a new online account opening capability for the bank, I thought to myself ‘this will take a while’. When the business then said “you have 3 months to deliver” I must not have been the only one to think ‘you’re pulling my leg, right?’ I have never seen that happen. EVER.
But now after 3 months of hard work — WOW! We’ve implemented the online system we set out to do. What an incredible ride!

But how on earth did we do it in a bank where typical projects of this nature usually takes 1.5–2 years? This was simply, unheard of.

Enter Agile

We were a traditional Waterfall enterprise, delivering projects in strict phases: Concept, Analysis, Design, Development, Test and Implement. Everything was sequential and no phase started without completion of the prior.

The 3-month timeline meant that we had to change our ways as the Waterfall approach would fail to meet target.

Agile was introduced and it proved to be a better reflection of reality in that multiple phases were allowed to occur in parallel within one sprint e.g. Analysis, Design, Development and Testing occurred concurrently. We went with it and never looked back.

But what components of Agile helped us the most and how did we do it? Was Agile the only contributor to success? Here’s how things went down.


The Human Interaction factor

The first point of the Agile manifesto brings us back to the old ways of doing business:

Individuals and interactions over Processes and tools

Once upon a time we did business without computers. And more so than the processes and tools we had back then, the workflow relied more on people.

We could not fulfill the above without being co-located. As soon as we gathered the core team in one area, we were better equipped tocommunicate, clarify and iterate through the requirements.

 

The People

The team collaboration motto to get things done: ‘the closer, the better.’

 

We were soon able to get rid of some Waterfall legacy:

“Sorry, I checked the document repository and the other team’s spec has not been checked-in. I can’t start work without their input.” — Developers waiting for a documented spec as a basis for coding.

Replaced with: Approaching the relevant team member and talking things through.

“I shot an email to Joe. I am waiting for him to respond.” — A team member (any team member) waiting on a key dependency.

Replaced with: Tapping a colleague on the shoulder and talking things through.

“We are down a resource and therefore cannot produce our output.” — The Project Manager reacting on a circumstance.

Replaced with: Helping each other where possible.

Now we didn’t exactly get off to a flying start as we were all pulled together from different areas. But time builds trust and after a couple of sprints, the lines of communication slowly opened up.


Inspect and Adapt

The second point of the manifesto is a beauty:

Working software over Comprehensive documentation

We created documents where it made sense but made sure that the #1 priority was working software. We demonstrated the software during our end of sprint showcase (a review).

bag-and-hands

Most of these showcases were a success — although one sprint failed to present some key features we set out to do. This turned out to be a good thing in the end as the wider audience were able to see the challenges and roadblocks we had.

In other words, we were able to get rid of some of these bad practices:

Keep that risk in the risk log and make sure it’s all up to date. We’ll look at it in the next steering committee. — The Project Manager keeping a project artefact current.

Replaced with: Making all risks and issues transparent when we hit them.

“Oh, I was not expecting the system to look like that. I thought we documented something different.” — The Stakeholder upon looking at the system after a year of development.

Replaced with: Either an explanation as to why it was designed that way, or, we modified the design according to the feedback — all within 2 week sprints.

“Why did the system do that? I thought our requirements said something else.”— Another Stakeholder after a year of development.

Replaced with: Either an explanation as to why the system behaves that way, or, we changed the required behaviour — once again, within a sprint.

The 2-week feedback loop cycle proved to be a better way to iterate through the work with the wider stakeholder group and allowed us to change course sooner rather than later.


Empowering the people

Our sprint planning sessions echoed point #3 of the manifesto:

Customer collaboration over Contract negotiation

Planning was a collaborative effort that started with the selection of user stories from the product backlog. We would then collaboratively discuss and size the user stories, ensuring that all voices were heard.

Lego

People were empowered to question, debate and work through problems together. The emphasis was on collaboration and not on taking ‘signed-off documents’ as the only source for development.

 

If we needed to know more about the business driver for the story, we asked the Business Owner who sat right beside us to ask.

We were able to replace some old habits once again:

“I would like to change that feature. Do you want me to raise a Change Request?” — the Business Owner after discovering new information.

Replaced with: A 2 week sprint cycle of taking in new stories.

There’s a new value being passed by the front end that we haven’t catered for in the back end. That wasn’t in our agreed document. — Developers after discovering a change in design.

Replaced with: Co-located team members who call out changes as it occurs.

“You cannot change that feature now as we’re in the middle of development.” — the Project Manager trying to control scope for a 2-year project after initial agreement.

Replaced with: The ability to change mid-sprint.

We might not have necessarily agreed on all points raised during development, as there are many way to handle a problem. But we still made sure that the business outcome was clear and understood by all.


Allowing for ‘FLEX’

Given a choice between a rigid plan which details activities over a year AND planned activities over 2-week cycle — which would you choose? Manifesto #4 states:

Responding to change over Following a plan

The Office

Decisions are made based on best available information at a point in time. New information that comes later in the process, can therefore change things. Why are we killing ourselves over decisions made in the past?

The requirements and design must finish by this date. — the Project Manager on forward planning.

Replaced with: Stories (requirements) were brought in at each sprint and if analysis on those stories required the design to change, we changed the design during that sprint.

“I have development starting in September. We are a month behind.” — the Project Manager when reporting project status.

Replaced with: Requirements, design and development occurring concurrently.

“I will need resources around July to help build the requirements.” — more forward planning by the Project Manager.

Replaced with: Fortnightly sprint planning where resourcing issues were addressed.

The cycle went down like this: If there was a roadblock ahead, then someone called it out and the powers that be, removed them. If there was a problem, then people that were able and willing to assist, helped out.

Our self-organizing team adjusted to new challenges as it came along. There wasn’t a problem we couldn’t solve, mitigate or work around as a group.


Find, Keep and Value Good People

Although Agile gave us the framework that helped set the project up for success — it’s actually the people that carried us through delivery in the end.

 

At the end of the day you can use any of the project approaches out there, any of the available tools in the market or follow any processes used by your peers. But without good people, then you will struggle to achieve a good outcome.

 

A good group of ‘can-do’ people who are flexible and are open to change can really take the project a long way. We all know that:

“There is no I in TEAM

It takes time to build trust and as our sprints progressed, people started opening up and helping others.

“We have a backlog of items in our testing queue!” — The Testers all clogged up.

Team response: Everyone became a tester and tested.

“We need a html template for our exceptions and the developers are tied up.” — the PM upon learning that the back office needed a template for exceptions.

Team response: A ‘non-developer’ stepped up to create the template.

“We are running behind on our Welcome Emails — can someone help?” — the Business Owner realising that we were running late in email development.

Team response: People pitched in to collate content and team members stepped out of their defined roles to help build the email.

Without a good team, the outcome would have been a lot different. I seriously doubt we could have pulled it off in 3 months time.

Thankfully, I am surrounded by a winning team and a good project framework.


About the author

PC halved

BA, IM, doer and Agile super-fan. I am proud to be part of the team that transformed this ‘too-hard-to-do 2-year project’, into a success story in 3 months. We worked, cried, worked-through, retried and succeeded…then said ‘Bring it on!

This article first came out @Medium and referenced on this post.  It’s posted here for completeness.

n.b. there’s a little bit more detail and presentation differences with the Medium version (click to see the magic).  

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s