New Agile Framework

I have been involved in agile software development for quite a few years now, and for the last couple in various process oriented roles. So, I was really excited when I was involved in defining a new agile methodology. The first thought was that why do we reinvent the wheel? Why not simply use Scrum, SAFe or something else? But, taken into account the environment (which I'll soon explain), it could be feasible to come up with a new one.

In this case we are not simply working in a product development organization. Many times the job sizes are so small that they don't require a full team. And by far not big enough to use Scaled Agile Framework. There are multiple smaller customers and work includes both development of new solutions and maintaining old systems. Very complex setup.

Dealing with multiple customers in different software development lifecycle stages is a very complex problem.

Some basic principles that were not to be negotiated:

• Teams. There needs to be some basic unit to share the work with.
• Autonomy & self-organization. The teams need to be able to organize their work. And the developers decide HOW things are built.
• Ownership. Teams need to own their results. This is why a large amount of craftsmanship is needed.
• Transparency. Everything should be open. In my experience transparency always improves quality.
• Backlog management. There should be one person who has authority over the job queue. The same person will represent the voice of the customer.
• Continuous Improvement. Teams need to examine their working methods regularly. Measurement enables feedback and thus learning.

In practice there are two types of teams. Some handle the larger customers. Mostly one team can serve a couple of bigger clients. This way they can have internal job rotation (which is refreshing) and still there's continuity in the customer relationship. And even if there's a slower period with some customer, the team can focus more on the other. The knowledge is kept alive and there's flexibility to answer variance in demand.

The team members will learn to know each other and work together. Increasing the level of trust will enable better working methods and slowly but steadily one plus one will become more than two. Restrospectives will help the team learn.

For the smaller customers and new gigs there's a special team. In a way the work with bigger customers is easier and you can have more junior colleagues learning the ropes from the seniors. But when there is a vast number of customers in maintenance mode, you can only cope with seasoned professionals. And you need to maintain a decent level in documentation. When the panic strikes, there's no time to start looking for instructions. You need to have clear plans and a solid map to navigate the environment.

All in all, although SAFe was developed for big and complex environments, I feel the problem with only one production and mostly one product is much easier to crack than the one I'm currently dealing with. And that's why it's so interesting!

SAFe deals with a relatively simple problem: one product.

One concrete challenge when you introduce something new is the unlearning of old ways. Many times people are biased, even if they don't perceive it themselves. And of course it's tempting to accuse the new framework about all surfaced problems. But recovery can only begin after admitting the facts.

By the way, I have written another blog post about this new framework in Elisa Hub (unfortunately only in Finnish). Feel free to check it out too.