The previous post was agile on it’s own. It was too big so had to split into smaller pieces.
Today we continue around the overal “cerimonies”.
Like all good stories, it always starts with planning. If you have a big list of wishlist items – which you’ve already agreed with your PO that they form part of the MVP. The first step is to have a backlog meeting.
Backlog meeting
Consider this as the house cleaning. You need to clean on a regular basis to ensure there’s no weird dust that went below the carpet. The backlog meeting aims to check what’s on the list, check what needs to be done in 1 or 2 sprints ahead and be sure all the depencies are understood. It aims to ensure you know what the team will be doing next and ensure by the time the new sprint starts you have enough stories “ready” to keep the team going and not loose momentum. Ideally the backlog meeting should happen mid sprint so there’s enough time to clear any dependencies and even for the team members to try to quantity how big the next stories will be and break them down further.
Sprint planning
This is where you look into what you’ve agreed to do and then ensure all the tasks are added so each team member knows what their priorities are. This is an opportunity to look into the work for that given sprint and measure criticality of stories between one and the other. Are there any high value quick wins (big points and low effort)? Then do those first. They will bost the moralle of the troops. It’s about every day improving 1%.
Daily scrum
I wrote about it in the previous post and this is where the magic happens. The daily scrum should happen with or without the scrum master there (at least in my view), it’s about team members to align and discuss any dependencies or blockers among them which can then be raised to the scrum master. If there are multiple scrums / workstreams, then you might need a Scrum of Scrums, so any resource dependencies between workstreams can be discussed and overall priorities assessed.
I really love love love this episode. It explains it a lot better than I did 😀
Retrospective
I know in a lot of places this is about getting the metrics. And yes indeed they are quite important, but even more so it’s to get the team together and look into what went well, discuss if the sprint goal was achieved, what didn’t went so well and what’s the one improvement everyone commits to implement. It doesn’t matter how small it is. Could be as simple as no mettings without an agenda, or that an additional SME is needed for the next few scrums. Whatever the team agrees.
What agile is not
No, it’s not a means of cutting documentation or cutting corners. The shift changes from the PM telling people what to work on or spending a lifetime writing the perfect documentation – be it a requirements document or a design document – to start by doing. Applying marginal gains and moving one step forward and documenting. It’s about a continuous assessment of what’s working well and what’s not and allow the experts in the team to propose where things can improve. As the functionality / product is build so is the documentation (incrementally).
Agile is not about cutting planning, in fact it’s about a new way of planning. One that relies on working closely with the product owner and the team members.
It’s not unstructured. It’s structured diferently around smaller workstreams with a brand new framework.
For further reading check here
![](https://i0.wp.com/globalnerdy.com/wordpress/wp-content/uploads/2007/11/dilbert-agile_programming.gif)
What’s in it for me?
But aren’t you a convert already?
It doesn’t even matter if your team does any software development or not. It’s the whole mindset of breaking something bigger into smaller achievable pieces. It’s about having the priorities clear and cutting the crap. It’s about empowering the team to make decisions around the how to deliver something based on their expertise as well as to measure how big a piece of work is. It’s about understanding any dependencies upfront before commiting to something.
It changes the shift from spending months or years doing something that went presented back to the “requestors” – be it another team in the organisation or your clients – is miles away from what’s needed or you’ve spent so long in development the product / service is no longer relevant.
It’s about spending the minimum time possible from prototype to output and figure out (fast) if something could work or not. Put it up there, in front of a small user base to smash it to pieces and confirm it you are going in the right direction or you need to go back to the drawing board.
Don’t believe this can work for you and your team? Then try it and let me know!
For the agile manifesto check here
![](https://tobeblamed.wordpress.com/wp-content/uploads/2022/03/3ed12-0313mw508xs1dmcbu.jpeg)