- April 8, 2016
- Author: admin
- Category: Agile Methodology
As someone who knew nothing but the Waterfall model and its endlessly long cycles, Agile was something that scared me first. When I got into an Agile workspace, I had to go through a culture shock, adapt and then become what I am today.
Several months from then on, for whoever wants to go Agile, I’ve always said ‘Welcome to the wonderful, colorful and energetic world of Agile’
Let me take you through how a typical Agile environment operates, but before that, let me warn you that this is no jargon filled, opinionated review of any tool or technique. This blog aims at telling the common man what Agile is, and how it can impact many, many lives for good.
The meaning of the word agile is the ability to move quickly and easily. The Agile workplace encourages this: quick and easy development and movement of working software.
The Agile Manifesto
After years in the traditional software development space, a group of people who decided that they needed to break free from endless and vicious cycles of software churning, wrote the Agile Manifesto and Principles.
The Agile Manifesto reads
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I hope that does not require explaining, because it is as simple as it can get.
The Agile Manifesto is beautifully interwoven in the Agile Workspace. For instance, try mapping these ‘NO’s to the manifesto above:
- There are no cubicles in the Agile Workspace
- There are no lengthy documents
- There are no major ‘change requests’
- There are hardly any paybacks
- There are no tedious communication channels
- There are no strict hierarchical divisions
Most of them will satisfy more than a statement from the Manifesto.
Agile is fun
Alright’, so you ask me, ‘what is the talk about so much fun?’
Coming straight at it: Agile workplaces are fun because it is the people who matter. Not the processes. Success is a measure of the team and not an individual. Feedback is the most important measure of an individual’s performance, and given timely, it is a great tool to foster amazing relationships. The fun is about delivering something of great value to a customer as a cohesive team whose camaraderie is evident by way of its work.
A typical Agile team would deliver business value in sprints or iterations which normally are one or two weeks long, as opposed to delivering something (with deprived value) after 6 months. At the end of iteration, the team produces working software, and their clients validate this before being deployed to production or pushed to UAT. Feedback is instant, and if there is a change, it is done almost immediately.
User Stories and their colourful nature:
‘What about the contract? A change is a change!’ you may ask. Remember that there are no contracts in Agile. No extensive documentation. Just what is enough to get work started. This is because when a project is begun, only high-level features are listed. These are then broken down to user stories (which is in itself a large part of the Agile way of working) and the user stories contain everything that is required to get a small chunk of work complete.
User stories are Agile’s way of breaking large feature chunks into the smallest possible piece of work so that it cannot be broken down further. Criteria for the story’s acceptance or completion are written on the card, along with tests that need to be performed, behind the card. This is the colourful part. User stories are written on colourful index cards.
Usually story cards are colour coded so that the development team knows differences in cards. A team may decide that functional story cards are written on Blue cards, non-functional cards like performance tests on Green cards and bugs on Red cards.
These cards are ‘played’: in the sense that they are taken from analysis to testing in a certain period of time. They usually traverse what Agile calls ‘swim lanes’ that consists of statuses for analysis, design, develop, test, and accept.
Each team has a physical wall where these cards are stuck and moved around so that everyone on the team knows and sees how much work is available for the team for the current iteration.
The good thing about Agile is that there are no fixed deadlines. Sounds a bit like an oxymoron right? Right. Actually there are deadlines- but they aren’t stringent. Teams and clients understand that requirements cannot be the same when they were envisioned and that change is as much a part of software delivery as it is a part of life.
Hence, if all the cards for a particular iteration are not played- there is no panic. A backlog is maintained, and as and when the development team can, they will pick and clear the backlog. More often than not, the backlog is not big at all.
The good thing is the focus on people-it makes everyone accountable, but as a team. One of the very few practices (note that I am not calling it a process) that dedicated Agile teams follow is a stand-up.
All members of the team meet at an agreed time every day (it could be anytime of the day) to update the others of what work was done the previous day, and what will be done today. This makes everyone accountable and serious about their work.
Ready to go?
That just covered all of the statements from the Agile manifesto.
So if all that gave you a good understanding of Agile, and if this blog caught your attention any bit, I suggest you indulge. For the pleasures of this unknown are far bigger than the struggles of the known. Happy Agile-ing!