Skipping the planning and initiation phase of a project is often justified by agile project models, but high-quality project preparations are not in conflict with agile development – quite the contrary.
North Patrol is a consulting firm specialized in the design of digital services and information systems. We shape ideas into a vision and service concept, find the best architectural and technological solutions, design a functional user experience, and compete to find the ideal partner for implementation work. We do not sell implementation projects, nor do we sell licenses; we are genuinely on the side of the customer.
19 April 2021
Most agile project methods start with the assumption that the plans for the project's vision and key decisions are done prior to the agile implementation, and detailed planning is done as part of the implementation sprints.
In agile methods, however, the steps of planning and initiation work are often described very lightly, or it is simply assumed that the guidelines have already been made before the project is launched. This often leads to the misconception that agile projects do not involve any preparatory work at all.
The product owner can't come up with requirements based on nothing
In agile methods (such as Scrum), the product owner has the demanding role of communicating the needs and priorities of the organization to the implementing party. In particular, technical suppliers often expect the customer's product owner to describe all the requirements of the project and to answer all questions on the go.
However, creating a project development queue, or a backlog, requires a vast amount of collaboration, planning, and documentation within the customer organization. The project requirements aren't usually just made up by the product owner, but they are based on the needs collected from users and the organization as well as the design work based on these needs, which often involves large teams.
The work done during the planning phase of the project serves as a basis for more detailed initiation and allows the product owner to work independently, once the project guidelines have been defined in advance within the customer organization.
Documenting the planning and initiation of an agile process
Agile methods emphasize a working software as a priority, and documentation does not have the same intrinsic value as in many more traditional models. This doesn't however mean that the agile project would not involve planning and documenting the plans. Planning is done continuously, both before starting the project and throughout it.
The following figure showing the Microsoft Azure DevOps Board´s documenting hierarchy, based on Agile Alliance´s model, is a good illustration of the hierarchy created by project goals and requirements.
The plans at the top level (Portfolio Backlog: Epic, Feature) describe the project's goals and key functional requirements, which are determined before starting the project. Plans at this level are usually outlined during the prestudy phase of the project.
The plans of the implementation phase (Backlog, User story, Task) on the other hand deepen the definition of the requirements and fine-tune the details of the implementation. They are specified as the implementation goes on. The requirement specification which is prepared before starting the implementation serves as a basis for the plans of this phase.
(Agile process: https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidance/choose-process)
Planning and initiation in a Scrum project
The most commonly used project model for agile software development, Scrum, uses backlog sprints for organizing and managing the implementation. Scrum gives surprisingly little guidance on how to organize design work before and during a project.
The project model assumes that the project has a vision, but does not specify how the vision is created. The project model also assumes that the project owner creates and prioritizes the backlog, but very little is said about how the project owner does this.
Another thing not included in Scrum is the role of architecture design (or the architect). Architecture is expected to be formed agilely through team work. However, for the project to be successful in practice, it's desirable to at least have a rough idea of the architecture before the project starts.
Neither does Scrum have a set operating method for user interface or visual design. They are assumed to happen within the implementation team as part of the implementation. This is inconsistent with practice, as the client organization rarely wants to start implementation without seeing any presentation of the desired end result or how the final product is thought to operate.
Planning and initiation phases are nearly always required in order to launch a new project, but the design work isn't usually visualized as part of the Scrum process as instead it´s hidden inside the role of the “almighty” product owner.
The next figure roughly illustrates how the planning and initiation work done in the prestudy and requirements specification phase practically work as the starting point for the Scrum project.
(Scrum process: https://scrumstudy.wordpress.com/2014/07/24/what-is-scrum/)
Prestudy confirms the starting points of the project
Regardless of the used project methods, before starting a new digital project, it's always worthwhile to specify the goals and scope of the project by making a prestudy, which serves as a basis for more detailed project planning and implementation work.
The aim of the prestudy is to clarify the goals of the project and the long-term vision of the resulting solution, as well as the concrete concept of the first phase. The second task is to create adequate guidelines for the project about the architecture of the solution and the technologies used. The third key task in the prestudy phase is to create the budget and schedule for the implementation of the project.
A good prestudy includes the following aspects:
- background and goals
- initial service concept and key requirements
- architecture and technologies
- workload and costs
- project phases and schedule (the roadmap)
- project resourcing, organization and management
The prestudy phase can be used to identify needs, for example through interviewing the users and other stakeholders as well as trying out solution options with prototypes. Perhaps the most important task of a prestudy of an agile project is to identify what is expected from the first published result (MVP) of the project.
The use of agile methods is often justified by the fact that large, complex systems cannot be planned in advance. Planning the details can well be left to the implementation phase, but especially in large development projects, a clear vision and architectural solutions are paramount for a smooth process of the agile implementation and successful outcomes.
(This article has been translated from the Finnish original. Read the original article.)
