020 8123 6068
Liberty, Lahore

Waterfall to Agile - What do you do first?

More and more organisations are looking to make the transition from the traditional waterfall delivery methodology and onto the agile delivery methodology.  As with any popular movement, there is a lot of advice available and many courses around to help you transition and so we thought, given that we took the decision to do exactly this mid 2012, it seems only right that we give you our own little 'How to...' from the lessons that we have learnt implementing agile!
 
There is so much detail that could be included in an agile discussion that, for the sake of keeping this article to an article and not a book, we have assumed a certain level of understanding on agile.  But don't worry, at the end are a few links to further reading to help if you need some more detail on any area.
 
This is our journey from waterfall to agile, how we approached the transition, what order we introduced each element and some of the difficulties we faced.
 
To start it all off, we decided to introduce...
 
 
User stories
 
User stories are the building blocks of agile delivery and are used to describe the functional objectives of a project.  This is the least disruptive element of agile to introduce to a non-agile organisation as it shouldn't impact on the process of building an application, but only on how you describe the functionality that you want built.  As such, it is only the person responsible for documenting the requirements that needs to make a change to how they work.  However, it will be the entire team that will benefit from this new way of describing functionality.
 
One thing we found useful was, although it's a little more time consuming, when you first start including user stories, it might be an idea to write both user stories as well as the traditional scope document for each project.  This doesn't need to be done for too long, but it gives the PMs (or AMs or whoever writes the requirements) the opportunity to learn how to write user stories without risk of missing any important requirements.
 
We took this approach and so the evolution of our scoping document moved from the detailed functional scope document that was very long and very wordy to a more structured document that included a set of tables of user stories alongside a (little shorter) wordy document to finally no document at all but instead an online story board that contains all the stories that make up the project.
 
Next up...
 
 
Sprints (or weekly deliverables)
 
Most developers will already work in iterative development cycles, developing a few functional features to then be tested, reviewed, fed back on and improved, before moving on to the next set of functional features.  So, in theory, it shouldn't be that challenging to move to the agile method of sprints.
 
However, this move throws up a few more obstacles and challenges than you would expect, and this is primarily caused by the misunderstanding that:
 
A sprint is TIME dependent and NOT DELIVERABLE dependent.
 
What this means is that you (or the dev team) cannot extend a sprint to give you time to finish a deliverable, which is the common approach to take for an incomplete deliverable.  
 
This sounds like a simple concept to grasp, yet it causes a few issues.  To start with, when your team becomes pushed to complete the deliverables of a sprint on time, you will notice that your team immediately looks to push back on the final date of the sprint or your sprint team starts putting in lots of overtime as the sprint approaches its end to try and complete all the functionality on time.  Neither of these are healthy or scalable long term.
 
Instead, the team (everyone in fact) needs to understand that, if a story (ie deliverable) is not completed by the end of the sprint, then this is not a problem and that the story can be carried over to the next sprint.
 
The other thing to look out for is how a team works together to deliver a story in a sprint.  Developers will often want to complete all their stories together before passing them to the QA.  However, if they do this in a sprint process, it means that the QA doesn't get any of the stories until the end of the sprint and then has a mad rush to try and get them QA'd in time for the devs to update any feedback they have...ultimately resulting in a number of the stories not completed due to not enough time to fix the issues.
 
The team needs to work together to pass stories between each other throughout the sprint to remain effective and efficient.
 
We then moved onto...
 
 
Daily stand up
 
You could argue that this should be the very first step that is introduced to your team and that's certainly an approach you can take, however, we considered that where the daily stand up really becomes a necessity for agile is when you start developing in sprint cycles.  It is the interdependencies of the team members that a sprint cycle demands that requires the daily stand up to be included at this stage.  In order to effectively work together, the team needs to communicate with each other and know what each other are working on and what problems they are having.
 
The biggest issue you are likely to experience with the introduction of the daily stand up is ensuring the quality of the communication at the stand up is correct.  The most likely shortfall will be that team members do not raise genuine obstacles when they need to (people don't always like to admit they are having a problem and will often try and avoid it) and as a result the problem is only discovered at the end of the sprint when it is too late to do something about it.
 
One tactic to help see & then share problems is to get each member to estimate how long they think they will need to deliver their bit of a story.  If they don't know or it starts taking them a lot longer than they initially thought, it is usually because they are having a problem and you can look into it in more detail.
 
At this point, the natural next step is...
 
 
Pointing (& sprint planning)
 
...what is a (the) point?
 
This is probably the hardest aspect of agile to introduce to your team.
 
From the start, your clients won't understand points, your account managers won't understand points, your sales team won't understand points and possibly even your developers won't understand points!  
 
What they will really struggle with is the fact that points are not hours, but effort.
 
However, this is a fundamental part of agile and it is vital that you are use points for your stories.  It will take time to get everyone round to what points are and how to point stories, but you need to stick at it.
 
The main obstacles you'll face are likely to be:
 
- Clients will want to reduce points for stories, thinking it will reduce the time to deliver that story.
- Developers will increase the points on stories, trying to reduce their workload in a sprint.
- The 'value' of a point will change from pointing session to pointing session, affecting your ability to estimate how many points you can deliver in a sprint.
- If there are different people in the pointing session, it will change the value of the points.
- Developers will try to add points to stories during the sprint as they discover more about the story.
 
There aren't really any definitive answers on how to deal with these problems but try to remember a few points:
 
Sprint planning is an estimate and not a guarantee.
 
When you put your stories into sprints, you are planning according to points.  People (ie the client) will start to expect the points that are included in the sprint to be delivered at the end and will be annoyed if they aren't.  It's important to remind them it's not a guarantee, but an estimate.
 
 
Keep an eye on your velocity (the average number of points you deliver per sprint) and ensure the points you include in the next sprint match the velocity.
 
Always have 25-50% of extra points 'on hand' to be pulled into the current sprint if the team find themselves ahead on the included stories. 
 
To help with effective sprint planning, you need to start...
 
 
Backlog Grooming
 
This is important for all agile projects, but is most important if you are using agile to deliver a time sensitive project (and not an ongoing product).  For these projects, it is important that you stay on top of the end of the project and the way you do this is by constantly grooming the backlog and seeing where the last sprint is falling.
 
It is very easy to forget or overlook this part.  If you do, you will find that the project will grow; with user stories added for learnings gained, features incorporated from the clients changing requirements and complications arising from unforeseen problems, the end delivery date of the project when all the key functionality is due to be delivered will have slipped quite a bit without you even noticing.
 
This makes for very awkward conversations with the client!
 
Ahh yes, the clients, which brings us nicely on to...
 
 
Client visibility
 
It is less cut and dry as to when you decide to open up your organisation and process to the inspection of the client, however if you want to be running a true agile process, eventually you will need to do this.  And when you do, there will be 2 very clear outcomes:
 
1 - you will very quickly find out which parts of the agile process you're team is not delivering as the clients focus will be immediately drawn to those aspects.
 
2 - you will have to exercise some real client management skills as a result of the client identifying these holes in your process!
 
Ultimately, it is up to you when you decide to take this step with pros and cons for every scenario, but the earlier you do it, the faster you will learn the holes in your process and therefore the faster you can fix them however the more of headache you will have trying to keep the client happy who will now be questioning your fundamental approach and process to delivering their project.  However, the later you decide to do it, the slower your implementation will be and it will be easy to develop bad habits that will affect the effectiveness of your agile process.
 
So.  In...
 
 
Conclusion
 
We have been transitioning our entire organisation across to agile for 18 months now.  All of our projects are now delivered in this fashion and we are always reviewing and assessing our processes to ensure keep improving the way we work.
 
The biggest advantage that we have experienced is the transparency this methodology delivers allows for much better client relationships and better products delivered.  We would urge any agency that has not yet embraced these principles to do so, we'd be happy to share our learning.
 
We know this is not a definitive approach to implementing agile into your organisation and every company is different, however we hope this helps.
 
Stick to your guns, good luck and it will definitely be worth it in the end!!!!
 
 
Helpful links:
 
User stories
 
 
Sprints (or weekly deliverables)
 
 
Daily stand up
 
 
Pointing
 
 
Sprint planning
 
 
Backlog Grooming
 

19th August 2014

Posted by Chris