Pages

Friday, November 28, 2014

Doing law and regulation development the Agile way

Writing laws
Recently I had a conversation with the Senior User of one of my Scrum projects, who also appeared to be a lawyer. We were talking about why my Scrum project was doing so well. I explained her why the agile way of working we used in our project, is one of the success factors. Her enthusiasm about the approach made her phrase the next question: Can we use this agile approach in development of new laws and regulations?

This is an interesting question. Though I don’t know anything about creating laws and regulation, I have tried to imagine what such project would look like when executed in an agile way.

Project Roles

In agile projects at least three roles are identified: the product owner, the development team and the agile coach.

  • The product owner is in charge of the scope and he will be prioritizing the product backlog. Though the minister or secretary of state is responsible for the law creation, a lower officer of the ministry can perform this role, as long as he has sufficient mandate and knowledge
  • As the agile coach is guiding the team on their agile road no matter what project, there would be no difference between an agile coach in a software development project and a law creation project. It is more important that the coach can teach the team than that he is familiar with the matter, i.c. the law process.
  • The development team is responsible for describing the new law. For that reason, it has to be populated with team members that know everything about creating a law, like legal officers and assistants.

Product backlog

The basis of every agile project is the product backlog, a prioritized features list. It contains short descriptions of all functionality desired in the product. For a new law this could be a list of all articles of that law with a short description of the purpose of the article.

At the project start the product owner should fill the product backlog with law articles and optionally special (exception) paragraphs. Per backlog item he describes the purpose. He also needs to prioritize these articles such that the articles with the most business value. By doing that he already has to think about the outline of the law which will certainly help him during the project.

Definition of Done

Both product Owner and development team need to know when backlog items are Done. This is described in the Definition of Done (DoD).

Where in software development it could contain sentences like ‘meets (performance) requirements’, ‘has been tested’, ‘has been installed in environment X’ and ‘has been documented), the rules in the DoD  for law are probably more like ‘contains at least 1 paragraph’, ‘lawyer X thinks it is very clear’ and ‘exceptions are described’. Of course, the new law needs to be approved by the parliament. Because the is approval activity is outside the scope op the development team, it may not be part of the DoD. The product owner however should be well informed about the amendments the parliament like the minister to be processed.

When the Definition of Done is clear, the team can start developing the law iteratively.

Iteration and regular activities

As in regular agile software development projects also law development projects should be executed in small iterations. I would suggest to keep them the same length, so 1 to 4 weeks. These iteration should start with a planning, end with a review and retrospective and have a daily stand up.

The iteration planning, retrospective and daily standup can be quite similar to software development projects. A more interesting question would be, what to show during the review. As most product backlog item intend to realize an new or adjusted article or paragraph of the law, their texts would be the thing to show and review. To me this seems quite boring. But when you find a way to involve the stakeholders, subject matter experts and product owner in this review vividly, these reviews might also work in a law creation project.

Benefits of this agile approach

As someone who isn’t familiar with law and regulations, I notice that judges often have to interpret laws, when they pronounce the verdict in court. If the law had been designed based on user stories or like wise, it would be more accurate to the judges. By developing in an agile way, it would also become much earlier clear to the development team that some parts are missing or multi interpretable. Eventually the created (or adjusted) law would get a higher quality and more suitable for a daily use.

So, I do think that laws can benefit from a agile development approach.

No comments:

Post a Comment