Agile is defined (according to the Agile Alliance) as “The ability to create and respond to change in order to succeed in an uncertain and turbulent environment.”
Agile is separated from all other approaches to software development because of its focus on the people doing the work and how they work together. Solutions evolve quicker and with quality, through collaboration between cross-functional teams. This is important as building software can be inherently unpredictable. Creating software is a unique (bespoke) process and should not be confused as commodity skilled work. Methods that allow quick feedback, quality testing, integration and impact to peripheral applications are all areas included in Agile methodologies.
First, a bit of history
Prior to Agile, product development was completed using Waterfall or V-model methodology. Using this method to create stable software was not efficient to say the least. Missed deadlines, scope creep, frequently blowing budgets and failing completely were becoming common outcomes. Knowing this solution was not working, in the 1990s, a revolutionary new methodology was presented, offering much more than it could resolve, Agile had taken its first steps in managing software development.
By no means was Agile going to be the panacea needed to completely resolve all problems with development; but it addressed critical issues and did provide a proven framework to provide a more consistent success rate than prior model methodologies.
All Agile methodologies share common core ideas. Each Agile method subtly uses these in their own way, be it iterative and incremental delivery of code, collaboration frequency with stakeholders, working closely, self-organizing teams and most importantly, its ability to embrace change late in the project. These varying Agile methods share many components and it can become quite eye opening at the amount of interbred use of each other’s techniques and styles.
The benefit of this interoperable Agile design of varying methodologies is that it becomes very easy to use Agile methods given the compatibility of concepts. Think of it like an Agile smorgasbord or a market where you can pick and choose parts at will.
There is an Agile Manifesto which provides a set of guidelines for those interested in becoming Agile. It is not though, a set of rules, nor does it define any processes specifically. That said, the manifesto has given a broad definition of what constitutes an Agile methodology.
Let’s examine a few Agile methodologies available today:
We list Scrum first as it remains the most popular Agile methodology in play. It has become the ‘go-to’ technique for mastering Agile. Part of its success rests on the amount of documentation and pre-built processes for teams available.
Scrum can seem foreign to inexperienced teams. Its greatest success doubles as its greatest weakness. It works well with trained teams who can work with tight deadlines, daily meetings and focus on high release-quality targets with each product iteration (sprints).
The prominent roles in Scrum include the ScrumMaster, the Product Owner and the team member.
o The Super team leader (not a team member though)
o Keeps the team focused on the goals of each iteration
o Ensures all Agile principles are followed
o Keeps backlog up to date (with Product Owner) and resolves issues putting the schedule at risk
· Product Owner
o Prioritizes the requirements
o Makes changes from prioritizing, based on feedback from stakeholders
o Product owners do not choose which requirements go into a sprint. It is based on demand and amount of work to be completed in a given sprint with the backlog in mind.
· Team members
o This group designs, code test and produce the product.
o Sprint goals require the team to be cross-functional to be able to respond to various needs at any given time.
o The team members as a whole are solely responsible to meet all goals.
Scrum defines its specific areas very well in its documentation. Any areas that lack clarity are usually supported by pulling processes from other concepts.
Extreme Programming (XP)
The thought behind this one was to take the best use of programming practices and take them to the ‘extreme’. While none of the individual concepts of XP are new, their application and combination are what makes XP ideally unique. It achieved its peak popularity in the 2000s.
XPs main concept is one of adaptability; recognizing that every project will face challenges and applying methods to resolve the challenge for one may not work for others. The concept allows to choose which to keep moving forward while discarding others. It is not uncommon to see partial XP in play on a project that is mainly running under a Scrum methodology.
Similar to Scrum, XP also embraces standards such as short iteration periods. They move on to almost immediate and regular testing, close on-site stakeholder involvement with immediate feedback and team members having responsibility for success or failure.
Testing is taken to the extreme with as many techniques as necessary and as often as possible. If practical, daily integration testing is greatly advocated. If not, then it will be weekly at minimum. This is where XPs ability to adapt shows its use.
Thinking that two heads are better than one, pair programming is a part of XP. One person codes while the other observes, giving feedback, spotting potential hurdles while keeping the big picture in mind. It is a good technique provided the pairs interchange with relative frequency to avoid pairs becoming too comfortable with each other and in effect turning two heads back into one.
This one is unique in that it is Agile without being iterative. Kanban looks at the big picture in that software is developed in one large development cycle. It seems contradictory as an Agile solution, but Kanban does meet all twelve of the Agile Manifesto principles as it is seen as more incremental than iterative.
The principle of Kanban’s incremental process to meet Agiles iterative similarity is via Kanbans limited throughput. Kanbans projects have no defined start and stop end points for individual work items. Each start and stop independently with no work duration included. The focus here is on each phase of the lifecycle as having a limited capacity for work at any one time. By controlling the number of tasks active at any one time, developers see the project as incremental as a work team cannot move forward until some capacity opens up ahead.
There are more
Each critical in their own, the following are used outside the main three Agile methodologies discussed above.
· Puts quality and scheduling first
· Uses MoSCoW as its method of prioritization
o Must have
o Should have
o Could have
o Won’t have this time around
· Addresses limitations of Scrum by including pre and post development phases making this a true project management process.
Disciplined Agile Delivery (DAD)
DAD expands its framework to include areas beyond software to the entire product process.
· Uses self-organizing, cross functional teams. (a.k.a. generalized specialists)
· Promotes an environment to include learning user needs, how to improve processes and growth in technical knowledge.
· Adherence to the Agile Manifesto
· Use of complementary Agile methodologies that may adapt to the current project (Scrum, XP, Kanban)
Agile Unified Process (AUP)
· Project management is a major discipline in this process.
· More ‘up-front’ loaded – requires considerable modeling before implementation begins.
Feature Driven Development (FDD)
· This one remains debatable if it is actually an Agile process.
· FDD is implemented iteratively, not according to business needs decided by the Product Owner. The needs are decided by the functional area instead.
Lean Software Development
· Less of a process and more of a set of principles to deliver by.
· Principles can be overlaid onto most major Agile methodologies.
· Identification and elimination of wasteful work adds value to the overall project timelines.
Agile is a mindset. Call it a commitment to the val