Dear Digia Agile Community – should I be worried?

In some rare occasions we might be left with a feeling that there is nothing left to be improved. Integration Developer Jani Hurskainen approached Digia Agile Community with a question: should I be worried?

Dear Digia Agile Community,

Over the last 2 years we have been able to optimize our working process so that personally I'm incredibly happy with it!

The tasks fluently flow in our Kanban board and are deployed to production fast enough for our business (planned production deployments 4 times a week and in practice 10-15 production deployments a week).

During the journey we have e.g.

• eliminated partially done work almost completely
• reduced all kind of waiting times and handovers significantly
• set WIP limit to 1 (and it is holding very well)
• implemented continuous integration/delivery from scratch (we are working on a crappy legacy platform with no out-of-the-box support)

Should I be worried?

And the Digia Agile Community answers:

Katja Luumi – Agile Coach

Glad to hear you are happy with the state of the affairs as being happy is not a bad thing at all! But what about rest of the team as they still come up with improvement ideas? People tend to see things from their own perspective so it might be that even if you think everything is fine, someone else might still think everything is a complete mess.

One idea to get new life for a retro is to change retro technique. Maybe you have been running the retro in the same way too long? I’d also like to double check that everyone can speak up during the retros.

Personally, I have not been able to get to the point when I feel like there is nothing to improve so I would be happy to learn about this situation more! It might be result of the work where people have been working for a long time together - or then not.

What comes to the topics outside of the team, that is something that should be escalated. I do not know how that is done in your project. Maybe you can hire an agile coach for the project to help you to resolve the escalation issues?

Johan Ericsson – Agile Coach

I don't think you need to be worried about achieving such impressive results. Maybe take a moment to reflect on what you did to get there (not everyone does) and take pride in your success. Writing blog posts or talking to others how you did it could also be worthwhile.

You could also think about how to prevent any regression into the bad old ways of working. Are your newly found ways of working disaster proof so you don't get tempted to cut corners even during a panic?

Then about next steps or raising the bar even further. There has probably been some development on the technologies used during the last 2 years. Could those be leveraged? Could you do some trials there? Are you using some open-source tools that need updating or do you have updates that could be pushed upstream? If not, could you use some open-source tools to mitigate risks?

You also said that your deployment pipe is "fast enough for your business", but could you make it even faster and more robust so that your business would get a competitive advantage?

Maybe get some potential threats that the business sees and mitigate those?

You could also leverage your success to get approval for training and such and then from that try to learn new ways of improving.

As said, I would not worry about having too much success. Try to enjoy it and share the success and use your experience to learn new things.

Henri Laine – Senior Agilist

Nope, you shouldn't worry. After having been through all that, it is completely okay to be momentarily out of ideas regarding the ways of working.

You said that other team members still come up with ideas on how to improve your situation. Do you think their ideas have merits? Do they typically have a point or are they just making up something? If their ideas still have value, then concentrate on those.

Now might still be a good time to enjoy the happiness (especially if it is shared). Hold an appreciative retro where you concentrate on how everything is awesome and what is especially awesome. Think how you got to this happy place.

After that see what can be done next.

If you are running out of ideas, ask is your software quality flawless? Honestly? If not, then how can you improve it?

What non-functional requirements / quality attributes that you are currently lacking would you like to add to it? How could you improve e.g., testability, maintainability, and understandability?

Are you putting enough effort into the maintenance of your system or is there a bomb festering somewhere out of sight? If you have doubts, the improvement could be to do code base inspection spikes so you would know.

Timo Korkeakoski – Systems Designer

Good to hear that evolution has been rapid and you feel proud of your work! Congrats!

Getting the workflow optimized and the technicalities fixed up so you can focus on actual work is a major cornerstone of agility – without technical ability you don’t have business capability. Developer's point of view often tends to focus on these topics. So I think you might be a senior developer who is running the agile rituals as a side focus.

Now that you have finally achieved the level of freedom, so you don’t need to focus on fixing the basic stuff, you can focus more on delivering something remarkable to the customer! This heavily relies on strong product/service vision and the long term plans. You take on a bigger picture and think about how you could achieve those things, as innovative as possible with the least amount of needed work while keeping the core idea intact.

What this means is, your day-to-day way of working probably doesn’t change much and you get the core requirements out with ease. But you have leftover effort what you can use to experiments, bounce ideas, PoCs, MVPs, reflect on what you are trying to actually achieve! Next I’ll give you one of my quarter dollars how you can train yourself and the team to the famous next level – empiricism and empirical research!

Empiricism is basically about only trusting your firsthand experience as data, and not take any other data as granted. When you think about new ideas, you usually have a "feeling" that it's a good idea or a worthless one. But who are we to say that some idea is bad until we've tested it? Some people are surprised they like pineapple in pizza!

Improvement happens often in unpredictable places, where our assumptions might have said otherwise. But for that improvement to happen, you must try them out. If we don’t systematically keep trying new things, we might miss some opportunities.

So you need to experiment, you force out the experimentation consciously, and use the lightweight process agile offers to systematically try out any ideas your team comes up with even if they seem silly!

This provides 2 different benefits:

1. You "force out" the evolutive cycle of the team to be on shorter intervals and give more opportunities to grow/improve. You basically pay a bit of time for accelerated evolution. With agile, we can do short and small trials (PoC, MVP, tryout) and consciously agree to spend a small allocation for those all the time. This keeps the cost of accelerated evolution small.
2. You are training yourself and your team to come up with new ideas constantly, and with time it becomes easier and more natural. After a while you start seeing things in a whole new perspective!

Summa summarum: you force trying out ideas to learn and gain experience. This keeps you competitive in the fast-paced market.

Sometimes this is doable from inside your "team bubble" but sometimes it is about the way of thinking growing out from the bubble and start touching the whole organization where the bubble works. That’s a whole different world than building CI/CD pipelines and just in time delivery!

Jussi Kirkkopelto – Agile Coach

I suggest you to check systems thinking -point of view.

Normally when I hear the team is fully optimized and high performing team – it appears to be optimized on the team level, but not for the whole organization. Sometimes the team is even in a black box and doesn't communicate with the other organization – ticket in, product out. "Bad" thing is that it can work internally just very well.