I was a developer for 10 years before I changed career to become a project manager. Several factors contributed to that choice, but one pivotal moment was when I as a Software Architect participated in a cross organisational meeting with mostly middle managers and a senior manager. The senior manager had a problem that the company needed to solve and that he wanted one of his teams to pick up. I had technical insight into the product area that might be impacted but not much background in the business drivers and the organisation outside my unit.
Very little of what happened at that meeting was about exploring the options available, the consequences of these options, and deciding the best outcome for the company. It felt more like the middle managers were playing to avoid taking a home an impossible assignment for their teams. It was frustrating and I felt that I could contribute to better decision making and more informed choices by taking the role as a project manager.
Being a project manager, working across the line organisation, bridging silos and layers, speaking the local dialects, and knowing enough about what everyone is doing to ask the right questions, is challenging and rewarding. You parachute into a land of chaos and frustration, engage with people and systems, create order and momentum, and hand back the project to the line organisation. Then move on to the next challenge. Always working for the best outcome for the company and with respect for the people involved.
One of the companies that I’d love to join is DeLaval in Tumba. Not just because of the short commute (I still miss my daily bike commute from when I was living in Copenhagen), but also because of the challenge they are addressing: Optimizing dairy farming using IT.
Humans have kept cows for 5,000 years and dairy farming has been optimized quite a lot already.
DeLaval is one of a handful companies who produce and sell milking robots — or voluntary milking systems. I’ve seen these in action at different sites in Denmark — the milking process is fully automated, the robot places the suction cups and milks the cow while the cow chews away on some power grain. Key figures like milk temperature, time since last milking, and quantum milked per udder are shown on a nearby display.
Milking robots have been around long enough for the technology to mature. When you have 500 cows not being milked while your system is down, reliability and availability are not just about money but also animal welfare. Once the system is in production, it needs to be in operation 24/7. Cows don’t go on weekend or take time off for Christmas.
Dairy stables are hostile environments for computers, they need to be protected from moisture, heat, and being stepped on by animals weighing nearly a ton.
Robots have moving parts that needs maintenance. Hence, one challenge is to service the robots. So far this has involved a service technician visiting the farm and measuring the machines with handheld devices to help decide which parts to replace. As farms often are located in remote areas, having the right spare part at the right place and time is a problem to be optimized. Replacing a component too soon because you are not sure it will last until the next scheduled maintenance visit costs money. Having a wide selection of spare parts in the service car just in case they may be needed costs money. Scheduling an extra service trip to replace a broken part costs money – and a lot of money if it has to be done express due to a production stop.
Enter the cloud: What if diagnostic data from the milking robots is collected automatically 24/7 and uploaded into a database in the cloud? Service technicians and the farmer can then monitor and analyse the data remotely to plan service visits and be sure to have exactly the spare parts needed.
This is what DeLaval is working on right now. In itself a desirable goal. But the implications down the line can be huge as it allows changing the business model:
What if a farmer does not invest in a milking robot but buys milking as a service? The operational risk will be on the milking service provider, not the farmer. Financing dairy production will move from CAPEX (farmer investing in machines financed by a bank loan) to OPEX (farmer paying for a service). The farmer needs to know less about operating milking robots and can speciliase in other areas like breeding cows, optimizing fodder, stable facilities, product development or doing marketing events like kosläpp.
Just like the Cloud has lowered the threshold for new companies to put a new product or service on the market, the Cloud can disrupt the business models around dairy farming. The bank may become less of a gatekeeper for young farmers to enter the business. Independent service technicians will have fewer opportunities to improvise fixes to mechanical problems and upsell while they are visiting.
Times are changing and it would be cool to help create optimal outcomes for the involved stakeholders.
The cows will probably not notice though.
I have actually worked with dairy farming previously: Back in my university days, I had a part time job to optimize scientific calculations to run on super computers. One of the programs did breeding planning for dairy farms.
But how does a team make good and informed choices about how to do the work?
Besides hiring good people (1) and doing retrospectives (2), stealing copying from others is still a smart thing to do, especially if you know how it works and why.
As a project manager for software development projects, I start with a very basic toolbox and adapt tools and processes to the specific team, product and environment at hand. It’s good to have a large toolbox, but it’s knowing how and when to use the tools that makes the big difference.
Today I want to share my reflections on two common agile practices: Scrum and Kanban.
Scrum = Kanban + Sprints
How do you choose between Scrum and Kanban? Well, Scrum is a framework and Kanban is a tool you may say, so let’s frame the situation:
You have a team of specialists that is doing changes to a software system that adds value for customers over time. Doing changes requires a number of different tasks, like writing code, testing, and deploying changes to production. Changes are identified, prioritised, and delivered continously — or at least frequently.
When you do Kanban, you capture the changes to be done on a Kanban board as they are identified and prioritise them according to some rule into a single todo list or column. Team members then pull changes and progress them through multiple stages represented by columns until changes are released.
This is a simple and cool way to visualise and for the team to self-organise work to be done. However, Kanban in itself leaves a lot of blank space for the team to fill out: How do we prioritise changes? How do we coordinate work on related changes? How do we ensure that changes are completed and released, not just started and abandoned?
Scrum is like Kanban with sprints. A sprint is a timebox, the Scrum Guide says 2-4 weeks, these days 2 weeks is most commonly used. At the start of a sprint, the team plans the work to be done. At the end of a sprint, the team reviews what has been done. Scrum adds some roles and a few other events that all work together to make the team make smarter decisions faster.
So is Scrum then the Audi while Kanban is the VW? Wouldn’t you always pick Scrum if you can afford it? Not really. While Scrum has aged amazingly well, times have changed.
Back when the Scrum framework was invented, delivery time for a software solution could be years. The Agile Manifesto, written in 2001, includes the — at the time revolutionary — idea to deliver working software every couple of weeks.
When I joined SimCorp in 2000, one of the development tools available in customer systems was to edit source code and commit local changes to the production system (3). As the programming language for the business logic was interpreted, this could be done without recompiling or taking down the system. From a quality and risk perspective, it seemed insane, but in the context of what the company was back then, the ability to fix or provide workarounds for critical production issues during business hours, was a killer feature that helped the company to grow into what it is today. With great power comes great responsibility. Obviously, the tool required discipline like remembering to re-implement a corresponding change in the main trunk back home in the office. Version control had begun just a few years earlier, code review practices were established to help grow the development team from the original four to four hundred plus today.
As fast as possible but not too fast
With todays build and test automation tools with and production software hosted in a cloud, you get the ability to deliver changes fast with low risk.
If you are in an environment where the impact of failure is much lower than the value of a faster delivery, then a two week sprint is going to slow you down. You will be waiting for feedback from a code reviewer or tester, you will be waiting for the next daily scrum to flag blocking issues, you will be waiting for the next sprint to begin before working on a change. Waiting time is waste when you could be releasing it now.
However, if you find that boring but important tasks are stuck in the todo column, and difficult tasks are stuck in the “almost done” column, then bringing in practices from the Scrum framework can help.
(1) The advice “You need good people” is as true as it is useless. It is a silver bullet that seldomly helps you improve from where you are.
(2) Retrospectives is a good way to create process awareness in the team. While doing retrospectives can be fun, just remember that acting on the insight gained is what matters, not the retrospectives themselves.
(3) The utility was called PROGLOCWRT and no, I don’t know if it still exists today.
So I ended up on garden leave just before the summer after a series of management changes. No big drama, no panic. I got a fair deal and have time to find the next step in my career.
Joining Itiviti in Stockholm was a great if somewhat chaotic experience compared to SimCorp. Insight into sell side trading, working with smart people across the planet, and taking ownership of goals, process, and results in the post merger void.
So what is next? I’ve spent some time over the summer playing with my kids – and reflecting on what I want to do next. I’ve enjoyed leading development projects, bridging the gaps between business and technology, managers and specialists, vision and reality. Looking at the job market here in Stockholm, there is still something called project managers out there.
I’ve also enjoyed doing business intelligence, analysing and visualising performance in dashboards. This could lead to business process modelling or a role as Data Scientist. I enjoy coaching and training peers. So far I’ve stayed away from people management, but I’ve come to a point in my life, where I can also see myself picking up that (1).
Structured processes like Scrum and Kanban make a lot of sense to me, and I’ve done lots of agile processes with iterative planning, refinement and delivery. I use a personal kanban to juggle work-life priorities. So I could also pick up a scrum master or agile coach role.
So what is next? Time will tell. Short term it’s an opportunity to discover and learn about new topics – companies, technologies, tools. It’s what I have always enjoyed.
I will be sharing thoughts and reflections on this blog. You are welcome to join my journey. And do get in touch if you know of an opportunity.
(1) Being a parent does that to you: While I have preferred participating in groups on equal authority level, with kids that simply doesn’t fly. Sometimes you are right and they are wrong and the best way forward is not a Socratic dialogue. As a manager, you need to master multiple styles of leadership.