Agile - More Than A Framework; A Change in Mindset
Today almost every software company is developing software using an Agile Development framework. What does that mean? Is this yet another buzz word or is there anything in there that is a fundamental change to the development process?
Let me offer an analogy to explain agile. You want to take a long multi-day road trip from Boston to San Francisco. How would you plan for this trip? Some will sit down with a detailed map, plan driving distance for each day using average speed and hours of driving, plan and book every hotel they are going to stay in, make a reservation at every restaurant they are going to eat lunch or dinner, maybe even plan the gas stations they will stop at. All that planning before even driving a single mile. Others may take a totally different approach. Once they know the general direction to drive, they start driving. When they feel hungry they stop for lunch, and when they feel tired they stop for the night at the closest hotel. Every night, they review the progress made and make changes in direction for the next day. The critical thing here is to follow the general direction and refine the plan after every day. Following the general direction of the destination will get you there in due time. These two approaches are an analogous comparison between the waterfall development approach and the agile development approach.
By dictionary definition of the word “Agile” means “ability to think quickly” or “the ability to do something quickly and well-coordinated”. It follows that Agile development means developing quickly and in well-coordinated sprints. To a certain extent that is true; but it is a whole lot more.
My first software project was to build a registration and billing system for one of the largest electric utility in the West Coast of USA. We went through an analysis phase that took a few months, then through a design phase which was 2 years and only then started development that lasted the next 3 years. Long story short, the system was tested and deployed in over 6 years. It was a massive system. On completion, the first thing end-users said was “our business has transformed and hence we need to change the system”. This is the downfall of the waterfall development approach. Even product companies (like Microsoft) would build products in multiple years and release them for the end users –only to realize a change in business needs.
The Agile development framework teaches us to build software in short bursts of very limited scope. These small bursts are called sprints. Each sprint may or may not have enough functionality to deploy the product for limited use, but has enough to show to the end user the functionality that is being built. A few sprints together will make enough to add business value, even though it may not be everything the company needs. For example, Microsoft is releasing the next version of Windows in many small releases. Every few months you see an upgrade to Windows 10 may get deployed. These upgrades will eventually add up to the next Windows version.
There are many advantages of building in the agile development framework. A few are:
1. End user sees functionality at every sprint. The more functionality they see in operation, the easier it is to meet changing requirements before everything is already built and tested.
2. Developers have the satisfaction of seeing something being developed and released and maybe even used by the end users before they have completed the project.
3. Business gets the functionality and starts using something before everything is ready, therefore gaining a business advantage with quick and frequent releases.
The biggest change that Agile brings to the development approach is the change in mindset that everyone must go through. Every developer, every system designer, every end user, every tester and everyone else who gets involved with the system development needs to go through a mindset change.
Users of the system must understand that they are getting smaller pieces of functionality so they can check it before they get more. Often, I have seen end users get some functionality and end up complaining everything else the system cannot do. They think each sprint is the end of the development cycle since they are used to waterfall approach, which causes a lot of frustration. End users are also confused as to how many times they must do User Acceptance Testing (UAT) before they can finally accept the system. In the waterfall approach, they test once (with every functionality) and then accept or reject the system. An agile framework may take multiple UAT sessions (the total time of UAT may also be greater), but the end users gets some functionality each sprint to start using.
Developers and testers also need to understand that agile is not an easier way to develop systems. Building systems without a full blueprint takes a lot of planning and foresight or else the systems can go horribly wrong. A very strong scrum master is an absolute must who can make sure the development stays on track.
The agile framework is often presented as easier than waterfall development. Trust me when I say it is NOT. The Agile framework requires a lot more planning and a bigger shift in viewpoint for everyone. Without the change in mindset and the big picture planning, agile development is more prone to failure than the waterfall approach.