A long time ago, companies doing software used to use a process call waterfall that led to massive delays in the schedules, and important deviations in the expected results as well. Waterfall steps and processes assumed complete knowledge of the problem beforehand, and as this never was the case, many little deviations occur throughout the process and those little errors, as it happens with the propagation of errors in statistics, in turn, led to achieving something completely different to what it was intended. In such circumstances, the Agile movement started. In a nutshell, the idea is that you don’t really know what the problem or the solution is, so instead of assuming you do and fail, you made the size of the iteration smaller and then try to achieve the desired outcome as a set of small improvements. Each of those iterations is time-bound, and from each of those iterations, you obtain something, knowledge or progress, that makes you closer to your goal. In a sense, the idea was quite similar to the kaizen philosophy.

Nowadays Agile has become the norm, almost nobody use waterfall anymore. The problem is that Agile is not as agile as one may expect as it has been stripped out of the core, the reason for existing in favour of a standard and in my opinion bland version of it. At some point terms like Scrum and Kanban started to appear and became the new way of doing things in software development. The problem I have with this is that with this, all the idea of being agile and flexible and find the right process and how to collaborate was completely wiped. Many companies are using Scrum by the book without stopping to figure out what they really need, and by doing so they are not taking all the advantage they should from being Agile. Scrum defines many ceremonies that all work for a certain purpose, but you might or might not need those. I think the reasoning behind and be flexible to adjust the actual team to the different needs and stages is many times more important than following the guidance closely.

Scrum defines different ceremonies:

• Daily scrum (often called daily standup)
• Sprint retrospective
• Scrum planning
• Estimation sessions
• Backlog refinement (or sometimes backlog grooming)
• Sprint review

Daily Scrum

This ceremony is about keeping people up to date and allowing people to ask for help if they need. It can be done on Slack or in person. This meeting is low-cost and helps to keep everybody in the loop. I’d say a version of this ceremony you probably need.

Sprint Retrospective

This ceremony is about continuous improvement. The only way to improve is to identify things that didn’t work and try to come up with concrete actions to fix them. The way I usually run this one is but putting some post-its in a whiteboard with the bad, the so-so, and the good. Usually, I spent most of the session going through the bad things (that go first) trying to get actions to fix those problems, then the so-so and we end up with the good ones giving a happy moment to the end.

Scrum Planning

I don’t normally run this ceremony. Scrum planning is great in conjunction with velocity tracking and estimations, however, I tend to lean over to Kanban instead on this matter. This ceremony is where the PM and the rest of the team decide what they are going to work in the next sprint. As I said I don’t normally do this ceremony instead the PM works directly with the developers and rest of the team on a less structured way.

Estimation Sessions

Again these sessions I don’t normally run. The goal of the ceremony is to have an estimation of the stories in the backlog. It should involve all the team and the PM. Having the stories estimated and having a good sense of your velocity as a team should help you manage the expectations from the stakeholders, the truth is that is a pretty expensive ceremony as the whole team has to be part of it, and I normally prefer to avoid it. Avoiding it puts a bit more pressure in the PM, but buys many hours for the developers, so I think it’s worth avoiding it.

Backlog Refinement

This ceremony is about addressing the mid, long term stories. The closer a story is to execution the more details it needs. Something we will be working on in a year time can be as simple as a simple paragraph with a high-level vision of what the feature or story means. The backlog refinement is where some developers good deep and understand all the technical implications of that feature and create a bunch of smaller stories with enough information to be estimated. The backlog refinement is pretty important as it links the roadmap with the backlog. You probably are going to need a version of this.

Sprint Review

This ceremony is about showing what we have done in the last sprint. It normally involves stakeholders so they can see progress and give input to the team. If you are doing product development and the product is sort of stable (maybe you are a scale-up or at a late stage of the development of a big project) you probably need a version of this ceremony. I normally like to involve in this showcasing the actual people that did the job or either people that tend to be a bit shyer.

Be flexible

The way a team works has a lot to do with the personality of the team members, therefore different teams will work better using different strategies, don’t be afraid of challenge the traditional scrum and follow a workflow that works for you and your team.

Also, the workflow can differ significantly depending on the stage of development you are in. It’s not the same thing be a solo developer working on a pre-seed startup, that be part of a scale-up, that be part of a big corporation. The workflow should be a live entity you are always willing to change in case your resources, or problem changes.