GuidesAgile, a Different Methodology

Agile, a Different Methodology

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction


In the past year, Agile development methodologies have
moved from the fringes to being considered a mainstream
method for software development. The Agile movement started
in the late 90’s with the advent of Extreme Programming
(XP), SCRUM, DSDM, Feature Driven Development and others.
The Agile manifesto created in February of 2001 contained
the core principles of Agile development. Why is this
important to us?


Agile is important, because in the end, it has helped to
bring business discipline to software development. Agile has
a lot in common with Lean methods, exemplified by the Toyota
Production System. Lean methods have begun appearing in
Agile teams, bringing even more business focus to software
development/IT teams.


Comparing Agile against what?


When discussing Agile, what are we comparing it against?
I am comparing Agile against strict Plan driven development
approaches. Often called waterfall, your company may not
have a specific name for it. But if the current process
involves making sure that all the requirements are nailed
down before the project is started, and changing those
requirements includes a request to walk on water before it
can be changed this is the process we are comparing Agile
against.


To get a sense of the high level view of Agile you can
read the manifesto at AgileManifesto.org.
The manifesto begins with four statements:




  • Individuals and interactions over process and tools

  • Working software over comprehensive documentation

  • Customer Collaboration over contract negotiation

  • Responding to change over following a plan



These statements may seem a little touchy, feely, so let
us put some meat on the bone, to understand how to implement
this in your shop.


For each of the statements in the Agile manifesto,
concrete practices from Agile methods are used. Each
statement is a section that will contain what practices are
used to achieve the intent.


Individuals and interactions over process and tools


This statement may indicate to you that Agile has no
process. In fact I have found this to be far from the truth.
Agile does not throw process out the door, rather Agile says
that Individuals and interactions trump the process and
tools.


This shows in the frequent planning and daily standup
meetings common to most Agile methods. In XP, Scrum, Lean
the daily standup meeting is a staple. At this meeting all
committed team members interact with each other via these
questions:




  1. What did I do yesterday?

  2. What am I working on today?

  3. What is blocking my work?



The daily standup should help communicate project
progress. In other words, what is communicated in the
standup (individuals AND interactions), may need to
supersede the project plan. It is during these meetings that
hurdles are uncovered. But usually they are discovered in
time to fix the problems quickly. If a technology is not
working as expected, or the business logic actually
conflicts with other logic, it is brought up in these
meetings, and after the meeting the action plan is
created.


Working software over comprehensive documentation


This phrase is best described by the practice of
delivering software on a regular, fairly quick schedule.
Normally in XP and Scrum, you work in iterations. The team
selects the length of the iteration at the beginning of the
project, and generally stays with that length for the
duration of the project. Within an iteration, the team
selects the stories or features they will complete. Once in
that iteration, the stories that are being worked on cannot
be changed. Any changes can be introduced at the beginning
of the next iteration.


Normally, at the end of the iteration, there is a demo
and planning meeting. In this meeting, your team demos the
solution including the new features/stories to the
stakeholders/customer. The intent is that if the customer
likes this, the team could release that version of the
software immediately. In practice this can mean that the
team releases the software to QA or User Acceptance state
where customers can test/use the new features. Other teams
may release to production (think of all the google beta
software you have used).


One note on iterations, the length is generally
considered to be 1 week to 1 month. This is up to the team.
Again, this decision should be made as a self determining
team, it should not come from management.


Many Lean/Kanban teams do not use iterations, but they do
frequent releases. The releases happen on a similar schedule
as iterations. This allows the Lean/Kanban teams to release
working software frequently.


The reason for valuing working software over detailed and
comprehensive documentation is that the value delivered is
the software. Documentation of your system should be baked
into the process of delivering software. Agile does this, by
encouraging good software engineering principles like Test
Driven Development using automated unit tests and automated
user acceptance tests.


Test Driven Development using unit tests, and acceptance
tests, encourage test writing that serve as documentation. A
well written unit or acceptance test should document the
requirement the developer is testing for. When any
maintenance is needed, different developers should be able
to look at these unit tests and understand the requirements
needed.


In addition, this suite of tests add a fantastic safety
net for modifications later in the life of the software. If
the software sits for a year before modifications, the new
team can start development on new features, knowing that
those tests ensure that they cannot break existing
features.





Click here for larger image

Figure 1: Example of what unit testing frameworks look like

Customer Collaboration over Contract Negotiation


In many plan driven environments, the customer sits down with analysts, and they put together a comprehensive document with their requirements. This document is handed over to a vendor or internal IT group, and an estimate is expected. The vendor/IT group can ask questions about the requirements, and once answered, they come back with an estimate.


At this point the customer is done, except for occasional contacts for milestones. Then when the agreed upon time frame is complete, the vendor/IT team delivers the software. For many, this is the first time the customer team has seen the software. In this scenario, many times, the customer asks to add features, or feels that what they wanted was not delivered.


When Agile methodologists talk about customer collaboration over contract negotiation, there is an expectation of close customer involvement. This means in the planning meetings held after every iteration, stakeholders are present. This also means that the customer is expected to assist team members in verifying requirements. So they may need to participate in creation of automated acceptance tests.


These acceptance tests, using tools like fitnesse, selenium, rSpec, define the tests using an agreed upon format. The tests are written in a business like language to call and test the software components that implement the business logic.


In other words, the Customer Collaboration over Contract Negotiation does mean that the customer is more involved with development. The customer commits more than the example given at the beginning of this section. And that collaboration is designed to foster more trust between the customer and development team.


Responding to change over following a plan


This is my favorite statement on Agile. It also cuts to the heart of how a business can differentiate itself over the competition. When your systems and processes are configured to respond to change quickly and effectively, your business has a good chance to prosper and make a difference.


Practically this philosophy means that during the development of the software, expect and embrace changes. In XP, requirements are met by creating them in small sizes called user stories. Other Agile methods may break the requirements into features. No matter what the size of the requirement, each method allows customers to make changes before the start of each iteration.


For example, when working on an ecommerce site, one of the requirements may be that a customer of the site can bookmark the product, to be available in their shopping cart after they come back, in 1 day or 1 year. At the beginning of an iteration, the customer has a new requirement. Their research indicates that a new feature that adds a recommendation engine to the site will increase sales. During the planning meeting the customer now asks to put the new feature for the recommendation engine as the first one to work on in this iteration. The team is fine with this, and the customer understands that their other feature may not get in soon or ever.


Taking care of changes so close to the process ensures quick response to customer needs. This allows Agile teams to work without cumbersome change committees, just the stakeholders in the planning meeting.


This does mean that in theory the customer could start out with say 150 stories for their requirements. They could through the course of this process get rid of 100 stories and add 200. But Agile processes are transparent enough to show what the cost of those stories is. The customers in the planning meetings see how much the team completes, and the stories left to complete. When the customer wants to change direction, they can, but then old stories that have not been worked on yet, will be pushed to the back.


As noted above, those stories that do not get into an iteration may never get worked on. During the planning meetings and daily standups, customers/stakeholders begin to see the cost of each feature. As they become familiar with the process, less important features may not be worked on, if there is no budget. This whole process helps the team focus on features with the most value to the company.


Agile is not Chaos


Through the description of the methods used to back up Agile principles, you see that Agile is not about chaos. Instead the Agile name is pretty apt. It is about responding quickly to change, through a process. And that process is generally about delivering good value to the customer, whoever that customer is.


As Agile methods mature, there is a movement incorporating more lean values and methods into the process. Lean fits perfectly with Agile in its pure sense, and helps focus the teams even more into the business side of software/IT. In the end, the focus is about your customers, and your people. Agile is a way to get there.


References


Robert C. Martin “Agile Principles, Patterns and Practices in C#”
Mike Cohn “Agile Estimating and Planning
David Anderson “A Kanban System for Sustaining Engineering“.
Mary Poppendieck and Tom Poppendieck Lean Software Development: An Agile Toolkit


About the Author


Eric Landes is a Project Manager/Project Lead for a large corporate IT department, specializing in coaching Agile teams. He has 4 + years experience using Agile/Lean techniques to bring customer value and a team focus to projects. See his LinkedIn profile for more information

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories