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

The art of planning a project

In the second edition of their book, Brilliant Project Management, Barker & Cole offer some excellent tips on how to plan and manage projects, even what to do and say as a Project Manager. It’s an excellent book for newbies and experienced Project Managers alike – serving as a good introduction or refresher depending on your experience.

One of the chapters focuses on planning projects, which I’d like to share, mainly because it summarises, very effectively, all the key aspects that one would associate with planning projects.

The five critical elements of a good project plan as stated by Barker & Cole (2009 p16 to p25), with additions from myself:-

Project objectives and supporting key requirements
Both your clients/customers and your team need to understand the “Big Picture” and the underlying business objectives. A good understanding of what is trying to be achieved is absolutely essential as well as clarity of the project objectives. Distinguish between objectives and requirements.

Project scope
Its essential to pin down the scope and identify boundaries. Knowing exactly what is to be delivered not only helps in your planning, but also when managing change requests further down the line. Remember to identify what is out of scope as well. This usually ends up as a “Statement of Scope” or “Scope of Work” document.

Major deliverables
All tangible things should be defined and agreed up front. Check your deliverables versus the project objectives – each deliverable should relate directly or indirectly to the objectives.

Resource needs
Resist pressure to adopt unrealistic budgets or reduce identified resource needs. Be clear about the costs and be prudent – it is after all “someone elses” money and you are responsible for it! Remember to include any possible hidden “overheads” such as lighting, heating or travel expenses on projects that dictate this kind of approach.

The Project Schedule with key delivery dates
Be realistic when putting your schedule together. Don’t try to please everyone with early delivery dates if there is no hope of achieving them! Your schedule should reflect key delivery dates calculated on the time it takes to achieve the tasks that will result in a deliverable. A good schedule is dependent upon three elements:- deliverables, resources and dependencies. Keep your schedule logical and involve your team in the development of your schedule.”

This particular books is available at most bookstores (I got mine at WH Smith), the publishers and also online at Amazon. I’m sure many people will be able to add to this list, based on their personal experiences and I’d like to hear from you about it.

References:-
Barker S and Cole R (2009) Brilliant Project Managers, 2nd Ed. UK: Prentice Hall

Costs to consider when you’re preparing your project budget

Looking back on all the projects I’ve managed, I’ve found that there are usually the same types of costs being budgeted for.  So when you’re planning your next project, hopefully this checklist below will be of help.


  1. People costs. This includes internal staff, freelancers, contractors, offshore developers.
  2. Equipment costs. This can include hardware, software, machinery, projectors – anything that is purchased or hired to help deliver the project.
  3. Research costs. Many projects require up front time by the team to research appropriate solutions.
  4. Facilities that are required for use by your project team e.g. rented temporary workspace or accommodation
  5. Quality Assurance. The time and cost for this should always be included along with time and budget for any corrections/amends.
  6. Handover/deployment costs such as client or staff training, marketing, de-briefs or preparing DVDs to showcase the end product.
  7. Project specific costs – e.g. translations, the purchase of a particular font, flights, sundries
  8. Licensing/Royalties. Some projects, especially online ones, will need to cater for costs to cover licensing fees or royalties.
  9. Overheads such as lighting, heating. Sometimes this is an agreed fixed percentage per project based on the number of project hours or duration.
  10. Administrative costs e.g. additional insurances, additional telephone/internet costs for remote workers.

If there are other costs you can think of to add to the list, I’d be happy to hear from you.

Overview of the Waterfall Methodology

The Waterfall method (also known as “traditional”) is a rigid step-by-step approach to project management. Once you have completed each step within the project, you cannot go backwards. With waterfall, the entire project is planned at the beginning with each phase being given a fixed deadline. Each phase has a distinct goal.

The waterfall model derives its name from the cascading effect from one phase to the other as illustrated below. In this model each phase has a well defined start and end point, with identifiable deliverables from one phase being passed to the next phase before it can begin. Waterfall is a well documented method, with documentation being produced at every stage and it is also a very disciplined approach to a project. However, it is not suited to projects where the scope or product is vague and change control can be cumbersome and difficult.

*TRY COPERNIC DESKTOP SEARCH NOW*

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

Prince2 Project Management Processes Series – Directing a Project (DP)

In the next part of our series, we look at Directing a Project. Whilst day to day management of a project is given to the Project Manager, it is key that the Executive exercise overall control and be responsible for making key decisions i.e the Project Board – and this falls within the scope of “Directing a Project”. Directing a Project as a process, starts after “Starting Up a Project” (SU) and continues to run until project closure.

The key steps involved in this process are:-

  1. Confirm the project organisation
  2. Agree the project objectives
  3. Approve the plan to generate the “contract for the project”
  4. Approve the “contract”
  5. Approve each stage of the project
  6. Make decision on any major problems
  7. Keep senior management informed
  8. Confirm the correct closure of the project

Each of the steps are applied at different points within the project as shown in last weeks diagram. DP4 – Giving Ad Hoc Direction is clearly seen to be running throughout the project. Authorising Initiation (DP1) is followed by Authorising the Project (DP2). Authorising a Stage or Exception Plan (DP3) usually occurs several times in any one project and eventually leads to Confirming Project Closure (DP5).

The core of Directing a Project, is defining responsibilities for the Project Board and the process also gives legitimacy and direction to the project and its control throughout its life. The main Project Board responsibilities are summarised:-

  • Approving the Project Brief and authorising initiation.
  • Authorising the Project Initiation Document, commonly known as the “PID”, and taking ownership of the project.
  • Checking project status at the end of each stage and authorising continuation to the next stage.
  • Providing management direction and guidance to the Project Manager.
  • Liaising with programme management.
  • Confirming project closure

There are projects where a Project Board is not clearly identified and not empowered, leaving all the responsibility to the Project Manager. This usually happens on “smaller” projects and is a practice not to be encouraged as this leaves too much responsibility on the shoulders of one person. Without the direction and guidance of the Project Board there is an increased risk of project failure.

Information contained within this post is copyright to Crown, OGC