Learn Software Development » Explanation

Some of the properties to look for in a Scrum coach – Part 3

ashish — Tue, 09 Aug 2011 15:26:05 +0000

In 2 previous posts, I have been mentioning some of the properties you should be looking for in a Scrum Coach (Which Scrum coach to hire). In this post, I will provide some more inputs on how to hire the best Scrum coach for your organization.
- A good Scrum coach will be ready to listen to any feedback your team members may have. Consider the scene whereby you would be speaking to an expert about some issue (and a pretty well known expert in their field), and you find that the person is not really very open. They would believe passionately in what they are advocating, and would not be willing to listen to issues that you bring up. You know the style, where you bring up some problem, and the first reaction could be “Well, you must be doing something wrong, since Scrum normally works well in these situations”. You get your team members to get these responses from a Coach on more than a couple of occasions and you will start hearing feedback from the team members that the Scrum coach does not seem open to ideas, is more of an evangelist and less of a coach. What you need is a person who patiently hears out the problem, works with the team members to analyse and see what the particular problem could be, and coaches them such that the one or more of the team members suggests a solution to the issue, gets the team to listen to their solution and gets more of the team to agree to the solution. The coach guides them, moves them away from wrong solutions that may be proposed by some team members, and eventually ensures that over a period of time, more and more of the team members learn the right way to do things when they are using Scrum.
- A Scrum coach, however skilled in their areas and an expert, should deal with the team members in a respectful way. Occasionally I have come across experts in their fields who are brusque in their manners, and even though being rude sometimes gets people on their side (if they really are experts), more often than not, they tend to push people away. Would you really like a Scrum coach who does not treat the team with respect. People who are implementing Scrum tend to be in the IT field, where they normally have a level of intelligence that is more than normal, and do not really like somebody talking down to them. This can be difficult when the question or suggestion is frustrating, but you need to get a Scrum coach who does not lose sight of the fact that these are skilled people, and need coaching to make them better in the area of Scrum implementation.

A description of Scrum For Project Managers – some details

ashish — Sat, 04 Sep 2010 20:03:47 +0000

The product requirements of Scrum are typically chunked into a small set called a Story, or feature, with a short narrative description, somewhat like a use case or a test case. When you talk to people who are involved in Scrum, you will hear the word ‘Story’ many times. Let us go into more detail of what a Story is. There are three types of stories namely: User Story, Technical Story and Bug Report. More details on each of these. A User Story describes what the user does with the software and how the software responds. A Technical Story is a non-functional requirement that describes the functionality supporting the user facing features in User Stories whereas a bug report is a description of the failure of the product to behave as designed and expected. Another important document in Scrum (one of the most important documents) is called – the Product Backlog; which includes all requirements not yet scheduled for implementation.
Another important term in Scrum is Sprint; in the old world, Project Managers call it the Schedule, but this is not an exact mapping. Small teams of 6-9 people work in short Sprints of 2-4 (the optimum Sprint timing is dependent on many factors, including the work to be done, the comfort level, etc) weeks to implement stories in rank order. In each of the Sprints the team members collaborate and self-organize; they also track progress and update tasks when finished. Team members collaborate to complete stories quickly instead of working on separate stories in parallel. At the end of a Sprint, completed stories are shipped: incomplete Stories are not. The schedule is not extended to complete work.
The three roles defined in Scrum are: the ScrumMaster, the Product Owner and the Team. The people who fulfill these roles work together closely, on a daily basis to ensure the smooth flow of information ant the resolution of issues. ScrumMaster is responsible for enforcing the process, tracking progress and expediting problem resolution. He keeps the team focused and productive, protects them from interference and ensures the swift removal of roadblocks. It is not required that a person like a Project Manager should be the ScrumMaster, you need a person who can keep the team moving, can understand the Scrum process, and can work quickly to resolve issues that the team faces. The Product Owner is the keeper of the requirements. He provides the single source of information about the requirements and their planned order of implementation. The Team is a group of people responsible for developing the product.
The different phases of development in scrum can be divided into three phases. During the first phase the SprintBacklog is defined and ranked set of requirements planned for implementation in a Sprint. Next is the turn of sprint planning meeting where the team estimates each Story in rank order. Next is the turn of task breakdown; in which identification of the set of tasks whose execution results in implementation of the desired functionality. Phase two consists of developing and testing of the Stories. This phase also includes monitoring and controlling which maps to updating the Burndown Chart and holding Daily Scrum meetings. Daily Scrums are daily status meetings to resolve issues proactively. An important practice of daily Scrum Meetings is that it is timeboxed to 15 minutes, which essentially means that questions are answered quickly; issues are identified and addressed quickly. The final final phase consists of Demo, Release and Retrospective. Closing maps to demonstrate the completed work in review meetings is done. The updated product is released and the Retrospective meetings held to capture the lessons learnt. At this point the cycle begins again. The next Sprint kicks off with the Sprint Planning Meeting using the updated ProductBacklog.

Scrum in a very brief nutshell – a set of points along with a brief description

ashish — Sat, 27 Feb 2010 17:23:01 +0000

I have written several articles about Scrum, none of them very long or like an essay, but this article will probably be the shortest, since it is more like a slide with a few points (and optional explanation) next to the slide points. Here goes:
- Have a prioritized list of requirements: This is essentially about putting all your requirements down in point form (and not trying to detail out all the requirements right now), and then prioritizing them so that everyone knows which are the most important points
- Plan a time for when to show your work: In essence, this is a demo. A demo of your work set for certain dates (these dates being at specific intervals), to show to your stakeholders and as a form of demonstration of completion by the team
- Invite people for this showing of the work: Showing off the work is not complete till you are sure that all the stakeholders are invited and can come and see. These stakeholders include the product owner (representative of the product management), senior management, and of course, the team members
- Agree to deliver a set of requirements: This is the hard part, since it includes the whole set of processes to take the overall set of requirements, get the team to understand them, break down those requirements into a set of features, do planning poker to help in estimation of those features and prepare a Sprint backlog for getting the list of features for the current Sprint
- Actually do the work required to complete these requirements: This is one of the most time taking part of the Scrum cycle, since this is the time when the team actually develops and tests the requirements, with monitoring of the work done through the breakdown charts, and also work through the progress through the use of the Daily Scrum
- Do the actual showing of the work: This is the actual summary of the work done, and includes getting the team together for the introspection / post-mortem, and having the demo to the stakeholders at the end of the cycle, so that people can comment as to whether the work is happening in the desired direction
- Repeat: All the above (except for the first point) is part of one of the cycles of Scrum, and you need to do these cycles through the project development cycle (with the length of each cycle varying between 1 week to 2 months or so).

Ad:

Different roles in a Scrum process – ScrumMaster, Product Owner, and The Team

ashish — Tue, 10 Nov 2009 19:00:40 +0000

A Scrum process has some key roles, which will not be familiar to those who have not done any Scrum training, or those who have not undergone Scrum. In order to make the Scrum process a success, it is critically important that wherever a Scrum process is being implemented, all the stakeholders understand the different roles involved and the responsibilities of each role. These roles are:
At a very broad level, first we should define two major categories. These are called ‘pigs’ and ‘chickens’. The difference is stated in the form of a standard joke,
————
A chicken and a pig are together when the chicken says, “Let’s start a restaurant”. The pig thinks it over and says, “what would we call this restaurant?”. The chicken says, “Ham n’ Eggs”. The pig says, “No thanks, I’d be committed, but you’d only be involved.”
————
In case you did not get the joke, for Ham and Eggs, Ham means that the pig has to dedicate portions of the body, while for Eggs, the chicken has just to deliver eggs, and remains whole. Hence the statement about Chickens being outsiders, while pigs are the people whose jobs are dedicated to this effort. In that sense, pigs refer to the team members who work day in and out on the project, while chicken refers to the other stakeholders who are involved such as management, customers, or who can also be defined as the people who are not assigned work, but are otherwise involved.

Now, once we move past this categorisation, we should concentrate on the people involved in the pigs role, those who are directly assigned work as part of the Scrum process. These are divided into 3 separate roles (and greater definition of these will be done in subsequent posts, just as the role of a ScrumMaster was defined in a previous article):
1. ScrumMaster: The ScrumMaster is the facilitator, running the Scrum meetings, working with the Product Owner, and ensuring that the processes are followed
2. Product Owner: The product represents Product Management, and defines the features and tasks that need to be done in every Sprint.
3. The team: The team is the group (small teams of between 7-10 people) who are assigned work for doing the project, and who are primarily from the development and testing teams.

Scrum explained: What is the daily Scrum ?

ashish — Mon, 02 Nov 2009 18:33:40 +0000

For those of you who are evaluating the usage of Scrum to run your project management process, you really need to understand the need for a daily Scrum. If you are the one tasked with implementing the process, then you need to understand the need, the requirement, and the benefits of doing a Scrum meeting on a daily (or frequent periodic) basis. You will need this understanding in order to ensure that you can convince the others (the potential Scrum team) about the need to have these daily meetings. On the other hand, if you are a member of the Scrum team, then you need to understand the need for these regular meetings so that you contribute the best, and be convinced to do these on a daily basis.
So what do you do in these daily meetings, and why would you want to spend the required time every day ?
- Well, first of all, these are very short meetings, meant to be 15-20 minutes each, held at a regular time at a regular place.
- These meetings are conducted by a ScrumMaster, who is the person responsible for makings sure that processes are followed
- The meeting is meant to answer the following questions:
a) What has been your progress since the last meeting on the previous day
b) What is your expected progress till the next meeting (expected on the next working day)
c) Are there are any issues or problems you are facing that will prevent you from doing this work ?
- The meetings are meant to be short and succinct, with only one person at a time speaking, with no lectures or prolonged statements
- The meetings demand promptness and everybody to be present (if people do not attend, then it starts a chain reaction where other people may not attend)