Debt is not all bad

---

Debt is not all bad; it's not living beyond you means if you have the means -- and commitment and discipline -- to pay it back. In fact, debt can be a source of leverage, a means of managing risk, and a means to bring the future closer to the present.

And so it is in the metaphor of technical debt in a project. Technical debt has been around as long as there have been projects. It's just that until the past 25 years we've not really called it "technical debt". More likely you've used these terms:

• Punch lists of things not done
• Low priority stuff deferred
• Action items from a design review
• Future resources borrowed for near term action (aka: mortgage the future)
• And, others .....

And so Mike Cohn, noted Agilist, in an emailing on the subject tells us:

"Ward Cunningham introduced the idea of technical debtat the 1992 OOPSLA conference. Cunningham’s term is often used by development teams to claim that technical debt is evil and all technical debt is to be avoided.

Cunningham’s point was exactly the opposite. It was that technical debt can be OK. He wrote, “A little debt speeds development so long as it is paid back promptly with a rewrite.”

So it’s not technical debt itself that is evil. It’s letting technical debt accumulate."

And, so the point is:
Don't let "deliver the best" be the enemy of getting on with it and making progress. For those old enough to remember, Win 95, Microsoft's first real windows OS (forgetting an even earlier version that I can hardly recall) was replete with "technical debt". And, Win 98 wasn't much better.  But, a lot was learned with those early efforts -- even if Apple was learning faster and delivering better.

Indeed, the whole point is to get something out there and gain experience from user's interaction. But, at the same time, have a plan to "learn fast". The slow learner will lose all advantage of going into debt.

Of course, if the customer's domain and culture is that "failure is not an option" and "it has to work the first time", then the debt needs repayment sooner than later.

But even if those are the constraints and the height of the bar, the opportunity for leverage and learning are not forfeited by the quality standard; they are simply sequenced differently.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

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!

Read my contribution to the Flashblog

"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!

Read my contribution to the Flashblog