All about AGILE
Agile is a buzzing word in the software engineering world, No! its one of the big buzzwords in the IT world. So it shouldn't be surprising if a non-programmer say that "I am doing it agile". Agile is not restricted to software engineering its all about quality product development. Why is agile so important? Lets take a look at what agile is all about.
What is AGILE?
Agile is a combination of methodologies and techniques that can help teams to adopt to the vicious and dynamic life cycle of a project [not necessarily software though it mainly relates to software]. It help companies and teams to react accordingly to the ever-changing nature of projects [especially software] and mitigate the risks involved.
The manifesto of agile consists of four major disciplines or principles."building the right thing and building the thing right"
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile is a process, a process that focus from the very beginning of the life cycle when you just lit an idea, to the very end until you deliver the final product. One can say it is a way of living which is true for any craftsman who perfects everything he do. What we need to know is that Agile is all about being "agile". I know its kind of a recursive definition but then again the definition of recursion itself is recursive. You can find more about Agile Development Here
There are 10 principles that are common to all the agile methodologies.
Kings and Queens
The most important discipline in any agile methodology is to promote user interaction. The customer is the most valuable and sought-after entity in the project. The end product [if it to end] will only be successful if you satisfy the requirements. Sometimes it is really hard to have the end-user involved during any part of the project since the customer maybe external users who are geographically scattered. But at least an experienced user representative should be involved during the process.
The A-Team
The development team should be empowered to take their own decisions. This team should include the customer since it is the number one requirement of agile. Mostly we think of the project as two phases where the client and analyst [maybe the project manager too] sit together and finalize what is that they want. But it is less expensive in the long run and make it very efficient if all the members are involved in these decision making processes.
We tend to think that there is no need for a developer to take part in such meetings but the success of this project heavily rely on the low level labor. Sudden changes to requirements without their consent not only disrupt operations, reduce efficiency but also lessen their motivation.
The team should feel the sense of ownership from the very beginning by clarifying requirements together, prioritize them together, estimate the effort and agree to take upon task TOGETHER.
Sand of Time
Change of requirements over the time is inevitable. Just because the requirements a slightly changed it usually doesn't extend the timeline for the project. Few years back it was not the case, customer was not allowed to change the requirements once agreed upon. But today with the rapid growth of technology it is circumvent to be up to date thus changes are to be expected.
Understanding this issue, agile gives many solutions from the management point of view to the bottom layer of labors. In reality we cannot 100% estimate everything to be perfect. There is always a variable that can change the outcome of the project. As a team we should always watch over these variables and analyse the risks involved.
Agile is all about being pragmatic. Your always safe with agile because you have taken the measures considering all the risks involved. The room to evolve is the freedom agile offers.
Fragile of Agile
There is no one, I mean NO ONE that can capture the final product [outcome] by a glance of the requirements. Requirements rise as we develop the product. Unseen aspects will be visible when you get dirty. We should focus on the requirements that are currently on the list while being cautious of future changes. This is the part where agile can be FRAGILE.
YAGNI ["You Ain't Gonna Need It"] is a concept of agile which focus on what is needed at the moment. We tend to get carried away when we analyze requirements and estimate timelines. This is a serious issue in software engineering where many have failed. The "Agile Fever" is an outcome mainly because of the thin line of "what is important" and "what is not". Only through experience one can define correctly the requirements that should be focused on. "Pair Programming" is a tool which is highly useful in these scenarios.
Ants vs Elephants
How do you eat an elephant? One bite at a time of course. Agile delivers in small pieces in an iterative and incremental fashion. In spite of trying to deliver the whole thing at once we should try to break the whole elephant into tiny bits of pieces which we can easily develop and manage. There are many advantages to this approach.
- Low risk for future changes
- Easy management
- Greater flexibiliy
- Increased value
Fast and Furious
Managing expectations is all about the ability to predict. If you know what to expect then you can be prepared for it. People are generally happy when they get what they expected. But if you predict wrong not only the result is worthless but people might get furious. Frequent delivery of product is very important as well as getting the CORRECT version. Just because you have to deliver fast it doesn't mean you can be careless.
Different methodologies define "frequency" in different levels. There is no correct definition to be right or wrong. Its all about the context.
Done means Done
Its not only for agile but for anything and everything we do we must make sure that we perfect our work flawlessly. If you are really doing agile then once a phase is completed it is never coming back. What is marked as complete should be complete or else the whole point of doing agile development is loss.
Enough is enough
Pareto's law is more commonly known as the 80/20 rule. Its about the law of distribution and how many things have a similar distribution curve. Typically 80% of the success comes only with 20% of the whole effort you put.
Its YAGNI all over again. One should not under-estimate or over-estimate anything. The trick is to find that 20% effort upfront and get the 80% quickly. But there is no universal path for that.
Testing is not for Dummies
This is the, most popularly misunderstood part of the whole agile process. Testing is not another activity of agile but a way of coding that will minimize future casualties. People often think that their code is right. That is the biggest mistake one can do. We should always think our code is "Guilty until proven Innocent". Frequent testing and verification not only boost your confidence in the product but also helps you debug and ultimately make your development process more efficient. In my next blog I will elaborate more on TDD.
Snipers?
As much as changes are to be expected, one should know that not every team will work accordingly especially when things doesn't work out as planned. If your truly agile these situations will be in your daily routine so it is not something new to you. Having the whole team together, meeting and deciding on the future releases frequently by not just the development team but also bringing the business minds as well. Things may get ugly in the project but everyone is at stake since its a team effort rather than just a Sniper mission assigned to a new recruit.
