I'm going to explore some scenarios: let's call them fiction - or perhaps the start of a first chapter in a novel 
.
The Story
So I had two conversations one fabled day that were, well, interesting. First; in a sprint planning meeting an exorbitant amount of time was spent on a previously unidentified backlog dependency. And later that day; a project manager took some resource allocation input from scrum masters as an indication that the sky was falling. The correlation between those two conversations and this post are abstract, however, they serve there purpose as muse.
To the first item: the dependency should have been placed on the product backlog and then a request for more information (offline) could have been made as, and more importantly, if ever needed. Remember, Scrum is an agile project management framework used to get organizations "unstuck". But the second conversation is one that is likely to result in some lasting issues. The reaction, by the PM, to the scrum master's status reports was to send out an inflammatory email to the PMO, IT and business executives alerting them to the process being broken. Now I won't go on about this, however, the concern here is that those people reporting to that PM will filter their statuses over time as a result of this type of reaction. This is a considerable issue as a promise of agile and scrum, in particular, is that product owners and executives writing the checks so-to-speak are provided with feedback on the track of progress early, often and accurately. Take a look at this article discussing TOC and why measurements are so important. The thing I take away here is that measurements also act as input (good or bad).
Both conversations were disruptive, distracting and wasteful (flow-down). Now I don't suggest that considerable elaboration is not at times needed and can sometimes get contentious, in particular, for increasingly complex problem domains: however, not the case this time. So I reflect a bit on process and management of constraints.
Background on the Subject Line
Boy it's been a while: but back in the mid/late 90s when the ERP boom was still in full ascent I became actively associated with, and am still a card carrying member of, APICS. Supply chain optimization and the subjects that the educational society promotes and deliberates over have ever since piqued my interest: the Theory of Constraints (ToC) being one of those interesting subjects.
Back then APICS was going through an identity shift as it changed its name from The American Production and Inventory Control Society to the Educational Society for Resource Management: this was a realization of sorts that supply chain as a concept was larger in scope than only production and inventory. Just in Time and Kanban was no longer en vogue now the concept and practices of Lean and continuous flow were “in”. Sometime in the last few years the society's moniker was again updated to the Association for Operations Management which many feel encapsulates an updated understanding of, what I often refer to as “the business of business”, supply chain. Note to self: an interesting post may be to consider the effects on ERP, financial and supply chain software vendors.
The Doyen of Supply Chain Theory
I can’t recall what exact year, but probably in 1999 I attended an APICS International Conference & Expo (one of a few). One of the sessions I attended, that year, was being presented by an attractive young lady who managed supply chain operations for Boeing. I remember being impressed with this young manager’s command of the topic and her position within the organization.
During the Q&A breakout, from the back of the room, a dingy, scratchy voiced middle aged guy with a cool accent and wearing a yamika chimed in to elaborate on a particular subject by request of the presenter. I was floored: it was Eli Goldratt nonchalantly adding some incredible footnotes and insightful caveats to the presenters answer. Funny: an IT manager in his early/mid 20’s (ahem) working at a multi-national company where ERP was being realized and implemented successfully across the enterprise considered this kooky old guy a rock star. Now this next tidbit could be fantasy, but I think I remember him smoking a cigar in the far back of the audience, which even back then wouldn't have been all that PC: but really cool.
So, as any card carrying APICS member would tell you – the books The Goal, It’s Not Luck and Theory of Constraints by Goldratt are must reads. His approach to his first book The Goal unconventionally was in the form of a novel, where the books hero, with piecemeal help of a former professor, turns around a failing plant he manages by finding bottlenecks and optimizing throughput. These books for me, and countless others, were not only eye opening but, interestingly enough, being able to quote ideas from Eli’s books has proven currency enough, in many cases, to ensure acceptance among the “in-the-know” of supply chain (and general business) practitioners.
Exploring the Similarities
Over time I’ve found countless non-supply chain domains where the Theory of Constraints was invoked, if in no other way but in my own mind, as a consideration when tackling a business or project management problem. I only recognized that I’d been fully assimilated, though, since applying/studying agile techniques and principles. Agile promotes continuous flow through its inspect and adapt mechanisms. Scrum's daily stand up, "the scrum", fleshes out impediments (constraints) and intends to resolve them right away. Sometimes these obstacles can't be resolved or even identified right away because they are too complex. Those longer-term impediments are what the Theory of Constraints seeks to address.
So I found myself, again, a few days ago asking a guy I work with if he'd heard of APICS or read at all about the Theory of Constraints. I asked this, of him, in the context of an organizational scrum adoption we’re driving at an MCS client. He'd heard of some of the concepts and, though his exposure was limited, he too was interested in the similarities I pointed out.
Sidebar (something I picked up a while back and I'm trying, poorly I'm sure, to paraphrase): that value is determined by how much the customer will pay for a feature or product and that value depreciates over time - time-to-market (and flow) is critical in product feature definition and delivery.
APICS, back in the day, in many ways, parallels the newer local and international groups forming now and culminating in artifacts like the Agile Manifesto and organizations like Agile Alliance and Scrum Alliance. Similarly, early pioneers are innovating along with an excited practitioner and academic community. Microsoft, in particular, has begun to realize and practice agile and scrum within their Patterns & Practices group and many of their major products are being rolled-out early to get community feedback on features and bugs. And among many others, the tier1 supply chain software company that Bennie and I used to work at as New Product Development Architects also adopted scrum to address creeping adoption and to ensure more nimble delivery.
So planning for and managing constraints is where the parallels between TOC and agile/lean software development get interesting. I'll explore this more in subsequent posts.
No Need to Hit a Home Run at Every At Bat
Though perhaps abrupt, I'm going to conclude this post for now and call it part of the larger agile discussion. I do, however, reserve the right to refactor if later determined appropriate .
Some closing observation as it comes to agile/scrum and TOC:
-
We don't have to hit a home run at every at bat but by adopting an agile/lean approach and embracing change we're more likely to win the game.
-
Identifying, and more importantly - avoiding, waste and bottlenecks and what is not adding value is critical.
-
Don't spend any time on unnecessary artifacts, processes and features: I find whole organizations promoting such poppycock.
-
And this one is important but not at first intuitive: agile attempts to delay decisions until the last moment they have to be made. This not only reduces design churn (paralysis) but it also results in decisions not ever needing to be made as things frequently change from the original expectation. So don't plan your sprints out further than you need to as the further out you plan - the less value there is in doing so.
Technorati tags: Agile, Patterns & Practices, Scrum
