By Linky van der Merwe
As a Project Management Professional and Agile Practitioner, the startup of a new project is one of the most important activities to lead. There is a good chance that if you start well, you will also finish well.
How do you start an Agile project if you are working in an enterprise organization with a mix of projects ranging from the traditional plan-driven (waterfall) projects to agile projects to a more hybrid agile approach?
The purpose of this article is to provide you with guidelines for starting an agile project as an Agile Project Leader. It is based on my own experience as a professional project manager who has made the transition to following an agile approach.
Hybrid Agile
Let’s first clarify what I mean by a hybrid agile approach. Hybrid agile approaches typically combine traditional (predictive) and agile elements. Whereas a blended approach combine two (or more) similar approaches. So, using a combination of Scrum and XP is a blended agile approach since they are both agile to begin with.
According to Mike Griffiths, in his article on Projectmanagement.com, called “Flavors of Hybrid Agile”, he explains that the goal of combining project approaches is to create something better suited for our current environment than using either a pure agile or pure traditional (predictive) approach. He promotes the argument of being smart about the tools we use and to choose the best approaches for the circumstances we face. I have to agree with being pragmatic about this and to apply our efforts where we have the most influence. In the end it’s about the results.
Agile Project Lifecycle
One example of such a hybrid agile approach that I have worked with before, is below.
You start with a phase called Inception and in the case of a really large program, there will be pre-work, sometimes called the Pre-Inception. As expected you will do analysis, developing, testing and deploying in every iteration during Development . You still do development, testing and test automation in every sprint, but instead of releasing to production, you will release to a test environment (sometimes called Acceptance).
You then have a phase for testing that a new solution will work end-to-end, called Stabilization. This is usually applicable in an IT environment where the new solution (system) needs to integrate with multiple existing applications. In normal Agile, a test iteration at then end, is also called a ‘hardening sprint’.
Once the end-to-end testing has been completed, it will be followed by user acceptance testing, also known as UAT, where end-users will test actual business like scenarios to ensure that the new solution is performing as expected. Only when UAT is signed off, the solution is deployed to production during the Deployment phase.
During the Inception phase, you will review the Business Case (in the case of a formal strategic project), confirm the scope, plan for the project (sprints), ensure team members are trained, elaborate the requirements and establish the infrastructure plan, including hardware, software and various environments to work within (development, testing and production environments).
Startup
Typically, there needs to be a Project Kick-off workshop where the Product Vision and Scope of Work is shared with all the stakeholders. On a high level the business requirements, the in scope work, the key stakeholders as well as the agile approach are presented.
Next is the Release Planning where the conditions of satisfaction are agreed, for example the expected timeline for the project, the scope including the Product vision and roadmap, the epics (and user stories), as well as the budget.
The release plan activities will include agreement on the scope, in other words which epics and user stories will deliver the scope. Next you want to gain consensus on user story estimates. Then you need to determine the team’s capacity for completing the work. The activities are explained very well in this picture, adapted from ‘Mike Cohn – Agile Estimation and Planning’
If you are used to looking at a project planning as a process, it will look something like this.
The Team
Another important step in the startup process, is the Team Formation which will consist of several onboarding activities.
With each team that will be part of the project, you want to develop a Team Charter in which the project team’s vision, the objectives, and the team member roles and responsibilities are covered. The team also needs to develop a Working Agreement to agree aspects like:
- Rules of communication
- Capacity of team
- Calendar
- respond times for mails, questions
- Decision making methods
- Interpersonal relationships, & conflict management approaches
- How Change Control will be dealt with
- Other relevant topics
The Process
Whatever agile approach has been decided on by the Management and Development teams, as fit for purpose based on the context of the organization, it needs to be documented as a process and explained and agreed with the overall team members.
The Tools
One thing that my experience has taught me, is that you need sufficient tools to support your agile process. Many people love Excel, but it certainly won’t be enough. Although it could be a good starting point, there are people who like to export data from electronic systems and use Excel to track the progress of the work. Try to stick to one system that will be the single source of truth, especially if coordination is required among multiple Development teams.
The tools can be as simple as physical white boards with stickies, so that the work in every sprint is visible and the stickies can be moved during daily standups. Impediments can also be clearly indicated so that action can be taken.
The tools can also be electronic task management systems with ‘whiteboards’ that allow for backlog refinement and boards that will make the work visible for teams to share and discuss. There are multiple good tools available in the market today and it’s up to the organization to find a tool suitable for their needs.
Ready, steady, go
At the end of Inception phase, the backlog will be ready and in a healthy state. This means that User Stories are adhering to the INVEST principle (Independent, Negotiable, Valuable, Estimable, Small, Testable), they have acceptance criteria, estimates and meet the Definition of Ready (DOR), based on what was agreed for them to be ready.
The Product Owner(s) will work with the teams to prioritise the work and it will be an ongoing refinement process before every sprint. Feedback will be provided and based on the inspect and adapt principle of agile, there will be continuous improvement in every sprint.
This is a very short synopsis of what it entails to start an agile project successfully. The aim is to give guidance and to provide a logical sequence of steps to be taken. As always, every project is unique, every organization is different, and as an Agile project leader you need to take your context into consideration to decide on the best approach for your situation.
