After years of experience working with, and training on Scrum/KANBAN, I do not doubt that Agile estimation techniques are better than classic, predictive estimation techniques. Still, daily basis involvement with Agile will leave many questions that kept nagging me over time. With such thoughts in mind, I feel it is important to socialize, meet and discuss with likely-minded people. Recently I have had an opportunity to join the ‘Agile – UK London’ meet-up. The meeting was nicely organized, the whole session was filled with brainstorming activities and I adored each moment spent. I am writing this blog to share my learnings from the Lean coffee meetup right from the way it is organized to some of the discussions which most of us face in our daily working life. The meeting discussion was based on the Lean Coffee format in a very casual relaxed environment at the Groucho Club, in London. As per the Lean Coffee format, we all had a clear agenda to discuss – Any question or thought that arise when we are working in the agile process. Folks assembled were covering every stream, to recall few were Project heads, Business Analyst, Scrum master, Test Manager, developer, and Team lead –from MOJ, Home Office, HMRC, HSBC Bank, DWP, and Telefonica O2 and many other companies (it helps to see diversified views).
A random group of 4 to 5 were made, and after a quick introduction (even if it included our main objective of joining this meeting) we were given post-it notes and a pen.
Everyone started to note down literally whatever they wants to discuss or to follow a theme. Every member gets two votes to decide which topic they also feel is interesting or is a good topic to discuss by putting a dot on that sticky note. In the end, we sorted it with the highest count as our first topic to discuss within a group and so on. To kick off the discussion the person who had written that note will explain their objective and what they are expecting out of the discussion and then everyone will start adding their thoughts to it. At the end of the discussion, we conclude and move on to the next topic to discuss.
Picking up a few of the topics, I would like to highlight some key points.
We don’t TRUST agile
To start- with all the build-up in the industry about Agile, and Scrum – it is no surprise that many companies hear or read about the benefits of these methods and think “we need this here”. And when Scrum is introduced in a company, most of the time, the team embraces it with lots of enthusiasm. But unfortunately, after a happy honeymoon period, some might think they are not as ready to make the mental shift required to embrace the agile way of doing things. Especially to accommodate the changes that keep happening in most of the sprints, sometime this eventually leads to a loss of trust in Agile. What one needs to understand is – in agile, we welcome change, we want the backlogs to change. Road maps are not set in stone, program road maps are meant to change. The team should be capable of releasing every (short) iteration that’s what makes the program effective and allows the program to change which in turn ensures the company releases a valuable product faster. By doing it in an Agile way we are enabling the end user to see some results at the end of every sprint which might not happen in other conventional methods. It makes me recall what Steve Job once said: “the users don’t necessarily know what they want until after they see it”.
To get fruitful results in Agile, what we need the most are – The Teams who commit to delivering features often, might not every time but most of the time- such teams are reliable. They don’t have to have predictable velocity, but they have to have predictable throughput. That means they might not realize how large features are, but they continually finish features and release them. The Management commits to managing the project portfolio so that work flows through the teams. The teams work on only one project at a time. This allows the team to swarm over a feature and push it through. And the Product owners who understand how to create a product roadmap and know how to create a product backlog for a team/teams to consume.
How to implement the feedback from Retrospective effectively?
The retrospective can be an opportunity for the whole team to look back and reflect on what they’ve done and how they’ve reached a certain point together. It is as important as planning. A meeting involving the whole team at the end of a cycle in an agile project or Sprint to identify any
improvements which can be made available in an upcoming sprint. It is also an opportunity for everyone to come and express their view. A simple way of carrying Retrospective is to get feedback for the below questions from every member of the team
- What went well?
- What went wrong?
- What did we miss in this sprint?
- What do we want to improve on, to make the next sprint better?
To conclude – Positive points from the above discussion are always good. They do motivate me for the coming sprint but what we might miss is implementing the rectification of what went wrong in the previous sprint or what can be made better in the next sprint. In such cases, there are two suggested options If
- only a few action items are there, then we must assign a person who will make sure these actions are met in the coming sprint or at least make it better than the previous sprint
- If there are multiple actions already seized with current sprint planning then prioritize the actions and try at least the top one is addressed them.
In the end, we have to understand that analysing a problem is not a solution. Implementing a course of action in a way to make it better is the solution.