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? 

Attention or Time Management

Flying over India returning from Mumbai to Chennai, I was browsing the Jet Airways magazine. Often filled with travel recommendations and shopping suggestions, these in-flight magazines have only created a browsing pleasure. But this magazine had a topic on achieving more with less perking my interest to explore.

It was an interesting read as the article began discussing how  time management pretty much shouldn't be the focus of smart managers. Instead, the article focused on attention management. Based on the time of the day, people can manage difficult tasks that require deep thinking, strategy, etc. when their attention to detail is at its peak. Then, as the energy winds down, their attention takes a deep dive. This time should be used for tasks that require less critical thinking.  Between these extremes is the reactive attention seeking time zone that should be used for other tasks that require a balance of the two.

I agree that it is a good idea and that tasks require different levels of thinking. For instance, planning for the project, evaluating strategies to grow accounts, or grooming the product backlog with new features based on the market and reactions from customers and users require thinking different from task or resource management.

However, the article said the urgency of the tasks shouldn't be a criterion for attention management.  This begs some thinking as depending upon the role of an individual manager, the urgency of the task, such as a grieving customer on the phone, an infrastructure deficiency leading to business continuity management, or a delayed or poor-quality work impacting deployment readiness of a project is not something that can be ignored.

The earlier approach on using Scrumban to think a couple of steps ahead and plan can be combined with attention management to better compartmentalize take at hand and energy/attention requirements to better manage productivity.

Thoughts?

RACI: An important tool to manage project outcome and stakeholder expectations

A few years back in a 2-day workshop on organizational strategy to structure, I saw the facilitator came up with the RACI chart and fumble on the RACI explanation confusing “A” in RACI to “Aid.” In a different situation, the vice president of a client management group was referring to giving copyrights to his manager for coming up with the RACI model. Recently, when I saw the RACI matrix for a process map on a sales-to-execution role definition, I saw processes where the same owner was both responsible and accountable and some areas where there was no person was identified as accountable.  The more I am in management, the more I am feeling that key important stakeholders should become trained on fundamentals of project management, such as the tools associated with Project Management, so that they can position the projects for success and even inadvertently don’t derail the projects.

There are several reasons why a RACI chart is required. The most common ones include when the organization is large enough that simple project communication tools alone would not eliminate role ambiguities efficiently controlling costs to the organization. The subtle reason for requiring a RACI becomes essential when the organization is siloed where several members are working on similar tasks creating waste and not making the organization lean. From a project, program, product, & portfolio management perspective, this RACI tool surfaces to the top of managing risks to these strategic initiatives as middle management wonders if they have the authority to implement their job or projects experience schedule slippage, scope creep, cost overrun, and escaped defects.

So, how does this manage strategic initiative from project to portfolio management?  Now that we realize the importance of the tool, let us ground our thoughts here in relating this tool to stakeholder and risk management. Here are my thoughts!

Role	Description	Stakeholder
Responsible	The individual performing an activity.	This person does the work. It may be a developer, tester, data analyst, or network administrator in software development or a project manager in a project.  In the Power-Interest grid, the R members are mapped to the "Keep Informed" (Low Power, High interest) quadrant for the most part.
Accountable	The individual ultimately accountable.	This person is answerable to the management in managing the client and the project’s profitability. An account manager, product manager, project manager, executive sponsor, functional manager are all examples. This person should also use the risk register effectively by mapping the risk owner to the RACI. In the Power-Interest grid, the A members are mapped to the "Manage Closely" (High Power, High interest) quadrant for the most part.
Consulted	The individual required to offer input and contribute to the activity.	This person offers 2-way communication and is a domain expert. This person should hold both “Responsible” and “Accountable” person in check if only they consult. This person alternative risk management techniques like the root cause analysis, force field analysist, and SWIFT (Structured What If Thinking) promoting thoughts that may otherwise be missed impeding flow. May be able to roll up the sleeves to do what these above roles should do. Can take on the roles of Director, Proposition Manager, Business Architect, Project Manager, etc. In the Power-Interest grid, the C members are mapped to the "Keep Satisfied" (High Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.
Informed	The individual that needs to be informed of the decision and its impact.	These are the people that PMBOK calls as stakeholders that can be positively or negatively impacted by the project’s outcome. These stakeholders must be managed so that unnecessary escalation and project derailment does not happen.  The “Informed” is not limited to organizational employees and business units but customers, vendors, partners, and end-users depending upon projects or product’s goals. In the Power-Interest grid, the C members are mapped to the "Monitor Marginally" (Low Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.

Every tool in the Project Management Book of Knowledge is so critical that it has its place in managing the project’s outcome. Understanding its purpose and utilizing it appropriately is critical to any organization’s job. RACI is an important asset to any management to eliminate waste, increase efficiency, and enhance stability.

Now, how do you foresee its use in your organization, business unit, and product or project management? Share your thoughts!

References

Project Management Institute (2013). Project Management Book of Knowledge. Fifth Edition. New Town Square, PA: Project Management Institute.

Enhancing Productivity

Today’s corporate world is characterized by increasing pressure to deliver more but of uncompromising quality at a better rate. Increasing efficiency of production using just in time production is not new followed by build-on-demand concepts where value add to a customer takes on the focus in agile software development.  Regardless of the industry and product built, how can today’s projects still deliver increasing value maintaining the strict adherence to quality?

The fundamentals of iron-triangle of quality by managing the levers of scope, schedule and cost is still present but timelines are requested sometimes without clear scope, schedule then is accelerated to meet customer’s demands, and still cost is allowed not to increase both in operational and capital expenses. Keeping the focus on operational expenses, the question often evolves: How to measure and enhance productivity?

I believe the basics of productivity are in clarity, duration, and customer management. For projects that have somewhat known scope, such as extending a product installation in a different client site that can leverage past lessons learned, the clarity is not an issue. But, for new initiatives, the product scope may be evolving, and this is where delivering to what is known using agile concepts may be beneficial.

But the basics of duration management are differentiating the type of hours that go into the project. Productivity losses come from two types of hours that derail the project because productive time is taken out of the duration because the “right” people are not on the “right” job at the “right” time.  These types of hours are as follows.

1. Non-Project Hours – Delivering no value to project but time for internal process enhances, functional department meetings, training, company meetings
2. Non-Productive Hours – Time lost due to ambiguous work, lost work requests, unnecessary meetings, doing other’s work, assumption about roles, lack of accountability, etc.

The basics of project management differentiate duration from estimate in addressing the first component which is often misunderstood. Agile concepts address these by using ideal time to ensure that the story points are properly incorporating enough time to develop value. But the second part is the difficult one that the management needs to spend additional time in ensuring that properly motivated and trained people are present, tools are sufficient, and collaboration is cohesive.

In terms of the customer management (remember client is both internal and external), the productivity goal should be to maximize hours charged to a project, establish a baseline for products of similar nature and use appropriate time entry/approval methods to evaluate against the baseline, forecast and promote predictability of workload and hold everyone accountable. The principles of stakeholder management are no wonder a newly added separate dimension in the Project Management Book of Knowledge (2013).

In summary, productivity measure is rooted in people, process, and tools that allow the job to be defined in adequate detail, breakdown accountability by increasing collocation, introduce distribution tools for effective collaboration, lead instead of managing the clients more effectively, and use process as a key vehicle to integrate the whole in a virtual distributed environment.

Thoughts? 

References

Project Management Institute (2013). Project Management Book of Knowledge. Fifth Edition. New Town Square, PA: Project Management Institute.