Why Agile?
Let’s look at the historical perspective to understand the need.
Manufacturing Project Management Mindset
Project management got a strong foothold in the organizations that were involved with manufacturing. With manufacturing, most of their requirements revolved around delivering complex projects, with huge investments, and thousands of workers involved. To structure it well and to avoid failure, managers devised a waterfall technique for managing projects.
With waterfall, most of the projects would be divided into different phases, starting from Planning, Requirement Gathering, Development, Testing, and then Handoff. Each phase output was handed off to the next phase, resulting in a sequential set of activities, resembling an assembly line.
This worked well for that particular industries. So the digital organization, involved with software development, opted for those traditional waterfall methodologies. But, then they started to run into issues working with using such practices.
Many software development companies found that adopting waterfall or similar practices resulted in failures, massive overspent on projects, and missed deadlines.
Organizational Structures
In addition, the traditional organizations were built using a hierarchical mechanism. With the command and control approach, the knowledge flows top to down and the skill set of the workers is assumed to progress as they move from the bottom to the top.
With software development organizations, this might not be the case. Here the hierarchies might not add any efficiency to the output. Also, most of the workers are expert and knowledgeable, so the top-down, command and control, type of management, wasn’t the solution.
Agile Manifesto
With this background and faced with many failures, few software developers sat together to fix the issue. They came with the Agile manifesto which is composed of 4 core values. These core values were used to build 12 principles to start coming up with concrete frameworks to add agility to software development.
Let’s look at those values and principles.
4 Values
Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan
12 Principles
Customer satisfaction by early and continuous delivery of valuable software.
Welcome changing requirements, even in late development.
Deliver working software frequently (weeks rather than months)
Close, daily cooperation between business people and developers
Projects are built around motivated individuals, who should be trusted
Face-to-face conversation is the best form of communication (co-location)
Working software is the primary measure of progress
Sustainable development, able to maintain a constant pace
Continuous attention to technical excellence and good design
Simplicity — the art of maximizing the amount of work not done — is essential
Best architectures, requirements, and designs emerge from self-organizing teams
Regularly, the team reflects on how to become more effective, and adjusts accordingly
The above manifesto with its values and principles brought about a revolution in the software development world. Many organizations started seeing benefits immediately and now agile practices have become a defacto for software development.
Benefits
Let’s look at some of the major benefits that this methodology brought to software development.
Focus with Small Iterations
Agile Principle 3 talks about delivering the software frequently within weeks and not in months. This meant that with Agile planning and development is done in an iterative way and with each iteration you are coming up with working software.
In the case of Scrum (An Agile Framework), usually, software is developed in 2 weeks of short time periods, called Sprints.
One of the biggest utility that comes out of this methodology is the ability for the team to focus. This results in killing a culture where people are multitasking. This also helps in avoiding distraction that was the case with the traditional way of building software – where the deadlines were far-off and no immediate need to produce working software.
Such small iteration forces the team to deliver a working and valuable piece within a short time period. This also enables the teams to get customers involved early in the process for collaboration and feedback too. Since the output is incremental, bad end-user feedback can be acted out early and efficiently.
Predictable Output
As stated, Agile asserts that your entire development effort to be focused on delivering working software in small chunks. Also to improve the quality of each iteration, you need to build autonomous cross-functional teams to plan, test, code, analysis and so on. All this results in coming up with a system where you can predict the output of each development cycle.
The scrum framework will call this output, velocity.
Once such development cycles are run for a few times, you get a good idea of the team capability to develop. Knowing this velocity results in a system that outputs a predictable chunk of an incremental software product at the end of each cycle.
3- Communication
Agile Principle 1 states the importance of delivering continuous and early delivery of valuable software. For this to happen you need a system where there are minimum handoffs and communication flow is fluid.
Organizations, especially the software development ones, have a horrible experience with handoffs. Such handoffs make team, work in silos and seeds blame game, without proper ownership.
So to eliminate all the communication hurdles and handoffs, cross-functional teams need to work together for development. This results in a reduction in all kinds of overheads that could reduce the quality and velocity of output.
4- Value Delivery
Most of the agile teamwork with user stories.
User Stories help Agile team to communicate and stay focused on delivering value. Usually, each feature is written from the perspective of a user, using the product, while clearly stating the value its adding.
User Stories should not look like a traditional requirement document, where all the features are listed. As with requirements, you are trying to limit any adoption or agility. It limits the conversation and focuses on rigid outputs.
Also with user stories, you are making team to ask the right questions. And all those questions and conversations are dedicated to adding value to your customers.
How to Start the Process: Scrum Basics
So there are many frameworks that came from Agile Manifesto.
Scrum, Kanban, XP are amongst the most popular.
But of all those, Scrum has been the most popular in terms of adoption. As many teams have utilized Scrum for delivery predictable and valuable products.
Scrum Basics
As already discussed, all the phases of planning, analysis, designing, coding, testing, deploying, are squeezed into shorter time frames. In the case of Scrum, it’s called Sprints. Usually 2 weeks long.
Scrum will have many internal meetings and reviews. You start off with Sprint Planning Meeting. The focus of such meeting is the short term planning. It should include all or most of the team members or stakeholders.
Then you have daily meetings for a 15–20 min review. This is where developers would coordinate and organize their work.
At the end of the sprint, you have Sprint Reviews. Most of the time is dedicated to the team retrospective. This is where the interactions and issues are discussed to make it better for the next sprint. Usually, such a session would last for 2 hours and at times will include customer to share their feedback.
There are few roles that enable or facilitate this process.
Usually, you need to have a Scrum Master. He/she is someone who can coach the team, encourage them for collaboration, and communication.
Since the Agile teams are self-managed and self-organized, the scrum master should not take the role of a master and try dictating process step-by-step. Instead, he/she should act as a coach and mentor for the team.
Then you have Product Owner. This person works with the team and owns the product. He has the authority to make real-time decisions. So, whenever there is an issue or a question, the team will ask the Product Owner and he/she should be able to answer there and then, instead of running to the customer or management.
Now, the Product Owner will be working with a set of features that are a part of the product backlog. A product backlog is the ranked list of features that you need to build.
This backlog comes from a bigger product vision, usually, a product road-map that envisions all the entire product.
Summing Up:
Remember Agile Development is a mindset. So, you need to get people and culture right before processes and tools can be adopted.
In my opinion, working with Pareto 80–20 rule, will help you while working with Agile development practices. As most of us know, that 20% of the work can delivery 80% of the value. So, agile teams have the potential ability to focus on that particular 20% that delivers the 80% value.
To talk to us for your app development requirements, please visit us at,