The Laws and the rules
“The average number of work items in a stable system is equal to their average completion rate, multiplied by their average time in the system.” ~ John Little, 1961
“A Proof for the Queuing Formula” by Little, J. D. C. (1961)
I started a new series of posts where I will answer some actual problems/ideas presented in an I&A problem solving workshop as part of open space facilitation. This is the third of a few dozen that I plan on covering. If you have any comments, please, let’s learn together.
“Outside team interference and noise; unnecessary outside team involvement”
A SAFe Answer
This problem is not unique to the SAFe or Lean-Agile space. It exists in every organization I’ve encountered.
It is, however, a big, common problem. How many times have you or your team been “redirected” to work on the latest fire fighting drill? Was this time accounted for in the waterfall/traditional silo planned WBS that you are working against? I’m certain your manager and project managers always go back to the integrated master schedule (IMS) to reflect lost productivity. IMS’s always account for production down, maintenance, operations? Sure they do. Especially when the team doing costing gets to review the proposal and “tweak” the final numbers. [insert massive sarcasm]
I am starting a new series of posts where I will answer some actual problems/ideas presented in an I&A problem solving workshop as part of open space facilitation. This is the first of a few dozen that I plan on covering. If you have any comments, please, let’s learn together.
“being assigned features after planning before the Program Increment planning (PI/PIP) is complete”
A SAFe Answer
From a SAFe (and Scrum/Agile/Kanban) perspective, features (or stories) should never be assigned to a team. This is a common anti-pattern/fragile action that occurs during the early stages of cultural change where people are learning to let go of their theory X selves and dismantle the old belief system that people are dumb oxen that must be led by a bridle.
Remote teams and Lean-Agile frameworks
In this article I cover various strategies and methods for effectively implementing and using Agile, Scrum, Lean and Kanban (the system) for globally remote teams (virtual workforces, telecommuters). I will also attempt to debunk the myth that Scrum may not be used for remote teams. We are not going to deep dive into the “Agile” mindset, values, and principles (Agile Manifesto) or Lean thinking here. Although, they are the critical foundations for using / implementing Scrum effectively.
Over the years I have heard many people say that you can’t “do” Scrum with remote teams or some other such nonsense. I find this fascinating because I have done Scrum with remote teams for years — successfully.