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? 

Agility and Scrum: Conversations outside of IT Software World

Through some of the corporate training work I had done, I got a referral to work with a couple of professional entrepreneurs in India. They were trying to introduce efficient ways of working through a combination of process improvement concepts and tools in the construction space. As part of the initial interview, I found out there was an executive level interest in increasing focus on building people up with experimental ideas to pilot and pivot! Naturally, I explored the notion of Scrum or Agile and there was an almost immediate dismissal of these concepts. The two people echoed, "I am not sure how much these IT thoughts apply in improving ways of working!"

Although our conversations never materialized in any work after 3-4 months, I felt compelled to write about how much work Agile and Scrum must deidentify themselves from their use mainly in the IT industry. I guess the Agile Manifesto principle, "Working Software over Comprehensive Documentation" has served itself to exclusively apply to the software product world. Perhaps the lack of diversity and inclusive thinking in the original Agile Manifesto thinkers has created a stigma about the Agile ways of working to the IT industry. However, as I have already mentioned about Agile being applicable in a non-IT setting (Rajagopalan, 2013), agility can be extended to healthcare (Rajagopalan, 2021). For example, replace "software" with "healthcare" to read as the "Working Healthcare over Comprehensive Documentation," and the principles can extend outside of software development.

Both Agile and Scrum are about empowering the teams to have a working agreement to solve a problem identified (or self-identified) for them by the organization. If the organizational culture is conducive to failing forward rather than punitive, any industry can apply these frameworks, which shouldn't be restricted to any industry. Consider, Andon Chord, that originated in the manufacturing assembly where all works stops to ensure that the team collectively engaged in problem solving! Examples of Andon Chord from Lean Manufacturing have found themselves applicable in many industries with the simplest example of "Stop Requested" in public buses! So, Agile and Scrum are both about the 'ways of working' where the teams are enabled to improvise with experiments to pilot and changes to pivot. 

Now, if you look at Dalmia cement, there is a lot of information about their partnership engagement with KKR (2016) that made them prosper. In that video they talk about five pillars such as learning & humility, teamwork, speed, excellence, and transparency (Alchemy: The Dalmia Bharat - KKR Partnership, n.d.). These are directly related to principles of courage, focus, openness, respect, and commitment of Scrum which emerge from the agile empirical pillars namely transparency, inspection, and adaption. Similar concepts can be seen in the US based Holcim Group, one of the famous cement producers where the very first sentence talks about the industry's focus on using agile management.

Transparency is already identified in the Dalmia/KKR partnership as pillar #5. When you look at the thoughts on speed, they talk about having a 100-day plan, metrics, process, roadmap, and experimentation! It is about the ways of working which enable the second pillar of teamwork. The focus of experimentation without the fear of failure is already mentioned that talks about trust, communication, and teamwork without which excellence does not come in. I challenge that the principles of agile and scrum are already applied but not understood. If the right tool and the framework is further identified, think about how it could improve! 

Example Scenarios presented by Dr. Sriram Rajagopalan

Similar examples are found in other industries as well. The Food & Drug Administration (FDA) allowed the use of Agile in Life Sciences and Healthcare (Deloitte, 2020). Here, there were focus on adopting risk- based governance in an iterative way addressing toxicology and pharmacology safety in clinical studies, adverse reaction protocols in later phases, and occupational hazard protection before, during, and after drug development. Centrus Energy, an international commercial nuclear power plant completed their R&D initiatives using Agile approaches (Stracusser, 2015). Telpak (n.d.) using the robotic process automation (RPA) for good manufacturing practices (GMP) and CSol's (n.d.) focus on laboratory insights for good laboratory practices (GLP) are all examples of Agile mindset. In fact, I see these agile approaches pave their foundation for the general automation manufacturing protocols (GAMP) as well. 

But such non-IT industry focuses need to be highlighted more! The stigma that Agile and Scrum applies to IT and Software product development is continuously emerging with DevOps and SAFe with too many technical terms proliferating solution-mindset in non-IT industries. So, many practitioners have more work to do! Who is willing to partner with me to write such case studies? 

References

Alchemy: The Dalmia Bharat-KKR Partnership (n.d.). https://www.youtube.com/watch?v=gxXxtMYKprg

CSols (n.d.) Agile development in Laboratory Informatics. https://www.csolsinc.com/blog/agile-development-in-laboratory-informatics/

Deloitte (2020). Validation using Agile in the Life Sciences and Healthcare Industry. https://www2.deloitte.com/content/dam/Deloitte/ie/Documents/LifeSciences_Healthcare/IE_RA_Agile_0320_.pdf

KKR strengthens association with Dalmia (2016, Jan 15). PR Newswire. https://www.prnewswire.com/in/news-releases/kkr-strengthens-association-with-dalmia-565397881.html

Rajagopalan, S. (2013). Agility outside of software world: A case study from a theatrical play. https://agilesriram.blogspot.com/2013/05/agility-outside-of-software-development.html

Rajagopalan, S. (2021, Mar 8). Agility in Healthcare Services: Insights from Clinical and Surgical Settings.

Straçusser, G. (2015). Agile project management concepts applied to construction and other non-IT fields. Paper presented at PMI® Global Congress 2015—North America, Orlando, FL. Newtown Square, PA: Project Management Institute

Tekpak (n.d.). Pharma Competency. https://tekpakautomation.com/pharma-competency/

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! 

Role Mergers: Is middle management – product, account, program, and project - learning from failure?

Based on the interactions I have had with attending various webinars, seminars, networking events, and conferences and bringing them to practical work, I always ponder over a question. Is middle management – product, account, program, and project - learning from failure? I share my viewpoints on the role mergers and how many are not rising up to the requirements leading to inefficiency. 

Traditional project management roles defined frequent lessons learned or post-mortem sessions and agile development practices recommended a retrospective after iterations so that inefficiencies can be addressed. With so many different types of projects, multi-project program initiatives, products developed, and accounts managed across multiple industries, have we incorporated the lessons from our failures and most importantly other people’s experiences of failures!

My definition of failure is that if we have not learned from our failure and success, then, we have a failure. If we have learned from our failure to adjust our processes to avoid repeating the same mistake, then, we have turned failure inside out. By that definition, we can’t agree that we have benefitted from the rich experiences of failure and success entirely.

In one of the Account Management seminars that I recently attended, I heard that one of the fundamental reasons for account management failure is the lack of understanding about the products and services to provide strategic direction towards solving the customer problems. Digging deeper, Kim Zoller and Kerry Preston in their book on Enhancing executive edge relate the account management operating from a quarter-to-quarter or similar frequency on their accounts (called opportunistic) will only derail even the best project management to fail unless the account management becomes relationship based and customer focused.

But is the relationship only with the client? If we say customer focused, are we not treating employees and internal teams as customers? Think about it! Relationships with internal teams are equally important as they are the ones that deliver!  Our clients watch these things too because if you fall for everything and yield to everything the client asks then you stand for nothing, losing credibility with the client and the team.

Interestingly, Schultz and Doerr (2014) from RAIN group called out in their strategic management failure white paper that the strategic account management roles will be coming with the backgrounds of relationship lead, entrepreneur, innovator, collaborator, consultant, researcher, project manager, and skeptic. In their attempt to describe this interaction as connect, convince, and collaborate, this was an interesting finding because it brought the characteristics of a product manager or product owner of how they collaborated with the client and team grooming the backlog but also playing the devil’s advocate from both the client and the value for performing organization. It also integrated how the account manager roles need to understand the foundational project management thinking that also looks for risks, schedule, scope, cost, quality, integration, and stakeholders. Even agile teams are introducing the acceptance and behavior driven testing where additional test cycles will be added to ensure that the business team performs the acceptance testing before products and projects are released to customers.

Woven deeply in these observations is the skill/task alignment required! Technology is so pervasive today but how much technical understanding is today’s middle management exposed to! Like the saying goes in the “Die Hard” movie, “you are the wrong man in the wrong place at the wrong time!” Businesses allow many reasons to continue having unskilled or untrained resources and expect a miracle instantly! Mike Schultz and John Doerr further relate to this in “Wrong People, Wrong Roles” in mandating a minimum of three skills – leading relationships, finding innovative ways to create value, and driving your (performing) organization and (client) team to get things done. As you can see these mean that no longer are the businesses requiring skilled personnel in one area but multiple skills in other areas.

These findings resonate in the fundamental Agile principle of self-organized team! If the team depends on others to initiate, route, and manage the tasks, then agile in such cases will fail! This is also the reason why Scrum didn’t even have a “Project Manager” role in their roles merging this role with either one of the three roles depending upon the multitude of skills in the project manager – account and product management knowledge.

Keane, a consulting organization in their “Productivity Management” book recommended that productivity comes when business teams, customers, and developers are all brought into one training event to hear various sides of the productivity spoilers and address them through processes. Once these processes are addressed, the onus shits to the people! Projects predominantly fail because of people and not because of processes! Extending these thoughts even from a sales perspective, Pink (2012) recommends the new adage of attunement, buoyancy, and clarity where the sales need to engage in problem-solving more! 

Even educational institutions are not an exception and recognizing this need. In one of my recent exchanges with a University in their Visual Arts and Animation curriculum review and design, the school professors were reiterating how the expansion of cultural diversity requires learner's understanding of the target markets and industry expectations of multitude of diverse skills in the graduating learners as part of the experiential learning approach. An example is having the narrators be able to write scripts, graphic artist to know and introduce animation, public relations communication member to modify the approach impromptu when the target market for the same product has changed.

So, there is a revolution happening! Customer service is no longer one department, and it sits with every person in every department. Roles are merging in the middle management because businesses are flattening the layers and going lean in their model. So, the middle management need to wake up and smell the completion and brush up on their knowledge to be multi-faceted ready to wear many hats. If not, failures are designed to repeat!

Thoughts?

References

Pink, D.H. (2012). To sell is Human: The surprising truth about moving others. New York, NY: Riverhead Books. 

Plummer, D.H. (1995). Productivity Management: Keane’s Project Management Approach for Systems Development. Boston, MA: Keane. 

Schults, M. and Doerr, J. (2014). Insight Selling: Surprising Research on what sales winners do differently. Hoboken, NJ: Wiley & Sons. 

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?