Moving Towards Being Agile – Introduction
I have attended a few talks and workshops at the Software Design and Development conference in London this week, specifically around the Agile methodology:
- Agile in a Waterfall World
- Applied Agile Workshop (both by Phil Japikse @skimedic)
- Agile: From Stories To Code
- The death of Agile
- Design by Coding (all by Allen Holub @allenholub)
Unless you’re convinced of its merits, Agile can seem like a methodology that makes working very difficult – and many people are convinced that their current approach is good enough and needs no change. I’ve used what was said in these talks and workshops as the basis of my next few posts, together with some of my own observations from working in a team trying to be Agile but in a largely Waterfall project for the last few months.
What is Agile?
The Agile software development manifesto states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Note that the manifesto shows what is favoured. It doesn’t say “instead of”, it says “over”. The things on the right are still important, just less so.
Agile is about transparency. In a Waterfall world, the Project manager will constantly be asking developers for a status update. The first step would be to set up a Kanban board. Track tasks that need to be done using cards or post-it notes, and the PM will have instant feedback and can get on with things like reporting the status and sorting out budgets and other important things. Developers will pluck a figure out of thin air when asked for a status update, so it really helps no one. The exact flavour of Agile is important too – Scrum likes its burndown charts, but these are subjective and don’t always tell an accurate story. It assumes that the number of story points you allocate to a task is exactly accurate, and is quite easy to manipulate to show increased velocity, for example. Moreover, it’s anyone’s guess why a burndown chart goes up and down; it doesn’t really improve transparency (it’s good for when things are good, not so good for identifying problems). On the other hand, a Kanban board shows you exactly where the issues lie – it’s wherever there are the most post-its sitting and not progressing :). This then allows a project manager to address the specific issue rather than using valuable time investigating what the issue is in the first place.
Scrum is a good way of beginning the transition from Waterfall to Agile. However, in and of itself it is not fully Agile. By its very nature of having retrospectives every sprint, it encourages the developers to think about what needs to be improved, and then going ahead and improving it. Hence, the scrum you follow today should be materially different from the scrum you follow in a year’s time.
Sticking with the theme of transparency, you must be brutally honest. Don’t say things are fine when they’re not. (Incidentally, how many times have the words “it’s fine” been uttered when things are *actually* fine?). Be transparent (there’s that word again!) and give the full story when asked. Don’t talk until the listener’s ear drops off though! This is another valuable skill (which many humans haven’t yet mastered in any form of communication) – give a concise update that is more detailed than “it’s fine” without going into full on detail and talking the morning away. Just as there’s a 5 sentence rule for email, spoken communication should be similarly concise (until you’re asked for more details).
Agile is about flexibility. There is no point developing beautiful pristine code, if it isn’t valuable to your users. Working in an Agile way means being flexible with code, time, and requirements. It means having a quick turnaround time, where you develop a small slice of the overall system, show it to the users, get quick feedback, and change things where necessary. In an Agile world, you have no qualms about simply throwing away code that is not of value, and that is not a bad thing.
Agile is about rapid feedback. For developers, unit tests count as pretty much instant feedback. For users, this means regular demos, so that they can comment on what is right/wrong with what’s been done so far. When there’s only a few days/weeks of work at stake, developers feel less attached to their code and are much happier to change what they’ve done (it also costs much less to change). The longer you leave it, the exponentially higher the barriers to change are and the less likely you are to actually change what has been done – especially more fundamental changes. In fact, a good test of whether or not you’re working in an Agile fashion is considering the following:
If your customer came to you with a huge fundamental requirement (e.g. making your website a mobile application) would you have something to show them in 2 weeks? If yes, you’re Agile. If you have to wait for permission to download software, reach out to different teams, fill out forms justifying why you’ve requested something, organise your budget, find a consultant, etc etc then you aren’t.
Finally, Agile is about collaboration. More on this in the next post.