Installing scrum - the hard way
A year ago I joined a new team, my goal was to introduce this team to Agile methods and approaches to software development. I was looking for a challenge and an opportunity to learn and I found one. So just in case you are looking for a challenge, this is what you need if you want to install Scrum and do things the hard way.
- You need a project, preferably one running at least two years late. It must be huge and complex; critical enterprise level software is good, a platform change is also good; both at once are best.
- Your project must be in an unknown state; there must not be anything that looks like a source of truth about the overall scope or the current state of the project. It's good when the business is unaware of this, because you get to tell them.
- It's particularly helpful if your project has accumulated a significant amount of technical debt, as a result of development shortcuts taken in order to meet unplanned business needs. There must not be a clear picture of the amount of TD nor must there have been any thought given to paying it off. Ideally your TD should become apparent at the least convenient moment.
- The team should not have had any training in Agile methodologies, or their associated vocabularies. Terms like “retrospective” and “backlog” should be completely foreign. The idea of a value-based approach to working should not have been broached at all.
- There should not be either budget or time for training, any training that is done must be strictly on-the-job and should not mean that the job takes any more time than the minimum required.
- There will be no visible use of story cards, burn down charts or any other form of publicly shared information radiator. These including things like the daily stand up must be kept out of sight of anyone who may find them a distraction or feels they look untidy.
- The practise of continuous integration, or the infrastructure to support it, must not be established. This means that you will need to put it in place as you go and you get to experience regular integration hell.
- Things like an established QA team or QA process and especially automated testing are a real nuisance. This deprives you of the challenge of trying to regression test an increasingly large code base by hand as well as all the fun associated with putting automation in place and ensuring your practises support it. There shouldn't be any additional budget for this either.
- It's best if your team is used to working within the confines of very clearly defined roles and are not in the habit of collaborating to decide the details of what should be built and how long it will take to build. This task should be done by someone else, it doesn't really matter who, so long as they are not a member of the development team, know very little about software development and are not distracted by things like the need to develop potentially shippable increments of the product.
- Finally, you must deliver potentially shippable increments of product, from sprint 1, whilst responding to the needs of the business by understanding their goals and challenges. You must teach the team that requirements which change as a result of these are to be welcomed as opportunities to build the right thing, meanwhile, learning the product and domain.
- We still have a large complex project, but we know exactly how much of the total scope we have built, and how much is yet to do. We have a release schedule and are totally unified in our commitment to meeting it.
- We regularly schedule activities such as re-factoring into our sprint plans, in order to manage our existing technical debt. We still accumulate new technical debt, but when we do so, it is the result of a strategic decision and we include its management and remediation in our planning.
- The team and the business have been gradually introduced to the values, philosophy, practises and rules of scrum. This has been done one tiny piece at a time, gently and quietly, leading by example coaching continuously and seizing every teachable moment possible. Gradually we have seen the language change and the framework and practises have become familiar and welcomed.
- We don't have a physical story wall, but we do have an electronic one that every member of the organisation has full access to. We have practised transparency through this tool by sharing our successes and failures openly and consistently.
- We have a shared repository of lightweight but permanent artefacts to support requirements and testing work. Because we know this product will outlive this team, we share responsibility for developing them and keeping these up to date.
- We do have continuous integration, as well as (for the first time recently) separate QA and UAT environments, although we still don't have fully automated testing. This is our next challenge, and we are very focused on developing the skills we need to introduce full automation. In the meantime, we are collectively a lean, mean testing machine
- The demarcation of individual roles and tasks is a distant memory. Everyone applies all the skills they have where they are needed, when they are needed.
- We work directly with the business to plan our releases at the theme level, our product backlog is about 90% estimated in story points and our detailed sprint planning is done by the team, in accordance with the rules of scrum. We are getting much better at estimating our work and breaking stories down into useful task lists.
- We delivered our first shippable increment in sprint 1, our first shippable release into our sandpit area for client feedback in March of this year and have continued to deliver two updated releases and increments every sprint and will shortly deliver our first release to go directly to client environments. Along the way, our product has been showcased to clients, has enabled us to compete for tenders and has attracted interest from new markets.
Perhaps most telling on a personal level, is that I stopped keeping half an eye on the job market, quite some time ago.