Ready for Agile: An Introduction to Agile Development

by: Ryan Martens

“If you want to teach people a new way of thinking, don’t bother to teach them. Instead, give them a tool, the use of which will lead to a new way of thinking.”
– Buckminster Fuller, American inventor, author and visionary

What Are Agile Methods?

Agile is an organizational change tool that can lead to positive changes in your projects and programs. It is a very simple and different strategy for project management than critical path and waterfall.

The “iron triangles” shown here depict the constraints that any project must wrestle with. Waterfall software development is measured by conformance to the plan. The essential disciplines of waterfall require you to get the plan right and make the phase hand-offs of documents effective. If you get it right, waterfall can be very efficient and successful, but never early.


Agile software development is driven and measured by its ability to deliver results to the vision and value. And like waterfall, Agile requires certain disciplines to be successful. With Agile, the essential disciplines require crisp and effective cross-functional collaboration and a commitment to delivering working code in the face of small fixed resources and fixed time boxes, known as iterations. As a result, Agile projects can deliver early – as soon as the vision and value are realized.

For projects where the risks are high and the project definition is evolving, Agile’s simple empirical method delivers consistently better results, faster and with less total cost. For projects where the technical, execution and funding risks are low and the definition is well known, the waterfall process can be more time- and resource-efficient – provided you plan, you hand-off documents well, and the definition does not change during the project.


Agile is a feedback-driven paradigm for managing the design and delivery of creative, innovative, risky and complex projects. Its principles are contained in the Agile Manifesto . Its best practices include:

• Run one- to four-week iterations that deliver working, tested increments of functionality

• Make releases to customers smaller and more frequent

• Maintain the system in a state that always runs and passes automated tests

• Organize around cross-functional component teams (define, test, code & build)

• Work projects serially from a regularly evaluated and prioritized backlog

• Inspect and adapt the process and product every cycle

The Agile software development process is well depicted by the Scrum model of working on the highest priority items in concentric time-boxes including daily, iteration, release, roadmap, and vision. Organizing for Agile methods requires working in cross-functional teams of resources required to produce a complete releasable solution. This typically means people who can define, develop, test and package a component of the system. Leadership of Agile teams requires servant leadership skills. Technology to support Agile facilitates collaboration, prioritization, visibility and lightweight signaling.

How Do Teams Adopt or Trial Agile?

A vast majority of teams get started with Agile software development by adopting it on one team first. To start a pilot team, follow these on an in-flight project or new project:

1. Get the team together and get agreement to try Agile methods.

2. Declare an iteration time box, for example two weeks from this coming Monday and schedule a demo with stakeholders for the end of the iteration.

3. Prepare your top five highest priority items to get done in the two-week period. This list of items includes for each a description of the item using a story template (“For system role, provide the capability to deliver benefit”) as well as the one to three acceptances tests necessary to declare these items done.

4. Have an iteration planning meeting for about four hours wherein you task estimate these five items and discuss, with the whole team, the designs necessary to get items done-done in the two week window. (Done-done is coded, tested, user accepted and integrated into the systems.)

5. In the planning meeting, estimate your capacity in the two-week window in hours of productive time. (Typically no more than 50 percent of the wall time to available new Agile team.)

6. Use your capacity to reprioritize and shape the five items to fit into the capacity-constrained iteration. Do not ask the team to do more than the available capacity.

7. End the planning meeting by have the team come to consensus and commit to delivering some portion of the five items in working, demonstrable code at the end of two weeks.

8. Run the iteration and steer it using a daily 15-minute stand-up meeting taught in Scrum training .

9. After the iteration ends, hold the demo to get stakeholder and customer feedback on the delivered software.

10. Hold a review meeting with the team to figure out what went well and what you want to change. Ask the team if they want to keep doing Agile development or go back.

What Are the Next Steps?

There is big footnote on Agile: “It’s simple, but it changes everything.” Because the time boxes are short, it is easy to measure progress and expose issues. Agile exposes “issues” quickly and effectively. You need to be ready to work in very open and visible environment. In addition, you need to be prepared for feedback and reflection. If your team collaborates well and has the discipline to work the highest priority items in small chunks, you will not be disappointed.

Finally, if you need to think about how Agile software development can cooperate with your current waterfall world, review Michele Sliger’s Agile 2006 presentation, “The Agile/Waterfall Cooperative” .

About The Author
Ryan Martens has helped hundreds of organizations transition from traditional development processes to Agile methods and is an elected board member to the Agile Alliance, a non-profit organization that supports Agile software development. Access additional resources on transitioning to Agile at http://www.rallydev.com/agile_knowledge.jsp.

Article courtesy of Ryan Martens, ArticleCity.Com

Agile Software Development Overview

Agile Software Developmen is a framework for software engineering/development projects and not a methodology in itself. Some of the methods that fall under Agile are Crystal Methods and Scrum. Agile methods attempt to minimise risk by developing software in short iterations, lasting one to four weeks. Each iteration is like a mini-project in its own right, and includes all the tasks necessary to release the increment of new functionality i.e. planning, requirements analysis, design, coding, testing, and documentation (although Agile is usually quite light on the documentation side).


Whilst one iteration may not add enough functionality to warrant releasing the product or newer version, it is usually the intention at the end of an iteration. At the end of every iteration, the project team re-evaluates project priorities to plan the next iteration.Agile methods emphasise the need for quick and open communication, preferably face-to-face, with the team being located in a ring fenced (bullpen) zone – this includes ALL the people necessary to finish the software e.g. programmers, product managers, business analysts, clients, project manager, designers, testers, and writers.

The diagram below demonstrates a typical agile (iterative) development process.

Figure 1
Figure 1

References:-
Hung, T (2007) Figure 1. Software Development Process Available from: http://cnx.org/content/m14619/latest/ (Accessed: 22 February 2009)

The Scrum Team – how to maximise productivity

Scrum is a project management methodology often used in software development and sometimes web development where multiple product increments are anticipated.

In Scrum, the team itself figure out how to maximise productivity.  No managers allocating tasks – the job of planning and executing all the tasks belongs solely to the team.  This way, each team member can have a say in what tasks need to be done and by when.  The Scrum Master is only there for advice and guidance.

Scrum has a 30 calender day Sprint (cycle). The team selects which Product Backlog to work from and works uninterrupted on that particular Backlog for 30 days. Once a backlog is selected the team are committed to turning it into a product increment within the 30 day period.

The key to maximising productivity here is that the scrum team manages itself. Those not used to working in a scrum environment may initially be confused by this, and await task allocation by a Project Manager. However, they will soon learn that the Scrum Master doesn’t do this but that he/she will be on hand to guide them in managing themselves and committing to delivery.

At all times, the scrum team must be encouraged to act together as one in order to ensure the product increment is ready at the end of the Sprint.  Sprint Reviews are helpful to ensure everyone is still on track.

*TRY COPERNIC DESKTOP SEARCH NOW*

FREE 30-day trial! Stop searching and FIND.
Voted best Desktop Search application. Click Here