Tuesday, 23 September 2014

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.

To know more click on:  http://www.scrumstudy.com/blog/preparing-the-pilot-team/

Thursday, 4 September 2014

Definition of Ready (DoR) in Agile

Introduction:
In Agile Scenario, definition of done (DoD) is very popular, but here we will also look at another important definition related to User Stories: definition of Ready (DoR). These two definitions form the basis of Sprint Principle:
Never pull anything into a Sprint that is not Ready. And never let anything out of the Sprint that is not Done
In simple terms, a user story needs to meet some criteria before it can be used in a sprint. Hence, Definition of Ready for a user story is when a user story is well defined; when testers have defined its user story acceptance criteria; all the dependencies are known; proper sizing or re-sizing has been done if required; the user artefacts have been accepted by the delivery team; delivery team has approved the user story; the clients have approved the user story; and finally the delivery team has a good idea of how the demo of the user story would be.
Definition of Ready is important so that everyone in the team is aware when to pull a user story in which sprint. Practically, the user story need not be 100% defined with all User Acceptance criteria fulfilled. What is most important is that it needs to be “ready enough” so that the team is confident of its successful delivery.
Similarly, Definition of Ready for an iteration is when the iteration backlog has  been prioritised based on importance of user stories; all the defects and bugs are logged in; other work like Lab setup, environment maintainence, supporting other projects etc are taken care of; utilization of resources is known by all; all the user stories of this iteration meet the definition of ready; and all the user stories involved in previous iteration meet the definition of Done (or included in this iteration with all the bugs known)
Consequences of “not being ready”:
  • Teams estimate vague and incomplete stories
  • Time and effort is wasted to get clarity on what the story means
  • One vague user story turns out to be 4-5 actual user stories once the work actually begins. This leads to rework by Business Analysts, Testers etc. all concerned

In conclusion, Definition of Ready is as important to improve productivity in the team as Definition of Done. Done properly, it saves a lot of time and effort of the team, and focus is only on doing the right thing the right way.