Thursday, April 27, 2017

Words matter -- anti-Agile dictionary


Peter Hyde has a great piece in Front Row Agile about the ever emerging linguistics of the Agilists. He has his "top 10" of anti-Agile words and phrases.

Here are a few from his list that would make my list (by the way, Hyde is looking for more, so if you have a favorite, get in touch with him)
  1. Agile in Name Only, or AINO: Companies that have adopted agile frameworks and practises without embracing the cultural changes required.
  2. FrAgile: Agile practises that are performed without rigour or discipline. FrAgile provides an excuse for poor quality development that avoids accountability.
  3. Lipstick Agile: Agile practises cosmetically applied without any understanding or noticeable difference to the true nature of development. In other words, you can put lipstick on a pig, but it will still be a pig.
  4. TrAgile: Tragically implemented agile frameworks or projects that end in tragedy.
  5. Wagile: A hybrid of waterfall and agile development practises resulting either from desperately trying to save failing projects, or from slipping back to waterfall from agile.
  6. Zombie Agile: A blind adherence to agile practises without adopting the mindset required to make them work.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, April 24, 2017

Square pegs; round holes -- the HR problem



Donald Rumsfeld -- former Secretary of Defense -- was criticized widely for his statement: "You go to war with the army you have, not the army you might want ..."

Substitute "project" for 'war' and "project team" for 'army' in there and it might appear more familiar than many of us want to admit.

I've always maintained: "You organize according to the staff you have, not the staff you might want"

Now, I find no less an eminence than the team of Reisman and Glazer, who wrote the HR classic "The Lonely Crowd", called by some a landmark study of the American character, said something similar to what both myself and Rumsfeld have said, only they wrote it many years ago:

" .... [Although] different kinds of characters can be used for the same work within an institution, a ‘price’ is paid by the character types that fit badly as against the release of energy provided by the congruence of character and task."  As quoted by Doris Kearns Goodwin in "Lyndon Johnson and the American Dream"

By that team Reisman and Glazer mean what?
  • "Character types that fit badly" are those staff or team members who can't do the job you have assigned them to do. They will either spend a lot of their energy getting nowhere, or they will suck up a lot of your energy trying to get them to do it 
  • "Congruence of character and task" is their speak for "the job you've asked them to do"

It's no coincidence I've named my consultancy "Square Peg". The organization chart, like staffing plans, and every other type of plan, rarely survive the collision of plan with reality.*

*Planning is good; it turns up a lot stuff that heretofore was under the rock. It's just that plans themselves often have to change
 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, April 21, 2017

System Engineering FAQ



A lot of PMs know they need systems engineering, or think they might, but aren't sure who these folks are or what they do.

Here's my FAQ I used when I was a Director for systems engineering for an aerospace and communications firm

(And, I tried to make this not to stuffy!)





What is this thing called system engineering?
  • What is system engineering? Here's the way NASA defines it: "System engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system"
  • What do systems engineers  (SE) do? Primarily, they have three work areas: system architecture; system feature, function, and performance; and system validation. Included in these three work areas are the system 'ilities', system risk management, major interfaces, and optimization among competing constituents. And, SEs contribute to the major project plans as directed by the PMO. 
  • Why is system validation one of their responsibilities? First, SEs are independent of the developers -- and independence is a good thing for validation. Second, the SE is charged with maintaining a holistic view of the system; this view should inform system validation procedures. And, third, this puts accountability into the mix: SE is actually in the workstream that makes it work!
  • Are there standards and protocols for what SEs do? Yes, like the body of knowledge for project management, there is a generally accepted body of knowledge for SEs. For instance,  INCOSE -- the SE counterpart to PMI or APM -- maintains a body of knowledge in their System Engineering Handbook. Among free resources are those in the public domain from the US DoD/SE and NASA.  Of course, there's also the ISO standard 26702, among other ISO standards on various disciplines with SE.
There's always the planning issues:
  • Do SEs have their own workpackage or swim lane? Yes, it's customary to uniquely track cost, schedule, and deliverables of the SE activity
  • Who do they report to? Typically, SE reports to the PMO
  • What's a good benchmark for cost? Benchmarks depend on the nature of the project. For studies, the SE could be the whole project; for a typical development with a generous system validation activity, SE could be as much as 40% of the cost, but probably not less than 8%.
  • Do they have deliverables? Yes, SE is not a level-of-effort; the deliverables depend on the specifics of the project, but for the most part they are plans, specifications, and procedures.
I get questions on this stuff also:
  • If SE are the architects, what is architecture? Architecture is that which defines/specifies/describes the overall boundaries of the major components and defines/specifies/describes the interrelationships and behaviors among the components. In some situations, the overall physical appearance and presentation may be part of the architecture
  • What are they thinking when a SE talks about a system? I've answered this before, but here's the simple answer: a set of 'things' -- constituents -- interconnected in such a way that they produce their own pattern of behavior over time. The way a system responds to stimulus is a characteristic of the system itself and not necessarily that of any of its constituents
  • Should I use SEs to pursue new business? Yes, many have good customer skills and can communicate conceptually to the thinkers in the customer community
  • Can I innovate without them? Anyone can be the innovator, but SEs are often cast in the role of coming up with unique and discriminating ways to do things.
And, of course, there's always the questions to end on:
  • What do I give up if I don't have them? Many projects don't have a SE per se and do just fine. However, on larger projects with complexity and scale, the architecture function is essential. If not an SE, then someone else with that role is needed for the activity
  • If my project team does this anyway aren't just redundant? Not really; they bring a mindset, attitude, bias, and skill that is unique to the SE tradecraft.
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, April 18, 2017

Integrated product teams



The US DoD has had the concept of the Integrated Product Team (IPT) for a couple of decades.  If you search "Crosstalk, the journal of defense software engineering", you'll find zillions of articles that reference the IPT.

And, if you search www.dau.mil, you'll also find a wealth of material. As the agile folks go about with multi-functional and persistent teams, they'll find that's an idea that was mature in DoD before the agilists were organized.

Here's few important points about integrated product teams (taken from training materials produced by Space and Naval Warfare Systems Command (SPAWAR) San Diego Systems Center):

  • IPTs are cross-functional teams that are formed for the specific purpose of delivering a product for an internal or external customer
  • IPT’s implement the IPPD Process.  DoD defines Integrated Product and Process Development (IPPD) as “A management process that integrates all activities from product concept through production/field support, using a multifunctional team, to simultaneously optimize the product and its manufacturing and sustainment processes to meet cost and performance objectives.”
 That's all well and good, but here's where their power comes from (and agilists will be sympathetic to this list)
  • (Team) must have vision or objective defined, including level of authority
  • Team should be multidisciplinary
  • Members must have both mutual and individual accountability
  • (Team) must have a decision-making process defined
  • Team members empowered to make decisions
  • Cost, schedule, and performance parameters pre-defined for the team
Of course, DoD is clever enough to know that one size does not fit all. Consider these various team possibilities:
  •  OIPTs (Overarching IPT)
    - acquisition oversight
  • IIPTs (Integrating IPT)
    - coordinates WIPT efforts and covers all topics not otherwise assigned to another IPT
  • WIPT (Working level IPT)
    - focuses on a particular topic
  • Program IPTs
    - provides for program execution
Interested? You might like "How to form an IPT" in the Sept-Oct 2002 edition of the Defense "AT&L" online magazine (free). Author David Hofstadter from the Defense Systems Management College. Hofstadter tells us this:
The first step was to determine the IPTs. The program manager and his functional chiefs decided which major products or components needed direct management by an IPT.

Next they took the necessary time to carefully craft a charter for each IPT. The charter had to be specific, not at high level, not vague or timid. It had to contain milestones, outcomes, or specific objectives.

The charter had to state the IPT’s authority and the next level of reporting for the IPT. The program manager and his chiefs named in the charter an IPT lead whose responsibilities were stated, which did not include any functional responsibilities. Finally the charter was signed by the program manager. Each charter was eventually posted in the IPT’s team area
You've probably got enough to get started.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Saturday, April 15, 2017

Agile and stage gates



One of my Agile Project Management students asked me about stage gates and agile. My first response was this:
  • Agile is not a gated methodology, primarily because scope is viewed as emergent, and thus the idea of pre-determined gate criteria is inconsistent with progressive elaboration and emergence.
  • Agile does embrace structured releases; you could put a criteria around a release and use it as a gate for scope to be delivered
  • Re budget: agile is effectively 'zero base' at every release, if not at every iteration. You can call the question at these points of demarcation.
  • Agile is a "best value" methodology, meaning: deliver the 'most' and 'best' that the budget will allow, wherein 'most' and 'best' is a value judgement of the customer/user.
  • Of course, every agile project should begin with a business case which morphs into a project charter. Thus, the epic narrative (the vision narrative) is told first in the business case, and retold in more project jargon in the charter. Thence, there are planning sessions to get the general scope and subordinate narratives so that an idea of best value can be formed.
But, DSDM is one agile method, among others, that is more oriented to a gated process than say, SCRUM. To see how this could work, take a look at this presentation:



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Wednesday, April 12, 2017

Agile -- the state of things



I was looking back at some prior essays on Agile and came across the April 2012 PMNetwork magazine. Specifically I was attracted (again) to page 58 for an interview with some agilists on the state of the practice.

Here are a couple of quotes from Jim Highsmith worth tucking away:

Agile project management embraces both “doing” agile and “being” agile—and the latter is the hardest. It defines a different management style: one of facilitation, collaboration, goal- and boundary-setting, and flexibility.

... agile is changing the way organizations measure success, moving from the traditional iron triangle of scope, schedule and cost to an agile triangle of value, quality and constraints.

My take:
The first idea is certainly agile but not unique to Agile. To my way of thinking, all enlightened project managers have been doing this all along, or they should have been. Now, I certainly agree that Agile calls for a reset of manager's and management's approach to projects.

Agile shifts the discussion from fixed value to best value. And, what is best value: it's the best the team can do, with the resources committed, towards achieving project goals that will ultimately lead to business success. Who says what's "best"? In the Agile space, that is a collaboration of the project team, the sponsor, and whoever holds the customer/user's proxy. That's the key:
  • The customer/user--through their proxy--gets an input to the value proposition because they may use or buy the outcomes, but the customer/user has no money at stake; it's other people's money, OPM
  • The sponsor also gets an input  because it is their money at stake. (The sponsor may be a contracting office, as in the public sector)
  • The project team gets an input because they are in the best place to judge feasibility.

The second idea is Agile, but it may be too agile for some. Why so? First, there's still "other people's money". Second, you can't work with OPM and not have metrics of performance to stack up against the money. So, the cost-schedule-scope tension may be hard to manage, but at least there are metrics.

I don't have a problem with another paradigm, say Highsmith's value, quality and constraints, so long as they come with metrics that align with the value that sponsors put on money. That's why I associate myself with best value: It's OPM with metrics for performance that align with a value proposition leading not only to project success but to business success as well.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Sunday, April 9, 2017

Leading change ... Kotter



John P. Kotter is a change guy. I've been going through his 1996 classic "Leading Change"


Here's my take: it's a good book, but a little long on the narrative since the essentials are right up front: 8 leadership steps towards change management.

Now, admittedly, this is more aimed at the business readiness swim lane, and the foreplay necessary to get the business and the customer ready, than it is aimed at some of the change management tactics for scope control. Nevertheless, here's my paraphrase of Kotter's 8:


1. Put a value on short term versus long term
2. Gather a coalition of the willing
3. Develop the vision, goals, and strategy
4. Communicate
5. Push action to the practitioners
6. Be incremental
7. Consolidate gains
8. Leverage culture


Now, in Kotter's actual formulation for point #1, he wrote more about creating a sense of urgency than simply putting a value on the short term. But, actually, I'm not a fan of crying wolf on urgency just to get the team moving. Frankly, I'm more about finding a legitimate reason to value a short term goal; with that in hand, you should be able to get some action going.

His point about #5 was the ole "empowerment" thing. It was probably less worn in 1996 that it is 15 years later. The issue is that the empowered may not know how to use their power. That hasn't changed since power and empowerment were invented:

Those with the power have no experience
Those with the experience have no power
General Sir John Dill
Placentia Bay Conference, August 1941



I really like the last one about culture. We've mused on culture a few times here.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, April 6, 2017

Agile is for Wimps .... ?



Here's an interesting video from a noted originalist of the Agile movement -- Alistair Cockburn

Ooops! It's over an hour long, so you might want to schedule it for a lunch break ... maybe more than one



He builds his talk around this graphic which is a metaphor for agile has become too complicated ... lets get back to these common sense ideas
 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, April 3, 2017

"Right kind of Crazy"


Have you read this book?
Spoiler alert: No math! And, it's only 225 pages in hardcover
  • If you are a mechanical engineer, it's a must
  • If you are any kind of an engineer, it's a should-read
  • If you are a project manager looking for leadership lessons, it's a must read (but you can skip the engineering detail)

It's an amazing story of the project team at Jet Propulsion Lab (JPL) that conceived the skycrane for the last Mars rover landing.

That's a fascinating tale by itself, but the leadership and teamwork insights are worth the price. Indeed, the subtitle is:
Teamwork, leadership, and high-stakes innovation
The chapter titles are major themes developed in the context of the JPL systems and mechanical engineering context, but really applicable all around. A few to ponder:
  • "Hold onto the doubt" meaning continuing doubt about that what you are doing is a good thing and that doubt will often keep you out of the disaster area 
  • "Self-authorization" meaning act when others won't or can't or are paralyzed by analysis
  • "Systems engineers" meaning step back and get a holistic view; the parts, when assembled, are sometimes destructive rather than constructive
  • "Dark room" meaning sometimes you wander into a black hole from which there seems no escape... now what?
And, there are others ....
Recommended reading for anyone in the leadership, team work, or technology domains
 


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, March 30, 2017

Qualities of leadership


...  the mantle of leadership [is assumed] with the enormous confidence that comes from the conviction that the ends of action are never in doubt, and that the achievement of those ends is always within the power of the brave and skillful.

[And] the unquestioned belief in the ... mission—the seed of both [the not-so-good] and tremendous good

Doris Kearns Goodwin. 
“Lyndon Johnson and the American Dream".

The operative words are: ".. conviction that the ends of action are never in doubt .." In other words, non-believers need not apply.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, March 27, 2017

No plan .... no worry!


Planning is an unnatural process, it’s much more fun to get on with it. The real benefit of not planning is that failure comes as a complete surprise and is not preceded by months of worry.
‒ Sir John Harvey Jones

My thanks to herdingcats for posting that bit of insight where I could find it.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, March 24, 2017

Who can say yes?


In your domain, who can say "Yes" -- and make it stick?

Should this be a hard question to answer? It can be. Consider:


If you want a "Yes", up close and personal works much better than remote and mystical. And, you may have to be cunning to work around the "staff" that protects the "yes-sayer" from saying "yes" too often.

What does that mean for the remote worker? Could be SOL in many situations because you just can't get access.

In fact, if the "staff" ordinarily works with knives, you may want to get one also. One doesn't want to show up at a knife fight with a pop-gun.

Hey, best of luck with that "yes thing". I hope it works for you.



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Tuesday, March 21, 2017

Risk Management Short Course


Need a quick introduction to risk management? Don't have much time for this?

Try this very short course on risk management (no math required!)





Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, March 17, 2017

"..... means are authorized"


James Madison, one of the intellectuals of the American revolutionary period, writing in Federalist* 44 in the pre-constitutional period of the late 1780's, said this:
".. wherever the end is required, the means are authorized"
Whoa! Not so fast!

What about " ... means are authorized" so long as they are:
  • Morally and ethically constructed
  • Conform to legal and regulatory constraints
Actually, Madison was defending the "necessary and proper" clause of the American constitution which recognizes that 
If a government has the authority to perform a particular function, it must necessarily have the power to do what is necessary and proper to perform that function. Madison asserts that it is a basic characteristic of government to have the authority to pass authoritative law

But, again I say: Not so fast. Every nefarious and authoritarian regime would make that argument, to wit: "it's legal because I say it's legal"; or, if the supreme authority does it, then it has to be legal.

WHAT ABOUT IN PROJECT MANAGEMENT?
Same thing applies in my mind. The PMO has a fiduciary responsibility to client and business to act in their best interests -- which, by the way, may be in conflict. But, that "end" does not justify any means. Nonetheless, the PMO does have a responsibility to stand up for better regulation and more sensible and practical rules so that best interest are served with ends that are moral, ethical, and legal


* The Federalist papers are a set of 85 essays by multiple authors written to persuade state legislatures to approve and adopt the Federal constitution, written by a convention of States in the late 1780's.


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, March 13, 2017

O-Ring jobs


Are you an O-Ring? Or in an O-Ring job?
Many professionals are.

What's an O-Ring job?
You are an indespensible link in a chain, or an important tile in a mosaic (system) whose performance bears on the performance of the entire chain or system. You do a poor job, or you do a really good job, and the larger outcome notices.


The name comes from the O-Ring failure in the shuttle disaster of the mid-80s when a simple part of the system failed and led to a catastrophic failure of the whole system.

Here's a key point:
As the other links become stronger, the value of increasing your strength increases also. Ergo: smarter links puts pressure on you to become smarter so that you are not the weakest and least valuable. 


TED talk
In a TED talk, David Autor gives us a rousing explanation of why there are more jobs now than there were 100 years ago, before the modern age of personal productivity, and why most of the jobs are now O-ring jobs.

He starts with the startling statistic that the number of bank tellers (people) have increased over the past generation, in spite of ATM machines. But their cognitive skill requirements have demonstrably increased.

Never Enough
He goes on to explain a second principle (O-rings being the first) which he calls the "never enough" principle, summarized as "Invention is the mother of necessity"

Give it a look





Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, March 9, 2017

On customer satisfaction


Is customer satisfaction one of your project metrics. Good grief, I hope so! If not, you might want to consider this little ditty:
 
  •  “If the customer is not satisfied, they may not want to pay for our efforts.
  • If they are not successful, they cannot pay.
  • If they are not more successful than they already were, why should they [pay]?”


Niels Malotaux
Paraphrased a bit


Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, March 6, 2017

Workflow for communications


I've always subscribed to the notion that the top three things for a PM to do are:
  1. Communicate often
  2. Communicate effectively
  3. Communicate widely
Perhaps I should have made "effectively" the first thing on the list. In any event, at every occasion (often, widely), here are the workflow rules for effective communications:



Two rules
Remember this
Rule 1
       Tell them what you’re going to tell them
       Tell them
       Tell them what you told them
Rule 2
If “they” don’t get it, it’s not their fault



Re Rule 2:
  • If at first you don't convey it, back out and reformulate
  • You can't show frustration
  • You can't show irritation
  • You can't blame it on the audience if they don't get it
  • You can take it off-line to try again




Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Thursday, March 2, 2017

Team overload -- burning out


Are you on one of those death march projects about to burn out. Want some time off? Perhaps it's in the plan

Formula  solution
Google among others -- Microsoft, etc -- are well known for the "time off, do what you want toward self improvement and personnel innovation" model; formulas like that lend objectivity to the process (not playing favorites, etc). Note: more on this in the "6x2x1" model discussed last

Productivity drop
Of course, the real issue is one that agile leader Scott Ambler has talked about: the precipitous drop in productivity once you reach about 70% throughput capacity of the team. Up to this point, the pace of output (velocity) is predictably close to team benchmarks; thereafter, it has been observed to fall off a cliff.

Other observers have put it down as a variation on "Brooks Law" named after famed IBM-370 project leader Fred Brooks: "Adding people to a late project makes it later" . In this case, it's too many people on the team with too many interferences. It's been observed that to raise productivity, reduce staff!


Wave bounces
In the physics of wave theory, we see the same phenomenon: when the "load" can not absorb the energy applied, the excess is reflected back, causing interference and setting up standing waves. This occurs in electronic cables, but it also happens on the beach, and in traffic.

Ever wondered why you are stopped in traffic miles from the interference while others up ahead are moving? Answer: traffic load exceeds the highway's ability to absorb the oncoming cars, thereby launching reflections of standing waves that ebb and crest.

So it is in teams: apply energy beyond the team's ability to absorb and you simply get reflected interference. Like I said: the way to speed things up is to reduce the number of teams working and the number of staff applied.

In agile/lean Kanban theory, this means getting a grip on the WIP limits... you simply can't have too many things in play beyond a certain capacity.

Sometimes the problem arises with sponsors: their answer is universally: Throw more resources in, exactly opposite the correct remedy

6x2x1 model
One of my students said this:
"Daniel Pink  has an excellent book called Drive, the surprising truth about what motivates us. In the book, Pink talks about inspiring high productivity and maintaining a sustainable pace.

One of the techniques is the 6x2x1 iteration model. This says that for every six two week iterations the development team should have a 1 week iteration where they are free to work project related issues of their choice.

You can also run a 3x4x1 model for four week iterations. Proponents of this approach have observed that the development teams will often tackle tough problems, implement significant improvements and generally advance the project during these free play periods. Without the time crunch to complete the story points the team also refreshes itself."

I don't know, but Pink's thesis may have been the genesis of the Google and Microsoft "time off" plans I've already mentioned, or maybe the experience of those plans found their way into Pink's thesis. Either way, time off matters!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Monday, February 27, 2017

TOC and the Kanban


Remember TOC: The Theory of Constraints? Goldratt explained it in his business novel "The Goal".

TOC is alive and well if you use Kanban in your WIP management

First, you may ask, before considering the theory:

What is a constraint?
  • Limitation on throughput

What’s throughput?
  • Stuff, outcomes, that are valuable to business or client
  • That which is value-add to the business value proposition
  • Debris is not throughput; it’s overhead

Now, what's the Theory?:
Once a stage is full, there’s no advantage to keep piling up WIP inventory at earlier stages

And, what is it that I'm supposed to do as manager re TOC?

Subordinate to the constraint
  • “Efficiency” of widgets/hour at earlier stages is meaningless
  • To clear the constraint, subordinate all resource allocations to the priority of working on the constraint
    All hands on deck rule
And, how can I make a constraint more capable so that I can improve throughput?
  • Add similar resources (parallelism)*
  • Re-organize methodology at the constraint
  • Re-tool or re-train
  • Avoid constraint by going a different direction


* Beware of Brooks Law: adding resources to a late project makes it later (Fred Brooks: "The Mythical Manmonth")



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

Friday, February 24, 2017

Kanban models


Looking for a Kanban model for your WIP -- work in process?

How about the simplest? DO -- DOING -- DONE?


Kanban
What it’s about
To Do
All the backlog from customer; all the project debris, all the technical debt
Doing
Everything started but not finished
Done
All done, except some debt might have been referred to TO DO

Too simple?
 Here's the one I like the best because it's ubiquitous and can be applied really anywhere:



Kanban
What it’s about
To Do
All the backlog from customer; all the project debris, all the technical debt
Narrative, design, outline
The epoch story; the overall architecture; the outline of the deliverable(s)
Construction
All the building and assembly of units
Integrate & test
Tie the units together and see if they work
Validate and Verify
Everything accounted for?  Ooops, left one out; back to construction
DONE
All done, except some debt might have been referred to TO DO

Got one you like? Use it!



Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog