Effective Scrum Meeting

What is the purpose of a meeting? The simple answer is making a decision, to come to a point. In Scrum, meeting is the part of life. You have daily scrum meeting, 1 on 1 meeting, retrospective, sprint planning meeting, user story presentation meeting, demo presentation meeting and unlisted many more when necessary. Doing effective meeting is very important for doing right things. PO has a vision that describe as a requirement in some PBL or user story. S/he describes his vision in a meeting so that it convey to the team. Daily scrum synchronize everybody's work and let the team know the status of individuals. Therefore, the meeting should be effective for an efficient and better job get done.

    Synchronization: Synchronization is very important for daily scrum. Right after the scrum, team lead should synchronize everybody's work. S/he also should find out the dependency among team members. Team lead should find out the issues and should take proper actions. This can be also scrum masters job but not always scrum master can find out issues, scrum master will dig into the impediments.

    Agenda: Besides daily scrum, there should be an agenda of all kind of meeting. The respective person who is calling the meeting should fix the agenda prior to the meeting.

    Tracking: There needs to keep a track that the meeting is going on the right direction. Sometimes in a meeting some different topics come in and a long discussion spent on that topic. The meeting manager (the person who called for the meeting) will notify everybody if meeting goes on the wrong direction.

    Summarize: In every end of a meeting there should be a summary which will be agreed among all parties who is attending on the meeting. The minute writer will responsible to write down the summary with the "Action Plan".

    Time: Time is less important factor for meeting. But I believe the morning meeting is more effective than afternoon meeting. In morning the mind stays fresh and cool, on the other hand at afternoon people get exhausted and they may not keep proper concentration.

    Length: The length of meeting can be an important. Typically, people can't keep concentrate for a long time. Very long time meeting can be very inefficient.

Implement “PIN” to meet your project deadline

I don't have a vast experience on project management, although I have spent almost 4 years in different scrum environment. I told in such way because there is no such role as "Project manager" in scrum. I can rather say project manager and PO is the same person. Our company implements this in some other way. Here, there have both PO and PM. The PM acts as a Team Lead. I've a very tiny experience as a Team Lead (Project manager) into our organization. So I need to run a team and meet projects deadline. From my tiny thoughts I can say that implementing PIN can avoid missing deadline. PIN stands for PLANNING, IDENTIFYING, NOTIFYING.

    Planning: Plan is the most important factor of meeting deadline. You need to plan for development, plan for testing, plan for code review/code refactor and plan to handle the risks. Without proper planning the entire project may fails. So, how do I plan better? First time the answer is so easy….. plan with your team members. Better planning will come from experience. You will learn from 1 on 1. You will learn from retrospective. You can do better planning by being pro-active.

    Identifying: You need to identify different factors and may create a matrix of timeline of the deadline. You can identify by seeing burndown chart. What needs to identify? Identify the impediments, identify the risk if it is turning to the crisis. You need to be intelligent enough to identify all these factors.

    Notifying: Notify to the team members, notify to scrum master or notify to the upper management if you see any problem happened. Raise the flag if you see the risk is becoming crisis.

    There may have some other factor involved to meeting deadline. There is no math/logic to solve any deadline equation.

Regretful practices of Scrum (Part 1)

Scrum is a framework where you can develop/manage your projects. In a typical framework, you can add, remove, modify different components to make is proper workable for you. So you can modify scrum concepts and can make is properly workable for you. There is nothing called "pure scrum". You need to find out a balance point between your needs and scrum which will be the best solution to accomplished/successfully drive your projects.

As an example, scrum don't have pair programming concept, XP has this one. But for the quality of code or for the training of Jr. Developers you can introduce pair programming model into your scrum-oriented organization. There must have an adjustable point on which you can drive your software projects.

So, how can I say "Violation of Scrum"? Does scrum really violates? Well, my answer is "obviously NO". But, sometimes peoples start doing valueless practices. From my little experience I tried to find out some pin points that should not apply in a scrum-oriented organization.

Micro-management: Micro-management is a habit of prior Waterfall-oriented managers. They like to come into the person and talk to the person level. Obviously there were teams. But team was less valued. In a scrum team, I have seen micro-management makes the environment misery. The team lead even didn't know what is going with the individual team members!!! Well, you can tell that they were not using scrum……. Exactly! But they were following pure scrum even there have certified ScrumMaster, Scrum Practitioners. Yes obviously everybody should be responsible but it should be at the team level. Team will decide who is performing well, who is not. Team lead will contact to the management as he is only the contact point with the management/PO.

Effectiveness of ScrumMaster: What is the role of a scrum master? As we know scrum master is the facilitator of a scrum team. S/he will be responsible for removing the impediments so that the team can perform well. Sometimes people tried to find out the effectiveness of a scrum master from their extra point of interest. They want to calculate using various matrix including Velocity, Quality in Production, Injection Rate, Health of Backlog, Ability to hold x% maintenance, Story completion rate etc. On the flip side, most, if not all, of these measures are not limited to the Scrum Master, but also the team. Some people think that the measurement can be

- Average time taken to resolve impediments

- Number of retrospective items auctioned

- Adherence to scrum guidelines

- Various scrum adoption survey results filled by the team

I think that this is again a situation of trying to measure the unmeasureable. I could start asking questions such as who measures that? When does the start time of resolving an impediment occur? When does the end time of resolving an impediment occur? And so on, but I'll go along with the spirit of the thing. It seems to me that the only ralistic way to measure such behavioral aspects is to ascertain the satisfaction level of the people whose activities are affected by the ScrumMasters' behavior. If people feel that the SM is resolving impediments promptly, and in a manner that is helpful, then they will indicate a high level of satisfaction.

Asking PO for the non business related issues: Suppose that the team needs programming training, or that the floors need cleaning. Are these things to be put into the Product Backlog and prioritized by the PO? Well, it may seem funny and you may ask me to use my common senseJ. Well, an interesting answer from Joseph Little is

"The Product Backlog has *all* the work the Team must do to complete the Product. If they really should have training, then in it goes. (If someone else will clean the floor, then that does not go in the PB.) Final decision-maker: The PO is only the final decision-maker. It was always true that for some things, that one real person often will not have all the info or expertise. The PO is supposed to understand that and get advice. And the Team is supposed to understand that and offer advice. STILL...ultimately it is a "business decision" where to invest the money (that pays for the Team). And that has to be balanced against all the other competing claims for that money." So asking PO about the priority of cleaning the floor is just a waste of time, as someone else the team will clean the floor.

Extending Sprint length frequently: Here's a scenario: It's late in the third week of a four-week sprint. It has been plugging along, making good progress against the user stories (new features and enhancements to a web product), and now the team focused on testing in the QA environment, and logging defects. A lot of defects! After a couple of days of testing, it is up over 100 -- more than we can probably fix before sprint's end.
What's the best thing to do at that point in terms of the Scrum process? Options that can think of include:
- extending the sprint to complete testing and fix all the critical bugs, then deploy
- completing the sprint without any deployment, rolling the bug fixes over to the next sprint, and continuing
- focusing our efforts on fixing a subset of the stories in order to deploy them, then roll the remaining stories over to the next sprint.

Well many people at the end try to extend the length of sprint. Extending the sprint creates a precedent that can be used again. Sprints should have fixed length. Completing the sprint without deployment is more like not completing the sprint. Let the team fail and help them have a healthy debate on the retrospective.

Scrum and Self-organized team

What is an organized team? Organized team is a team which is well driven by some Lead, manager. In a well organized team people only think to satisfy his/her manager by working on the task which is assigned on him/her. All the members are controlled and monitored by the lead. Whole team works for an integrated task/story and the individual members work for the individual task assigned to him/her.

So what is the self-organized means? The team is well organized by the team members. That means each team members are organized by him. Nothing outside the team will control or monitor the team. The team will have a vision or milestone that have to achieve by a fixed time, so team members will be known enough and pro-actively step up to come to a point how they meet the milestone.

In a self-organized team there may not have any team-lead! Then who is the contract point of the team? By whom the management/PO will get involved to the team? Who will raise the issues from the team? Well, I mean, there is absolutely no need of a team-lead in a self-organizing team!!!

I think, in a self-organizing team Sr. developers/members may play a vital role. As they are sr. they have a quite long relation with management and PO. Any of them can be a contract point of the team. The whole team can raise a flag when there is an upcoming issues/risk. Since we know that every developer always get stuck on his technological challenge, then they have scrum meeting every day beginning, They can decide any suitable solution.
Now think about the challenges of a self-organizing team. We know people laugh, people cry, people get angry, people can become de-motivatedL. If these happen, the team starts malfunctioning. Well, there is so many ways to handle this situation. ScrumMaster is responsible for handling the impediments/issues. So within a scrum ScrumMaster can identify the issue and make a 1 on 1 meeting. Other than that ScrumMaster can sit along with team to help/support the team.

So what are the qualities of self-organizing team members? Well, from myself I believe the following qualities is essential

· High communication skill. So that every team member can ask for or report to PO/PM.
· Working approach should be simple.
· Humility is important for respecting peoples and their area of expertise.
· Embrace changes as requirement changes over the time.
· Goal oriented thinking.