Preparing the pilot team

In addition to providing mentoring to the pilot team during the project, you also need to prepare the team in other ways. You need to train the pilot team on agile practices and principles, and provide a method for feedback during the pilot.

Ensure everyone is trained on agile

The untrained pilot-team members go through a process similar to that followed by the core team. They need an overview of why the company is pursuing agile, training on the agile principles, and an understanding of the process they’re to use on the pilot. If possible, have your agile coach provide the pilot team’s training, with core-team members contributing to the discussions. This process training takes one or two days and is slightly different for the pilot team. In addition to the fundamental principles and practices of agile, they also need training on how the core team has represented those principles in the custom methodology. For example, they need to see how the core team’s new process supports the agile principle of customers and developers working together daily. If core-team members are attending the fundamentals training with the pilot team, they can show the pilot team how the principles are reflected in the custom methodology. You should expect the untrained team members to have some cynicism and negativity related to using the new process. Their concerns usually relate to the following:

■ A misunderstanding of agile principles.

■ A belief that the current process works fine —Project team members may be unaware of the issues that the new methodology addresses.

■ Lack of detail in the agile process —In the past, you may have prescribed every step in the development process. Now, the team is asked to participate in selecting the processes that add the most value, and that can be a shock. If your environment has been controlling in the past, the last item will take time to resolve. Agile doesn’t assign employee A to do step B; it tells the employee to deliver value to the customer as quickly as possible and provides tools and processes to reach that goal. The team works together to determine logical steps and assignments during the project. No matter what the feedback is, listen to the pilot team with an open mind. Where applicable, show them how the new design takes their concerns into account. You may receive enough feedback from pilot-team members to tempt you to make another update to the methodology. But unless the feedback identifies a showstopper, we suggest holding off on any changes—the pilot will provide plenty of feedback, and you can incorporate the pilot-team feedback when the pilot project is complete.

Providing a mechanism for feedback

When the pilot project kicks off, you need to provide a way to gather feedback from the pilot team. The best way to do this is to invite them to the weekly core-team meetings and give them the floor. The core team can listen, see how the methodology is working, and provide guidance to the pilot team. You should expect some apprehension from the pilot team during the first few meetings. The pilot team knows they’re providing feedback to the group that customized the methodology. Do your best to create an environment where egos are checked at the door and the pilot team feels comfortable sharing their feelings.

Scrum : Important Roles in a Scrum Project

It has been proved by surveys that additional certifications such as ITIL, PRINCE2, PMP and Scrum can not only help a professional (IT or non-IT) gain more knowledge regarding success in their projects, but also help an organization in which he/she works in the long run. One of the most similar facts that can be seen from these certifications is that they all emphasize the importance of roles and non-roles in their projects. In this article, the emphasis is placed on roles and non-roles of an organization. In Scrum training or Scrum certification, a lot of time is dedicated to defining and understanding roles and responsibilities for the success of every project.

The roles of Scrum fall into two categories, i.e., core and non-core roes. In Scrum, core roles are defined as the roles that are mandatorily considered necessary for production of the project, they are and should be committed to the specific project and also responsible for success in every Sprint of the project and for the entire project. Non-core roles are those roles which are not mandatory in a Scrum project. The roles may consist of members interested in the project though they might not have any formal role in the team. But they are given permission to interact with the members of team. They may or may not be responsible for the outcome of the project. But in Scrum, it has been clearly specified that these roles should also be considered.

Here is a video on the Scrum Project Roles: http://www.scrumstudy.com/watch.asp?vid=454

Core Roles are further divided into three and they are held responsible for meeting the objectives of the project. Commonly referred to as the SCRUM core team, they are known by the names: Product Owner, Scrum Master and Scrum team. But the important fact to be taken into account is that these roles have or given no authority over other roles. Let us first consider the role of Product Owner. The responsibility of maximization of business value in a project is assigned to this role. It includes articulating requirements of the customer and maintenance of justification of business about the project. In short, Product Owner can be defined best as the Voice of the Customer.

Next is the Scrum Master role. Scrum Master can be best described as the person who ensures that the environment in which the team works is as per the guidelines that are required to develop the product or service successfully. Finally, the Scrum Team is a group of members responsible for understanding the requirements of the business as specified by the Product Owner, who estimates User Stories and creating the project Deliverables.

scrum : Information Radiators or Tools in Scrum Projects

One of the main advantages of Scrum is that the whole activity is transparent for all and the information can be viewed directly from information tools such as Scrumboard, where the progress of the team can be made visible. The progress of a team can be planned accurately and tracked by the Scrumboard during each Interval of a Sprint. The Scrumboard consists of four columns for indicating the progress of the proposed tasks in a Sprint; the first one consists of the “To Do” column, i.e., for tasks in the pipeline, the second column consists of a “To Do” column for tasks that have not yet started, the third one for “In Progress” column for the tasks that are in action but not concluded and the final column stands for tasks which have been completed including the successful completing of tests. It has to be noted that in the initial stages of a Sprint, all the tasks for that phase are confined to the “To Do” column and their place changes as the project proceeds to completion.

The Scrum board is usually maintained on a white board or on paper, or as in recent times, where it is managed electronically on a Spreadsheet. Changes in the Scrumboard should be managed by the Scrum team as per the standards of time so that the information is transparent for the stakeholder and other team members to ensure that the project is on the right track as per the guidelines.

Another important tool in this regard is Impediment Log in which all the impediments affecting the project are documented. An Impediment is usually described as an obstacle, hindrance or hurdle which can decrease the productivity and performance of the Scrum team. It is mandatory that they should be identified as soon as possible, solution found in quick time and they should be removed in order for the team to contribute effectively. They can be classified into two types: Internal and External. Internal Impediments can be classified as either improper communication or reduction in performance of workforce whereas External impediments could involve various factors such as requirement of unnecessary documents or issues in software license. An organization can suffer from unwanted cost if it fails in identification or not finding an appropriate solution in dealing with this factor. The Scrum Master is responsible for recording the impediments in the Impediment Log and these issues can be discussed and sorted in Daily Standup Meetings and Sprint Review Meetings.

Sprint Burndown Chart is another key information radiator in Scrum. The Sprint Burndown Chart is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.

Here is a video on the Sprint Burndown Chart: http://www.scrumstudy.com/watch.asp?vid=615.

Scrum : Lifecycle of a Scrum Project

As with other certifications such as ITIL, PRINCE2 or PMP, SCRUM can also be described as an additional way in which organizations can achieve their goal of providing the best services or products to their customers. A new service which has to be designed or modification of an existing service can be termed as projects by organizations. But these so-called projects can become restrained due to shortage of time, resources, financial cost, and various challenges which can make an organization vulnerable to improper planning, execution, management and succession of projects. Organizations have henceforth formulated different methodologies for proper project management.

Scrum has become one of the most sought-after methodologies to be implemented for success of a project. One of the advantages of Scrum is that it ensures transparency for communication where the conversation becomes easy for collective accountability and consistent progress. Every methodology will have a special feature by which the challenges related to a project can be met. The benefits of Scrum are the usage of self-empowered, well-organized and across-department teams who can divide a project into little work cycles known popularly as Sprints.

Here is a video describing the Scrum methodology: http://www.scrumstudy.com/watch.asp?vid=434

Similar to the beginning of any project, the Scrum cycle also begins via a stakeholder meeting in which the details are explained to the delegate called as “Project Vision.” A Prioritized Product Backlog is then designed and developed by the Product Owner. The Backlog consists of a list of project and business requirements according to their priorities in the formula of user stories. A Sprint is usually begun with a “Sprint Planning Meeting” and during the discussion high priority issues and stories will be included in the sprint. The time-limit of a Sprint will be between one and six weeks and will involve the Scrum team.

The highlights of the meeting will be the short, to-the-point stand-up meetings which will be conducted and the SCRUM team will discuss the daily progress of the project. When the time-limit is concluded, a Sprint review meeting is conducted and the Product Owner and concerned stakeholders will be provided updates and demonstrations regarding the Deliverables. The Product Owner has the option to accept the Deliverables provided they meet the accepted criteria or reject it if they do not meet the concerned guidelines.

The conclusion of the Sprint Cycle is the “Retrospect Sprint Meeting” in which the team suggests ways on improving the processes and their performance in moving forward into the subsequent Sprint. Organizations that have used Scrum in their projects, vouch for its many benefits, some of them, adaptability, transparency, continuous improvement, motivation, faster problem resolution, and innovative environment.

Scrum : Quality Considerations in Scrum Projects

“Quality is baked in,” we have often heard this statement. But to actually understand what it means in the Agile context, we need to have a QA mind-set. Let’s take an example to understand this. As part of a proposed acquisition, my boss asks me to perform some final due diligence on the development team and its product. We’d already established that the company’s recently launched product is doing well in the market, but I have to make sure we are not about to buy more trouble than benefit. So I spend my time with the development team.

Here is a video on quality considerations in Scrum project: http://www.scrumstudy.com/watch.asp?vid=585

I am looking for problems that might arise from having rushed the product into release. I wonder, “Was the code clean? Were there modules that could only be worked on by one developer? Were there hundreds or thousands of defects waiting to be discovered?” And when I ask about the team’s approach to testing, “Quality is baked in” is the answer I get. Because this rather unusual colloquialism could mean just about anything, I press further. What I find is that this is the company founder’s shorthand for expressing one of the quality principles: Bring quality in your development phase itself, rather than waiting for the testing phase. The idea of building quality into their products is at the heart of how agile teams work. Agile teams work in short iterations in part to ensure that the application remains at a known state of quality. Agile teams work in a cross-functional manner, with everyone working side-by-side in every iteration to improve the quality of the product thorough techniques like automation, refactoring, pair programming, integration etc.

Here a dedicated tester is involved throughout the timeline, continuously testing recently developed codes, and integrating them with the existing codes to conduct a functionality test as well. Smoke testing is also encouraged to improve the quality of the demo to be shown to the clients. Learning how to do these things is difficult, and especially so for testers, whose role changes dramatically in an Agile environment. It is important to look at the questions a tester will have in his/her mind while embarking on an agile project, such as:

  • What are my roles and responsibilities?
  • How do I work more closely with programmers?
  • How much do we automate, and how do we start automating?

Once these questions are answered, a tester will be able to perform his/her role in an Agile environment in a much better way.

Time-boxing

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the benefits of Time-boxing are:

  • Efficient development process
  • Less overheads
  • High velocity for teams

Risk Identification in Scrum Projects

The objective of the Scrum Team members, the Scrum Master should be to minimize the risk involved in attaining the project objectives if not to remove it completely. Therefore, the Scrum Teams and the Scrum Master should spend their time to attempt to identify the potential risks that impact the project. This can be achieved only by looking at the project from different perspectives, using a variety of techniques. The following techniques are commonly used by the Scrum Team and the Scrum Master to identify risks.

Risk Identification Techniques:

1.  Review Lessons Learned from Retrospect Sprint or Retrospect Project Processes

Historical data is used to identify and access the risk involved in similar projects previously by the Scrum Team. Learning from similar projects and earlier Sprints in the same project and exploring the uncertainties that affected those projects and Sprints can be a useful way to identify risks.

2.  Risk Checklists

Risk checklist is a valuable tool to help ensure comprehensive risk identification. This checklist includes key points about the risks involved, steps to be followed in identifying the risks, steps to handle the risk and minimize the impact, etc.

3.  Risk Prompt Lists

There are the tools which are used to stimulate the thought about the sources from which risk may arise in a project or when the risk is encountered by the team. These tools are available freely in the market and Scrum Team members can use them to identify the risk during the course of project completion.

4.  Brainstorming

The project experts, stakeholders, Scrum Master and Scrum Team members involve in discussion and share their ideas openly. Each individual idea is picked up and discussed and a consensus is drawn about the risk that may be encountered by the team.

5.  Risk Breakdown Structure (RBS)

The risks are categorised into grouped on the basis of their characteristics like the financial, operational, physical risk etc.  Then strategies are drawn to minimize the impact of each group of risk.

The above techniques are not the final set to identify the risks involved in a project. There are other tools like individual expertise, Expert opinion, etc. to identify the risk which need to be used by the scrum teams to identify the risks so that they are well prepared in advance to minimize the impact the effect of these on the Scrum Projects.