Can you be Half-Agile?

A lot of companies I’ve come across in my consultancy life have heard all about Agile and think they should be going there.  It’s new, it’s exciting, it’s faster, it’s cheaper, it works and just about everyone is doing it.  They want some of that too!

Well let’s first get some realism into this first.  The IT industry and especially the consultancy end of it (oops that’s me!) has a reputation for inventing the next big thing and then promoting it endlessly as the best since sliced bread!  So let’s not get too carried away.

Is Waterfall evil?  Is Agile Faster?

 

Waterfall isn’t evil, and if it’s managed properly it doesn’t have to be synonymous with command and control, as the Agile evangelists most often criticise it for.  Blame managers for command and control, not methodologies.

In my experience Agile isn’t necessarily faster and it’s not faultless either – there have been plenty of Agile screw ups – just give it some time to catch up with Waterfall on that front, it’s young as yet!

Agile is a good thing

 

However, Agile, if done correctly, it is a good thing and if you are developing things that people can touch and see, I’d say it’s a no brainer.  All that mocking up of screen shots in Visio and pasting them into word documents with endless descriptive paragraphs is all a bit 1990s.

I do want to emphasise – ‘if done correctly’.  I have witnessed teams claiming to be  ‘Agile’, but actually using this as an excuse to throw all documentation and management (it’s about self-managed teams after all!) out of the window, which is much closer to the way people worked in the 1970s and believe me, that wasn’t good!

With any culture change, it’s a good idea to take it slowly

 

Scrum is a culture change for both project teams and senior management and they may initially find it hard to adapt.  Scrum and Waterfall both try to deliver as much as possible, within the budget and time constraints.  Waterfall tries to decide what can be delivered as soon as possible and then attempts to stick to it, Scrum tries to make the final decision on what is going to be delivered as late as possible.  Management needs to get used to the idea that it prioritises what it wants, then finds out as it goes along what will fit in the timebox.  This may be hard to adapt to, particularly if your development shop has been working with Waterfall for a long time and has become very good at it.

I want to discuss a compromise approach for your first Scrum project that may soften the magnitude of the change and I would be really interested in your feedback on this.  The idea is to get people used to the way of working for Scrum and start senior management thinking the right way.   All of the principles of Scrum are to be adhered to, but with some concessions to make it both easier for the staff working on the project and for senior management.  It needs to be very clear to everyone that compromises are being made and why.

Planning

Plan a Scrum project, but with definite deliverables in mind.  Don’t try to hit the Scrum ideal of making every Sprint potentially deliverable.

Clarify not just the plan for the next Sprint, but also the overall plan, as you get a better idea of what velocity you can manage, at the end of each Sprint.  Feed this back to senior management.

Go for an approach that retains a system test phase, rather than trying to ensure each Sprint works perfectly, and is releasable, before moving to the next.

Product Backlog

 

You must start with a Product Backlog.  This is usually what is missed in the scenarios where people claim to be running Agile/Scrum, but have in fact descended into anarchy.  The Product Backlog represents your prioritised requirements.

Sprints

 

Go easy on yourself first up.  Don’t plan sprints of less than two weeks.  Work closely with your users in producing the system. Test as you develop, but don’t get overly hung up on making everything work so perfectly that you can release the code at the end of the Sprint.

Measure your velocity and adjust the entire Sprint schedule accordingly, at the end of each Sprint.  Importantly, inform your Project Board of this, to give them the opportunity either to agree an extension of timescales or drop lower priority functionality, if it starts to look like the entire functionality cannot be delivered to the original timescales and budget.

Make use of Sprint Backlogs and Burn Down Charts in your Sprints.

Daily Scrum Meetings

 

Are a great part of Scrum and one that all projects should consider using, regardless of the methodology.  Hold your short daily scrum meetings to discuss progress, impediments and days remaining in each task.

Sprint Retrospective

 

Another great Agile concept and what of course the really good managers have always been doing.  Hold these at the end of each sprint to work out how to make the next sprint better.

Scrum Team Organisation

 

Organise your team as you would if you were going for full Scrum, this is good practice for everyone.

System Test

 

Retain your old Waterfall System Test phase for the moment.  It means you can be a bit more forgiving when making progress from one Sprint to the next and in your final definition of Done.   It also increases your chances on your first Scrum project, of delivering something that will work in production.  Aim to dispense with this in your next project, unless you’re running a mixed Waterfall/Agile project.

Conclusion

 

This approach takes away some of the exacting need to make every Sprint work, it also concentrates on planning the entire project, rather than zeroing in only on the next Sprint, which is easier for senior management to adapt to and it adds the assurance of a system test phase to increase the likelihood of a fault free delivery.

It should be emphasised that this is an interim step, aimed at getting everyone up to speed with the methodology, before moving to a full Scrum approach.

I’d be interested in your views on this and I expect I’ll see some interesting ones!

Enjoyed reading this?