Clearing the backlog

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling? 

Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

 

Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?

If coupling is a benefit, how to obtain it?

First, there's buffers to loosen coupling

The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects

• To avoid coupling, buffers may not do the trick.
• But to enable coupling, we need some connectivity

In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 

 

One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.

 

Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 

Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Software: Is it ever Done?

---

The software is never done!

Certainly not news; and certainly not profound to any engineer, coder, or PM working in the software industry, writing apps, or supporting software enabled devices.

Users have come to expect routine and regular updates to all things software.

Ooops, not so fast!

What about the automobile industry?

Traditionally: the car is done! 

• Buy it; keep it; sell it, eventually. Never needs an upgrade!

But that tradition may be short-lived: Cars will need upgrades over the life-cycle

What now?

A few months after I bought a new car I got a recall notice to take it in for an upgrade to the transmission control software. That recall system is probably the way to keep software up to date for many of the in-vehicle software programs. 

• But, is this only a warranty service? 
• How long would manufactures support software upgrades for 2nd or 3rd party apps?
• The life of car is 12 years+ for new vehicles. That's 'forever and forever' in the software industry, comparable to still supporting the iPhone 4! 

Big Tech

So-called big tech is taking over much of the user interface and user apps in new vehicles (except Tesla which does all its own in-house design and does not support Android and Apple apps on its user panels)

Long term support

As a project manager, what can you look forward to as regards long-term supportability of apps?

And, as a app developer, you may be one layer removed from knowing that it will find its way into the automobile industry. 

And as a business manager or customer support liaison, which customer are you supporting most?

• The one that pays the bills (automobile manufacturer) or 
• The customer that buys the car?

In the Agile sense of value-as defined-by-the customer, who is most influential?

Long term, these are my wonderments. I wonder how they would be written into project requirements?

• I wonder if you'll be able to go to your local auto parts retailer and buy an upgrade-on-a-stick for legacy vehicles? 
• I wonder if there is not a whole industry to be invented supporting older cars with updated interfaces?  
• I wonder if its practical to expect the after-market developer to maintain currency for 'a long time'. 
• I wonder if personal security, data security (nav data, for instance, but also other data about downloads to the car like music stations and podcasts, etc), and all the rest will not spawn a whole set of requirements, support issues, and a supporting industry?

Perhaps in the future, the mantra will have to be something like this:

The software is never done!
And, neither is the car!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Is your enterprise Agile?

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc. come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the enterprise has money!

And where does that money come from? Not you, most likely. Other people! So Other People's Money (OPM) is what is funding you.

Who are these people? If an enterprise, then there are going to be a wide variety: Customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise imposes expectations

So, here's the thing: even if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations up front .... starting with: expected value return on resources invested.

It's natural that Agile people resist too much "up front" definition; we're about evolution and iteration. But there has to be a compromise.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is more than expected; it's required.

Enterprise expects estimates (gasp!)

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience, unless you're just a researcher working on your own small project.

Enterprise brings scale

What makes an enterprise an enterprise is size and scale. 

And what makes a project "enterprise" in it's scope is size and scale.

And there is the rub: Size and scale is always more than what a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. 

Scale is not just a lot of one thing, like a large code base. Scale brings breadth, meaning a lot of different things involved and integrated, and scale brings then brings rules, procedures, accountability, etc. into the frame because a lot of people have to work somewhat anonymously ... according to rules and procedures ... to bring it together, repeatedly, within predictable limits.

The question: "Can it be done what your doing 'at scale'?" Hand-crafted, job shop, one-off are not descriptions of scale.  

Enterprise brings rules

There will be a lot of rules. 

There will be a lot of rules because there will be a lot of people involved, many you will never meet, doing jobs for the enterprise you may not even be aware of, but these jobs will nevertheless touch your project or product.

Enterprise requires a narrative

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard elements of the narrative you've heard before:

1. Vision: What is envisioned as the benefit to the enterprise? Who are envisioned as the beneficiaries?
2. Scope: What is it you're going to do (and what are the ancillary or consequential impacts elsewhere in the enterprise that you don't consider part of your scope?)
3. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
4. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

Narrative, estimates, rules, value commitments?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Agile "DONE" defined

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... Definition of Done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my definition of "Done" has been framed by the answers to these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical definition of done would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. But it's very tactical. There's more to a product than just the code. In other words his theory is proven when, in the crucible of a trying to make money or fulfill a mission by writing software, you are strategically successful (deployable, saleable, supportable product) while being simultaneously tactically successful. How swell for us who read Cohn!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

By the rules, or not?

---

A lot of great outcomes are directly from emergent innovation

• Emergent meaning the properties were not predictable from analyzing the constituents; they surprise us all when the integrated constituents all came together and something new appears!
• Innovation meaning that risks to norms were deliberately taken; a form of destruction-construction

But not everybody is comfortable for destruction-construction; and indeed, there are many industries where the rules and regulations prohibit departure from the norms.

And so if you are managing a rules-based rules-driven project, what's the profile of the staff you need?

The question begs the answer: people who have been successful obtaining quality outcomes while still following the rules ... staying between the hedges, as it were.

So, who are 'they' that can get it done within the rules?

Look here first for the "rules" people:

• Former military and police
• Former government agencies staff
• Former very large corporate leaders
• Former staff from major 'safety' projects (where the stakes were life-threatening)
• People who value discipline, even if not one of the 'formers'
• Athletes from team sports, particularly if not the star of the team
• Socially moderate, and so likely to fit well into a heterogeneous team

Now, of course, there are a lot of 'formers' from rules-based organizations that are 'former' because they can't follow the rules. It's likely they have been invited to leave and apply their spirits elsewhere. Your job is to filter these rules-misfits out of your hiring plan.

Rules don't necessarily quash innovation

Rules generally go to methods and limits. Rarely do you find a rule about an outcome.

So, within the allowable methods, and within the allowable limits of disturbance, sustainability, availability, and quality in the large sense, any innovative outcome is possible.

You just need to hire the 'rules people' to get there!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Are we there yet? Agile "done"

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... Definition of Done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my definition of "Done" has been framed by the answers to these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical definition of done would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. But it's very tactical. There's more to a product than just the code. In other words his theory is proven when, in the crucible of a trying to make money or fulfill a mission by writing software, you are strategically successful (deployable, saleable, supportable product) while being simultaneously tactically successful. How swell for us who read Cohn!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Enterprise Agile

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good too.

Why so?

Access to resources is the main reason.

• You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine. But how many small teams are needed for your project? Dozens? Hundreds even?
  
  
• Where do those people, tools, training, facilities, communications, etc come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the Enterprise!

And where does that money come from? It comes from customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners and/or private investors (if privately held), or owners and public investors (if you're a publicly traded company)

Enterprise expectations

So, here's the thing: if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations .... starting with: value return on resources invested.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is required.

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of funds you can dip into at your leisure and convenience. Enterprises don't work that way.

With enterprises comes rules and accountability

What makes an enterprise an enterprise is size and scale. And there is the rub: Sad to say, but size and scale is always more than a handful that a few people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. Such then brings rules, procedures, accountability, etc. into the frame.

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard three elements of the narrative you've heard before:

1. Scope: what is it you are going to do, and how does that "doing" add value to the enterprise?
2. Schedule: when can you likely produce results? (No single point estimates, of course. It takes a range!)urc
3. Resources: how much do you need, and when do you need it? In other words, the resource ramp (up, but then inevitably down) We're speaking about cash flow, and resource allocations.

I can't do this!

You can't handle the narrative?

You can't describe what you need? (Or you stubbornly cling to the No Estimates paradigm?)

You can't connect the dots: value, resources, scope? 

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition. The cover photo is below

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Agile "Definition of Done"

---

Now we're getting somewhere! No less an Agile/Scrum eminence than Mike Cohn -- author of some really good books and articles -- has come out with a newsletter on -- are you ready for this? -- what's the meaning of DONE in Agile.

His acronym, a bit a poor choice to my mind, is "DoD"... Definition of Done. But, there you have it... perhaps a new GAAP "generally accepted agile practice" for agile-done

In the past, my definition of "Done" has been framed by the answers to these three questions:

1. Is it done when the money or schedule runs out?
2. Is it done when the sponsor or product manager says it's done?
3. Is it done when Best Value* has been delivered?
   * The most ,and the most affordable, scope within the constraints of time and money

If you can't read my bias into these questions, I line up firmly on #3.

Cohn instructs us differently:
A typical definition of done would be something similar to:

• The code is well written. (That is, we’re happy with it and don’t feel like it immediately needs to be rewritten.)
• The code is checked in. (Kind of an “of course” statement, but still worth calling out.)
• The code was either pair programmed or peer reviewed.
• The code comes with tests at all appropriate levels. (That is, unit, service and user interface.)
• The feature the code implements has been documented in any end-user documentation such as manuals or help systems. 

Cohn hastens to add:
I am most definitely not saying they code something in a first sprint and test it in a second sprint. “Done” still means tested, but it may mean tested to different—but appropriate—levels.

Now, I find this quite practical.. Indeed, most of Cohn's stuff is very practical and reflects the way projects really work. But it's very tactical. There's more to a product than just the code. In other words his theory is proven when, in the crucible of a trying to make money or fulfill a mission by writing software, you are strategically successful (deployable, saleable, supportable product) while being simultaneously tactically successful. How swell for us who read Cohn!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Mixed methods, Agile and Other

---

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: In the past, I've owned some OGM leases in Texas, so I've a bit of personal experience with this)

So, what have you got here?

• A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
• A need to run with pilot projects before committing to production
• A need to tie into legacy systems (in the OGM case, distribution systems)
• A lot of deliverables that can be done incrementally and then integrated
• Small (it's all relative re small) teams, co-located (or the virtual version thereof), personally committed, with risk hanging on every move.
• A degree of local autonomy -- even if virtual -- required to meet the challenges of the moment

Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":

You can't go around self-organizing (agile speak) willy-nilly! There are regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!

Agile in the Enterprise

So, the bureaucracy has to be reckoned with, aka, 'the enterprise'. To that point take a read of my post about 'agile in the enterprise', or better yet, take a look at my book, 'Project Management the Agile Way; Making it work in the Enterprise."

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Agile and the sailor's analogy

---

The presentation -- in the link below -- that I gave to PMI some years ago that makes an analogy between sailing a boat and Agile methods is still relevant, and probably will remain so.

Why?

Because a sailing "project" is has much in common with an Agile project:

• Tactics overlay a strategic goal, though there are broadly stated limitations and rules
• Small teams have to work together, or else someone goes overboard
• There's a lot of local autonomy
• Risk is managed locally
• The environment is pretty flat, managerially, but the leader is clearly recognized
• Team success trumps individual success; teamwork is rewarded, particularly in overcoming adversity
• The goal is set by others, but it's obvious to all observers
• The value proposition is clear and present

Have a look:

Click here for a slideshare

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The innovators' lament ....

---

Recently heard: this lament from IT innovation workers:

[We] encounter ironclad corporate hierarchies and resistance to change, a paradox in [our] industry that thrives on innovation and risk-taking.

"They" want things in a particular order; they want case studies and past experience. IT doesn't work like that. There is no past experience. We have to reinvent ourselves every day.

As reported by Joseph Coleman

Golly! I think the corporate masters must have missed the Agile memo. 

They may also have missed some principles of risk management in the context of 'new to the world' development, to wit: 

Some things never work out; some things are a home run. Setting artful limits to the balance sheet is the key skill if you aren't willing to bet the business.

On the other hand .....

There's a case to made for a business case, even in the context of Agile methods. 

Unless you are spending your own money, you have an obligation to the financier to show some respect and responsibility for the funds they are providing, even if you keep overrunning and going back for more. In effect, "innovation" never met a budget it couldn't bust!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Working for an enterprise with Agile

---

Applying agile methodology in your software project? Good!

Working for an organization large enough to be called an 'enterprise'? Probably that's good.

Why so?

• Access to resources is the main reason. You may have heard that agile is all about small self-directing teams -- yes, that's part of the doctrine.
   
• But how many teams are needed for your project? Dozens? Hundreds even? Where do those people, tools, training, facilities, communications, etc. come from? And who pays for all that?
  
  
• Answer: the Enterprise.
  

Ah, yes, the enterprise has money!

And where does that money come from? Not you, most likely. Other people! So Other People's Money (OPM) is what is funding you.

Who are these people? If an enterprise, then there are going to be a wide variety: Customers (profit), or taxpayers (if you're a government enterprise), or donors (if you're a charity, church, etc), or owners (if privately held), or investors (if you're a publicly traded company)

Enterprise imposes expectations

So, here's the thing: even if you're doing Agile methods in an enterprise setting, the enterprise will impose expectations up front .... starting with: expected value return on resources invested.

It's natural that Agile people resist too much "up front" definition; we're about evolution and iteration. But there has to be a compromise.

It's the ageless problem: Other people's money! OPM comes with strings, to wit: a value return is more than expected; it's required.

Enterprise expects estimates (gasp!)

And here's another thing: the enterprise expects that you can estimate/forecast/predict what the resource requirements are that will get to something valuable (to the enterprise). In other words, it's rare indeed that there's a pot of gold you can dip into at your leisure and convenience, unless you're just a researcher working on your own small project.

Enterprise brings scale

What makes an enterprise an enterprise is size and scale. 

And what makes a project "enterprise" in it's scope is size and scale.

And there is the rub: Size and scale is always more than what a handful of people can carry around in their head. So, many others have to lend a hand and participate in making and supporting both size and scale. 

Scale is not just a lot of one thing, like a large code base. Scale brings breadth, meaning a lot of different things involved and integrated, and scale brings then brings rules, procedures, accountability, etc. into the frame because a lot of people have to work somewhat anonymously ... according to rules and procedures ... to bring it together, repeatedly, within predictable limits.

The question: "Can it be done what your doing 'at scale'?" Hand-crafted, job shop, one-off are not descriptions of scale.  

Enterprise brings rules

There will be a lot of rules. 

There will be a lot of rules because there will be a lot of people involved, many you will never meet, doing jobs for the enterprise you may not even be aware of, but these jobs will nevertheless touch your project or product.

Enterprise requires a narrative

Invariably, one of the rules is going to be you have to have a viable narrative to get resources committed to your project. The standard elements of the narrative you've heard before:

1. Vision: What is envisioned as the benefit to the enterprise? Who are envisioned as the beneficiaries?
2. Scope: What is it you're going to do (and what are the ancillary or consequential impacts elsewhere in the enterprise that you don't consider part of your scope?)
3. Schedule: when can you likely produce results (no single point estimates, of course. It takes a range!)
4. Resources: how much, and when (cash flow, and resource allocations)

I can't do this!

Narrative, estimates, rules, value commitments?

You're not enterprise-ready!

I almost forgot:

I wrote the book: "Project Management the Agile Way: Making it work in the Enterprise" 2nd Edition

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Methodologies: more than one way to do it

---

Did everyone catch Glen Alleman's posting on LinkedIn about the 'Waterfall Myth'? If not, here are a few value-adds from that posting. 

First up: Glen's definition of sundry methodologies for developing software systems, whether stand-alone, as it were, or embedded with hardware development:

• Waterfall Approach: Development activities are performed in order, with possibly minor overlap, but with little or no iteration between activities. User needs are determined, requirements are defined, and the full system is designed, built, and tested for ultimate delivery at one point in time. A document-driven approach is best suited for highly unprecedented systems with stable requirements.
  
  
• Incremental Approach: Determines user needs and defines the overall architecture, but then delivers the system in a series of increments (“software builds”). The first build incorporates a part of the total planned capabilities; the next build adds more capabilities, and so on until the entire system is complete.
  
 
• Spiral Approach: A risk-driven controlled prototyping approach that develops prototypes early in the development process to specifically address risk areas, followed by assessment of prototyping results and further determination of risk areas to prototype. Areas that are prototyped frequently include user requirements and algorithm performance. Prototyping continues until high-risk areas are resolved and mitigated to an acceptable level.
  
  
• Evolutionary Approach: An approach that delivers capability in increments, recognizing upfront the need for future capability improvements. The objective is to balance needs and available capability with resources, and to put capability into the hands of the user quickly.

A long legacy

Now Glen goes on to let us know that some of these ideas go back almost 50 years, if not or more. So if you recognize some Agile concepts in the words above, you would be right. And, their provenance is a trail much longer than the infamous Agile conference --  at the turn of the millennia -- that more or less launched Scrum and XP and others into the public domain. 

What's to like?

Looking at all of these methods conceptually, it's hard not to like a combo of Spiral -- which has a strong focus on risk management of testy requirements that may be impractical at first blush, but might yield to some clever prototyping and evaluation -- and Evolutionary which has an up-front bias toward early value-add for users, but with recognition that these same users are going to provide insight to future capabilities and needs.

The hard part

If you go with some version of the incremental or evolutionary method, or some version of classical Agile, like Scrum or XP, they all presume flexibility on the PM's part to approach and engage the customer or user in product evaluation and value development. 

That's easier said than done in many situations:

• In the public sector, cost often is first priority, and users have to make do.
• In the contracting domain, the engagement with the user if often proscribed, limited, and arm's reach remote
• In the commercial sector, "first" often wins, but what's to come "first" is often a big corporate secret not to be shown to anyone outside the 'green room'. 

And, don't forget: I wrote the book ... see the cover below. You'll find it wherever you buy your books with e-commerce.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

AGILE: how to get there from left to right

---

If you are new to Agile (thus, perhaps, a late adopter .... or a newbie to the software industry) read through this posting at LeadingAnswers. 

The big message is: 

Internalize the founding concepts and guiding principles before jumping into sundry Agile practices. 

Start left; move right
In particular, understand this lecture: Absorb the idea of moving 'left to right' from the founding ideas to the many implementing practices. Avoid the shortcut to cut to the chase and start pick among the practices. 

If your mindset is "I'm not keen on the founding stuff; I'm a 'doer'", then LeadingAnswer's post is really designed for you! 

Read it through; take time to grasp the message in the graphics, and then summarize to yourself what you just learned. You and your project will be more successful than you might have been.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Mixed methodologies: Agile and ....

---

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what have you got here?

• A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
• A need to run with pilot projects before committing to production
• A need to tie into legacy systems (in the OGM case, distribution systems)
• A lot of deliverables that can be done incrementally and then integrated
• Small (it's all relative re small) teams, co-located (or the virtual version thereof), personally committed, with risk hanging on every move.
• A degree of local autonomy -- even if virtual -- required to meet the challenges of the moment

Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":

You can't go around self-organizing (agile speak) willy-nilly! There are regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Sketching out the architecture

---

I was recently directed toward an interesting site (blog, presentations, etc) by Simon Brown, and his download presentation about "sketching the architecture" that more or less reinforces my idea that:

 "If you can't draw it, you can't build it."

Box model

From this idea flows my "box model" approach to setting down high level narrative (business story with context), major functions (boxes) and the interconnecting process (network).

Now, Brown tells a similar story -- with more depth re design -- with an idea he calls C4. C4 is a box model that Brown claims enables agility in architecture:

• Context
• Container
• Components
• Classes

One thing in Brown's version is an assertion that multiple views may be needed to convey the architecture completely. To this end he posits views like:

• logical vs conceptual;
• process vs functional; and others.

In Brown's world, these different views are tools to "... manage complexity and highlight different aspects of the solution."

For instance, logic shows interconnections with conditions (if, then, else, etc) and process shows work flow, as an example.

Profound
These ideas of Mr. Brown are profound:

• We can visualize our process but not our software.
• In [Brown's] experience, software teams are unable to visualize the software architecture of their systems.
• Pictures are the simplest form of documentation.
• Sketches are not complete models.
• Abstraction is about simplifying, not creating a different representation.

---

Buy them at any online book retailer!

AGILE: mixing methods

---

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what have you got here?

• A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
• A need to run with pilot projects before committing to production
• A need to tie into legacy systems (in the OGM case, distribution systems)
• A lot of deliverables that can be done incrementally and then integrated
• Small (it's all relative re small) teams, co-located, personally committed, with risk hanging on every move.
• A degree of local autonomy required to meet the challenges of the moment

Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":

You can't go around self-organizing (agile speak)willy-nilly! There's regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!

---

Buy them at any online book retailer!

Backlog blocked?

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling is the culprit.

Coupling? 

Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost no energy is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

 

Managing coupling is a task in risk management because coupling may introduce unwanted risks in the project or the product.

If coupling is a problem, how to solve it?

If coupling is a benefit, how to obtain it?

First, there's buffers to loosen coupling

The buffer -- if large enough -- absorbs the effect. For an excellent treatment of buffers in the PM domain, see Goldratt's  book "Critical Chain Method" for more about decoupling with buffers

Second, there are coupling objects

• To avoid coupling, buffers may not do the trick.
• But to enable coupling, we need some connectivity

In either case, think of objects, temporary or permanent, that can effect the coupling. A common example is seam in one fabric joining to another. The seam forms a "rip-stop" which prevents a ripping all down the fabric. 

 

One system that uses such a rip-stop is the sails on a boat: rip-stops are sewn into the sail fabric to prevent a total failure in the event of damage in one section, and thereby to decouple the damage from one section to another.

 

Now, move that idea from a sail to a backlog, using object interfaces for isolating one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in "Environment A" without strongly influencing "Environment B". 

Some caution advised: this is sort of a "us vs them" approach, some might say stove piping.

The case for tight coupling

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Buy them at any online book retailer!

Agile means ....

---

Agile means:

• ‘Agile’ means small teams, working collectively and collaboratively, with this mission: 
•  To deliver frequent, incremental releases of innovative functions and features, prioritized for need and affordability;
• Evolved iteratively from a vision according to user reflection and feedback;
• And produced at the best possible value.(*)

Agile ideas to keep in mind

•  Requirements are too important to be left to the beginning; they must be evolved with user interaction and interpretation as all the implications come into view
•  Process emerges to fit the circumstances; control metrics are empirically determined, not defined by historical performance in the manner of Six Sigma (**)
• Planning is very important but following the plan is not as important as satisfying the customer

Agile works better when...

• Agile is the better method when requirements are changing, unknown, or unknowable until seen (I won't know it until I see it).
• Agile methods are best when in situations of fewer than a handful of small teams, typically fewer than 50 developers
• Agile methods work better in-house than through the constraint of a contract
• Agile works better with co-located teams than though the cultural translation and limited communications channel of a virtual team

---

(**) Six Sigma is a ‘defined control’ methodology consisting of a multi-step problem identification practice and a defect control standard formally stated as requiring less than 3.4 million defects outside control limits per million opportunities.  The actual control limits are determined by analysis and by historical measurements

---

(*)  In this posting, innovate functions and features encompasses product base, product, system, deliverables, and outcomes; these terms are frequently used interchangeably.   

They all refer to whatever it is that the user or customer owns or uses at the conclusion of the project.  The projects applicable to Agile methods are software intensive, but may have many and complex hardware components.  

---

Buy them at any online book retailer!