1611824668049

SD Experts: Always on the hunt for improvement

Evolution has ensured that phenomena always adapt to being better. The blue whale’s nostrils were at first placed in the face center like human nostrils. As the centuries have gone by, the whale nostrils have moved further and further up towards the top. Just because it makes more sense, when being under water.  

There are many reasons that we should be evolutionary. In other words, we should improve continuously.  

In the software development branch of SkabelonDesign we always try to improve. It iingrained in our culture that we should reflect on how to do our tasks differently or better. We always try to improve our processesboth in planning and execution of specific tasks.  

My name is Sebastian Dybdahl Ehlers, Technology Innovation Manager at SkabelonDesign, and I have done my very best to take note of what it is, we do in terms of continuous improvementKeep on reading to learn much more about my discoveries. And also, find me on LinkedIn!

One for empowerment

Speaking of continuous improvement, I remember a recent task, where we were challenged and getting behind due to frequent changes to scope from our client. Some would have written this off as a troublesome client “incapable of making up their mind” … However, we chose to see this as a way for us to improve our ability to make sure that we can be even better at guiding and explaining the impact of scope changes to our clients. This ended up with us preparing even more standard material to send out to clients before starting on specific assignments.

This is just one example of the idea that when we take notice of a problem, we discuss it internally to get the best of it. Instead of repeating the same process without further consideration, we see it as an opportunity for making a change, do the process differently next time and doing better.

The outcome of these considerations can be processual changes, guiding material, or even product changes. Instead of adhering strictly to standards and fit the team to these definitions, we gather information from standards and experiences and then we implement them in the way they make sense.

We keep each other aware that this is one step in the right direction, but it’s not final. It’s about aiming for improvement, not finding a definitive solution. There is always one more step to find and take. Just like software is moving from big heavy monolithic systems to a constantly improving microservices, we keep doing small frequent improvements to our ways of working.

Our work methods are founded in the approach of PDCA (Plan-Do-Check-Act), which is about improving processes, products or services and always resolving problems. It involves testing possible solutions, assessing the results, and implementing the ones that have been shown to work.

Maybe it’s a culture thing?

In my team we listen to everyone, so that even the student assistant has the feeling that she or he can contribute to improvement. I have a mantra saying that new employees should always have a better experience than the people hired before them.

It’s about never being afraid saying it out loud, when something doesn’t make sense. Always ask questions about the process and be critical about why it should be done in one way instead of another. Beginning with: Does the subject matter even make sense?

It might sound harsh, but I have stopped being too polite. You should never tell anyone that what they’re discussing is interesting and exciting, if it isn’t. Don’t be afraid to be critical and ask questions. Soon you will realize that it will give you better results.

Generally, one should know what one is doing – and why. We don’t have endless time for doing things without purpose. Do what you are good at.

50/50 – happy team, happy client

We work in sprints, meaning that estimated stories are planned for a week, which eventually becomes the sprint once we get to that week. This way we can balance and plan internal features and custom client solutions in advance, side-by-side.

Normally one would plan a sprint with 100 percent capacity. But our time schedule is planned with only 50 percent capacity, while the last 50 percent is a buffer for ad hoc tasks (20 %), bug fixes (20 %) and spill over (10 %). What others would squeeze in to an unrealistic 2 weeks to execute, we would plan 4 weeks to do. This is for avoiding pushing the deadline, when meeting unforeseen difficulties.

If no priority items or issues appear, the client will receive our solution earlier than deadline. Other times we may use the buffer for learning new concepts and technologies to keep us up to date without requiring team members to spend their precious family-time preparing to work smarter.

There is no concrete plan for the buffered time, best case we provide features before they were promised – worst case we provide great response time to our clients. Win-win.

As both a software company and a consultancy company we need to provide great solutions and keep staying relevant. Sadly, one could say, we – opposite the blue whale – don’t have evolution to deal with this task. We gladly take the responsibility to ensure that our self-made evolution emerges within the team and lives on in every discussion we start.