Changing how we work from waterfall to agile is all about envisioning the goals, focusing on success factors and then surviving the transit, said Torstein Skarra at TestCon Europe 2019. The Norwegian Labour and Welfare Administration (NAV) has moved from project-based waterfall and six releases per year to agile cross-function autonomous teams with several releases per day, per team. Skarra manages the Test Centre of Excellence at NAV which supported this agile transformation.
Skarra stated that "projects destroy agile". They are short-lived by nature, activity-focused, and the goal is more often to finish on time and on budget, than to maximize effort on value for the user/customer. Projects start to live their own life; they become self-aware and thus lose what should be the top priority for every bit of code delivered: bringing value to the user/customer.
As they bought code from development projects, testing at NAV was primarily acceptance testing, and that turned testing into "contract verification" as well. Skarra mentioned that testing in projects was more focused on measuring progress and activities, sometimes losing sight of real quality issues, like "are we building the right thing?"
NAV cancelled the fixed-price contracts and the parts where contractors were responsible for errors, and turned all contracts into "time and material". Contractors became part of the teams, were aligned with a product, and continuously improved on that product. The teams vary in composition, but most consist of product owner, designer, developer, team lead and sometimes a technical tester or a functional tester. This way there are no handovers between the business side and the developers, or the developers and OPS side, Skarra explained. The team handles everything, and most remaining handovers are micro-handovers within the team.
Skarra mentioned that to connect with the users of the systems, team members did all sorts of things, like actually visiting users and spending days with them. They installed feedback buttons directly on their applications. There is also indirect contact through monitoring essential functions, like the number of transactions that must be handled manually. "The most important effect was getting back to the basics: we are here for the user, and our purpose is to create value for them and the business," Skarra said.
Everything you do that does not directly add value to the user or your client is potentially something you should stop doing, Skarra argued. Living according to this becomes difficult as we add complexity to our daily life. Stuff like projects and hierarchical organizations, contracts, and systems architectures (that usually follow Conway’s Law) are all contributing to cluttering things, while being disguised as helpful constructs with only the best of intentions.
InfoQ interviewed Torstein Skarra after his talk at TestCon Europe 2019.
InfoQ: What was the situation at NAV before you decided to adopt agile?
Torstein Skarra: We believed that projects were good for software development, that the classic economy of scale was valid for software development projects. We also believed that you could plan and design complex stuff, and then build it with no risk of wasting millions on building the wrong thing. I think our notion of software was more an engine you install and run forever. We had our plan-build-run separation of departments, and thus created big and costly handovers with heavy loss of insight and lots of wasted time. All this created the need for heavy coordination, control and management; work that creates no value to the end customers.
InfoQ: You mention that "NAV is not an IT company" is a misconception. Can you elaborate?
Skarra: Most of our services and products were so specialized and of such strategic importance to our mission that they required custom-built software. There were no "pension system providers" out there suitable for the Norwegian laws. Thus, we bought projects, hired loads of excellent programmers, and bought custom-built software that we neither had the skills for nor the capacity to change or fix. Basically, we did not acknowledge the advantage of owning the skills and knowledge of our IT assets. And that’s ironic, as most of our systems are unique, and vital for our operations, and there we sat, thinking it was clever to have someone else own all that knowledge!
InfoQ: What made you decide to reduce the number of test environments, and how has this worked out?
Skarra: They are very costly to maintain, that’s one reason. Also, even though it appears necessary for all teams to own a dedicated environment shielded from other parts of the ongoing software development, what they do best is conceal messy development. In a world with few shared environments, to avoid being overloaded with complaints and having to carry out bug-fixing for adjacent teams for who you’ve messed things up, you are better served with dropping stable high-quality code. We see that this is actually true in practice for many teams, but we also see a lot of creativity and what they drop and where. In sum, we have no doubts that this was the right decision.
InfoQ: What did you do to increase trust?
Skarra: To increase trust between employees and contractors, we took away all fixed-priced elements and said that from now we were all equal team members. Trust between the business side and IT was a lesser problem on the "people level", while on department level it was more visible in terms of budget discussions, and the financing of projects and activities across departments. IT gained trust from the business side by delivering faster and cheaper.