LeSS SAFe is more - events coming up right now

Another installment looking at different ways to adapt Agile to enterprise scale.  Inflating it, as it were ...





Photo credit: Gerald Pereira and License

• First, some comments on LeSS given that you have the opportunity to go see for yourself (if you can afford it).
• Then opportunities to learn about SAFe.

What is with these mixed-case acronyms?  I guess there are some people pedantic enough to complain that you cannot use a capital E in SAFE because the words has a lower-case "e".  It would be if we YELLED IT LOUD ENOUGH :-)
Worrying about that sort of thing is very un-Agile.

LeSS Materials and events

H/T to Brian Sjoberg at Excella Consulting (a company that has impressed me over the past 2 years), although in this case Brian is representing the DC Scrum Users Group (DCSUG)for this heads-up.  If you have interest in Agile I can thoroughly recommend DSUG's meetups.

• A course on Large-Scale Scrum (LeSS)in the DC area from August 10-12 (registration page)
• LeSS SAFe Comparison by Gosei
• Blog post comparing Waterfall, SCRUM, SAFe and LeSS here.

LeSS Seems to be Just Less

As noted in an earlier post, I have not quite got the drift of LeSS.

The folks who are leading proponents of it in the US describe the integrative processes as "whatever the self-defining teams define it to be".  One could make a case that a pyramiding schema of scrum-of-scrums and product owners would be able to establish integration in terms of cross-component integration.   I don't see that as alleviating the organization's concerns over scalability and security.

I do note that in the most recent framework picture (at the LeSS link above), architecture and security now have a specific place.

A Turn for SAFe

H/T here to Net Objectives for the following information:

• Conference: Agile2015, in Washington DC - next week (August 3-7).  $2400.

• Net Objectives' 3rd Day of SAFe: Elaborating SAFe  (you have to give up your e-mail address but it gets you access to tones of material).

• SAFe in an Hour. A quick introduction to SAFe.

• Driving from Business Value in SAFe. Introducing minimum business increments and why they improve SAFe's portfolio management.

• Rapid Implementation of SAFe. Rapid is the new method we'll be discussing in the open space.  This was a pre-look at it. 

• Introducing Leanban. A first look at our new team-level Agile process that is more than an integration of Scrum and Kanban. [This link here is further updated since the presentation date].

• Using SAFe in Small & Mid-Scale Organizations. SAFe is intended for development groups of more than 50 people.  This webinar presents methods of coordinating multiple teams which total fewer than the 50 required for SAFe.

Agile Enthusiasts and Professionals

Beware the agile enthusiast who has only worked on one project at a time and does not get why the enterprise doesn't get Agile. Enterprise Agile often fails because Agile enthusiasts do not really understand it either.

I distinguish here "agile enthusiasts" from true agilist professionals who absolutely do get the issues around Agile at scale, indeed I defer absolutely to their vast experience.  You know who they are.  I hope not to offend the many others who fall into that category by naming those I've had the most interaction with and therefore admire tremendously include David Anderson, Ron Jeffries and Jeff Sutherland.   How do you tell the enthusiast from the true professionals? Ask them a couple of questions:

Where did the money came from to do their agile project in the first place? Where did the themes and epics came from?  Do we really rely solely on the product manager's brilliance? Where did the networks come from that you're going to build your solution on? Deer in the headlights [sorry for not attributing, but the hosting page didn't either].

The question isn't really why enterprises won't adopt agile; the real question is why agile enthusiasts don't understand some key things:

• the processes at work in their own enterprise
• how their projects came to be in the first place
• how to fit their little piece of the world into a bigger picture. 

Here's a post that explains how Agile fits very well into the enterprise - if you understand how both of them work. Understanding one and not the other leads to misunderstandings and outright hostility.  Not unlike the rest of the world.

They are  not alone, of course; lots of people on the more traditional side of project, portfolio and program management don't understand it either.  Which is why I write this blog.

Agile artifacts - low-tech solutions in a high-tech field

Isn't it ironic that Agile is the latest thing used to drive our most high-tech field but it seems to be most effective to carry it out using really old-school tools: wallboards and spreadsheets.



I would have started with the credit for the inspiration but it wouldn't have made a very appealing thumbnail on Linked-In or Google. This post was inspired by a tweet from Andrew Yochum (@Yochum) which in turn leads to a blog posting which is absolutely the least self-promotional ever -- no author credits anywhere. So now you have his Twitter information and a link to the post . As you will see from the link, I used his kanban picture too, as that helps to drive readership, but since I'm promoting his post that seems fair.

Back to the topic: I've taken a look at several automated tools that support Agile processes (Rally, Mingle, Jira) and they all have the same weakness: real estate.   Unless you have a humongous monitor, it's pretty hard to see what's going on in a screen-rendered version of the wallboard, and if the metaphor converts everything to lists then at least for me the whole flavor of Agile is lost.

So what about the low-tech options?

I've used SharePoint to try and track stories and progress.  It works, after a fashion.  It has the advantage over Excel in that everyone can see it and work on it at the same time.  The disadvantage is that you can't see the cards laid out; you have to use each story as an item in a list.  By creating the progress points as discrete options in a single column (fields), you can get SharePoint to generate views, using the list-type format and the power of the "group by" function, to show you such information as:
You can also use the calculation function (sum) to show you the number of story points planned and completed in each sprint, and that of course is the information you need to construct velocity charts - in Excel!

Excel, of course, lends itself to the charting.  It is also very handy for tracking the stories in the form of a requirements matrix (I know the purists are gagging, stop that).

What about using the Excel as the board itself?   No problem!  With its columns-and-rows display, Excel is of course capable of acting as the board.  In fact, in the example shown above, we could and did extend the columns to the right because we are tracking the stories anyway). But it gets to be a pretty big sheet.  For group purposes, Excel's drawbacks as the primary tool is that only one person can edit it at a time and it must be maintained on a shared drive, which means everyone must have access to that drive. For some reason office shared drives seem to be a bit more persnickety than things hat live on a web site if you're coming to them remotely.  And of course Excel doesn't do versions, so if one person trashes up the sheet the only way to fix it is go back to the last version that was saved separately.

And of course there is the wallboard. The problem with that is the demise of the concept "wall".  With open-plan offices increasingly the rage, there are no walls. Withe remote workers, there is nobody there to look at the wall anyway.  And people seem to get upset if they have the work-space right next to a spot (e.g a space along one of the rare walls) where a half-dozen people will cluster and jabber, even if it is work-related.

In a related post on Linked-In Pulse, I also note that the same problem arises with the traditional waterfall tool (MS-Project).

Please feel free to share your workarounds for using electronic methods of replicating a physical collaboration that hardly exists in the real world any more.

Scrum as a Teenager: A Retrospective from Jeff Sutherland

Getting to Done

This post is a summary of Jeff Sutherland's presentation to the DC Scrum Users Group, 21 May 2015.
The slide deck is available at Jeff's company's website.
The entire presentation can be seen on the DC Scrum Users Group Meetup site which may require you to join the group, as well you should if you are in the DC area and interested in Scrum.

Reminder: the goal of Scrum is to produce working software at the end of each sprint.

The Agile Manifesto did not spring from the blue.  The group drew its conclusions from over 20 years' of data compiled by Bell Laboratories. Those records showed conclusively that:

• Communications drive production effectiveness
• Specialization cripples production

Quite aside from the speed aspect, the data also showed  (and current data continues to show) that a bug (or failed test) that escapes from a sprint costs 24x the original development effort and time to find it and fix it.  Keep track of these events is important: in his experience, as soon as management get hard data on it, the problem of whether software needs to work at the end of a sprint is dealt with immediately.

Jeff provided references to a second data source (the Chaos Manifesto) which found that the long-standing problem with delivery of IT projects documented by the  Standish Group over the years has not changed much for Scrum-managed projects.

He also noted that for small projects, waterfall is just about as effective as Agile, probably because the timing and scope don't offer much risk anyway.

What are the blockers to success with Agile?  Success being defined as ready and done.

• Teams trying to drive features out at maximum velocity are buried in technical debt.  You can't dig your way out of that hole with continuous improvement efforts later on.
• There is organizational debt.  This is what Kik Piney calls "anti-maturity"; you can learn more about it in this post. 
• Organizations are stuck in "old way" thinking: press the developers harder, and compile more reports.

How bad is it?  At Microsoft, as much as 85% of the effort is classified as "non-tool" (a euphemism for "rework").  But at least they have recognized it and are doing something about it.  Something quite scary-sounding, in fact: they are abolishing all testing outside the main sprints. [Audience gasps]. At Nokia, the company's Agile process got so bureaucratic they were completely unable to react to the invention of the smartphone.  Ironically, Microsoft returns to the story - it bought Nokia and killed off the company.

Some bad news for those consultants who have gone in on the credential mania: Silicon Valley is now divesting itself of Agile Coaches, replacing them with internal assets because they already understand how the company actually works and they can be held accountable to deliver working software.

One of the big new topics is Agile at  Scale.  The consensus seems to be that it does not work.  That isn't really true.  Consider the Internet itself, the world's largest and longest Agile effort! Scaling Agile and Scrum, like the one-project versions, depends heavily on competence for success. It is best done by scaling out, not up, though coordination rather than developing policies.  Consider the 24-hour car-building project.

So why are we not getting to done?

• Done is not well-defined.  Done must include "working".  Product owners are sometimes pressured to accept work that is not truly done in order to maintain an appearance of "no problems".  That's not the point of Agile. Accepting incomplete work also provides a distorted view of velocity (well, that is rather the point, isn't it) that just makes subsequent estimates even worse.
• Stories are not ready.  Estimates are bad; stories are not broken down to minimal bites.  Failing to understand true velocity causes the team to take on too much work, and then they just start shaving the work even more. 
• Dysfunctional leadership.  Often, they can't stick with their priorities long enough to get through a sprint.  Worse, when things run into issues, they are willing to paper over it to provide the illusion of velocity for reporting purposes.
• Technical debt (already discussed)
• Organizational debt (already mentioned)
• Last but not least, bad Agile Coaching.

What can we do about it?

• Use a defined Scrum model. That would include the definition of done.  If effectively defined, it may not be necessary to test every feature on every build or sprint.
• Have stories ready.  They need to be defined effectively, and trying to get it all done in a few Spring Planning meeting hours is simply not possible.  So you have to front-load that effort.
• Major shifts in the corporate supporting processes.
• Establish goals and work to them
• Establish a viable business plans before starting development
• Remove barriers and wastes
• Hold the Product Owner accountable for the value delivered per story point
• Hold the Scrum Master accountable for ... well, that is the key question.
• Eliminate Technical Debt.
• Identify and fix blocks
• Use cross-functional feature teams
• Train and hire "T-shaped people" - people with the ability to contribute in several areas (wide) and solid skills in one or more particular areas (deep).
• Build out an object-oriented architecture to permit re-use
• Monitor the value streams
• Queues
• Wait status
• Other metrics

This summary didn't capture all of the nuances - many of the pearls are in the one-liners!  See the live presentation, you will enjoy it.

Earned Value EVM and Level of Effort - Yes You Can

Oscar Wilde would have made a great program manager.

"Nowadays, people know the price of everything and the value of nothing" - Oscar Wilde.

We saw in an earlier post that you can do EVM with Fixed Price after all. In a true fixed price contract, the number of resources and working arrangements are not under the buyer's control; the vendor just gets the job done somehow.  You can still work EVM into it (see the prior post at the link above).

It is ironic that so much of the contract work for the government, which advocates very strongly for using EVM has migrated very rapidly from the much-maligned cost basis to LOE. Why is this a problem?  Because it appears to be unaccountable.  The team comes aboard to ... well, to do what?  Whatever needs to be done, meaning whatever the contract monitor wants done, which of course is a personal services contract and would therefore be illegal (in government), which no doubt explains why so many of them are in place in Washington.  But there they are, and we have to deal with it.

People think you cannot use EVM with LOE because there are no real deliverables and the planned and actual costs are always the same.  The "official" solution is that level-of-effort activities don't contribute to specific work packages and should be held in a separate line of accounting from the work packages.  Then they just accrue costs as the calendar passes; but they do not earn value. They are part of the project cost baseline but not the performance baseline. This is a good way to account for project-wide overhead costs, which contribute more or less equally to all ongoing work packages (or impede them, depending on your point of view!)

What happens if the level-of-effort people are working on the actual deliverables?  You can't exempt 95% of the project labor from the EVM metrics.  For true LOE contracts, whether on their face or disguised as fixed-price contracts, the people just show up to work ... and do what?.  Since it is illegal to award an actual personal services contract, you don't often see one that actually says "just give us xx bodies and we'll tell them what to do". What you see instead is a "fixed price" contract that is really level-of-effort: the vendor is to deliver a defined number of hours (conveniently 1980) of various labor categories, with a statement of work that is either very vague or quite specific but will be completely ignored.

At a very basic level, if the vendor fails to provide the agreed resources (a common occurrence), then you can show a delta between planned cost and actual cost.  The philosophical problem here is that no backlog of work builds up: customers may be poorly served at the time, but there is no way to go back and serve them later when the resource does show up.  That, of course, raises the uncomfortable question of what value was lost by the work not done, and if you use that math then you have to extend it to question whether any much more value is gained from the work that was done.

As to the so-called "fixed price" contracts to provide labor-hours, that's no different at all from other cost-based contracts; there's just less paperwork needed to establish the actual cost.  Many contract monitors prefer not to crack the whip, or don't know how, but since it is nothing but a typical cost-based contract you can give guidance on the deliverables to be produced and the hours (costs) needed to do it.  If it gets done sooner or cheaper, you are ahead of the game; if it takes longer or more work, then you are behind the plan.  Voila: we have EVM!

Let's suppose that the contract does provide for a real LOE and real (if vague) deliverables.  The very latest thing in this arena is agile-type work (especially Scrum, the most popular brand) in which a team assembles on a near-full-time basis to do whatever work they can get done to deliver for each sprint.  Despite the popular impression that Agile is just a license to throw all oversight away, there is actually a rich body of knowledge on Agile metrics.  Just as with a true fixed price effort, it is entirely possible to establish intermediate milestones for longer-term efforts (such as a release) in which the earned value might be as simple as a completed sprint and may be more complex to address the planned and actual velocity.  an even more sophistical scoring method can address the velocity at which delivered features are meeting value priorities.

Just as with the true fixed price scenario, the important thing is to separate the concepts of "value" and "cost". 

Earned Value and Fixed Price - Yes You Can.

Earned Value Management is at the core of any project management framework as the method of integrating cost, schedule and scope to assess the progress of a project.  The framework has been remarkably stable over at least the past 40 years, from its earlier incarnation as the Cost/Schedule Status Report (C/SSR), and since it pretty much conforms to common sense [we can talk about Schedule Variance in another post], it is quite likely that the Pharaohs had something similar. Tens of thousands of project managers have been trained in EVM, and it is quite impossible to pass any certification test without knowing at least the basics.  And it is Federal law that any contract over $1 million must be managed using EVM.  Yet at seminar after seminar, certified PMs report that they are not using EVM.  In the public sector it is resisted with a passion that most people had assumed bureaucrats do not possess.

Sure, most people, even trained PMs, and all organizations vastly prefer to evade being held accountable. That's why we need objective reporting systems in the first place.  Let's just deal with the argument that EVM does not apply to fixed-price work (which most Federal contract work is supposed to be) or to level-of-effort work (which almost all Federal contracts are).  Once you take those two approaches off the table, particularly if you buy into the nonsense that a labor-hours contract is "fixed price" because the unit price per hour is fixed, there's not much left. But what "everybody knows" is quite untrue.  Saying that something cannot be done does not really mean that it is impossible, just that you want me to think that it is impossible so I stop asking you to do it..

The argument against using EVM for fixed-price work is that the cost is accrued only at the point that the delivery is completed, at which point the cost is always equal to the negotiated price (unless you are selling airplanes to the Defense Department).  Likewise with level-of-effort work, where people just show up and do whatever the client wants, there is no contractual relationship between the completion of deliverables and the cost of the service (which is the reason that at the Federal level such contracts are illegal bwah-hah-hah).  At, at a certain level of disingenuity, that's true.  But you don't have to set up this work in an unaccountable way, unless of course you are just trying to avoid accountability.

Assume for the moment that both the vendor and customer are interested in a quality product (or service) at a reasonable cost.  Do we really think that the vendors let their people just do whatever until a few weeks before the contract delivery period expires?     Of course not.  There are interim milestones and estimates of the work needed to achieve them; in fact, those had to be developed to come up with the proposed cost of the work in the first place.  Except for the very smallest increment of delivery, there is no reason at all that we cannot establish intervening milestones and the value associated with achieving those milestones.  That value does not have to be the costs incurred to date; doing so merely converts the work back to cost-based.  And please do not allow the vendor (or a lazy contracting officer) to set up straight-line progress payments; that, too, converts the work to cost-based.  What are you going to do when after the 11th month it finally becomes clear that the deliverable will not arrive on time?  Now instead of 100% of the payment (highly motivational), then vendor only has 9% of the total payment at risk.  Good luck pressuring them into timely delivery at that point.  You should determine the value of the milestones and pay for those deliveries only when they are complete and acceptable - and if they are late or do not perform as required, you don't pay for them at all.  Now you have deliverables that have schedules and a planned value (which, notice, does not have to be a planned cost-to-date).

You can get a simple template that allows you to produce an EVM graph and metrics in this manner (see the Solutions tab).

Tune in next time for a discussion of EVM in a Level-of-Effort situation.

Trust but verify - heavy on the verify

If a decision happens but nobody writes it down, does anybody hear it?
If a decision is published but nobody checks to see that it is being followed, will anybody follow it?

Why can't you see the glass as half-full once in a while?
We've got good people here. We told them what we wanted to do. They don't need to be baby-sat.

If everyone was in agreement we would just go ahead and do it.
The reason we have highly-paid executives to decisions is that there are conflicting points of view as to the best course of action.
Therefore, whatever they decide is going to differ from what a good proportion of the next layer or two in the organization would have done if left to themselves.

At the same time, most executives didn't get where they are by having no political instincts, which means that quite often they say things that they don't really believe because that seems like the proper thing to say at the time.
So it's entirely possible that a decision isn't really a decision, more like a pronouncement to kick the real decision down the road a while.
All very Byzantine.

So what do people do while trying to get on with life in their smaller part of the organization?
If the executives don't have the gumption or the stamina to make sure that their decisions are carried out, it sends a pretty strong signal that they don't care too much either.
Then the people who didn't agree with the decision in the first place won't be very deterred from giving it at best lip-service until they find out whether this initiative is anything more than the fad of the month.
The first sign that the decisions aren't really decisions is that the deciders don't really want anyone to know what they decided or why.
It removes their latitude later for changing their minds.
Of course, in the short run, it also means that it is more likely that the decision will be ignored.

If our governance decision authorities (whether boards or individuals) are serious about having their decisions respected and followed, then:

Write down what was decided in clear terms: Who will do what by when with what resources

Include enough information to understand why the decision was reached and any issues that were raised<\li>

Publish the decisions to those who are affected - at all levels. That way intermediate managers can't slow-roll or pocket-veto.

Follow up on the progress of the actions that were decided on

When it makes sense to do so, change a decision and publish the fact that it has been changed

Assuming that the PMs and/or staff have done due diligence before offering up solutions for the board to approve, then the approved course of action should be achievable.
If the intermediate managers can't or won't get things done, find someone who will.
Preferably someone who was rooting for the original decision. It will greatly improve the quality of analysis in the future.