Sales department has always handled winning projects for your Company saying that we follow “Agile Methodology”. The whole organization is full of ‘Follow Agile’ noise. But are we really Agile and do we follow it appropriately?
I started following Scrum methodology (as per my understanding!!) way back in 2004, in one of the Products maintenance projects. I am quite sure, no one was aware what Scrum was all about, apart from following daily standups religiously at that time. But, after I did my CSM training from Knowledgehut, I learned that I am missing a lot of stuff and I am also doing few tasks incorrectly, which might result in a project failure. So, to avoid this catastrophe, I needed to act on it. Below is the list of few activities that I did immediately after my CSM training.
1.Trained my Team, Management, Client & Vendor on Scrum:
Generally, when a new project arrives, management wants us to start with a kick-off meeting and commence coding immediately. As per team, the project is ALWAYS underestimated and we tend to start with activities like planning, coding, module/tasks division etc. as soon as possible.
When we have to follow Agile / Scrum, I realized how important it is to train the team, manage the clients and vendors. A team should be able to understand that they are now self-organizing and self-directing team and no one is going to assign tasks to them. The PM has to take up Servant leader role, rather than assigning work or controlling the team. The organization management MUST be aware that Being Agile does not ONLY mean deliveries in every 2 weeks. The client should be aware of the Product Owner’s responsibility and how important it is to be available for planning, reviewing and retrospective meetings. The vendors should be aware how Sprint and Scrum works, to track delivery from their end.
2. Scheduled Product Backlog Grooming Meeting and followed consistently:
Agile expects us to do just enough and JIT documentation, but Product Backlog is a very crucial document for the project and it has to be updated regularly by the Product Owner (PO). PO has to update Product Backlog based on the market requirements or importance of releases. Unlike BRD, this is the ONLY document that is used by the team for forming user stories, estimating, planning sprints & finally coding, testing and then releasing. If PO is not aware of how to go about it, the Scrum master can help. So, make sure that the BASE document is updated regularly.
3. Scrum Master (SM) is a Servant Leader and not a Manager anymore:
Myself being the PM for almost 10 years, it was difficult to get into servant leader role, but we have to wear servant leader’s hat. Rather than controlling or just delegating the work, I realized, now I have to WORK with the team and for the team. SM is helping the team to get out from bottlenecks, SM is keeping the team together, keeping them motivated throughout the project.
4. Regularly update THE BOARD:
There is a need to post daily standups, whereas we were too lazy to update the latest information on the whiteboard. The team has to update the board immediately after daily standup and the SM has to facilitate that. Post review or retrospectives, we started creating Burndown charts, latest review comments and some motivational notes. With this, I noticed an unbelievable change in the mindset of the team and management. It kept the environment light, motivated and the team started performing more.
5. Not conducting Retrospectives:
Before CSM training, I was just aware that there is a meeting that has to be done called as Retrospectives. With CSM training, I came to know how this meeting has to be conducted, when and who are the audience and what should be the agenda of the meeting. Now I understand, this meeting is MOST important for the team to improve the process, avoid mistakes that we did in past iterations. With Traditional Project management, we always have “Lessons Learned” during closure of the project. Have you ever read those lessons when starting the new project? Well, I never did. But with the Retrospective meeting, my team and I came into a habit of applying learning lessons immediately.
6. Elaborating as late as possible:
Sprint Planning meeting results in Sprint backlog and we elaborate only those items that are there in the current sprint. Other items in Product Backlog are not detailed enough to start with coding. This actually helped us save time and reduce requirement gathering time in initial stages of the project even when requirements are not clear enough. So, as project proceeds, we gather more information and this helps us in elaborating other requirements too.
7. Making Product Owner aware of responsibilities:
For me, the toughest job was to make my client aware of the POs responsibilities. We all know how important clients are for the companies. The customer is the KING of the world. Somehow, I convinced management that I need to make PO or BA from client site aware of the responsibilities. Client duty is just not to see how the product looks like and escalate things to management, but the client has to be aware of how you have to state your requirements correct, review the understanding and suggest rather than escalate things out. Clients escape saying they don’t have time for a review/demo, retrospectives etc., it is the duty of the Scrum Master to make them and management aware how important it is to be present for events. Else, in the end, it’s only the team who is blamed when the project is not a success.
I hope, these few insights or my lessons learned will help you in some way or the other. Hoping to see the “Agile world” soon where practices are followed religiously.