Join online with today’s leading executives at the Data Summit on March 9th. Register here.
This article is provided by Rollbar Developer Advocate Nick Hodges.
It’s been almost 20 years since the Agile Manifesto was released. While the manifesto itself is great, many of us have been misled into implementing it.
Let’s all be honest – how many of us really are To read Clever Manifesto? If you haven’t read it, read it now. I’ll wait.
Interesting, isn’t it?
Scrum seems to be by far the most popular way to “implement” agile development. There are scary quotes because I’m not sure Scrum can be considered really agile. In fact, in a way, Scrum may actually be the exact opposite of what Agile Manifesto is all about. And it’s time we all embraced that.
That’s a pretty bold suit. Here are three main reasons why this might be the case:
- Scrum creates incorrect deadlines.
- Scrum cannot and does not always distribute working software in a single sprint.
- Scrum ceremonies make busy work.
In Scrum you divide your work into “sprints”, usually a two-week piece of work where the developer agrees to complete a given effort (usually measured in hours or story points). At the end of each sprint, the developer is supposed to deliver functional software – which in principle can be delivered to the customer.
Well, not every project fits into a two-week sprint. What if the work is really three weeks long? It’s an enigma. Scrum tells you to divide the work into two parts: one which is two weeks long and the other which is one week long. Then, of course, you have to decide what to do with those extra weeks at the end of the second sprint as you also need to deliver the functional software at the end of that sprint!
Scrum creates all these timelines and lets you fit your project into it whether the project likes it or not. And in my experience, most projects don’t like it. Often, the project is a single entity – it either works or it doesn’t – and it’s not really possible to break it down into deliverable parts. And even if you break it into pieces, those pieces cannot be considered functional software for delivering to customers.
Does the software work in two weeks?
Delivery of functional software every two weeks makes a huge assumption – that task can be divided into deliverable, functional, two-week segments. Sorry, but we all know this is not the case. It just doesn’t work that way all the time. It’s like trying to fit a square peg into a round hole.
Sometimes a project takes up to three months to complete. That doesn’t mean creating the wrong deadline every two weeks for the project. It creates overhead and false sections of work that make things inefficient. An eight-week project is an eight-week project, not a 4 or 2-week project. Trying to make it is just a waste of time and effort.
Stand at the ceremony
Scrum suggests that you have a 15-minute daily stand-up, an hour of backlog grooming session, and an hour of sprint planning and pre-session. Then, many teams also do a one- or two-hour sprint demo at the end of each sprint.
If I have my math correct, I spend at least eight hours every two weeks in meetings – well, let’s be honest – not everything needs to happen. If those meetings go on – as they tend to do – it’s more than a whole working day every two weeks.
Backlog grooming sessions are usually spent trying to break up large projects into those two-week chunks. You take out a knife and try to cut that large piece of cheese into two weeks long, precise, even pieces. You get it done, but really, some of the parts are probably weirdly shaped.
Then, you organize those sprint planning meetings and take those weird parts and fit them into your sprint slot. Maybe he understands how things work – or maybe not. You also do a sprint preview to find out what could be better.
And then every day you get together and tell each other how it goes with the weird part.
At the end of those two weeks, you are supposed to have something that you can send to customers. But how often is that really true? I’m guessing it’s not often. Most of the time, you take the time to split a 10-week project into five artificial two-week slices, none of which are actually deliverable until it’s completed.
When you can’t be agile
There are some situations where a software development organization just can’t be agile.
The first is where there is a fixed deadline. If there is a deadline, you can almost certainly not make the adjustments that may be needed to complete the project. Changes to what you’re coding always mean a change in date. When you do a Sprint review with a customer, what happens if the customer asks for changes? You cannot return the entire sprint, reschedule, or even reschedule the contract. If you can’t accept the changing requirements, then you are not agile.
The second is when there is a fixed value. This works exactly as I described in the previous paragraph – if you are paid only a set amount to project, you cannot afford to redo parts of the work based on customer feedback. You will probably lose money on the project.
Bottom line: If you have a set deadline or a specific time, you can’t strictly follow the scrum, which is much less than clever principles.
It’s hard to call it crisp
In the end, it’s hard to call the scrum method crisp. It doesn’t usually deliver functional software as it says it should. It takes a lot of time for a time-consuming ceremony. It makes for a busy task because you try to split something that you don’t really want to split. It is a mystery to me how this system was conceived in the first place to fulfill the principles of the agile manifesto.
What will really work
Okay, so I’ve made some bold claims, but I’ve upheld them. So, here is a solution.
Your list of features will naturally fall into projects – projects that may vary in size and complexity. Embrace that. Acknowledge that the project is different, individual efforts. Then, do the following:
- Make your best estimate of how much work is in each project.
- On your schedule, prioritize projects according to estimates. You have to play a little “Schedule Tetris”, but it will be possible.
- Assign to the developer – or the developer, if you think it will work better – and give them an explanation.
- Set them on their way to developing the project.
- Harass them as little as possible, but keep an eye on what is happening. Do daily standups if you want, but keep them short and to the point – such as “Do you have any questions or problems?” And if the answer is “no” and the meeting is two minutes long, fine. (Also, do it at the meeting maker’s time.)
- When that means, check with the customer (whether it’s a product manager or a real live customer) to see how things are going. The mistake that can easily get your claim denied is to fail.
- Make adjustments as needed. Acknowledge that the results may take longer than you planned.
- Deliver it when the project is complete. (I’ll leave the discussion for next time about what “done” means …)
- Meet and talk about how the project went well and could have progressed better.
- Repeat this process – parallel to the serial and to the number of projects your team can handle.
At this point, I have to ask – which of the clever principles does this method Not at all Satisfied? I will not go with anyone. This system hits all principles and will deliver software when it is ready – not sooner, and not later.
I don’t know what the writers of Crisp Manifesto think of Scrum. I only know what worked and didn’t work for me, and Scrum never seems to make sense. The plan always made sense to me: figure out the project, project, and then use the project.
Note that I am not advocating a return to the waterfall system here – away from it. Checking in with the customer is an important part of the process. Adjusting on the fly is still an important part of the process.
I have proposed a way to do software development in a smart way. It is quite straightforward. Can it really be done? If so, under what circumstances is it best?
To answer these questions, I will make one more statement: Be Really Agility was not really possible unless one could perform continuous integration (CI) and continuous delivery (CD) through the SaaS solution.
Another bold statement, I know. But listen to me – this is pretty cool.
Crisp sauce model
A typical SaaS application is a web frontend with a backend API that serves JSON. Because the seller usually handles both sides of this equation, he can change it whenever he wants.
Or, in other words, the seller can constantly deliver new functionality to the customer, whether it’s daily (or hourly!) Bug fix updates or features delivered immediately after completion. Your code and your project are constantly improving. You no longer need to keep the completed work “in inventory”. Value is distributed as soon as it is created.
Therefore, as a result, the following is not only possible but is usually done with modern software architecture:
- The project is defined and assigned to the developer (or developers).
- Developer (s) completes the project using the above method.
- They merge their code into the main branch.
- The CI / CD system detects the merge, creates a new code, runs tests (which are passed), and then immediately uses the new code.
- Using feature flag, the code only appears to a few customers who have agreed to beta test the feature.
- The developer receives immediate feedback about the code from beta testers.
- If changes or adjustments are required, code changes can be rolled back, modified, and rearranged.
- Repeat steps six and seven as needed until everyone is satisfied.
- Removing the feature flag immediately adds new functionality to the entire user base.
It is actually enabled by the SaaS model, which makes the deployment simpler and easier for every customer. Instead of waiting for a huge clientele on each customer’s site, you can instantly deliver a new functionality to all customers at the push of a button.
Now That, My friends, be crisp.
Don’t follow a difficult plan or strict procedure
The crisp manifesto looked forward. Probably too much. And I believe it has been pulled away from its original moorings.
Clever Manifesto clearly states its base premises:
- Individuals and interactions on processes and tools.
- Working software on understanding documentation.
- Customer collaboration on contract negotiations.
- Respond to change by following the plan.
I feel bad for saying this, but it’s hard to see how he is satisfied with any of the four statements. The first and the last are particularly flexible, as there can be no “following the plan” other than sticking to the scrum whatever. And what is Scrum but a strict plan to follow?
The agile manifesto predicted what was to come and could really come true in the SaaS model. Maybe it was just 20 years too early.
Nick Hodges is a developer advocate at Rolbar. He is an experienced development technologist with over 30 years of leadership experience and a passion for leading, developing and mentoring various development teams.
Welcome to the VentureBeat community!
DataDecisionMakers is where experts, including tech people working on data, can share data-related insights and innovations.
If you would like to read about the latest ideas and latest information, best practices and the future of data and data tech, join us at DataDecisionMakers.
You might even consider contributing to your own article!
Read more from DataDecisionMakers