This blog, perhaps, repeats what we talked about in Agile Introduction For Dummies – Part I and Agile Introduction For Dummies – Part II, but it is essential to ensure that one understands the dynamics of Agile methodology clearly. So, here we go once again!
The past few years have seen software methodology adopting a new style and going agile! Well knownas Agile Methods, the style is adaptive; people oriented in nature and have stirred up a whole lot of interest. It is also seen as an antidote to bureaucracy or licence to hack. A reaction to engineering or plan driven methodologies, agile methods are an attempt at compromising between no process and too much process, providing just enough process to gain a reasonable pay-off. As well, Agile Methods tend to be:1. Adaptive rather than predictive. Engineering methods mean a planned detailed software process covering a long time span and a nature that resists change. Agile methods, however, welcome it, trying to be processes that adapt and thrive on change, even to the point of changing themselves.2. People-oriented rather than process-oriented. Engineering methods work at defining processes that will work for whoever uses them. Agile methods assert a process cannot match the skills of a development team, only playing a support role in development team work. Exploration of the differences in detail makes it easier to understand what adaptive or people-centred processes are about, their benefits, drawbacks, and usefulness if used by developer or software customer.
Design and construction, two fundamentally different activities show that difficult to predict design requires expensively creative people, while construction is easier to predict, and only once design is in place, can easier to predict construction begin.
In every project, developers can be heard complaining that the problem with the particular project is that requirements are always changing. Not surprising, as in building business software requirements, changes are the norm. The question is what is to be done as software development is a design activity that is hard to plan for and estimate the cost for, as basic materials change rapidly and much depends on which individual people are involved resulting in unpredictability.
Generally speaking, one cannot say predictability is not predictable. While, it is very desirable, however letting it go does not mean reverting to uncontrollable chaos. All one needs is a process that gives control over unpredictability, which easily explains what adaptability is all about.
So, what is the key to an unpredictable world? Is it iterative development or frequent production of the final system working version with a sub-set of the required features? While iterative development is short on functionality, it is otherwise faithful to the demands of the final system; hence these features should be fully integrated and carefully tested as the final delivery for best results. A far better process than traditional methods where before doing anything else, the entire process is documented, and as one knows documents can hide all sorts of flaws, as does untested code. However, sitting in front of a system and working with it, allows these flaws to become truly apparent, both in terms of bugs and misunderstood requirements. Agile, an iterative and incremental development process is adaptive in nature and can totally deal with changes in required features. This means fluid long term plans, as the only stable plans are short term plans made for single iterations. AS well, iterative development also gives a firm foundation to each iteration, which means later plans can be based around it. The key question is, how long should iteration be. Different Agile methods suggest different time frames, e.g. XP suggests iterations of one or two weeks, SCRUM suggests a month, Crystal stretches it further. However, the tendency is to make each iteration, as short as can be got away with, as this not only provides more frequent feedback, but allows you to know where you are more often.
An adaptive process requires adaptive customers, since it gives them much more control over software development processes. They, not only get to check progress made at every iteration, they can also alter the direction of software development, which often results in a much closer relationship with the software developers, a true business partnership. The customer benefits, as there are a number of advantages to using agile methods, such as, much more responsive software development and an usable, although minimal system that goes into production early on. As well, the customer can change system capabilities according to changes in business, and is also able to learn how the system is used in reality allowing for risk control, which is indeed, a key advantage of iterative development. Further, keeping iteration lengths small means variations can be seen in different ways.
Another attraction of agile methods is that they put people first, since adaptive process execution is not easy task and requires a very effective team of developers i.e. effective both in quality of the individuals, as well as, team blending. Adaptivity requires a strong team and it bodes well for agile method application to a project, since it is a well known fact that most good developers prefer an adaptive process.
A people oriented process, agile process acceptance requires commitment and active involvement of all the team, as these methods like Extreme Programming (XP) requires a lot of discipline to execute, with the less disciplined Crystal approach, far more suited to a wider audience. As well, developers are required to be able to make all technical decisions, with XP getting to the heart by stating that only developers are allowed to estimate how much time it will take to do the work. This shift in technical leadership requires developers and management to share responsibility and an equal place in project leadership. While, management still plays a role, it also recognizes the expertise of developers.
However, technical people cannot do the whole process themselves and require guidance in terms of what a business needs, which highlights another important adaptive processes aspect i.e. close contact with business expertise.
The term agile refers to a philosophy of software development which includes many specific approaches under its broad umbrella, approaches, such as, Extreme Programming, SCRUM, Lean Development, etc., each of them having their own particular approach and own ideas..
While, during the late 1990’s, Extreme Programming got the lion’s share of attention, in many ways it still does and it beings with five values (Communication, Feedback, Simplicity, Courage, and Respect). It further elaborates these into fourteen principles, and again into twenty-four practices, placing a strong emphasis on testing. While, all processes mention testing, not much emphasis is placed on it. However, XP believes testing is the foundation of development and has every programmer writing tests and production code, simultaneously, which are then integrated into a continuous integration and build process, yielding a highly stable platform for future development.
In the 1980’s and 1990’s, Scrum also developed as a highly iterative development methodology that concentrates on the management aspects of software development, dividing development into thirty day iterations (called ‘sprints’) and applying closer monitoring and control, by holding daily scrum meetings. It places much less emphasis on engineering practices, with many people combining its project management approach with extreme programming engineering practices.
The Crystal family of software development methods approaches tailored to different size teams approach. Despite varying, all crystal approaches share common features and have the following priorities:
Safety (in project outcome, efficiency, habitability.
Reflective Improvement, and
Lean movement pioneered at Toyota was an inspiration to many of early agilists, but one should be wary of the engineering separation between design and construction. However, there are still interesting ideas to be got from the lean direction.
SHOULD YOU GO AGILE?
Using an agile method is not for everyone. However, these methodologies are widely applicable their use should be seriously considered. The most common methodology of code and fix often results in chaos, showing that the discipline and lightweight agile approach found missing in heavyweight methods is the better method. Start by finding projects that agile methods can be tried on, and since methods are so fundamentally people-oriented, it is important to start with a team receptive to being agile. As well, you will also need to find someone experienced in agile methods, having learnt through making mistakes. And, then you may find out about the many advantages of going agile!