What is Agility?
Let’s begin with some history!
Systems establishing the scene for agility – like Scrum, XP, DSM, and Crystal – were gaining popularity in the ’90s. In the beginning of the 2000s, a meetup for like-minded men was organized, including creators of Scrum. The goal was to find a collective name for all these frameworks, one that could indicate their purpose.
Their finalists were adaptive and agile.
Both of these verbs indicate flexibility, though agility was chosen because of it reflecting on quick reactions to change.
What does this all mean for software development?
Let’s be clear up front.
We need to accept the fact that our client will not be able to precisely express her expectations regarding the final product before development.
This is why we need lots of communication! By that I mean internally and also externally, with the client. This is the only way to fully understand the pains of our client, hence, search for the most efficient solution.
Meeting twice (once at the beginning and once at the end of the project) is not enough. You will have to coordinate on a regular basis. “Why can’t we just meet twice? We will walk through the project in the beginning and create a document we can agree on. According to it you will carry out the development and I will take the final product!” – the client might say.
- First of all, even if it’s a smaller project, laying the document out will take a couple of days. Then, will you be able to specify the nitty-gritty, finalize the question-answers and boom, a week has gone by… and we haven’t even written a single line of code!
- Secondly, the client will only be able to specify the exact path when she is faced with alternatives; thorough development is when we meet these alternatives.
Think about it, you shouldn’t have to build a spaceship from scratch! If you create a specification (like how we’ve explained in a post before), you’ll get an accurate price estimate. Through this process the client will have a better picture of what she wants. But then, she still doesn’t know very much about the alternatives, what further options she might have. In order to make exactly what she wants, the best way is to create working functionalities in the shortest possible times.
If she only sees the final product, she will realize, “Now that I see it, it would be better if we had another option in the hamburger menu.”… i.e. it’d be better if this or that were here instead of there and what if it took the user to a different place… In contrast, if she is shown the finished functionalities regularly (e.g. biweekly), she will see what has been done and she’ll be able to cost-effectively make changes. Meaning, she will know how much it’ll cost and how long it’ll take to implement certain modifications. No surprises.
So, it’s extremely important for the client to work together with and trust the development team, to ‘think agile’.
Us developers, we need not forget two things:
- creating a code-base that is prepared for change,
- make the most of the project, so the client will actually get what she really wants for her money.
What does agility give us?
Agility gives us a framework and a philosophy. It’s not just guidelines it’s a way of thinking about software development and client-developer relationships.
For reference, I’ve included the Agile Manifesto below:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
What does agility not give us?
Agility does nothing without a good team. Consider a 3D printer. Its output will only ever be as good as the model it was fed. Now, agility will only work as well as the team that’s using its guidelines. Like a printer, no matter how well-designed it is, it won’t print anything beautiful unless the model it’s been given is beautiful. Agility is a great way to develop great software, but it works properly only if the team that’s using it knows how.
Agility without proper application is just a rule-book, to implement it properly, you need flexibility and committed software engineers.
All in all
Agility is a work in progress for many of us. We have daily stand-ups and proper Sprints in most of our projects, but we are just implementing project reviews (partially, because there hasn’t been much demand from our clients). Better understanding of agility might lead you to engage with your team in a new way, or it might not. Its rules should be applied only when needed, not followed blindly.
Agility is not faster delivery, not less mistakes, not higher productivity, nor higher quality. Agility simply means agility.
With it we should be able to quickly and easily embrace change and adapt to it.
This is how we will become masters of change.