RSS

Tag Archives: Scrum

Are the 3 daily standup questions actually effective? 


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

I have been an Agile coach for more than nine years and have worked in various Indian, American & European companies that develop software locally and internationally using Scrum. The clients of these companies have adopted Scrum and participate in the Daily Scrum meeting, assuming the role of Product Owner.

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It’s not an opportunity to get a report on where the team is up to. It’s not an opportunity to ensure everyone is ‘busy’. Unfortunately, the three questions just tend to reinforce this perspective.

  1. What did you do yesterday?
  2. What will you do today?
  3. What (if anything) is blocking your progress?

The purpose of the 3 daily scrum questions is relatively simple and obvious. These questions are asked routinely first thing in the morning, which allows teams to assess: (1) how they performed in the last 24 hours and (2) what the next 24 hours look like.

This article tells the story of our experience implementing a shift in approach during the Daily Scrum meeting. We went from a typical approach centered on each individual to one centered on each story of the Sprint Backlog.

The 2020 version of the Scrum Guide dropped the classic “three questions” of the Daily Scrum. Yet many teams stick with the practice, even when it doesn’t produce the collaboration that is the hallmark of a valuable Daily Scrum. When a Scrum Team I worked with said that their Daily Scrum was lackluster and unproductive, I challenged them to design a better one. The new pattern we created shifted the focus from individual action to team collaboration toward the Sprint Goal.

Smarter questions for the Daily Scrum

Scrum isn’t prescriptive about the way Developers run their Daily Scrum. Importantly, going ‘around the room’ and ‘standing up’ isn’t required. Some useful questions to raise at the Daily Scrum include:

Questions about scope

  • Do we need to change some of the work we have in the Sprint so we achieve the Sprint Goal?
  • Do we need to change some of the tasks we decided need doing?
  • Do some of the backlog items we chose need to be put aside because we now know they don’t help us achieve the Sprint Goal?
  • Do we need to negotiate scope with the Product Owner to help us achieve the Sprint Goal?

Questions about collaboration

  • Does anyone need their work peer reviewed yet?
  • Does anyone need help today?
  • What pairing activities will we do today?
  • Whose turn is it to pair with the new team member?

Questions about transparency

  • Have we updated the board to show our actual progress?
  • Is the Sprint Backlog up to date?
  • Is the status of work up to date?

Questions about metrics

  • How are we tracking toward the Sprint Goal? Are we where we thought we’d be?
  • What do our burndown metrics say about our progress?
  • What does our cycle time metrics say about whether we’ll complete the work by the end of the Sprint?
  • Questions about Done
  • What work is in-progress that we can work on today and get to Done?

Questions about learning 

  • Did anyone learn anything yesterday that means our work for today needs to change?

If the traditional “three questions” Daily Scrum doesn’t provide value for your team, try something new. Create a collaborative discussion focused on making each day a valuable step toward the Sprint Goal.

If you came across similar situations , please share your experience in the comments section.

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on May 3, 2022 in Technical

 

Tags: , , , , , , ,

What to do you do when a sprint is cancelled?


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

During my stint as a Scrum Master, I have experienced multiple cancelled Sprints. I have always tried to use these as learning opportunities.

Though Cancelling the sprint isn’t a frequent situation. In Scrum framework it’s at the discretion of the Product Owner(PO) to cancel the sprint if PO realize that the sprint goal and plan isn’t adding value to the product. In Scrum, only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

“Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.” — The Scrum Guide.

Sprint cancellations, might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense. When a Sprint is cancelled, product backlog is updated with latest priorities any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

A Sprint may be cancelled in the event that an organisation has to adapt to an abrupt situation. In a way it enhances agility. It generally occurs when there is something more valuable or urgent that requires the team’s commitment and focus. A Sprint doesn’t get cancelled if the Scrum Team discovers it cannot meet it. Calling for cancellations often, reveals however that focus and commitment is lacking. Perhaps even the Sprint timebox is too long for the team to timely adapt to the changing conditions in the market. It could even reveal a lack of vision, or that the Product Owner’s vision for a Sprint isn’t respected by his or hers management.

Valid Reasons the PO Might Cancel A Sprint:

  1. A better technical solution is found that makes the current Sprint’s activity throw-away work.
  2. A major technology change occurs.
  3. Fundamental and urgent external changes invalidate the Sprint Goal or the Product Goal
  4. Company’s vision is changed
  5. Product strategy is changed
  6. Company’s business strategy is changed
  7. Market conditions are changed
  8. Customer needs are changed
  9. Product owner realize the value of the identified goal is obsolete
  10. Another poor reason to cancel a Sprint is when a Sprint Goal is already achieved early and there is still time remaining.

When Product Owner cancel Sprint, all the work done until that moment is evaluated and remaining work items are pushed to product backlog for further analysis. The time, efforts and at times work done might be considered waste and Product Owner takes the accountability of any such business impacts. 

When a sprint is cancelled, It is biggest challenge for Scrum Master to handle to situation. When a sprint is cancelled team morale is likely to drop off significantly. Team members are likely to have a negative reaction to the PO and the product. Its where Scrum Master communication skills comes to play.

Most teams are unlikely to be able to start a new sprint immediately. Instead opting to maintain a sprint heartbeat consistent with what they are used to.

If you came across similar situations , please share your experience in the comments section.

Please feel free to share your story and any lessons you learned, experienced, you came across in your life in the comments below. If you enjoyed this or any other posts, I’d be honored if you’d share them with your family, friends, and followers!

If you wish to follow my journey outside of my writing, you can find me on LinkedIn and Facebook

 
Leave a comment

Posted by on April 20, 2022 in Technical, Work Place

 

Tags: , , , , ,

Scrum Vs Kanban


Each minute of our life is a lesson but most of us fail to read it. I thought I would just add my daily lessons & the lessons that I learned by seeing the people around here. So it may be useful for you and as memories for me.

Article by AXA XL Team…

Which framework works best: Kanban or Scrum? If you are on the verge of a brand new project, I bet this question has posed quite the challenge to your mind. Today Kanban and Scrum have grown in popularity and have taken the place of the previously popular waterfall method.

Agile –  Agile software development is based on an incremental, iterative approach. Instead of in-depth planning at the beginning of the project, Agile methodologies are open to changing requirements over time and encourages constant feedback from the end users. Cross-functional teams work on iterations of a product over a period of time, and this work is organized into a backlog that is prioritized based on business or customer value. The goal of each iteration is to produce a working product.

Scrum – The approach followed here is breaking down a complex task into simpler smaller manageable pieces which are easy to collaborate upon by the respective owners of the scrum.

Kanban – It is a Continuous improvement, flexible process. Kanban helps visualize your work, limit work-in-progress(WIP) and quickly move work from “Doing” to “Done.” It is a framework which utilizes visualization technique, limiting the number of tasks to be taken in “Work in Progress” column.

Scrum Vs Kanban

Kanban and Scrum are both iterative Agile development models, the goal is to get the most important tasks fully done (including testing) as soon as possible. The product should be potentially shippable at the end of the iteration. The difference is with Scrum the end is a set date, with Kanban it could be anytime the features that need releasing are done. In Scrum you plan a fixed period of time and with Kanban you plan just in time.

ks1.jpg

Roles –

  • Scrum is dependent on the scrum owners and is worked upon by them respectively. Scrum has three clearly defined roles.
    1. The product owner advocates for the customer, manages the product backlog, and helps prioritize the work done by the development team.
    2. The scrum master helps the team stay grounded in the scrum principles.
    3. The scrum team chooses the work to be done, delivers increments, and demonstrates collective accountability
  • Kanban is independent of cross-functional team members and parallel roles. The whole team owns the kanban board. Some teams enlist an agile coach but, unlike scrum, there is no single “kanban master” who keeps everything running smoothly. It’s the collective responsibility of the entire team to collaborate on and deliver the tasks on the board.

Release cycle –

  • Scrum makes use of sprints whose duration varies from one week to two weeks. The user stories are then taken up for development, testing and bug fixes. Nowadays, it’s common to have ad-hoc releases in scrum, but it’s long been a best practice to release at the end of each sprint. Teams set an objective for each sprint, the sprint goal, and either approves it for release in the sprint review meeting, or don’t
  • Kanban does not follow any cycle and the process is continuous in nature. In kanban, updates are released whenever they are ready, without a regular schedule or predetermined due dates. In theory, kanban does not prescribe a fixed time to deliver a task. If the task gets completed earlier (or later), it can be released as needed without having to wait for a release milestone like sprint review.

Tracking parameters –

  • Scrum makes use of velocity in planning upcoming sprints taking into account the complexity and number of user stories completed in the previous sprint.
  • Kanban ensures limiting of user stories in “Work in Progress” column to avoid bottlenecks. It tracks the time taken to finish a task from the starting to the end.

The scope of improvement –

  • Scrum does not encourage changes in ongoing sprints.
  • Kanban is open to any changes before the completion of the project. It is flexible in nature.

Fit factor –

  • Scrum is suitable for projects with clearly defined user stories. Acknowledgement on the same by the client for timely completion of the project makes it a fit.
  • Kanban being flexible in nature allows variations in priorities on the basis of the current scenario.

Pick process –

  • Scrum picks the entire batch of user stories from the product backlog for development.
  • Kanban follows the maximum number of tasks allowed in the columns to maintain the sanity of the framework and to avoid bottlenecks.

Delivery –

  • Scrum follows delivery based on sprint planning and prioritize based on the specifications given by the client.
  • Kanban follows the continuous delivery model based on business needs.

Key metrics

  • Scrum – Velocity i.e. the number of story points completed in a sprint—is the central metric for scrum teams. It guides future sprint commitments, or how much work the scrum team takes on in future sprints. If the team completes an average of 35 story points per sprint (Velocity = 35), it won’t agree to a sprint backlog that contains 45 points.
  • Kanban – Lead time and cycle time are important metrics for kanban teams. The deal with the average amount of time that it takes for a task to move from start to finish. Improving cycle times indicates the success of kanban teams.

The above points are easy to remember if you are able to visualize working on them. Ideally where the scrum follows a rather predefined set of principles. Kanban is backed up by the principle of flexibility. It allows you to track tasks that are of utmost importance for delivery.

What Is Kanban? ks3

In order to simplify the manufacturing process and increase efficiency, in the 1940s Toyota implemented just-in-time manufacturing—effectively, making only what is needed, only when it is needed, and only in the amount that is needed.

Kanban is great for teams that have lots of incoming requests that vary in priority and size. Whereas scrum processes require high control over what is in scope, kanban let’s you go with the flow. Let’s take a look at the same five considerations to help you decide. What makes Kanban interesting is this aspect of it – that you could be continuously developing, integrating, testing and releasing at a cadence that you feel comfortable with – and so the whole concept of Continuous Delivery becomes much more ‘natural’ with Kanban.

How Does Kanban Work?

The only essential materials for kanban are a marker, sticky notes, and a board. Create “cards” from the sticky notes representing work items that have to go through several phases, from start to finish. Then draw columns on the board for each phase the cards need to go through, with a number at the top of each column that indicates the maximum number of cards (i.e., work in progress) that can be in that phase at a time. This number probably will and should change as your team improves its ability to gauge and reduce bottlenecks. The columns could simply be labeled “to do,” “doing,” “waiting,” and “done,” or they can be more process-specific, such as in the examples below.

Another helpful thing many teams do is dividing the columns in two, with one lane for “doing” and one for “done,” as you can see in the software development kanban example above. This way, it is clear to whoever is in charge of the following column to know when they can pull another card and begin working on it.

ks 2

The beauty of this system is that it helps you detect where bottlenecks are. The work-in-progress limit stimulates conversations about process problems. In the examples above, you can see some columns are at capacity and some are not, but none has more cards than prescribed.

 

Please feel free to share your story and any lessons you learned, you experienced, you came across in your life in the comments below.

 

 

 

 

 
1 Comment

Posted by on March 22, 2019 in Technical

 

Tags: , , ,

 
%d bloggers like this: