Agile ceremonies, how it's supposed to be
- Richard
- Feb 7, 2020
- 4 min read
In my last posts I've mentioned a few by name, and even gave my opinion on which ones are the most important. Now, let's dive in the specifics of each meeting together and I'll share some of my experiences with you as best practices.
Refinement. Contrary to how it's often taught, I don't like to do this every other week as a pre-planning meeting. Usually what they tell you is to have this meeting prior to the planning, to have in-depth discussions about the stories you're about to commit to. To make sure they're complete and to make sure they're clear to everybody that might touch it. Instead I'd like to refine before the project is sold. This might sound a bit strange at first, but hear me out.
A customer is in need of something extra, and you're just the company to help them out. So you're going in for the sale right? No. Before you sell you make sure you fully understand what the customer needs and how you can provide in this need and how much effort this will cost you. How else will you give your services a price? So you send in your business analyst (BA), the BA writes down all the requirements and the ideas on how to provide for them. The BA checks this with both your development team and your customer, if both sign off on it there's still two more steps to take before you give your price. Because the development team needs to give estimates on how much effort it will take them, and your product owner needs this information to tell you when there's room to work on this project with the customer. You can't make an honest deal with the customer without this information, and the customer will appreciate all the effort you put in this.
So before the sale, the refinement has been done, everybody knows how to provide in the needs, when to provide and the effort needed to provide. If it'll take some time before this project actually starts, it will be a good idea to sit down with everyone involved for a quick recap before the project kicks off.
More on how to write your requirements in my next blog.
Planning & Goals. The planning should be easy now right? You already know when to start the project, and you know how much effort it'll cost. Still you must take some time to sit down together and look at the planning. Is it still realistic, have new things developed which have impacted this planning? Maybe you have a head start because another project you did in the meanwhile already set the base for this one?
Another thing you need to do when planning is to set goals. Often called sprint goals. Since I want you to be agile every day, and not be stuck in a two week cycle, a good way to use these goals is to set milestones. Milestones on starting things, not ending things. So instead of having a new prototype ready next month, we're going to start working on the new prototype next week. In 2 weeks we'll start migrating the data and in 4 weeks we're going to work on the could haves.
Daily & Review. Every day you need to get together, not the development department, but everyone involved in the project. The developers, the customers, the project managers, the ux designers, the business analyst, everyone. It doesn't matter if you start your day like this, do it in the middle of the day or at the end of the day. As long as you do it. What often happens is that people take up a whole lot of time to tell their colleagues what they already know. They've been working on this issue, and there has been some progress, it's not done yet but they don't need help. Amazing. Now let everyone tell us that in way too many words and you'll have spent half an hour and still know nothing new.
Instead I want you to talk about the goals, are you still on schedule to reach them? Do you need help reaching them? What did you finish? Let the customer touch and feel it, get it's feedback. Discuss the possibilities for said feedback and make a plan for it. Also talk about what's left to do, is there an obvious order to doing it? Is it smart to have a particular someone do it. Do we need help from other departments? These are just examples of what paints a bigger picture, stop talking about what you're doing because we already know, but start talking about what needs to be done.
Retrospective. This is the odd one out. How much I want you to be agile every single minute, I can't have you retro every single minute or every day. The correct schedule for this would be every Friday. Because you don't want a weekend to have interfered with people's memories. You want people to talk about what happened while they're still in the flow. This is the moment you all come together, scrum master, product owner, business analyst, customer, developers, ux designers, project managers, who ever is involved in this project and you tell each other what went well and what could've gone better. Not about the project, not about the product, but about people's behaviour. Give a compliment to your coworker for stepping out of his comfort zone and making his first database, give some feedback to the customer that you felt hurt just because the way she talked to you. Get everything out, good and bad, and grow together.
Comments