Turning Agile is more of a mindset than a ruleset. The learning curve is not steep on a technical level, but it requires enthusiasm, dedication, and commitment from all your team members. You see, I believe in Agile as a people management, project management, software lifecycle framework. In that order. This explains why I prefer saying Agile, rather than Agile Software Development.
The Agile manifesto is a set of 4 values and 12 principles, serving as a canvas for many methodologies. That is not to say that rapid, iterative lifecycles did not exist before the manifesto, quite the contrary — the latter was authored in 2001, or five years after the creation of Extreme Programming, to name just one methodology. But overall, the statements in the manifesto reflect an underlying approach to management and development which all Agile methodologies share. Let’s take a closer look.
The 4 values of the Agile manifesto
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
Agile does not claim that the values on the right are useless. Rather, it states a preference for the values on the left. Moreover, other than value #2 specifically mentioning software, these values can be applied to management, team building, etc.
The 12 principles behind the Agile manifesto
What follows are the 12 principles as stated by the manifesto’s authors. I am citing these here for the sake of readability and comfort.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity, the art of maximizing the amount of work not done, is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
As you can see, no rocket science here. Simply a desire for open communication, and flexibility to change. Now, as stated earlier, the manifesto and its principles is only a common canvas. A great canvas, but a starting point nonetheless. Its tenets are applied by your choice of methodology, each enforcing, emphasizing, or even discarding principles to further shape your mindset.
To embrace agility, start by following a given methodology. Given that all share the same values and principles, your choice is simply a question of preference. To help you in your decision, though, here are the three methodologies I favor.
- Lean: with its origins in the manufacturing world (Toyota), this very interesting methodology is intent on streamlining the workflow (planning, requirements, bureaucracy) by eliminating everything deemed as waste, of which there are many sources! Workflow and mindset on a diet.
- Scrum: popular methodology used in areas such as product development, software development, and maintenance operations. Scrum focuses on adaptive planning, team building, and ample verbal communication.
- Extreme Programming: strong emphasis on technical aspects, peer-to-peer education and collaboration, aiming for and often resulting in technical excellence. Some of its key elements are pair programming, strict coding standards, extensive testing, and refactoring. For the record, this is the first methodology I practised, back in 2001.
Choose a methodology, then practice, practice extensively. Over time, you will understand what works for you, what differs from your way of working and the methodology’s approach. It will be a good time to learn more about other methodologies, through books or peer discussion. Perhaps you will change methodology, or stick with your choice and start bending the rules. This will be a really exciting moment, pursuing your reflection of Agile through constant fine-tuning.
You may wonder how we do it at graphility… I shall present our approach on my next post.