Sometimes we’re in projects in which we need to prepare a large number of things before starting out. Can we start building without stopping to plan or analyse what we’re about to do?
When we read about Scrum, we get the impression that all texts start directly with development, but…what about environment, team or office preparation tasks? What about design? Shouldn’t we stop to think about the whole design and architecture of what we’re about to build before we start programming?
About preparation or “before” programming. Some people call it “sprint #0”, the sprint where you prepare your tools, install the stuff you need, train the team, etc.. It can be a longer sprint (3, 4 weeks or so). Some detractors criticise this sprint because it is not agile, and because it hides some work that is taken care of in the same way as the rest.
It is true that it can be very comfortable, because we tell the client that we’ll be back in 3 weeks to have the preparation meeting for the first sprint, and by then we have organized it all. I have also used those zero sprints in my first projects, but now I prefer to solve those issues also in an Agile manner.
I try to make every one of those tasks (installing the development server, installing the demo server, creating a project and tasks in Trac or Redmine, installing the Integrated Development Environment or IDE, etc.) part of the first sprint and, if possible, have a set deliverable at the end of each demo.
In that demo, we could show, for example, the project-management tool already installed in the final URL and the task list with the tasks ready to be assigned, or we could launch the IDE in that demo meeting, and check whether the environment has been created correctly and whether Jetty executes a “Hello World” application correctly.
Another important step is the initial architecture design. If we make a huge design with all the application architecture (known as a big up-front design) before we start programming, we will be returning to a waterfall design. Firstly, we analyse everything, three months later we do all the design work during a couple of months, and then we program everything in one go until we finish it six months later. If we finish all work and show it to the clients and they say: “that is not what we discussed a year ago…” then we have a problem.
It is better to design one of the modules of the application, or one of the new features, then draft the specifications, and finally send them to development. While part of the team implements them, analysts can gather requirements for another module or another feature, and go on doing so sprint after sprint.
There will be sprints in which we won’t have new stuff to analyse and others in which the development goes a bit faster than the specifications, but normally there is always some task ready to be carried out while Product Owners sign off the latest requirements, or until those requirements are completely defined.
If we work like that, new modules or features could be regularly deployed to production or preproduction, so users will be able to take advantage of them without waiting until the very last feature of the application has been designed.
You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).