Agile@NNIP

Within this organisation, we started a journey.

Adopting a way of working we call Agile.

We have been working this way for a while in small ways.

Now we would like to take it to the next level by integrating it into our organisational structure.

But what is Agile?

The Agile process begins with a User Story.

It goes something like this: “I (the user), wish to do (something)”.

Like, “I want to offer clients a bruto pension insurance policy connected with the existing net policy option.”

The User Story is taken up in the Product Backlog.

This is the queue of things we want to build, constantly re-arranged and prioritised.

The story comes with a Product Owner; in our case, generally, the Business, on behalf of the end-user.

Our system landscape is complex.

Too complex to manage in its entirety. So we break it down into smaller, stand-alone mini-systems we call “ecosystems”.

A small, closely-knit team is built around such an ecosystem.

This team is called a squad.

Squads are built to last, not just for a single project.

Squads own and execute change. They own the result of that change, the day-to-day, post-release run.

Each squad member has his or her own expertise - business, development, design, content, UX, testing, data.

The squad will take responsibility for the deliverable from concept to launch and is empowered to make deci-sions during the development process.

The squad meets at the start of every day for the morning standup.

The idea is to check in briefly to talk about what you accomplished yesterday.

What impediments stand in your way today.

This reduces the need for additional meetings.

Keeps the focus on the creative process.

A squad works alongside other squads, each working independently but sharing ideas, content and strategies.

Chapter groupings cut across squads. These are groups that share best practices, and that ensure that squads consistently meet our fiduciary duties towards our clients; testing, for example.

Squads and chapters work within a tribe.

The work is broken into small, manageable processes called sprints.

A sprint is a short period of time during which certain stories are completed, generally 20-30 days.

Stories are released when they are ready and fed into a continual moving Release Train.

If a certain story doesn’t make it on this release, it will make it onto the next one.