Regardless of what many Agilists say, we cannot in most organisations, just start sprinting. Many organisations need a little bit of governance and most projects need to think about “how” they execute their projects.
Now before you get upset and start talking about the Scaled Agile Framework (SAFe), I want to point out that there are many many many organisations that are not ready for such a radical cultural change. This article applies to them and as such, presents a guide on how to start or indeed restart an Agile project.
Just to be clear, this guide is not relevant for those organisations that love the benefits of continuous product development that SAFe supports.
For instance I came across a project at a media company that had been running for more than one year yet had made no real progress. They had even changed direction a number of times. Yet as a result, stakeholders were not engaged. In fact they had given up. This project should have been restarted much earlier. But the need from the business to have the benefits realized was too critical to the business to make such a dramatic intervention, so they simply carried on. The only thing they tried to change was the scope.
The project simply needed restarting in order to give everybody involved a firm understanding of “how” the project would be executed.
As a second example we need to examine a project that we helped to launch and kick-off at the point of implementation. This “point” was when the project “switched” from preparing to delivery via sprints. Yet when we looked and asked about the so-called “Sprint 0”, the project team informed me that it had been running for over one year.
What had they been doing?
The project was large. It was multi-geographical, involved multi-business lines and was replacing a key system that had reached its natural end-of-life.
During Sprint 0 they had to at least:
- select vendors and partners through extensive RFP RFI processes
- frame the scope
- decide on the high-level architecture
- ensure the technical stack
- narrow down roll-out options
- identify risks
It had just taken them a long time to get it right. It should have been easier. It was simply haphazard.
We Need to Prepare Projects before we Start Sprinting
So both cases provided evidence that there was a need to prepare the projects before they entered into delivery sprints.
As a reminder, in most organisations there are real constraints where governance plays an extremely important role in the culture of the organisation. Burn-up charts and velocity will not suffice.
In order to illustrate this further, we are going to take that second example and simply go back in time. Our starting point is the moment the sprints start. We go backwards because we always tend to go forwards in such blogs. Going backwards makes us think more!
Are you ready? Good…
Preparation for the “How” is Everything
In order to feel confident to start the delivery sprints it may just be advantageous to have considered a number of things. For example
- Is the funding secured and understood (who is paying the salaries)?
- Is the business case defendable (projected ROI reasonable)?
- Are there any audit requirements (we don’t want to find out 6 months in that all our tests fail audit requirements)?
- Are there any legal or regulatory constraints (Banks, insurance, pharmaceuticals)?
- What are the benefits that have to be delivered, and by when?
- Are the resources secured including vendors, suppliers, partners, users?
- Has procurement been involved?
- Are the roles defined and the right people assigned?
- Have we identified any dependencies with the activities in the company (e.g. other projects)?
- Do we need to comply with any standards (i.e. ISO9001)?
Notice we have not even started to consider anything to do with the actual solution. That is next:
- Do we understand the high-level architecture?
- Do we have an idea of which benefits are going to be delivered in the near future i.e. the next three months?
- Do we have detailed stories for the first few sprints?
- What about testing and development infrastructure?
These are just a few of the questions that we should really be answering or considering before we enter sprints. We are simply addressing “how” the project organisation will be set-up and how the project will be governed.
But we can get carried away! We certainly do not want to be developing scripts or tools that we think we’re going to need. We’ll certainly not be writing stories for work due in four, five or six months, let alone in one year! We have to wait until we need them, at which point we will consider implementing them, and that will be done in the sprints. i.e. we delay until the last possible moment.
Notice that in order to complete the above, we must have surely taken time to understand the potential options, because if we don’t prove the options and recommend one, we could be duplicating work or worse doing things listed above that are not relevant. That would be waste.
Let’s Investigate Options First & Check Feasibility
Don’t forget we are going back in time… so the previous steps required a high level rough plan and a tested prototype with potential solutions. We should also be looking at make or buy and if buy, which vendors? After an RFP/RFI round we would be able to hopefully recommend one. Oh and by the way, an RFP/RFI/selection process can take months, it is not something that can be done in a 2-week sprint.
Now, if we are “making” our solution, ie developing it ourselves using technology we do not know, then this bordering on research, and how long does that take?
In addition, we will certainly not understand the requirements to any great detail but we will certainly be fleshing out some of the epics into features, but no more, please! We need to do just enough upfront to be able to understand the benefits that we will have.
It is of course the prototyping of the technical solutions that takes the majority of time as well as the vendor selection process. For research, it is often best to fund a certain amount of time. E.g. Four sprints and then see what the results look like at the end of it.
Once we’ve done all of this work, it is then possible to plan the next activities but only when we have the confidence to progress. Or we stop it. Yes that is right, we stop it.
But why are we even Considering this Project?
But what did we have to do before we started looking at options and checking feasibility?
Somebody somewhere has realized that they can either make money or save money in some way.
They will have a one- or two-pager outlining at a very high-level the business case and the main benefits. They may also have nothing other than a high-level cost range and certainly no exact number.
They should also have a plan and the cost estimate for the next phase which is about testing the feasibility. They also have an idea of who is needed to do that work.
It’s only when those things are considered and it is safe enough to proceed, should feasibility (research & vendor selection) actually take place. Once that is done and the preferred solution identified should the project then proceed, which involves “fleshing out” more details on “how” the project will be done.
Testing the Foundations
One trick to help you judge whether or not the project has good foundations, and to test your project lead & stakeholders, is to ask them to rate the questions below on a scale of 1 (strongly do not agree) to 5 (strongly agree). Get them to complete the questions individually, without conferring, and then see where the differences are*.
It will provide a reason to have potentially difficult conversations, or to expose “the elephant in the room”. Additionally differences will be exposed and challenges will be recognized – with the chance to do something about it.
- All members of the project understand and accept the Agile approach (Philosophy, Principles and Practices).
- The Sponsor and the Business lead demonstrate clear and proactive ownership of the project.
- The business vision driving the project is clearly stated and understood by all members of the project team.
- All project participants understand and accept that on-time delivery of an acceptable solution is the primary measure of success for the project.
- The requirements can be prioritised and there is confidence that cost and time commitments can be met by flexing the scope of what’s delivered.
- All members of the project team accept that requirements should only be defined at a high level in the early phases of the project and that detail will emerge as development progresses.
- All members of the project team accept that change in requirements is inevitable and that it is only by embracing change that the right solution will be delivered.
- The Sponsor and the Business lead understand that active business involvement is essential and have the willingness and authority to commit appropriate business resources to the project.
In the first example, at the beginning of this article, during the first workshop all six individuals disagreed on the purpose of the project (question 3). They were not aligned. That was quite a revelation for the people.
When we look at the second example although the purpose of the project was clear, the way they got to the beginning of the sprints was very convoluted and could have and should have been streamlined. Had the project team answered the questions listed above earlier and repeatedly, their answers would have shown the need to act.
Even today, 15 years after the signing of the Agile Manifesto, within many organisations, it is necessary to put down some structure to set in place the foundations for “how” the Agile project should be executed. Agile projects (indeed any project, for that matter) will be on shaky ground if only a little thought is done upfront.
Even projects that are already underway may want to consider whether or not they are struggling because their foundations are weak. If so, isn’t it better to act now before it is too late?
* These questions are part of the DSDM Agile Project Management Framework’s “Project Approach Questionnaire”.