How to climb a mountain?
One step at a time.
Agile is a process by which a team can manage a project by breaking it up into several stages and involving constant collaboration with stakeholders and continuous improvement and iteration at every stage.
It’s a network of empowered team working in rapid learning and decision making cycles using a mix of stable and dynamic practices to reduce risk and create flexibility. Agile says, let’s break things into small little increments and make sure we deliver value each time.
Today, agile project management methodology is used by software developers, construction companies, educational organizations, and even marketing teams.
So, coming to what Agile really means:
- Agile is a customer-oriented approach focused on optimum customer satisfaction.
- Agile is iterative, which means it is done in pieces called sprints.
- Agile is about effective communication between developers and clients.
Agile principles bridge the gap between the Agile Manifesto and Agile practices. You’ll be able to better understand and adapt the practices to your environment without compromising on what makes them so effective.
Let’s go through the principles one by one:
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
One of my favorite sayings is “Waste is anything the customer doesn't want and isn't willing to pay for”. Planning is essential. Agile events are useful. Technical spikes who explore new technologies can give us architectural runway and new competitive advantages but at the end of the day customers pays for working software and services not the effort that got us there. As a project manager using an agile methodology, you need to make sure that you deliver a solution that solves user’s problems.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
Agile embraces empiricism. It's almost a guarantee that we will be more knowledgeable once we have commenced work in a project than at the beginning. Our customers will learn more about their own needs when they see an increment of our work. Let's not forget that our competition isn't standing still either, so inevitably you will learn something during the development cycle that clearly demonstrates that the current plan is not wise, possible or both. Welcoming changing requirements means that we are being empirical and data-driven. this isn't to say that we should get in the habit of constantly interrupting work in process as long as whatever is being worked on now is still valuable. Try to give your team the time they need to finish what they started before you introduce to change.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
This principle frequently draws controversy. For a start-up every two weeks seems like an eternity whereas a giant lumbering publicly traded corporation can take two months just to get code through the bureaucratic approval deployment process. The more frequently you deliver software the smaller and less risk in your releases and the more likely you are to have good automation the more frequently you deliver software the more chances you have to get and incorporate feedback from your customers in real world use of your product.
4. Business people and developers must work together daily throughout the project
This principle also draws controversy particularly from developers who have had to deal with micromanagement or harassment from project managers and other stakeholders. At the very minimum I suggest that the product owner who acts as a proxy for business people and customers to the team work with the team daily to clarify requirements, accept work and help remove impediments. It's also effectively to have business people attend sprint review and remain available and accountable to their teams.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done
Three things that motivate us the most are autonomy, mastery and purpose, not financial rewards. In agile project management, teams are self-reliant and self-directed. More importantly, there is no micromanagement. The important part here is that you should hire the right people to work for you and provide them with everything they need to accomplish project goals before the deadline and inside the budget. Project managers must trust their team to deliver results.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
I think this principle covers a few things First don't let written documentation requirements get in the way of talking to one another. Obtain direct feedback by going to the source of problem or confusion and use oral communication at the workplace for the benefit of osmotic communication. Virtual team conversations are facilitated via video conferencing.
7. Working software is the primary measure of progress
The most important measure for business should be working software.For agile project teams, there is nothing more important than a working prototype. Irrespective of how many bugs you have fixed or how many hours you have put in the development of a product, the only thing that counts is a working product. If it is not working properly, then all the factors become irrelevant.
8. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely
Developing software should feel more like running a long marathon than back-to-back sprints. Excessive effort can rapidly exhaust teams burnout employees and even impact relationships at home. The important reason of team so hurry in adopting agile is to have sustainability and scalability in their product, as it just cut through the waste. Making everyone to work with constant pace continuously, meaning with in with fixed set of scope to achieve it, collectively as a team of sponsors, developer and manager.
9. Continuous attention to technical excellence and good design enhances agility
An absence of good code management, integration testing and deployment rapidly compromises a team's performance. Poor design decisions can paint a team into a corner and failing to address bugs. To gain agility, we should give more emphasis on design and technical excellence as nothing else really matters.
10. Simplicity - the art of maximising the amount of work not done - is essential
More features or poor architectural decisions make a software more complex. Highly complex code is harder to test, maintain and develop. Many products have features that are so rarely used that the development and maintenance likely result a negative return on investment. In general, it's better to have a targeted product that does a few things extraordinarily well being everything to someone or other than one that attempts to cash in the entire market or pleases no one.
11. The best architectures, requirements and designs emerge from self organising teams
As mentioned above, agile teams are self-directed. You will not have to tell them what they have to do. Instead, they will find a way themselves and remove any hurdle that comes in the way. The project manager will only interfere when there are some warning signs or situation gets out of hand. In normal circumstances, everything goes smoothly and all credit goes to well-organized teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly
Apply the improvement process activities like the retrospective and other activities more often. Self-organise team tune to itself and do a sanity check regularly. In today’s dynamic agile project environments, it is important that we keep on looking for flaws and improve. More importantly, adapting to a certain situation is crucial for success. Project managers who are still using older methodologies will struggle in today’s rapidly evolving project environments. They will have to keep pace with emerging trends and adjust according to the situation in order to achieve project goals.
Are these principles still relevant?
You may notice that all the agile principles are still relevant today. That’s because they’re based on economic reality and human nature, two things that don’t really change that much. If anything, some principles have become more radical than they were intended to be. For example, we should deploy weekly or even daily and we can now automate more than we imagined in 2001. On the other hand, some principles have been given a different meaning than we imagined in 2001: individuals no longer need to be in the same room for effective communication for example.
Jagmeet leads the technology development at BOD. He is a Computer Science graduate, who is passionate about creating products with great user experiences. To achieve this, he is constantly honing his skills in user journey mapping, wireframing and development. He has an experience of over 5 years working in the digital & technology space. Jagmeet likes to keep up with the latest trends in technology and enjoys trying new things. He says, ‘Since new tools and practices are coming out everyday in the field of development, it’s always exciting to keep on learning new things.’