Agile methods are currently one of the hottest topics in business management.
Agile methods break tasks into manageable increments with minimal planning. Agile is an iterative process, splitting larger tasks into phases of fixed duration. Though there are many Agile methods in use, we’ll concentrate on one of the more common, which is known as Scrum.
The Scrum Method
Scrum incorporates a number of key processes, techniques and roles. In Scrum, each project phase is known as a Sprint and can be considered as a mini project in itself. The objective of each sprint is to create a ‘latest system’ which has been tested, debugged and can be demonstrated to stakeholders, and its objectives measured against an overall plan. Depending on the complexity and scope of a project, there may be many Sprints, each one advancing the development in measurable steps.
Agile projects emphasise people over process, with face-to-face communication and collaboration underpinning all activities. Agile teams are normally composed of between six and ten people having a variety of different skills and experience. Larger projects may split into multiple teams, but the optimal number is generally in this range. Each team aims to be largely self organising; each member takes responsibility for both their own individual objectives and the progress of the Sprint itself. Location is another important consideration, with teams ideally located in one location and coordinated by Daily Scrums – that is, brief stand-up meetings to report progress, allocate tasks and communicate any ‘blocking’ issues.
Each Agile team includes someone who will represent the business stakeholders and act as liaison between the team and the business – the Product Owner. This roles involves acting as a single point of contact for questions and as a reviewer at the end of each sprint, to ensure objectives are met and minimise any expectation mismatch between the team and the business. A Scrum Master is another individual role, responsible for maintaining the processes and performing general project management duties, including resolving any problems.
During a Scrum project, it is recognised that the customer can and probably will change their minds about what they want and consequently Scrum aims to focus on responsiveness to change.
Drawbacks of Scrum
On the surface, Scrum appears well suited to business software development. However, the lack of structure and documentation output is seen as a real drawback, with significant risk of requirements mismatch and knowledge loss. It also lacks the rigour of conventional software design, leading to short-cuts, unnecessary reworking, inefficiency and a lack of overall architectural governance. Moreover, it is notoriously difficult to provide useful estimation due to the fact that development begins before the full scope and requirements are identified. Lastly, though it aims to respond quickly to change, it fails to provide any real mechanism to help organise and channel that change and is entirely passive in working with its customer to ensure that any change is properly scoped, designed and managed.
The Power of Requirements Prototyping
Requirements Prototyping is the structured use of conceptual and interactive models to help stakeholders and users shape the design process. Executed and coordinated properly, iterative prototyping is normally performed in several iterative cycles which may include multiple prototypes to explore alternatives. The prototyping consultant operates with many responsibilities, including acting as a liaison between different business units, a technical adviser, usability expert and business analyst. Of course, input from business domain experts is required and the skill of the prototyping analyst is to distill this knowledge into models which reflect the basic objectives of the project and help put ‘flesh on the bones’ of the requirements and design.
Use of Requirements Prototyping in the Agile World
Agile is development focused and encourages creating the ‘how’ before the ‘what’ has been pinned down sufficiently. It does not really facilitate interactive design. Requirements Prototyping, on the other hand, is very suited to the creation of effective interactive design, and excels in shaping the requirements early on, before expensive development effort begins.
ProtoSMART is one solution we are developing: a sprint-based Requirements Prototyping methodology which itself can form the initial phases of a larger Agile project, particularly those based around Scrum.
How it works is quite simple: during the early stages of any non-trivial development, detailed requirements are not always finalised. General objectives, however, are normally in place and provide a skeleton to begin an iterative process of prototype steps.
1. Kick Off
To begin with, a kick-off meeting is held which agrees on the foundation objectives and requirements of the project. These are categorised and rated according to priority, completeness and expected complexity. This sets the agenda for the project. This is similar to a Sprint Planning meeting but instead of being focused on a single sprint, covers general objectives for the entire project.
2. Early Requirements Gathering
The prototyping analyst will spend some time with each stakeholder extracting more information about each of the foundation objectives and will begin work on high level flow prototypes. These high level prototypes gloss over specific detail, instead acting as placeholders onto which the requirements prototyping process can pin its outputs.
3. The Requirements Prototyping Cycle
This involves taking the high-level prototypes from the second stage and beginning to work with the business stakeholders and end-users to build in detail and try typical user scenarios against the design. Sometimes multiple models of a particular slice of functionality will be created so as to choose between alternative approaches (perhaps in a workshop scenario). This phase is often split out into several sprint-like stages of its own, with deliverable milestone prototypes and reviews being performed at the end of each sprint. In essence, this is the ‘spirit of Agile’ applied to prototyping.
4. Design Finalisation
After a few iterations of requirements prototyping, a much clearer idea of the true shape of the project will have emerged, backed up by the existence of an ‘interactive requirements specification’ which doubles as a simulation of the proposed system. At this stage a workshop is help which involves all key stakeholders and user representatives, with the view to signing-off the design.
5. Development Initiation
This is the usual point at which the actual development phase begins, using the signed-off prototype as a requirements foundation and guide. The prototyping analyst generally remains involved in a gatekeeper capacity, helping to map tasks into sprints and ensuring that any refinements required of the design are managed appropriately. She may also take on the role of Product Owner, if required, or that role may go to another person.
6. Sprint-based Development
This phase is essentially the same as for a conventional Scrum development, but supported by proactive requirements prototyping which supports any changes which come through from the business. The prototyping analyst continues to play a part, either working directly with the business or with the Product Owner, and may optionally take on additional responsibilities as suits the resourcing of the project.
Benefits of ProtoSMART Agile Prototyping
- Takes advantage of the responsiveness and focus of a conventional Agile project, and is familiar with anyone who has experience of operating in that manner;
- Allows the benefits of requirements prototyping to shape the direction of an Agile project both during the early stages and as a way to co-ordinate and facilitate change during later sprints;
- Proactively engages stakeholders and users at all stages;
- Avoids the mismatch which is inevitable when development starts before the requirements are clear;
- Guides the optimal choice of tasks and user journeys in the Agile process.
This model for system development is still evolving; as we learn where the methodology’s strengths and weaknesses lie, we may adapt it or even skip certain stages. It will not fit every type of project, but for non-trivial modern software development projects lacking clear objectives from the start, it provides a flexible yet structured approach which combines two existing approaches in a sympathetic manner.