The UK Government has invested £17 million over the past 2 years migrating from several rather old websites to the new, shiny gov.uk website. James Stewart and Anna Shipman gave an uplifting talk at the Edinburgh BCS branch meeting on May 1st, describing how they had scaled from one small team of 12 to ten teams (and an organisation of over 200) in not much more than a year. Not only that, but they had delivered on-time and have since gone on to win the “Design Award of the Year.” Everything was not perfect – they admit to having worked unsustainable hours and of accruing significant technical debt – yet they appeared energised, motivated and undeniably happy.
Prior to that meeting I spent several days with a large corporate client where a large number of teams were being mobilised to develop a major, strategic implementation. They will have to learn new technologies and new methodologies at the same time as being asked to deliver mission critical functionality within a very tight schedule. These teams are in their early days, but there are early signs of the pain to come.
Both of these teams consider themselves to be agile. Neither of these teams consider themselves to be using behaviour driven development (BDD).
My corporate client is aiming to deliver a complex, monolithic application, and has a small number of product owners supported by a somewhat larger number of subject matter experts (SMEs). There is conceptually one backlog, but each team is having a subset of it pushed onto a team backlog from which they pull stories to be elaborated. There’s no clear division between each team’s role and hence each story may require the team to interact with different business stakeholders. Add to this the (all too common) geographical separation of the development team and some of the SMEs and you can see that bandwidth and availability are both going to be issues.
On the other hand, gov.uk managed to slice the application vertically. Each team had complete ownership of their part of the workload and had a single, dedicated, co-located product owner.
The corporate client is adopting agile methods for the first time. The developers have mainly migrated from older systems, and are just learning the languages, toolchain and practices. Despite the fact that everyone is learning, a compartmentalised competency model is already evolving causing further “resourcing” issues.
Each gov.uk team owned its own process. Many of the development team had significant experience in specific technical areas and agile development. Even so, one of the core hiring principles was that each team member should be willing to put their hand to any task.
At the corporate client, the product owners and SMEs pass the stories and acceptance criteria to the development team via an electronic ticketing system. Once entered into the system (without the benefit of any technical input) there is a reluctance to split or reframe the stories. Teams struggle with explicit dependencies on systems that have not yet been delivered and solution oriented requirements that tie stories to these systems.
The gov.uk teams have their dedicated product owner who discusses the stories with the team, and is on hand to assist with decomposition and prioritisation of sub-stories. Their dependencies were of a different nature – organisational rather than technical – trying to navigate their way through the quicksand of governmental budgeting and accreditation.
It would be fair to say that the behaviour of the gov.uk system is significantly simpler than that of the corporate’s, but there are lessons that can be drawn nonetheless:
- Start small and only scale once things are working well
- Minimise communication bottlenecks by giving each team ownership over a vertical slice
- Enable early and continuous collaboration between empowered non-technical and technical team members
- Don’t fix scope AND date if you want pace to remain sustainable
BDD is not about test automation. It’s not about tools. It’s not about Given/When/Then. It never has been.
I believe that BDD is about better communication between the technical and non-technical members of the team. And if that definition works for you, then I’m sure you’ll be able to say which of these two teams is driving their development from the behaviour requried by the customer.
In many ways the strap line of gov.uk should be applicable to all of our efforts in software development: “Simpler. Clearer. Faster”