Shewhart coined the term PDCA; plan, do, check and act which was modified by Deming to PDSA; plan, do, study and act.
Is PDCSA more appropriate in the present day world?. We plan things, do things as per the plan, check to see the status, and then study. That is exactly what happened in todays retrospective meeting I attended. We studied the burn down chart for potential learning opportunities.
Start it on time and finish it on time.
Each person gets 2 minutes to update the status of his work to the rest of the team (what did I do yesterday, what am I doing today anx what are the issues I am facing.
Do not convert it into an issue resolution meeting
Very often the team members will talk to the senior most person in the group. In that case deliberately cut the eye contact with that person so that she will be forced to have eye contact with the rest of the team.
For issue resolution have separate meetings.
In case you are clubbing the scrum with the issue resolution meeting, formally divide the meeting into two and at the same time ensure that the scrum follows its rules.
Please remember that going for a meeting late or skipping an agreed upon meeting are not positive indicators of mutual respect.
If somebody violates the meeting norms anyone in the team can highlight it so that the correction happens then and there itself.
Every one must stand up during the stand up meeting.
Switch off mobiles
When a persontalks listen
Meeting must not take more than twenty minutes.
Stand up in a circle.
Donot stand with the boss on one side and others on the other side. This creates a divide. Always stand in a circle.
Who will start the meeting?. The person standing on the right side or left side of the scrum master
Whenever someone requests help pls note it down.
Always have the scrum meeting near the tracking board.
Conclude the meeting by putting your hands together for the progress made. Celebrate even small achievements.
Sprint planning using fibanacci series and poker results in better discussions, resulting in better knowledge sharing and estimates. These discussions results in better team capabilities which is one of the greatest benefits of agile. Do not compromise on it.
I came across this situation of someone who is invited as a guest for the sprint planning meeting taking an higher interest in the architecture of the product, creating a conflict of interest between the development team and the guest. Yes, someone dominating a meeting due to his expert power can be a violation of scrum. If this is due to the huge technical deficit between him and the rest of the team, then it is good for the product in the longer run. Now, here is the question of process vs product. We are following a certain set of processes to build a great product, and we must be open to all ideas and suggestions, if it is adding value to the product. This situation, if not managed properly can spoil the team morale and the product. Scrum master is trying to sort it out by only talking to the development team by asking them to prevent the expert from dominating. Personally I feel that it would be better, if the scrum master could talk to the expert one to one and sort it out. Leveraging expertise without stifling teaming, innovation and knowledge sharing is a must for better teaming and a great product.
Past three days, I was with a team of 20+ software professionals from the Oracle financial services, Mumbai. The participation level was very good, as some of them have already experienced scrum within the organization. My sincere thanks to the team for making this training really interesting, and for the hospitality extended to me during the past three days. Wish good luck to all participants for their future projects and career.
I am just thinking aloud. One of my assignments calls for coaching a team on how to deliver better value to the customer using agile projects. If I am scheduling high value features / themes in the early iterations then the team will be delivering maximum value early in the project and it will taper down over a period of time. Do any one out there use a value burn down chart (sounds very negative and useful) during product, release planning?. Just curious to know.
I am not bad in starting things, and at the same time do not have the perseverance to make them grand success stories. So is the case with many organisations embarking on the scrum journey. They get into it enthusiastically and then looses interest over a period of time for no major reasons. They do not hate it, and at the same time they do not adore it any more. It’s like buying that new car. You talk about it, take care of it, are enthusiastic about it during the early days of possession and then familiarity broods boredom. Scrum implementations are not different from this. It is here the commitment and the will of the senior management can make a huge difference.
What is the point in sharing ideas in bits and pieces?. So I have charted out a simple roadmap for those implementing scrum, which will help them to be realistic and have sustainable scrum implementations. Please visit http://www.scrmmaturitymodel.org for the first draft. This is an output of my tryst with 27 teams, helping them to implement scrum. Your comments will help to streamline it further.