Posts

Showing posts from 2016

Tips to Scrum Master on removing impediments

One of the important duty of a Scrum Master is to remove impediments to the Development Team’s progress. This is correct and must be followed and here are some tips on doing this effectively During development sprint, team need clarity on the design from Architect who may not be co-located, this can become a potential impediment if clarification does not come on time from architect. In such cases, Scrum Master should advise the team member to draft the clarification with  his/her thoughts on tackling it rather than just looking for Architect's guidance. This will help Team member to evolve his thinking and at the same time this will help Architect the respond fast as he/she will have some ideas.       2.  During development sprint, testing member raises bugs/issues which they realize when they get the build to test from development. This can become a potential blocker to completion of the story as this has come late in the game. In such ...

User story writing issues, causes and tips

Issue - While the concept of User story is now quite old but still there are still cases where we see the stories are incomplete and not having enough details which would make team feel confident. Possible Cause of the Issue - Reason for such issue could be due to the culture change. With Agile culture, documents are converted into discussions and Product/business feel that details are not required for documented as this is already discussed in the team meeting. And this will remain in either emails or with some people with whom it was discussed.  Another reason is that it takes time to understand and clarify the requirements queries coming from team by the product/business who are not exactly the user rather some documenting people whose job is to write stories. Tips to handle such issues  - To handle issues with culture, I would advise to listen to team and collaborate with team. It is very much important to understand what team wants. Documenting details would ...

Root cause analysis for why so many meeting happens

One of the common issues that every organization is facing is too many meetings!! Is it good or bad, we can easily find out using a technique called 5 whys!! Lets take an example - In a typical scrum environment, after the sprint planning is over, team is again meeting to clarify some more doubts Why#1 - why are we meeting again to clarify requirement? response - because when team actually started working on the requirement they found more questions/gaps. Why#2 - why team did not come up with earlier during the sprint refinement/grooming meeting? Response - because team were busy with the last sprint activities hence did not go through the requirement gaps. Why#3 - Why Product owner could not realize these gaps earlier? Response - because PO was busy with the other priorities and could not focus on the requirement to analyze it thoroughly Why#4 - Why is Product owner is so busy when it is clearly defined role. Response - Because Product owner is handling too many proj...

10 critical tasks for a ScrumMaster

It has been always asked what is a typical day look like for Scrum Master and I would say it is not the same every day. Here's why: Lets say it is 2 weeks sprint then during the first day SM is busy facilitating the Sprint planning and ensuring the team members have committed the stories which they find it fully confident. 2nd day onwards, SM is talking to PO to ensure the for the coming backlog refinement/grooming meeting there is clear requirement defined with clear expectations. SM is lucky if he/she has knowledgeable PO who not only understands the Scrum but also understand why it is so important to have clear requirement defined. This can give SM to sit relaxed, however if this is not the case then SM's most of the time goes in coaching PO and impractical world it is dependent on the person who is playing the PO's role. lets say during backlog grooming meeting, we discussed some requirement which is understood and some which have gaps identified by team then ...

Prioritization, Who How Why...

Who needs to prioritize? In a typical project execution we have several roles who participate in making things happen. In a scrum framework we have Product owner, Scrum Master, development team  All these roles have a common goal which is to make project a success.But what does success mean is defined by customer and her needs/wants/desires.  Hence it is very much important for Product owner to first prioritize what will help her first. The same prioritization can be translated to Team and Scrum Master.  Hence the answer is Prioritization is for everyone however team can influence PO in making the right decision.  How to  prioritize? There is no magic formula for prioritization, though there are techniques like MOSCOW rule  but i have noticed for customer everything is MUST HAVE. This will not help customer as it would lead to a wrong product which may not help customer. Remember 80/20 rule, 80 perc of the user use 20per...

Advice and tips to the Product Owner

While Scrum Guide clearly mentions what Product Owner role is and what is expected. But in the real life projects, there are number of cases where Product owner role is not played as per the expectations. Why? There can be many reasons to it but the prominent is budget constraint to companies. Due to which PO is given at a time 3-4 projects to work on. While this may be working in some cases but in most cases this scenario never works and gives bad results. Ideally,  PO need to focus on a single product backlog by continuous conversations with stakeholders, Users and SMEs and translate the most clear defined requirement to team for development. But this never happens, PO gets the requirement and do not have time to analyze so the half cooked requirement is explained to team and more conversations are happening without any constructive results. here's what needs to be done to correct it: PO need to be sure of "what User wants vs What User Needs"  PO m...

Why some companies fail to implement scrum

These days Agile word is quite popular  and many companies are adopting the principles of Agile however there are companies who start well but soon find difficulty in implementing scrum. There can be many reasons to it 1) Top management feels that team is taking advantage of Scrum process and not delivering the business value which is expected. Team may be questioning a lot in terms of priority and clear product backlog. And for some top management everything is MUST and they feel that why cant team work on all the priority items and deliver the maximum productivity. 2) Another reason could be that Top management do not have enough resource (RIGHT people) to play the scrum roles hence they expect people to play multiple roles which in turn creates a lot of other issues which top management does not realize. 3) finally top management think they are losing control over team and they need to follow what team says. They can't direct team and push them to do what they want. W...

How to challenge the Agile team - tips for Scrum Master

I am often told by people who are senior to me to challenge the team and increase the productivity. After all we are in business and if we deliver more than we will in good shape. This s true to some extent as we are ultimately human beings and require some sort of push/motivation to continuously deliver more. I would address this in 2 different ways: A team that is self organized, disciplined,hard working and consistently performing then I would suggest to act as a friend and constantly ask this question " How can we improve" Let the response comes from them. It may be possible that team is doing their best however team may come up with certain areas of improvement. See as a Scrum Master if you can help them. A team which is in its initial stage and may not realize the areas of improvement on their own. In such cases I suggest to act as a coach and keep sharing the best practices with them. The little areas of improvement can change the team to the next level and b...

6 tips for Scrum Master to make Retrospection meeting effective

Comparing to other Scrum Meetings, Sprint retrospection meeting is sometimes considered boring by the Scrum Teams. Team do not find much value in participating in this meeting. What could be cause of such feelings. Sometimes this becomes repetitive and same issues/pointers are discussed. SM need to think over it. I advise the Scrum Master to follow the below mentioned pointers to make retrospective meeting effective: 1) This is a place for team to talk about the people, process, relationships and tools which are delicate matters as there are chances team members start pointing fingers to one another for the failure. SM master need to avoid such discussion to popup. Lets keep this meeting healthy. Note it down and discuss it later with the concerned member. 2) See all the team members are getting the opportunity to talk and share their thoughts on the sprint.  3) This meeting to thank to all the people who helped during sprint execution. There could be dependencies ...

Individual and interactions over process and tools

One of the Agile Manifesto principle says " Individual and interactions over process and tools " this needs to be practised on a daily basis to make it a habit. In a team, you can have team members of different behaviour, some talk less, some talk more and some try to hide their feelings. In such situations, it is the responsibility of Scrum Master to ensure team members are talking to each other and the conversations are happening. Scrum Master can do this by having casual, informal conversation and this would help team to collaborate often and this could minimize the issues. Encourage face to face conversation if possible. Another very important responsibility of Scrum master is to promote discussions which requires attention from other team members. Most of the project fails due to communication issues hence this principle must be taken very seriously and scrum master need to keep innovating the ways of handling this! How do you want to promote this principle...

Continuous learning in Scrum

While working in an Scrum projects, I have experienced that there is a need to have a continuous learning approach. In a complex project environment, we face issues/impediments on a daily basis which is quite possible if there are dependencies across many teams.In such case, though Scrum master and team need to continuously resolve issues but at the same time we need to pause and think on how can we prevent the issues to occur. If Scrum master coaches the team to become proactive then there are high chances we can reduce a lot of issues to occur. What is a proactive approach...an example would be team on the very first 2-3 days of sprint start, is able to start conversation around the dependencies and possible issues. Scrum Master need to encourage such thoughts so as to make the sprint smooth. additionally collaboration with product owner is required here so that a shared understanding is built. By practising this, everyone is continuously learning about the people,process and te...

Scrum is simple to understand but difficult to master

Why Scrum is easy to understand because: It does not talk anything new. We are still talking about software development lifecycle phases. We have clearly defined roles here with their responsibilities. Simple to understand ceremonies. Ceremonies have clear objectives defined.  but it is difficult to master because: Roles described do not follow as per the definition,  Ceremonies are happening but are not productive, not timeboxed. People still have difficulty in understanding the ceremonies within Scrum we follow mini waterfall Management do not value much on coaching and cultural change People do not understand that it is lightweight  so what must be done to master Scrum: Deploy the RIGHT people in the roles defined. Management should be committed to follow Scrum and they should get the coaching first.

Why all the focus on process over people or technology?

We all know it is people and technology which is accountable to deliver a software project successfully but how they deliver the project. How people get together and how they interact to ensure the project goal is understood by them and they are on track to deliver the same. Lets imagine there is no well established process and we need to deliver a project which is large sized and can be estimated to be 1 year or more involving 30-40 people. How is this achievable. Software projects are dynamic in nature and what customer is asking today may no longer be valid tomorrow then in such situation what is needed to ensure project is on track and will be delivered as per customer expectation. In the absence of any well established process, organization will have to rely on people for the project delivery. It requires a huge motivation in people to use technology and consistently work towards the  project goal to deliver on time on schedule and on budget. This can create communication...