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.