Agile is mainstream. This is good and bad. In 2018, Martin Fowler criticised the "Agile Industrial Complex" for imposing methods on people and violating the first value in the Agile Manifesto. What fake agile is getting wrong is that "the team doing work decides how to do it."
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 teams commonly do two-week sprints. At the start of a sprint, the team plans the work to be done. At the end of a sprint, the team reviews what was done. Scrum adds some roles and a few other events that all work together to make the team make smarter decisions faster.
Times have changed
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 no faster
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.
Hi Frederik, it is interesting to read your thoughts about Scrum and Kanban practices. I have recently joined a new implementation project as part of a consultancy company team. The Client decided to do Implementation using Agile methodologies. For the software provider it will be the first experience to do implementation in Agile and they are not happy about this. They need to change the horizontal functional approach of configuration to the slicing approach of configuration. We (Client, the consultancy company and the software provider) have just started our first Sprint. The first challenge is the Client’s decision to have two-weeks term for Sprint. They have not realized yet, that for such complex software as this, two weeks is too short term, as promotion of configuration changes from DEV env to TEST env is mostly manual process, which takes time, especially if it will take place in different Time Zone. But will see how the project will go. It is interesting to me to see the final outcome 🙂
Hi Nadiya,
Thanks for reading and thanks for commenting. I edited your comment to leave out the names of the companies involved.
It sounds like the project violates exactly the agile manifesto principle that Martin Fowler is talking about. What are the reasons for the client to want to use agile methods?
Implementation projects is an interesting case. The traditional approach would be a phased go-live, sliced by business area and workflow. This would be the smallest delivery that adds value for the customer, it doesn’t make sense to implement only parts of a workflow in the production system. Next, the driver for having a test system in the first place, is to verify the workflow both from a functional point of view but also to ensure the transactions and audit trail created are correct. Troubleshooting and rolling back data in a production system is super complex and expensive.
Note that the Scrum framework does not say that you should release to production at the end of every sprint – only that you should be able to if so desired. If the cost of releasing (replicating configuration in the test system manually in the production system) is high, this should drive you to release less frequent and/or to improve the tools and processes to reduce the cost.
My guess is that even if you set up two week sprints and aim to release the changes completed in the sprint to production at the end of every sprint, the value created in a single sprint will rarely be enough for users to actually take the functionality into use. So over time you will end up releasing to production every 4-6 sprints.
Any project has constraints, some you can challenge, but in the end you and the team will have to find a way for the project to succeed.
Best regards,
Frederik