Agile continues

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

Sourced from: https://wiki.cantara.no/display/dev/About+failing+agile+projects

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

Sourced from here: https://sander-dur.medium.com/10-agile-memes-to-lighten-up-your-day-7f577ffbfe89

Let’s talk agile

Agile has been quite a buzzword for the last few years. Initially something you would link to a fancy fast moving startup, but now it’s all around you. Well if it isn’t it should!

Typically agile is linked as a new way of project management especially in the area of software development but I would say it’s way more agile than that (yap I wrote that).

It’s not just about delivering a piece of software but it’s a whole new mindset in which any team, and I mean any team can operate.

Let’s start with some definitions – and again this is just my own simplified view.

The team

Size matters

In this case, a smaller size is the best. An agile team should be composed ideally by 3 to 9 team members, if it’s bigger than that then it should be subdivided in smaller groups with a “scrum of scrums” to check for any conflicts and dependencies between them.

Product owner

Ideally there should be a product owner per scrum to avoid clashes of opinion across them, or even worse, no product owner. If there’s no product owner I would advise to stop there and don’t even bother to start. It can only lead to doom. Yap. The role of the product owner is to define their wish list and articulate it in a way the team understands. Then they also need to drive criticality: What’s more important for them? What’s nice to have and could be done later?

Scrum Master

See this role as a kind of a PM whose main focus is to resolve dependencies, either internal or external to the scrum. Also it should drive the sprint ceremonies (I’ll get to them shortly). I also see the role of the scrum master as an internal coach who raised the right question to both the PO (aka product owner) and team members. Where a lot of people struggle with agile is that it’s no longer the role of the “PM” to tell people what to do and how long it takes.

Team members

It’s the role of the team members to define their tasks – how to deliver what the product owner. This is very important as it’s with the feedback of the team members that a “story” can be defined or even broken down into smaller pieces if it’s too big to achieve in the space of say 2 weeks. It’s also the role of the team members to raise any dependencies that a particular delivery requires before it can be completed. If it’s blocked there’s no point in starting until the dependency has been cleared. It puts team members on the spot (but I would say in a good way) as they own their tasks.

What are we doing?

The PO has a big wishlist, it’s the role of PO, Team members and scrum master to get together and define what are the really critical functionality and which features are nice to have. The concept of what’s critical forms the Minimum Viable Product (MVP). Everyone needs to understand the “what is” in the team.

How do we get there?

Now that we know this big thing that needs to be achieved, how do we get there? Well, chop it into pieces. Agile is about breaking down smaller and smaller so it seems you have something that you individually can achieve and contribute on any given day. That is encouraging!

First we divide into “features”, big functionality pieces that are to be delivered. From features then we move into stories. A story needs to be achieved in a sprint (whatever that sprint is, 2 or 3 weeks). A lot of people struggle with the concept of “story” because they get stuck into the features. I have described this before as building a house. The house is your MVP. Things like the garden or the shed can be seen as nice to haves (for most people at least). Once you have the first MVP completed you can tackle those. Then you can think of each division of the house a “feature”. It’s the builder that can then articulate how you build the foundation of the house and then each division. A story in this context could be: prepare the land – to start building. This is a dependency that needs to be cleared before anything else can start. Then you can get the baseline building, then you can get multiple stories in parallel for the building of each room. Then another story to add the plumbing and electricals and so on.

Each user story needs to have a tangible output at the end of it. Let’s take building the kitchen as an example. Even to add all the internal walls and baseline foundations for the kitchen will take a few days, so this is where the tasks come into play. Every day the team must know what they are doing. The team members, using their expertise must break that output which is the foundation for the kitchen and define the tasks for each day. Ideally a task should be between 1h to 8h, if it’s more than that then it needs to be broken down further. It needs to take into consideration the sequence of events from the start to the final outcome. Ultimately the story is considered “done” when the PO has seen a demo – in this case goes and checks if the sizing is as expected, if there’s space for the windows as per spec and so on. If all is good, the PO will say great job and the team can move into the next story, which could be all about furniture and electricals.

Is the story ready to start?

This is where things fail miserably. Before a piece of work can start, it should be clear to all team members what it is that is to be achieved. If there’s any vagueness in the what, then I would suggest PO and team members to sit down and refine further. Let’s go back to the kitchen, so say the PO only said that he wanted a kitchen. It will be subject to the interpretation of the team members. The kitchen could end up being tiny or not have enough light. It might be that there’s even a user story to define what are the requirements for the kitchen with a series of drawings on paper until everyone understands what’s the ask.

Managing progress – meet the daily scrum

This is where I see agile being applied to anything and any team really. As opposed to having team meetings without a clear purpose, the scrum has one goal, measure the progress of the day in relation to the sprint goal. In each daily scrum, each team member will provide a brief of what was achieved the day before, what they are working on that specific day (e.g. referring to the tasks) and if there are any blockers / impediments they found which the scrum master will need to resolve. It cuts the crap in essence and retains the focus on what’s really important. I have seen “business as usual” teams applying this to their day to day work and it works! If you have access to some agile tools then even better. (I can probably write a post on tools another day).

The beauty of agile

I seriously feel like tattooing this mantra

Fail fast, learn faster

This is what agile is ultimately about. As you try to have an output as part of each sprint and get the product owner to work with the team directly to measure how close we are (or not) to the ultimate goal (the MVP), the team will have the chance to learn what went wrong and change tactics. I will write another post about the scrum ceremonies as a lot can be said in this space.