Author: Bernadette Greenock


Our highest priority is to satisfy the customer through early and continuous delivery of valuable and useful software. Identifying issues early and changing direction quickly to satisfy the customer need is key to achieving this priority.

Having a product owner, business SME and key stakeholders as part of the agile project team allows good collaboration and a shared understanding of progress. It permits the customer to see firsthand what is being developed, allowing project ‘tweaks’ or ‘changes’ if required, therefore delivering software that is what the customer really wants. This method helps to deliver business requirements and ultimately the benefits associated to the project.

This ability to change quickly is the key to lowering the cost. How many projects have failed because they’ve been developed over years based on requirements and designs gathered and built years earlier? Failing fast and reacting quickly to resolve or find better ways ensures time and effort is not wasted on developing a solution that does not meet the requirements of the business.


Lightweight methods can provide the business value for minimal cost. As a practitioner, I typically like to plan an Agile project in this way:

  • Ensure that project kick off, charter, and risk sessions are held. These are very short meetings but start to ensure that all team members share a common understanding of what the project is expected to achieve
  • Hold a discovery event or series of workshops to confirm the scope, objectives, and high-level plan of the project. The length of time required will depend on the size of the project, but typically it shouldn’t take more than a week or two’s effort for a 3-6 month project. This event or series of workshops is critical to building a common understanding of the vision and solution
  • Create and estimate the project schedule at a deliverable-level with dependency management to ensure that the project can deliver the minimum customer scope, budget, and schedule requirements
  • Gain agreement from key stakeholders and the agile project team as to how the agile project will run and what the ‘rules of engagement’ or ‘way or working’ are. We have already confirmed we think we can deliver the minimum functionality, so this meeting is focused on gaining agreement on the process of how we will work together to deal with change.

I’m not suggesting detailed documents such as a full blown project plans, full BRS documents, or architectural documents, but a little work on these key areas can assist with a shared understanding and ultimately the success of the project.

In summary, it’s about doing ‘just enough’ to gain a shared understanding without getting held back with waterfall methods seeking full detailed requirements before commencing any delivery.