What can agile do for you?
After years of experience working with, training on Scrum/KANBAN, I have no 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 ‘Agile Women – 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 Lean coffee meet-up right from the way it is organized to some of our discussions which most of us face in our daily working life.
Meeting discussion was based on the Lean Coffee format in a very casual relaxed environment at the Groucho Club, London. As per 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. Womenfolk’s assembled were covering every stream, to recall few were Project head, Business Analyst, Scrum master, Test Manager, developer, Team lead –from MOJ, Home Office, HMRC, HSBC Bank, DWP, and Telefonica O2 and many other companies (it really helps to see diversified views). A random group of 4 to 5 were made, after a quick introduction (even 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 one wants to discuss or to follow a theme. Every member gets two votes to decide which topic they also feel interesting or is a good topic to discuss by putting a dot on that sticky note. At 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 a 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 onto next topic to discuss.
Picking up 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, 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 lead to 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 to release a valuable product faster. By doing it 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 of Agile, what we need the most are – The Teams who commit to delivering features often, might not be 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 who 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. Simple way of carrying Retrospective is to get feedback for below questions from every member of team
- What went well?
- What wrong?
- What did we miss in this sprint?
- What do I want to improve on, to make next sprint better?
To conclude – Positive points from above discussion are always good. They really do motivate for coming sprint but what we might miss is to implement the rectification of what went wrong in the previous sprint or what can be made better in next sprint. In such cases, there are two suggested options
- If only few action items are there, then it is important that we assign it a person who will make sure this actions is met in coming sprint or at least to make it better than previous sprint
- If there are multiple actions and already seized with current sprint planning then prioritize the actions and try at least the top one is addressed.
In the end, we have to understand that analysing problem is not a solution. Implementing a course of actions in a way to make it better is the solution