Agile Methodologies

A bit of history

The use of the word agile derives from the agile manifesto. A small group of people got together in 2001 to discuss their feelings that the traditional approach to managing software development projects was failing far too often. They came up with the agile manifesto, which describes 4 important values that are as relevant today as they were then. It says, we value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Ever since then, the use of methods that support these values has become increasingly popular.

What is Agile ?

Agile development is a different way of managing IT development teams and projects. Agile practices helps teams to respond to unpredictability through small incremental continous development. The team stops and re-evaluates the direction of a project usually every two weeks, so there’s always time to steer it in another direction.

shared

Why use Agile ?

Software development is probably one of the fastest changing work environments, what is good for today might not be good for tomorrow, so having the ability to quicky adapt to those changes is a key factor in the success of a software product. Agile tends to focus on incremental continuous delivery by repetition of abbreviated work cycles that will allow the team to easily and quickly adapt to new requirements or changes. The results of this approach helps greatly reduce both development costs and time to market.

Agile principles

Agile is base on 12 principles and good practices that fit teams that works in a continuous fast changing environment, those principles are:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Having software delivery frequently, increases the ability to adapt to new requirements faster and make the team more competitive agains fast evolving environments.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale, the shorter the better. This increase productivity and avoid having a product on the shelf for ages.
Business people and developers must work together daily throughout the project. Having continuous feedback and collaboration between the different members of the team creates and atmosphere of knowledge shared that flows through the team and benefit the product.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. This is a psychological aspect of agile that build trust between the team and the client.
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. An important aspect of this is regular releases of a product. If a team can deliver a shippable product each quarter, for example, it makes conversations with the customer much easier.
Continuous attention to technical excellence and good design enhances agility. Code refactoring and the push of good practices benefit the team in the long term.
Agile is all about doing the right amount of something at any given time, and no more. We should build what we know we need now, software development projects evolve extremely fast so what’s coming tomorrow is more likely to be different to what we think it will be, so it doesn’t make any sense thinking about the future as it is uncertain.
The best architectures, requirements, and designs emerge from self-organizing teams. The team knows the best way to get something done. However, this does not mean the right outcome will happen on its own. Having feedback from other team or members that don’t belong to the team will always be beneficial for the product and increase the knowledge of the team.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Team retrospectives is the best feedback to improve the way we work today and avoid making the same mistakes over and over again.

Metholodogies

The term word agile is just an umbrella under which a few different methodologies sit.

shared

There are various methodologies that promote the values of the agile manifesto and they are consistent with the above principles. The most popular ones are:

Dynamic Systems Development Method (DSDM) is probably the original agile development method. DSDM was around before the term ‘agile’ was even invented, but is absolutely based on all the principles we’ve come to know as agile.
DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM focus on the useful 80% of the system that can be deployed in 20% of the time. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritized using MoSCoW Rules( Must have requirements, Should have if at all possible, Could have but not critical, Won ‘t have this time, but potentially later).
The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative methodologies such as Extreme Programming and the Rational Unified Process.
DSDM is probably the most complete agile methodology, whereas Scrum and XP are easier to implement and complementary because they tackle different aspects of software development projects and are both founded on very similar concepts.
Scrum’s early advocates were inspired by empirical inspect and adapt feedback loops to cope with complexity and risk. Scrum emphasizes decision making from real-world results rather than speculation. Time is divided into short work cadences, known as sprints, typically one or two weeks in length. The product is kept in a potentially shippable (properly integrated and tested) state at all times. At the end of each sprint, stakeholders and team members meet to see a demonstrated potentially shippable product increment and plan its next steps. Scrum methodology has been proven to scale to multiple teams across very large organizations with 800+ people.
XP (Extreme Programming), originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. The “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks. Extreme Programming emphasizes teamwork. It improves a software project in five essential ways: communication, simplicity, feedback, respect, and courage and supports the use of several practices(Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor, Sustainable Pace).
Lean Software Development focuses the team on delivering Value to the customer, and the efficiency of the “Value Stream,” the mechanisms that deliver that Value. The main principles of Lean methodology include eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team and seeing the whole. Lean methodology eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.
Kanban is NOT an Agile tool or framework —in fact it’s not even derived from software development practices. Instead, Kanban came out of lean manufacturing techniques made famous by Japanese automakers who used it to manage their workloads. Since the concept has expanded outside that industry, Kanban has become a popular workflow method software teams and businesses employ to work through projects of any size. A kanban team is only focused on the work that’s actively in progress. Once the team completes a work item, they pluck the next work item off the top of the backlog. The product owner is free to re-prioritize work in the backlog without disrupting the team, because any changes outside the current work items don’t impact the team. As long as the product owner keeps the most important work items on top of the backlog, the development team is assured they are delivering maximum value back to the business. So there’s no need for the fixed-length iterations you find in Scrum. Kanban focus on continuous delivery, this is the practice of releasing work to customers frequently–even daily or hourly. The faster a team can deliver innovation to market, the more competitive their product will be in the marketplace. Like Scrum, Kanban is a process designed to help teams work together more effectively and is based on 3 basic principles:

Visualize what you do today (workflow): seeing all the items in context of each other can be very informative
Limit the amount of work in progress (WIP): this helps teams not to commit to too much work at once
Enhance flow: when something is finished, the next highest thing from the backlog is pulled into play

Conclusion

When applying agile practices there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and abandon the effort entirely. Agile is arguably the most appropriate practice for fast evolving environments. This is one of the main reasons why you should be using agile if you work in the IT industry. Not every team has to adopt the same agile practices, in fact a good agile team picks and chooses the management and technical practices that best work for them. Teams are made of individuals, and what works with some, doesn’t necessarily means that will work with others. Agile is a continuous process and if something is not working, the team should sit together and think about what is going wrong or what could be improved and make a decision to change or adapt whatever is not going on the right direction. Only through continuous improvement and feedback can the team achieve the highest success, and remember the most important thing in an agile environment are individuals, never the tools. Chose the right team, encourage them to use good agile practices, give them freedom and trust and you can be sure and confident that they will bring success.

References

Agile software development methodologies and how to apply them

The Agile Manifesto Principles

Kanban Fundamentals

A brief introduction to kanban

Agile Software Development, Principles, Patterns, and Practices (Robert C. Martin)