neoworks product develop_nw banner 920x430px

Agile has meaning

This article was first featured in Commerce Insights – for more fresh and interesting insights click here.

The world’s gone agile. Why? More and more companies realise that being agile is better than trying to be perfect. Releasing a perfect product (if such thing existed) might take years and meanwhile a lot could change – customer requirements may transform, a similar product may get launched, and by the time you have released you find out that some features never get used. By launching more frequently, you gain an advantage over your competitors, who are still stuck with tweaking and adjustments (or maybe even planning). Being agile is not about being careless but about being realistic and adaptive. Agile is not just a fluffy buzzword and it doesn’t mean ‘no planning’ as perceived by many. Developing with agility has meaning.

Incremental means evolving

It is a natural temptation only to start work once everything has been carefully planned out. Much like building a house, this implies a sequential process – once one step has been completed, you can move on to the next one. You must resist this temptation – in software development it only makes for a completely unnecessary limitation. The earlier you realise you made a mistake (and you will make them) or even change your mind, the cheaper it is to make amends. Release your product a hundred times and give yourself a chance to see how your decisions shape it. You will benefit greatly from these frequent reality checks – just because something looked good on paper doesn’t mean it will fit the bigger picture. It is impossible to get everything right the first time. Allow your creation to evolve and adapt to the ever-changing environment.

A bonus on top of all this is that testing can be done concurrently with the development, which means frequent and thorough validation.

Planning

It is a common misconception that Agile discourages planning. You will probably need a plan, but plan with agility – just enough to get you going. Your plans are there to enable progress, not to constrain it. As an aside, a written plan will often have a soothing effect on your client’s (or your boss’) wracked nerves.

Imagine you’re planning your house refurbishment. You want it done by Christmas and the priorities are: kitchen, bathroom, bedroom, and then the rest of the house. However, reality confronts you straight away – two walls in the bathroom have to be rebuilt and you’ve changed your mind and decided to go for a double fridge. Costs are rising. What do you do? Agile says you drop or change requirements in order to meet your deadline. Don’t fall in love with your features and plans; I know they are your babies, but sometimes you may have let some of them go (you may be able to revisit them later)!

Empowerment

Bureaucracy is worse than sabotage; filling in forms, writing knotty reports for nobody to read, changing cell colours in Excel spreadsheets and staring at slide-decks. It is rarely discussed what effect a project methodology can have on the morale of the team. Apart from being ineffective (and, ultimately, expensive), excessive protocol can be quite disheartening for people involved in a project. It’s easy to underestimate the influence this can have on efficiency and quality of work. Here is Agile’s take on this matter:

Releases

Launching new features brings a lot of satisfaction for both the development team and the customer – do it often. The whole team gets excited about each new accomplishment; it gives the customer something to talk about; it energises everyone. Months of work without a single milestone can lead to burn out!

Procedures

Procedures are like plans – they can provide guidance or overwhelm you. One powerful motivator is responsibility. If everything everyone does is according to some procedure, then the sense of ownership and accomplishment vanishes and motivation along with it. Did something go wrong? Did we miss something? Should we introduce a new procedure? Maybe not, let’s pick it up at the nearest retrospective* (which is never more than a couple of weeks away) and make sure everyone is aware of how things are going.

Talk to each other

Don’t communicate through spreadsheets and slide-decks. Agile embraces close, every-day communication. The earlier you catch out any misconceptions and bring everyone on the same page the better. Progress can be reviewed and priorities re-evaluated virtually every day because the milestones are small and frequent.

A common practice of agile development is having short daily status meetings or ‘stand-ups'; it’s a way for team members to bring each other up to speed on the latest developments in the project.

Back to basics

Allegedly, the Manifesto for Agile Software Development was created in less than a day. It was supposed to allow developers to break free of some of the rigid and time wasteful practices of the 80’s. Here is the gist of it:

Individuals and Interactions over Processes and Tools
Working Product over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

Agile is about going back to basics and restoring the balance. Assess where you are and start taking small steps towards the goal. Invest some time in reflexive thinking (What have we learned? What worked? What didn’t?), adjust and make changes based on your evaluation. Rinse and repeat. Always choose the solution that will make future changes easier.

A lot of devaluation and abuse of the word agile is happening today. Agile became a fashionable marketing term, akin to organic, used to improve sales. Too many consultants too often will sell Agile to you, but in practice show a preference for processes, contract negotiation and documentation over true agile values. Agile is not a buzzword or media-speak; agile is meaningful, sincere, expressive and deep. And it has a purpose.

*    A ‘look back’ meeting for the whole team at the end of each iteration. This is the time to discuss mistakes, new tricks, lessons learned, new ideas etc.