RSS

Tag Archives: Scrum

Questions a Scrum Master Should Ask Before Joining an Organisation 


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.

Having been a Scrum Master for several years and having led 3 large and many small Agile transformations, I have come to appreciate the Scrum Master role more than anything else. Depending on the organizational setup, organizational maturity and Scrum maturity the Scrum Master role can be very challenging. Even if organization is conducive of Scrum, the role is challenging. 

Starting a new role as a Scrum Master for any startup or new organisation can be daunting. Whether you are new to the Scrum Master role or have a wealth of experience, joining a new team means getting up to speed with new people, processes and products. 

A smart scrum master needs to ask appropriate questions before joining a company. Before coming to a decision, the scrum master should clearly evaluate the current situation within the startup.

The scrum master role has been gaining popularity with the widespread adoption of Agile. Startups adopt Scrum at an ever earlier stage and look for professionals to help them out. There are some important questions a scrum master candidate can ask to find the right startup company for their skill set.

In order to get a good idea of how your new Scrum team are operating, I have collated list of questions for you to ask. This list of questions covers all the various topics you are likely to want to know more about, so gather your new Scrum team and ask away!

Here are list of favourite questions for candidates to ask *employers* when interviewing as a Scrum Master:

– What is the biggest challenge Scrum team(s) are currently facing?

– What Is Your Current Software Development Process?

– How much support does the scrum teams have in the organization?

– Why Are You Hiring a Scrum Master and Not a Project Manager?

– How do your team(s) currently feel about working with Scrum?

– How will we validate the success of this team and the product they’re going to build?

– Is the Product Owner empowered to make important decisions?

– What do you think will be this Scrum Master’s biggest challenge?

– What support from a Scrum Master is most important to you?

– Does each dev team currently have a Scrum Master and Product Owner?

– What is the Product Owner’s take on agile product development and planning?

– How would you rate the organization’s Agile or Scrum maturity on a scale of 1-5? Why did you give that score?

– What do you see as the biggest opportunities for your Scrum team(s) to improve?

– How big are your dev teams? How many developers and testers are on your dev teams?

– How many teams does each Scrum Master manage in your organization?

– What Is the Leadership Style of your organisation ?

– How long have the team(s) been working with Scrum?

– Is the team cross-functional enough to deliver a valuable increment?

– What does success look like in this position, and how do you measure it?

– How does the company practice its values and the values of Scrum?

– What’s the attitude of the company’s leadership towards Agile and Scrum

– What’s the last thing your team disagreed on, and how did you resolve that disagreement?

The answers to these questions will give an overview of what to expect upon joining a startup company. A good scrum master should be able to identify the situations where a startup needs a project manager instead of a scrum master and not take on unnecessary responsibilities.

 Do you have any go-to questions you always like to ask?

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

 
 

Tags: , , , , , ,

Top Books to guide your Scrum Master journey


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. 

Scrum is the most popular Agile framework. It is simple to adopt, but implementing it with success could prove to be challenging. The only way to overcome the “glitches” that may appear in the process is to understand its fundamentals and discover practical techniques that will help you get past any obstacles.

Anyone who has ever taken on a role of Scrum Master will tell you it is much harder than it looks. The responsibilities are massive, the traps are common and the organisations are unwilling to change. Agile Project Management requires a deep level of skill and understanding. It doesn’t lend itself to a step-by-step manual that you might find in a book.

That is why I have made a selection of top 20 Scrum Master books you should read if you are thinking of becoming a Scrum Master, or even if you are already one. I strongly believe below list of books are a game changer for the pre-game, game and post-game phases of the Scrum methodology.

  1. The Scrum Guide by Ken Schwaber and Jeff Sutherland
  2. Scrum: The Ultimate Beginner’s Guide To Learn And Master Scrum Agile Framework by Hein Smith
  3. The Great ScrumMaster: ScrumMasterWay by Zuzana Šochová
  4. Agile Retrospectives: Making Good Teams Great by Esther Derby
  5. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
  6. Essential Scrum: A Practical Guide to the Most Popular Agile Process by Kenneth S. Rubin
  7. Scrum: A Pocket Guide by Gunther Verheyen
  8. Scrum Mastery: From Good To Great Servant-Leadership by Geoff Watts
  9. Learning Agile: Understanding Scrum, XP, Lean, and Kanban by Andrew Stellman & Jennifer Greene
  10. A Scrum Book: The Spirit of the Game by Jeff Sutherland
  11. Fixing Your Scrum by Ryan Ripley and Todd Miller
  12. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins
  13. Agile Software Development with SCRUM, by Ken Schwaber and Mike Beedle.
  14. The Scrum Field Guide: Practical Advice For Your First year by Mitch Lacey
  15. Managing Agile Projects by Sanjiv Augustine.
  16. The Scrum Master’s Path 2 books in 1. A Guide for Servant Leaders Navigating Growth and Change Using SCRUM and the Agile Project Management
  17. Fun In Scrum — A Visual Approach Towards Mastering Scrum Fundamentals by Souvik Seal
  18. Zombie Scrum Survival Guide by Christiaan Verwijs, Johannes Schartau, Barry Overeem
  19. Agile Estimating and Planning by Mike Cohn
  20. The Elements of Scrum by Chris Sims & Hillary Louise Johnson

You can find few more suggestions here : https://agileforgrowth.com/scrum-master-books/

Learning is a lifelong process. Improving oneself is never a bad thing. Scrum helps us to adapt to changes and dynamics of the market. The same can be said for Scrum Masters. If you don’t work on yourself and seek to improve your knowledge, skills, and experiences, you’ll be stuck.

Hope this list of books help you select the best fit book for your agile and scrum learning. Do remember to comment down below your favourite book on the topic that might help other readers. If you have already read any of the above books do not forget to comment down your review and learnings from the book. 

Any book suggestions, drop it in the comments!

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 July 10, 2022 in Technical, Work Place

 

Tags: , , , , , , ,

Retrospective ideas to try with your team


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. 

Retrospectives are popular in the team-working world of the Lean & Agile community. The purpose of the sprint retrospective is to find areas for improvement. The meeting sets out to identify potential pitfalls and past mistakes while finding ways to avoid them in the future. It’s also an opportunity to reflect on what was successful and therefore should continue.

Retrospectives are used frequently to give teams the opportunity to pause and reflect on how things have been going and then, based on those reflections, identify the improvements they want to make. Conducting Retrospectives frequently and regularly supports a team to continuously improve their performance — but what’s the best way to go about it?

Whether you are an experienced scrum team or brand new to agile retrospectives, switching up your techniques is a great way to ensure your team never has to sit through another boring retrospective. However, with so many retrospective techniques out there to try, picking the one that best fits the unique needs of your team can be hard. 

Here are top retrospective ideas that you can add to your Scrum toolkit.

Liked, learned, lacked, longed for (4 L’s) If you are part of a team that thinks the only failure is not learning, then this is the technique for you. 4L´s is the perfect retro technique for teams at the end of a project or between projects. This technique has the team explore what happened in a current sprint or project but also what they hope will happen in future sprints. For organizations that want to remain agile and consistently evaluate processes and find a long-term solution to a systemic issue, 4Ls is an easy way to collaborate and strive for continuous improvement. 

Sailboat  sailboat retrospective will help any team struggling with staying aligned from sprint to sprint. A ship sailing to the island paradise sets the stage for valuable open discussions at the beginning or middle of a project. Sailboat discussions improve team alignment and provide valuable feedback on project goals, issues, and assets. Get everyone on board! 

Speedcar Speed Car is a simple activity for helping the team identify things that make them move faster, and things that slow them down. This is a common retrospective activity for data gathering. It is an alternative to keep the team engaged while slightly changing the format.

Starfish (smalllarge) This agile technique dives deeper into team habits by examining what to start doing, stop doing, keep doing, do more of, and do less of. Use this technique when your team is in need of a systems overhaul or needs more innovative ideas of workflow. Starfish works best for long-standing teams or projects in the process where teams are a bit more familiar with each other. 

Stop, start, continue Start, Stop, Continue is one of the most popular retrospective techniques, and for good reason. Whether you are using the traditional Scrum sprint model or just starting to implement retrospective Start Stop Continue is a great way to examine the systems and habits of the team, as well as reprioritize team goals. 

Mad, sad, glad When your team is feeling burnt out or emotionally drained, or even if something is just a little off with morale, a Mad, Sad, Glad retrospective can give you the insights you need. Particularly effective in the middle of larger projects this retrospective template gives managers insights into what team members need to remain happy in their workplace. A simple column-based retrospective, this agile technique will have teams focusing less on specific goals and on the emotions of the team. 

Token of appreciation This is a great activity for acknowledgement, increasing the team morale and putting the team on a good mood. A tasty advice is to use a box of chocolates as a token of appreciation. Participants pass the box around and give a chocolate as they appreciate their colleagues. It works both as an opening and as a closing activity for a meeting.

Drop-add-keep-improve  DAKI technique is a way for Scrum team members to think about what they should stop (or drop) doing, what they should start (or add) to their processes, what they should continue doing, and what they should keep.  Continue often refers to processes, and keep frequently refers to tools.  Remember to ask team members to consider  individuals, interactions, processes, tools, and their Definition of Done when participating in the Retrospective. 

One word retrospective The one-word retrospective technique is often considered as a checking exercise, to get the team members ready for the retrospective. But if the team has major problems, then this one-word exercise check-in and the discussion that follows is the retrospective! It is an effective way for the team to discuss what is hampering them, and agree on how to deal with it and get it out of the way. And that is what retrospectives are all about!

KALM (Keep, add, more, less) KALM is a retrospective activity that fosters the conversation about current activities and their perceived value. It helps team members understand each other’s perceived value off such practices. This is a common retrospective activity for data gathering. It is an alternative to keep the team engaged while slightly changing the format.

Team Happiness Radar Organizations around the world are beginning to recognize the importance of mental health and happiness on overall team productivity and lasting success. Running regular Team Happiness Radars can help you recognize the team’s morale and recognize points of improvement. When done in combination with a column technique, this retrospective can help your team create lasting culture changes. 

Lean coffee style Don’t have a specific goal or topic for the day’s retrospective? You need Lean Coffee, another agile favorite, is a basic template to use when you don’t know what to do, but still want an effective retrospective. The Lean Coffee agile retrospective has teams examining the status of the team’s assignments and looking into where issues are developing and what hold-ups are preventing the team’s momentum forward. By discussing common topics of concern the team can create relevant action items for improvement on a range of topics. You never know information can spill out in a Lean Coffee retrospective session.

Below are the list of references and also If you are interested to try more Retrospective ways, please find the below links.

Retrospective Techniques

100+ Sprint Retrospectives Ideas

FunRetrospectives

Remote and Distributed Retrospective Meetings

14 Types of Ideas for Sprint Retrospective Formats

Conclusion

Regardless of whether you follow an agile framework for project management or not, a retrospective meeting acts as a fantastic opportunity to pause and reflect. Your team will gain a comprehensive view of every increment, and quickly identify areas for continuous improvement. The quality of work delivered to the business will be stronger, productivity will increase, and so will the happiness of your team.

The Sprint Retrospective is extremely useful when used correctly.  After every Sprint, the team identifies at least one improvement idea to focus on during the next Sprint.  Remember, even minor improvements can result in an astonishing amount of change over time – so don’t neglect this valuable process!

Need more retrospective ideas? Keep following my posts on Agile.

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

 
 

Tags: , , , , , , ,

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: