What can a Scrum member do when they have finished commitments but Sprint is not done?

Frequently, this question comes up in agile and scrum teams. And, it did come up with senior officer I was mentoring on agile practices. The scenario was that a team member had finished their sprint commitments and had capacity. The team member has also asked other team members about assisting in their work. The other team members were self-sustaining and were focused on their commitments and reasoned that breaking their commitments could only increase more context switching and delays. What should we do? 

To a large extent, this is a good situation because the team is self-organized and showing good signs of maturity. From a Bruce Tuckerman's team point of view, they are in a "performing" stage. But, should the team member waste their capacity? Let us look at a few scenarios. 

First, should the scrum master assign any task to fill the capacity? Well, the scrum team breaks the user stories into tasks. So, assigning new tasks to that member is not promoting self-organization. On the other hand, the scrum master should coach the individual to look for opportunities where they can add value. If the goal is delivering incremental value, then, what can they do? Updating documentation, refactoring code, taking training, and improving CICD processes are all examples where they can add value. 

Second, should the team member review the backlog and pick up user stories to add to the current sprint? Well, this is a two-part question that has different answers depending upon the business practice. Anyone following the Scrum in theory would advise that additional user stories can not be pulled into the current sprint that would endanger sprint commitment. If you parse this point, no work can be added that would compromise sprint commitment. That is true! But sprint commitment is by the team and not by an individual. If the individual has already asked the other team members to support on their sprint commitments and have no team member needs the assistance, then, sitting idle and wasting capacity is not going to add value! This is where the Scrum is also forward looking suggesting backlog refinement as an additional ongoing/continuous activity. So, the team member can rightfully review the backlog (which by the way should be prioritized by the product owner for at least two upcoming sprints) and more clarity from a customer, business, technical, and process stand point. 

A good product backlog should also have some experimental stories - not himportant now but may be in the future. Recall Scrum approaches also recommend the MoSCoW (Must, Should, Could, Won't) for prioritization. So, reviewing and perhaps even picking those research oriented spikes is definitely an option. Since not finishing them does not compromise the team member's commitment, unless of course their work is in the direct critical path of the existing sprint commitment of others, then, working on such experiments only add value. For instance, an AI based experiment to do things better or automating some work to improve CICD processes, etc. 

Finally, can the team member pick one of the prioritized stories and possibly begin working on them. Designing or developing on that user story is sometimes looked down upon because that work can not then make it to the current sprint. If work done on that user story not committed to the current sprint is proactively being worked on, only because the current team member does have excess capacity that the scrum team cannot leverage, then, such a proactive work can make it to the next sprint (because it is prioritized high already in the backlog) with a lead on the schedule for the next sprint. That is facilitating the delivery of working software faster! 

In summary, having excess capacity is an opportunity. Scrum is mainly about working agreements among the team members. It is an opportunity to look at these ideas and see how cross-training, documenting, role-playing, and experimentation can all be factored into backlog and agreements made when such opportunities arise. Wasting valuable resource time neither contributes to productivity or throughput and only contributes to waste (non-utilized resource is one of the lean waste). So, build quality more consciously in scrum.

Thoughts? 

Kanban India 2023: Reflections on Kanban Awareness

I had an opportunity to present a 90-min workshop on boosting business agility leveraging Kanban principles in the Kanban India 2023 conference organized by Innovation Roots in Bengaluru, India. This conference was represented by various types of people from many industries but mainly from project management offices and information technology professionals. So, it was not surprising for me to see the diverse roles of project manager, product manager, product owner, director or project management office, agile coaches, scrum masters, and a small percentage of resource managers and senior leaders. However, what surprised me largely was the complete unawareness of the Kanban principles by almost all the 30+ members that sat in my workshop across all these previously represented roles!

First, Kanban is not a framework or methodology! It is a method because Kanban can be adopted within any plan-driven or adaptive framework as well as the organization specific methodology adaptations of these frameworks specifically within their organizations! Without understanding these distinctions among framework, methodology, and methods, people have rushed to the same thought process of how they conceived waterfall methodology when the original author never even promoted the concept of such linear waterfall thinking (Rajagopalan, 2014). Instead, Kanban has been conceived as a set of cards organized in status-driven swim-lanes such as "To Do", "Doing" and "Done". 

Figure 1: Dr. Rajagopalan's synthesis of value flow

Contrary to popular thinking of Kanban cards in such statuses reducing the Kanban implementation as a tactile execution, Kanban has a set of principles that promote business level systems thinking among the team members for strategic value delivery. Since value itself flows both vertically across projects, programs, and portfolios (and hence the notions of benefit management in programs, value stream mapping in product management, and expanding these concepts with risk management in programs and portfolios), Kanban applied the lean manufacturing concepts combining managerial (efficiency) and leadership (effectiveness) with a concerted qualification efforts (efficacy) applying five important principles. Without all these five thoughts, business agility with both horizontal and vertical value delivery simply does not exist!

Figure 2: Dr. Rajagopalan's adaptation of Kanban Principles

First among these principles is the Andon thinking promoting the notion of team accountability through a transparent visual factory. While the Andon thinking emphasized team level ownership by allowing the team members to self-organize using the visual cards and queue buildups towards better documentation and training as needed to ensure cost of quality! 

This team accountability was supplemented with Jidoka that ensured people thought value delivery from an overall system (not just tactical cards like how people conceive of tasks and subtasks) but the combined influence of all these tasks towards benefits (requirements, specifications, design, quality, etc.). This "systems thinking" thought process also elevated people to relieve themselves of mundane tasks (for the sake of doing them - remember being busy is not being productive) by intelligent automation wherever possible. 

This simultaneous concept of thinking both from a systems perspective and automating mundane activities intelligently also was supported by teams and their line managers (hence project managers, product owners, scrum masters, agile coaches, managers) thinking of Heijunka bringing the resource optimization principles of reducing unevenness and minimizing overburden in distributing work for people or load with systems and processes. The entire notions of the total quality management (focusing on muda, mura, and muri) emerge from these Heijunka thinking for cost of quality!

As people owned the processes (means to end) that supported in delivering products (evaluating value for customers), the focus on Kaizen emerged on continuously improving the processes (simplifying documentation, training, reducing errors (Poka Yoke, for instance), risk management, etc.) and evaluating customer success factors and business benefits. This is when objectives and key results (OKR) were evaluated with the right level of key performance indicators (KPIs) along with built-in quality thoughts of critical success factors (CSF). 

Just to ensure that Kaizen thinking itself didn't apply to product and process increments in a monotonous way, the systems thinking was further advanced by radical innovations of continuous experiments. This thought process led to Kaikaku ensuring that everyone contributed researching market trends in augmenting business value by doing something innovative avoiding the notion of "this is how it is done here" (Kotter & Rathgeber, 2016)

As Kotter & Rathgeber (2016) very nicely discuss the using of meerkat colonies organizing differently to deal with emerging threats to their survival, it is pivotal to understand the principles of Kanban rather than bring it down to its knees by reducing them to a set of nice visuals (cards and swim-lanes) limited to the tools used! If all these principles are not understood and practiced, no tool or technology can help the teams to swarm, self-organize, and survive!

References

Kotter, J. & Rathgeber, H. (2016). That's Not How We Do It Here!" Plantation, FL: J.Ross Publishing.

Rajagopalan, S. (2014). Review of the myths on original software development model. International Journal of Software Engineering & Applications, 5(16), 103-111.

Adapting Scrumban to Personal Productivity

Agile approaches to product development and project management are growing exponentially. I have been a proponent of the lean approaches even at my house chores and recently found that such approaches were discussed even in the Agile 2014 conferences. Unlike Scrum’s requirements to have self-organized teams with timeboxed iterations within which changes are generally frozen and disallowed, the project management approaches do not rejoice the dedicated team. Often, the members may be spread across multiple projects like project managers having multiple projects. So, how do we manage time effectively in multi-project and program initiatives?

An approach that I have found useful is adopting Scrumban to proactively manage myself and build on the team’s innate strengths to empower themselves to do better. Sounds great, but how? Let me explain.

Scrum

Kanban

1.       Scrum focuses on timeboxed iterations with self-organized cross-functional teams. 2.       Team decides on what can be accomplished in a 2-week sprint and emphasizes continuous improvement by retrospectives 3.       The customer representative is expected to be sometimes on-site and be multi-functional with skills in product, project, account, technical, business analysis, etc. 4.       Measure of progress is working software delivery

1.       Team visualizes the workflow in queue 2.       Anyone can pull (i.e., take) any task that is in the queue 3.       Tasks are generally not dependent 4.       Balances work in progress 5.       Reduces waste between tasks

In traditional project management where resources are not procured for the duration of the project or in balanced matrix organizations where projects inherently face wait times, such as in regulated and construction industries, the project team may not be multi-functional. Therefore, it is not possible for any member of the project team to take on any project or tasks within the project. For instance, can a tester write code? Can a database architect develop deployment requirements? Can a project manager be a business analyst? While technically these are all possible in high performing organizations, other organizations may not have resources that have multitude of skills where roles can be effectively merged eliminating waste.

Here is where Scrumban comes to help. It combines the best of both the Scrum and Kanban worlds. Tasks become structured (design a program overview, develop the stored procedure, test interactive voice response for a specific Voice XML flow, etc.) to be executed by anyone within a specific group. The group or functional leader is entitled to provide the guidelines and process direction for continuous improvement reducing cycle time increasing predictability in productivity. Example, regardless of who develops the program or tests the campaign, in the given service level agreement of 5 days, the program will be developed or tested. Yet, workflow need not be limited to changes only between iterations thereby allowing new tasks to be created eliminating wait time and allowing the team to prioritize projects.

While Scrumban is a great alternative where neither Scrum nor Kanban can be effectively applied, I found out that I can use it to manage myself to be productive better in multi-project, program, and portfolio management. I have illustrated this in the above figure. From my point of view, the team is the expert, and I am just a facilitator. So, when the team has been provided with a task, it is in progress (Yellow sticky). Now, what am I doing when the team is working on it?

I don’t need to hold a meeting to check on progress – that’s project management by unnecessary meetings. But I shift my gears to what the team may be requiring next – eliminating all ambiguity for the potential next task. As a project manager, I focus on the upcoming milestone working a step proactively ahead (Blue sticky) and work with the stakeholders to get that ready so that when the work in progress is done, I am servicing the team with the next unambiguous task. This comes in handy when the team is virtually distributed because in such cases where communication needs to be both pull- and push forms, I have time to over-communicate! This is an example of what I label as 6P principle (Proper proactive planning prevents poor performance!)

Now, the more I work at this the more effective I become and so I work another step – 2 steps ahead – and work with the client, product, account or other teams to push them to deliver on their deliverable ahead so that there is no impact to critical path (Green sticky). I stop at 2 steps only because in my mind I am 1 sprint ahead and my agility hat tells me that there may be change coming that I need to prepare for.

Let us take it to the next level. May be the green sticky (Product, account, client, or other teams) can’t do anything because they are waiting on something else. Then, so much of time becomes unfrozen. Immediately, that means productive hours can be provided to another project. This is an approach to doing more with less. This next project could be part of the same program, product, portfolio or a totally different project for a different client or even developing a hobby, helping another team member, writing this article, or dedicating time for a cause. 

This is an approach I have used to timebox all the incoming work so that within the given time available, I am still able to keep multiple things moving! 

Differences between Kanban and Scrum

Recently when attending the 5-day Agile 2014 conference in Orlando, Florida, I had an opportunity to discuss various agile implementations. Some of the discussions centered on selecting the right type of agile methodology to consider for software implementations from extremely regulated medical devices industry and government projects where Scrum was considered prevalent. Then, when I found in my network of work and friends, there were questions that revolved around using Kanban because Scrum wasn’t working.

Having used Kanban and Scrum, I wondered why there is still confusion among the early adopters of Agile and why Kanban would be considered as a substitute for Scrum. Unclear understanding of agile concepts may lead to failure just like how people created a non-existent theory of waterfall based on inaccurate practices (Rajagopalan, 2014). So, I focus below on a comparative study of the basic premises between Kanban and Scrum. I hope this article captures the essence of these approaches demystifying the confusion and helping in the selection of the right approach for the challenge at hand.

One of the primary differences is that Kanban is a method that can be used independently or along with other approaches like Scrum. This is why we even have derivative approaches like the Scrumban.

Concept	Kanban	Scrum
Management focus	Maximize resource usage avoiding delay and enhancing accountability to support flow.	Consistent delivery in the cadence of execution, as the features in the product backlog is delivered.
Operating rhythm	No time-boxed iterative development exists.	Time-boxed iterative development – usually two to four weeks.
Granularity of work	Focus is at the task level for which the scope of work is generally known.	Focus is at the user story level for which the scope may not always be known, requiring it to be estimated before tasks can be identified and taken up by the team.
Agile Estimation & Planning	Estimation is generally not done. There is little to no ambiguity on the task that any member of that team should be able to take on the next available task and execute it.	User stories are estimated. Then, they are prioritized, and risk adjusted so that these are included in the release and iteration planning.
Value Delivery	Every task completion may not necessarily add minimally marketable value to the customer. Task identification and dependency require careful coordination.	The cadence of release and iteration planning focuses on adding minimally marketable feature through the scrum cycle. The self-organized team determines the task identification and dependency.
Progress Tracking	Flow of items throughout the lifecycle limiting delay. This is why the focus is on limiting “Work in progress (WIP)” is promoted through “Don’t Repeat Yourself (DRY)” focuses on maximizing work not done	Focus is on tracking the velocity measuring the user stories done and delivered to customer in an iteration
Utility value	Better for managing workload and resource management. E.g.: How many projects of different combinations can be taken up by a project?	Better for managing products, programs, and projects.
Thoughts to consider in software development	Use of Kanban for software development may impede flow if all the units don’t consume the work produced at the same speed. Therefore, additional processes must be in place to support Kanban. E.g.: QA not having capacity to test code developed by engineering team. If QA’s capacity comes from the fact that more defects are found in the build, then, more granularity in tasks to ensure proper code review, unit testing, and documentation are processes that the organizations must have in place.	Implementing Scrum doesn’t mean the ability to write user stories and avoiding documentation completely! This requires a management shift to ensure critical thinking on the product, program, and projects. If iterative delivery is not understood by the management and client, then, Scrum is not an option to consider.

In summary, Kanban and Scrum are both light-weight approaches, but the operating philosophy is different. Scrum focuses on the work being delivered to customers through multiple iterative deliveries of minimally marketable value by assembling a cross-functional, skilled, and self-organizing team or team of teams. Kanban, on the other hand, is a pull-based system and focuses on the visualized workflow where flow is maximized by limiting what gets worked on by the team. Although both approaches require prioritization in the items represented in the backlog, Scrum team can’t pull an item outside of the Sprint backlog when they have capacity. Kanban team can pull the next priority item from the backlog. So, depending on what product, service, or result the team is delivering, or the benefit being sustained in operations, Scrum, Kanban or Scrumban may work. Select the right tool for the right job!

Thoughts?