Introduction

This article is a brief study case of an agile development process implementation in a public sector. Co-authored with: Vanderlei Silva.

If you have an empirical process (one that is complex and/or not very well understood) we need to be prepared to fail fast but learn even faster. And in a public sector, of course, it is not an exception. See what UK government says about it.

People tend to see government as a deviation from the norm - in some cases it really is, but it is not a rule - and we believe that great part of the comprehension problems are related to that fact.

Public sector needs to answer fast to changes - although this is not what we’re used to - of laws, policies and external variables. They are constantly requiring efforts and decisions from the public managers. This happens more frequently in countries which are economically and politically unstable.

First, check over the agile principles. Having these aspects in mind, the great challenge of its implementation is the mindset change.

Paradigm shift

The first obstacle is comprehend that IT processes - and here we are focusing in software development - work better (in most cases) using agile frameworks such as Scrum, instead of Waterfall models. This fact demands from managers a conceptual shift of the whole process.

There is no point in planning the entire project at the beginning, considering that changes may occur - and they certainly will - and you can’t foresee the future, it will only make you spend precious time. It is better to deliver small but functional increments of your product more frequently instead. By doing that, you can fix detours and comprehension mistakes before they get too expensive or difficult to modify.

Need of control

Another aspect that needs to change is the false sensation of control that managers have nowadays. They think that by seeing a bunch of documentation artifacts they are in control of the project and protected against the several variables, including those human factors. If you are one of them I must tell you: no, you don’t.

Scrum suggests self-organizing teams which means that there’s no need to anyone controlling or monitoring the developers.

It may shock some managers, but in our experience it’s been proving a nice way to keep things going.

Implementation

Our first challenge to the scrum implementation was to structure the reduced team in a way which we could deal with legacy demands and new ones. At that time we had people associated with product development dealing with all kinds of requests, to coding from user support. This effort resulted in the following workflow:

So, we’ve separated the development team in 2 fronts: the “project” team and the “maintenance” one. The first is committed to the sprints and the second to keep the legacy running - here we’re talking about bugfixes and some small changes.

Ideally, teams will rotate their members after a specified period of time. We see this rotation as a great way to spread knowledge.

Adopted deviations

There are some practices that we consider to be far from the ideal scenario, but we’ve adopted as a way of transition from the current mindset to the agile one:

• We still have business analysts working together with product owner (the idea is that these business guys work as product owners in a future);
• We are still not able to keep teams exclusively to projects, so at the end of each sprint, the product owner evaluates the demands and may redirect this team to another project.

Feedback

In our first sprint review, our stakeholders were able to see the first release of the software and they did appreciate that, not only the software per se, but mainly the idea of having after two weeks (sprint adopted period) a new version of the system. Our clients, up to that moment, were used to deadlines measured in months.

Fallback

As a definition of done to the first sprint we considered every task posted on the development and testing environment and with TDD or BDD implemented, however we only developed tests for critical operations. Therefore, as a technical debt we need to improve our code coverage in the future.

First results

With the agile adoption, our team got more focused and deliverables more reliable. Stakeholders, product owner, and developers working together has created an unified vision of the product, which generated in everyone a clear vision of how great our efforts had been. Not mentioning the bureaucracy reduction made by decision decentralization.

Of course there is a lot of improvement to be done, but considering that Scrum endorses the concept of successive approximation we think that we’re on the right track, failing in some aspects but in all of them learning even faster.

Team members

Danilo Bezerra, Gabriel Olivério, Lucas Borges, Rafael Monteiro, Sandro Fonseca, Vanderlei Silva.

Acknowledgement

We’d like to thanks Knowledge21 and Rafael Sabbagh for training and support at the matter.

References:

Fail Fast Learn Faster - IBM blogs
Vets.gov: A Modern Software Development Environment in Government
Agile Manifesto
UK government