How to ensure your team does not have too much or too little to do?

How to ensure your team does not have too much or too little to do?
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 advantages of Time-boxing are as follows:
• Efficient development process
• Less overheads
• High velocity for teams
Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup
process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to
avoid excessive improvement of an item (i.e., gold-plating).
Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing
can lead to de-motivation of the team and may have the consequence of creating an apprehensive
environment, so it should be used appropriately.
Scrum Time-Boxes
• Sprint—A Sprint is a Time-boxed iteration of one to six weeks in duration, during which the
Scrum Master guides, facilitates, and shields the Scrum Team from both internal and external
impediments during the Create Deliverables process.
• This aids in avoiding vision creep that could affect the Sprint goal. During this time, the team
works to convert the requirements in the Prioritized Product Backlog into shippable product
functionalities. To get maximum benefits from a Scrum project, it is always recommended to
keep the Sprint Time-boxed to 4 weeks, unless there are projects with very stable requirements,
where Sprints can extend up to 6 weeks.
• Daily Standup Meeting—The Daily Standup Meeting is a short daily meeting, Time-boxed to 15
minutes. The team members get together to report the progress of the project by answering the
following three questions:
1. What did I complete yesterday?
2. What will I complete today?
3. Am I facing any impediments?
This meeting is carried out by the team as part of the Conduct Daily Standup process.
• Sprint Planning Meeting—This meeting is conducted at the beginning of a Sprint as part of
Create Sprint Backlog process. It is Time-boxed to eight hours for a one-month Sprint. The Sprint
Planning Meeting is divided into two parts:
1. Objective Definition—During the first half of the meeting, the Product Owner explains
the highest priority User Stories or requirements in the Prioritized Product Backlog to
the Scrum Team. The Scrum Team in collaboration with the Product Owner then defines
the Sprint goal.
2. Task Estimation—During the second half of the meeting, the Scrum Team decides “how”
to complete the selected Prioritized Product Backlog Items to fulfill the Sprint goal.
• Sprint Review Meeting—The Sprint Review Meeting is Time-boxed to four hours for a one-
month Sprint. During the Sprint Review Meeting that is conducted in the Demonstrate and
Validate Sprint process, the Scrum Team presents the deliverables of the current Sprint to the
Product Owner. The Product Owner reviews the product (or product increment) against the
agreed Acceptance Criteria and either accepts or rejects the completed User Stories.
• Retrospect Sprint Meeting—The Retrospect Sprint Meeting is Time-boxed to 4 hours for a one-
month Sprint and conducted as part of the Retrospect Sprint process. During this meeting, the
Scrum Team gets together to review and reflect on the previous Sprint in terms of the processes
followed, tools employed, collaboration and communication mechanisms, and other aspects
relevant to the project. The team discusses what went well during the previous Sprint and what
did not go well, the goal being to learn and make improvements in the Sprints to follow. Some
improvement opportunities or best practices from this meeting could also be updated as part of
the Scrum Guidance Body documents.

 To know more click on: http://www.scrumstudy.com/blog/

Common leadership mistakes creating Agile fiascos

Agile methodology as any other methodology would need to be planned, managed and implemented by people/stakeholders because people are the drivers behind any change. Top level management support is highly crucial for realizing the success of Agile implementation as its success rests up to a significant extent on management fueled organizational transformation. Many disasters of software projects toward Agile development can be factored in on the absence of support from the side of management. Agile misconceptions on the part of higher management need to be done away it as that poses to be one of the most important factors in jeopardizing the Agile project. Imposing Agile adoption alone just cannot change anything; the leaders need to be a very much active part of the whole process.

Agile delusions

• Business leaders take it for granted that adopting Agile would improve software development within a short period of time – say a couple of months. Time, as a crucial aspect of any project management, is an area which the leaders of businesses are not prepared to negotiate with the development team as the team goes on about the learning process of Agile implementation. Effective implementation of Agile development would require years, if not months, in a given organization holistically. No doubt, progress in increments can be seen during the process but in the scope of the larger picture, efficiently responding to changes and requirements of the business in the long term would require more time. The team and the organization, by then, would have learnt Agile as a way of life and, thus take pride in achieving improvements on a continual basis.

Fostering Agile is only about ferrying in innovative trappings to the development organization

• It is a complete misnomer to believe and accept the fact that adopting Agile is all about getting to know their tools aiding iterative development in the spheres of designing, analyzing, developing and releasing activities. This culminates in disasters often.

Swift delivery of apps and software is the principal objective of Agile development

• Technical debt can be a major drawback of teams striving for more speed in terms of delivery working on delivery of software. This would impact adversely quality – another major aspect of the project culminating in sacrificing a core part of the value delivery.

The core focus of change in embracing Agile should be the development group ONLY

• Agile brings with it organizational transformations. The change toward transformation of the organization should be whole and only the development team just doesn’t justify that logic. It should start from top level management who needs to understand and practice it.

To know more: http://www.scrumstudy.com/blog/common-leadership-mistakes-creating-agile-fiascos/