With the invention of the IBM microcomputer in the 1980’s it was only a matter of time before computers would become the main method for doing business and communication in the world. Previously, dumb computer terminals were used to access central mainframe computers to enter processes via punch cards. Before the invention of the microprocessor in the early 1970s, computers were large costly systems owned by large corporations, universities and governments. The classic end users that exist today did not directly interact with computers.

The software wars began in the mid 1990’s, I refer to it as a war because more and more software vendors came into being and thus competition grew. The internet and software technologies began to advance at an exponential rate of growth. The war to win the hearts and minds of the consumer and business world had begun. Rapid industry growth coupled with investor greed created an unsustainable situation ultimately leading to the popping of the internet bubble in the early 2000’s.

At the end of the previous century towards the beginning of the 1990’s software was becoming more and more prevalent in enterprise companies as the main way of managing business. 

In a Nutshell

The main problem was that it was taking too long to design, build and develop software solutions and deliver them to their target customers (big business). This phenomenon was referred to as “application delivery lag”. The average time to market for a software solution from the design and inception stage to delivery was averaged to be around three years. The problem with this time lag was that businesses were moving forward with their ever-expanding system requirements and new ways of doing business too quickly. Their requirements were growing much faster than the software industry could handle. In addition, these changes in the business and consumer markets were occurring faster and faster as time progressed.

The businesses themselves were also morphing, growing and changing. This meant that during the production process the pre-designed software solution was already irrelevant, out-of-date and often ended up being cancelled. It also meant that the software solutions were incapable of meeting their stated business objectives. In certain cases, the lag was even greater than three years, in the defense industry for example, it could take decades before a system was up and running and finally deployed. For the automotive, telecommunication and aircraft industries software was at best an afterthought. This is because software design heavily relied upon the hardware design to be finished first.

The Boiling Point

By the year 2000 the software industry executives had run out of excuses and the software industry had reached a high level of frustration and finally a boiling point. In addition, investors started to lose confidence in the ability of the software industry to produce the goods as they had promised and the software developers and thought leaders needed to find a solution, fast.

The Pioneers

So on a dark winters night at a lodge at the Snowbird ski resort deep in the mountains of Utah, a bunch of software pioneer dudes who shared similar understandings of the problem, got together for the first time and attempted to solve this problem. After a series of meetings, buttered rum and skiing adventures the group of seventeen development leaders came up with a plan to solve the inherent limitations of the waterfall methodology. They began to devise a lightweight methodology for quickly building software solutions.

This software production approach was aimed at rapidly building a working piece of software and exposing it to the customers as quickly as possible. Then, receive customer feedback on the software version and implement it into the growing product fast before architectural limitations could be set into the product.

This methodology became known as the “Agile Manifesto”.

The Agile Manifesto

The Manifesto is based on the following twelve principles:

1. Customer Satisfaction – by providing early and continuous delivery of a valuable software offering.
2. Welcome Change – alter and expand the product requirements, even in late stage development.
3. Working Software – Make sure that the application works at very stage of development and endure that it is delivered frequently (weeks rather than months)
4. Synchronicity – Employ close and daily cooperation between the product and development team.
5. Team Motivation – Projects are built around motivated individuals, who should be trusted, there is nothing more important than the human capital you have invested in the project. Changing team members mid project can sometime cost you the project itself.
6. Interaction – Face-to-face conversation is the best form of communication.
7. Measure of Success – Working software is the primary measure of progress.
8. Sustainable Development – ensure that you are able to maintain a constant pace.
9. Attention to Detail – Continuous attention to technical excellence and good design.
10. Simplicity – the art of maximizing the amount of work not done is essential, maintain the shortest path between two points.
11. Radical Self Reliance – The best architectures, requirements, and designs emerge from self-organizing teams and power players.
12. Regular Tune Ups – Make sure that the team reflects on how to become more effective, and tweak and adjust accordingly.

How Does It All Connect

The Agile development methodology provides all involved parties the ability to assess the advancement of a project throughout the development lifecycle. This is achieved through regular work segments, known as sprints. At the end of each sprint, the development teams must present a product demo increment.

By focusing on sprint work cycles and the functionality they produce, the agile incremental approach highlights issues that arise throughout the development process without having to wait until the end release to see if the initial direction was correct.

The day to day software development work load is managed according to the following task breakup and hierarchy.

The Scrum

The Scrum is the most popular way of introducing the agile methodology because of its simplicity and flexibility. The Scrum emphasizes developer feedback, team self-management, and strives to build properly tested product increments within short sprint iterations. The Scrum has four main roles, the product owner, the release manager, the dev. team, and the scrum master.

Product Owner

The product owner builds the product backlog which is comprised of three main types the themes, features, user stories and the backlog items. These three collections represent the backlog of the products structure. 

The product owner then prioritizes the user stories according to the customer and market requirements. A good ticketing system enables the product owner to perform the prioritization of tasks by simply adding new items to the backlog. Once the backlog is created the task items can be reprioritized by numbering them into a ranked position list.

Release Manager

The release managers’ main roles include managing the release timeline and deliveries, building the dev. team required for the user story implementation, measure and track the execution of the release user stories.

Development Team

The Dev. team is tasked with implementing the user stories while adhering to the predefined standards of functionality, quality, unit testing and on time delivery. A good ticketing system simplifies this process by empowering the developer with a central location where all the user story requirements are located, they include Dev. Tasks, acceptance tests, relevant attachments, stakeholders, code coverage and unit tests.

Scrum Master

The Scrum Masters role is to ensure that the Dev. team performs their respective tasks according to the logical task breakdown. This breakdown is performed together with relevant developer for each task. The scrum master is not necessarily the team or R&D manager but, rather a persona who knows how to move through daily items quickly and efficiently.

In addition, the scrum master ensures that the developers perform their task according to the backlog rank and that the advancement is tracked in a ticketing system. This ticketing system enables the scrum master to easily track, update and manage the teams’ workload and user story content within the ticketing system.

In Conclusion

The Agile methodology is best suited for ever changing customer target environments and because of new practices that arise throughout the development process. This flexibility enables a devolvement team to build a product in very short period of time.

Being agile is based on the concept of iterative software application development. A simple working software application should be built after the completion of an iteration. An iteration should not take more than a couple of weeks to complete the code.

The agile methodology requires the developers to get involved in the testing process, rather than relying on a separate QA team exclusively.

Working according to the Agile methodology should result in the reduction of bureaucratic management overhead and remove formalities from your development team. K.I.S.S is the answer.

Agility is everywhere. Ignore it and you will be lost in the current technical dialogue. Learn about it and you will be able to make intelligent decisions about whether it is right for you. You will also be able to understand many of the other practices and methodologies that are emerging. If you are a manager of technology at any level, this is your responsibility as well as a survival necessity.

“The measure of intelligence is the ability to change.” ― Albert Einstein