Conversation: How Agical Makes Agile Work

Note: This article is available in Swedish at the Agical Blog.

Very recently, I visited Agical, a software company in Stockholm that has used agile software development for many years, and has been very successful at it. I've visited before, but it's been more than ten years, so it was time to reconnect.

Agile has become very popular, but it has also led to a dilution of the agile ideas in many workplaces. Ola Ellnestam, CEO at Agical, and I decided to write an article together and show how agile works at Agical.

At the end of the article, Ola has advice for both management and developers who want to be agile.

Henrik:

It was fun meeting the whole team at Agical last week. It is noticeable that the software development is at full speed. Before we talk about that, I thought I'd ask about the background. When did you start Agical, and how did you work in the beginning?

Ola:

Agical was started in the spring of 2005. A bit like a backlash to how work was done in the industry at the time. It was very common with projects. Almost all IT systems were developed by one part of the organization, while another part handled operation and maintenance.

We wanted to change that.

In the beginning, we often worked on our customers' terms. Project, requirement specification, and line organization. But we knew that it was possible to work differently, we had done that in individual cases. We wanted to put a different stamp on the work. It would be agile. Almost two decades have passed so it is worth remembering that it was at a time when we had to explain what we meant. Week after week, month after month. For everything and everyone.

Agile was new, fresh and above all rebellious.

Henrik:

What kind of agile method did you come into contact with first? What was it about him that made the job easier? I noticed when I visited you that you have fun while you work. Did agile working methods contribute to that?

Ola:

Extreme Programming (XP) was the first method that we came into contact with. Then came Scrum and a dose of Lean Software Development. The journey was a little different for all of us, but one thing was common even then. We wanted to have fun. It should be fun and rewarding to work with system development.

Henrik:

The method you are using now is your own. Can you tell us a bit about how it has evolved, and both similarities and differences compared to other agile methods?

Ola:

The way we work today is strongly colored by XP's values ​​and the ideas behind Lean Software Development. Simplicity, communication and short lead times are extremely central to us.

We sit together and work together. We own the code together and further develop it together.

All this in the same place. At the same time. It is easy.

We have rationalized awayXP's "Planning Game" and Scrum's "Sprint Planning". We negotiate daily about our focus area. Our joking motto is: Deliver new requests before users have time to change their minds. It works well. Also, since we deliver code three times a day, we can change direction at any time. It is appreciated by the users of the system.

This is our interpretation of short lead times from Lean thinking.

Henrik:

Many teams struggle to deliver once a month, or once a quarter. How do you deliver three times a day? And how do you keep the quality of the code high enough?

Ola:

It started with us acquiring a very simple way to be able to return to a working version of the system. We have a way where with a few simple commands we can restore the system to normal operation. When something goes wrong. We call it our “revert” strategy.

With the undo strategy in place, we then took the next step: Partial deliveries.

We challenged ourselves to break up functions. In close dialogue with the business, we were able to reduce the scope of the desired functions, and deliver earlier. Or deliver a replacement alongside the older way of doing something. We use technologies that facilitate ongoing deployments. Eg Dark Launches, Keystone and Circuit Breaker.

When we were comfortable with these techniques, we dared to move from development in feature branches to short-lived Git branches. After that we also dumped the short-lived branches and now devote ourselves to Trunk Based Development.

We keep the code in check with the help of tests, static typing and programming in groups or pairs.

Henrik:

When I was visiting you, you mentioned that refactoring is important to you. Can you tell us a little bit about it?

Ola:

Refactoring is a fundamental tool in our group. It is so important and highly regarded that we equate it with the skill of a craftsman, the skills of an artist or perhaps the technique of a skating princess.

We use refactoring all the time to be able to reshape the code base as needed. Hundreds, if not thousands, of refactorings flow from our fingers daily. Rename method, nest, expose, move, rearrange and so on. All this in the name of readability and understanding.

For computers, it doesn't matter what the code looks like, as long as it compiles. For us humans, on the other hand, readability and understanding are of utmost importance. We must understand what and why the code looks the way it does, otherwise we dare not take responsibility for it. Let alone change it.

Because we are so strong at refactoring, we can use our close relationship with the business in a good way.

It is easy for us to translate new needs and new information immediately. That is possible only because we can reshape code quickly. That, and deploying often.

Henrik:

There are many companies that struggle with making software development work. They often use Scrum. If they have larger projects, they have SAFe as an overall framework for coordinating multiple teams. Do you have any advice for managers who want to build a well-functioning development organization?

Ola:

It's easy to get sidetracked, larger projects require a larger number of people. We immediately think: "If we are to build a pyramid, we need thousands of workers" or "If we are to program a huge computer program, we need hundreds of developers".

Ironically, it is our own will to succeed that causes us to lay traps for ourselves. We want to succeed quickly. We throw people on board. Which just slows us down.

If we are going to do great deeds, which I personally think is a trap in itself. But IF we are going to do it, we should take it easy and let it grow over a longer period of time.

We need to calm down and scale the length, instead of the width. Take our time and say "No" to ten thousand things. Instead of saying yes to ten.

In other words; resist the temptation to make the organization bigger. Help each other keep the organization small and encourage each other to be patient.

Small is beautiful.

Henrik:

That matches my experiences. I often see projects with 4-5 times more people than are really needed. The reason is that you more or less automatically bring in more people, instead of trying to understand what kind of problem you have. I also see organizations bringing in more people without regard to whether the software architecture allows many people to work effectively together.

What can individual developers, and development teams, do on their own to solve problems with poor software development?

Ola:

I evaluate organizations that develop software according to four metrics:

  • The time it takes to deliver a change
  • The number of deliveries per day
  • The rate of incorrect deliveries
  • Average time to restore incorrect delivery

If we look closely, it is about the size and quality of the flow.

If you want the work to flow better around you and your team, you must get better at focusing on the right thing. In turn, this means you should be able to drop what you're doing if something more important comes up.

A simple recipe for that is

  • Break what you do into smaller pieces
  • Deliver continuously
  • Deliver all the way
  • Do fewer things

We have touched on techniques for this before, but I will summarize here

Learn:

  • Understand the business value
  • Refactor
  • Listen to each other
  • Speak clearly

Henrik:

Thanks Ola! Good advice, both for management and developers.

It was fun to join and see how you work. At least as full speed as when I met you last time, ten years ago, and you can see that you are having fun.

I hope we see each other again soon.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more