Big Agile

---

For a long time it's been "big data". Now comes the new coinage: "big Agile", or agile on a really big scale

It's all about scaling up. The argument, if there is an argument, is about whether to (a) add more process to handle more scale -- which is somewhat like saying add a framework which itself is often a surrogate for guided workflow processes -- or (b) just add more smart teams, pump up the collaboration so that everyone is doing 360's with everyone else, and apply a touch of process to tie them together. That's the recipe, or so we are told.

In reading stuff on this topic, I was struck by this bit of wit:

 Simple, clear purpose and principles give rise to complex and intelligent behaviour. Complex rules and regulations give rise to simple and stupid behavior.

Dee Hock, former CEO of Visa

What more do you need? We have the Agile Principles; we have some methodology guidance (Scrum, XP, DSD, etc), so we've got it; that's all smart people should need.

I actually agree with CEO Hock on the big picture (said picture to go along with the other biggies: data, and now Agile): a light touch in governance is likely better than Taylorism: all jobs scripted and defined to a fare thee well. Why so? Simply for the point made by Hock: advantageous behavior arises where there is flexibility to be different and challenging.

But, let me put in a word for process, especially as required in "big Agile". If by big Agile you mean a half dozen teams, then perhaps you can get away with a pretty simple guidance paradigm: do no harm to the other guys, and check in regularly.

But if you are talking seriously "big Agile" with many distributed teams, lots of interactions and dependencies on a myriad of non-development stuff, like training and logistics, then it's not good enough to just have the "dots". There has to be a systemic and sustainable way to connect the dots, and that's what's embedded in process.

Try building a million lines of code contained within thousands of objects for an automobile, to take a relevant example, without some serious processes for handling interfaces, integration testing, validation of function and feature, and customer supportability, to say nothing of reliability, security, fail safe, etc  (Remember the Toyota thing with the unintended acceleration? Was it the software?)

---

Bookmark this on Delicious

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

15 ways to communicate or improve communications

---

Some New Year's lists are more practical and useful than others. Here's 15 ways to get leverage out of your communications. Given the center spot of communications in our business, this list -- from "A girls' guide to project management" is worth a look.

One suggestion you don't see all that often is this one:

6. Create a communications asset register A communications asset register is a list of all the communications assets that you have created for the project. That includes:

• Newsletters
• Press releases
• Internal magazine articles
• Posters
• Flyers and leaflets
• Photos

And, of course, there is this one that is ageless:
3. Use checklists

• Create checklists for tasks that you do frequently like hosting Project Board meetings or project kick off.
• Checklists are in use in hospitals and airlines because they help people remember everything they need to do and ensure nothing gets forgotten.
• Pick a few tasks that you struggle with (for me it’s creating POs and then paying the invoices) and create a checklist so you don’t have to think about it anymore.

---

Bookmark this on Delicious

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

Done, as in 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 DoD as it were has been 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 DoD 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. In other words his theory is tested in the crucible of a trying to make money or fulfill a mission by writing software. How swell for us who read Cohn!

---

Bookmark this on Delicious

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

Intruder alert

---

Cyber attacks are in the news almost daily, and certainly high profile projects, or projects in high profile businesses are not immune. Indeed, theft of proprietary project information is high on many lists of the criminal mind.

Of course, your IT should be on the case, but it might help if you can talk to them a bit in their language about how safe are your project proprietary files.

Here's a nice primer from one the US national laboratories at Los Alamos. The article is in one of the back issues -- November 2013 -- of their Science and Technology Magazine (free online subscriptions)

Unfortunately, the theme of the article is: they're going to get in. The trick is detect the intrusion and then mount countermeasures. It's a play on: for success "they have to be right only once; you have to be right every time"

Of course, one is led directly to Nassim Taleb with two big ideas:

1. Black swans: I can't imagine it could happen to me, but of course, it can! Thus: heads up! if anyone actually needs that advice in this day and time.
2. Anti-fragile: I can sustain a big shock and keep on truckin' (or, if I am doing my systems right, I can sustain a big shock, else I am in a world of hurt)

And one is also led to one of the key principles of system engineering: loose coupling, and the ability to decouple quickly (read: instantly) -- that is, disconnect and isolate. We've been loosely coupling railroad cars since 1840 or thereabouts; we've had ejection seats in aircraft since the '50s... why not computer systems?

Personally, I keep anything important on a physically disconnected drive. It's only connected for short periods to get updates. The cloud is a step in this direction, but even clouds are not as safe as physically disconnected storage.

So, you've been warned, as if you've not read this stuff before elsewhere

---

Bookmark this on Delicious

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

Integrity is free... or should be!

---

In an essay recently published, Elizabeth Doty, in a take-off on Phillip Crosby's "Quality is Free" idea, as told in his 1979 book of the same title, tells us:

Integrity—or lack thereof—remains a critical challenge for companies today. Whether it involves promising a client that our software will work in their setting, adhering to investment guidelines with people’s retirement savings, or performing the correct medical procedure, we owe it to our customers, employees, shareholders, and the world at large to be responsible about what we commit to and what we deliver.

Now we are not given in real evidence of the criticality of this challenge -- we are pretty much left to think of our own experience -- but it's suggested that there is a "commitment drift" that may have settled in.

There seem to be two elements to the drift idea:

1. We're really not committed, so the integrity of promises made is more of a fair weather thing... if things go well, you get what you expect, but if there's trouble, the commitment may be lacking, or worse: corners are cut to give the facade or impression of integrity
2. We're committed but we've over-committed, so the integrity of the promise is more of Ponzi scheme

The remedy for this drift seems to be the well known formula: under promise, over deliver. To put this to action for PMs we do these things -- which, by the way, are "free", only to cost something if not addressed up front:

1. Do not accept single point estimates for anything, because that means no serious thought has gone into the downside
2. Do not schedule without buffers or slack, because no plan survives actual performance
3. Do not not plan: that's just stupid to start off with only a hope and no real plan
4. Do not expect performance to emerge where it's not even promised -- example: miracle occurs here!
5. Do speak truth to power; eventually you are going to have to face them, so earlier is better; later will clearly get you a demerit
6. Do walk away if your personal integrity is challenged... your reputation is leverage: don't give it away

---

Bookmark this on Delicious

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

Baselines, baselines

---

In a recent Agile class I facilitated this discussion re baselines:

Student 1:
 "I have a new Operations Director, and he says once you've missed a date, you re-baseline, and the item is no longer indicative of a bad/out of date status. In previous positions, we didn't always or weren't allowed to do that, so that they could track the original dates vs. current progress. Just wondering how others handle this."

Student 2, in reply:
"When I baseline a project, it is once and done. How can one measure truly the progress and planning of a project if the baseline is reset every time a date is missed? I agree that this would indicate a false sense of progress, a false green.

The only exception I can think of is if the project plan introduces a significant change that is approved by the project board and sponsor that impacts greatly the objectives and especially the schedule.... "

My facilitation:
Not exactly!
Re Student 1: if  you've missed a date, that's a variance. The baseline is still the plan you are managing to so long as you are trying to recover the schedule.

Re Student 2: "once and done" doesn't work either. There may be many reasons to rebaseline as the project goes along. It's not like you have a budget of 're-baselines' and you can only use so many. However, the key to the whole thing is the second point: "... significant change approved by the [controlling authority..]"

So here's the thing: first common sense always applies. In most non-trivial situations you have two plans at all times:

1. The baseline which is the agreement between the sponsor (business) and the project
2. The operating plan which is the day-to-day plan derived from the baseline

As project manager, you must have a strategy to merge or bring together the operating plan and the baseline so that at the end of the day, the baseline is the plan of record... all variances of record are measured against the baseline.

Now, if it becomes the situation that the baseline is no longer valid -- approved changes, etc -- such that there is no practical way to merge the ops plan with the baseline, then you rebaseline:

1.  Record and archive all variances to the baseline -- B1
2. Replan the project; this replan becomes the second baseline -- B2
3. At the project conclusion, sum the archive of variances from B1 with the variances accumulated in B2. These become the cumulative variances of record.

To wit: you get no free lunch on variances just because you re-baselined. And, this is the deal in Agile or traditional... no escaping there either.

---

Bookmark this on Delicious

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

The shape of the table

---

The shape of the table matters. Ask anyone who has negotiated.

Want to even the playing field? Make the table round.
Want to be agile? Make the table round.

From tables to agile? How did that happen?

One way to get agile -- or increase agility, or velocity -- is to purge hierarchy. Flat is better. Square is ok; round-and-flat is better yet. There is no head of the table. At least by seating, there's no chief among chiefs, though in every group or team some dominance will emerge.

We can extend round-and-flat to portfolios -- all projects equal; and to projects -- all work streams equal; and to the WBS: all major activities equal.

And the advantages of round-and-flat are: less hierarchy; less dominance; improved safety; shorter and quicker lines of command and communications; more lateral interaction; and close-at-hand working to foster innovation. From all this we get a better ROI: more production at less cost.

What's not to like? Really, nothing, unless you are a control person. In that case, you may be pretty uncomfortable.

You ask: what about a virtual round table? Does that work for remote workers the way it works in a co-located venue?

Not exactly.

Remote working has a slower velocity, and a poorer track record of innovation. We are social, and do our best work in a social environment. It may be only you and me; but generally it holds that even if only pairs, the paired environment works better than the sole contributor. (If you really are working alone, add some background, audio or visual: music, chat, even TV with the sound off.)

Take away message: go round!

---

Bookmark this on Delicious

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