Sunday, September 28, 2008

Agile Specification: is it a hoax? or a necessity?

When Alistair Cockburn says something like:

"There is no such thing as 'agile specification'. The phrase is a hoax."

This is exactly the kind of discussion we had at the Agile Manifesto meeting in 2001. It means there is something really interesting to talk about. First, read why Alistair says he still uses use cases.

At PatientKeeper we have "Agile Specifications" which are similar to Alistair's use cases for new functionality. We require that they clearly specify the user experience with detailed screen shots, workflow, business logic, and data descriptions. We want just enough specification and a dialogue with the developers to determine how much to document. For simple things, a users story may suffice.

Problem: You will implement over a thousand user stories over many years at random times. Very tight precision is required for screen shots, flow, and business logic as a error could kill a patient. Or a physician could call it "crap" and refuse to use it.

Forces: Physician users require an exact fit to their workflow, their inferencing from clinical data, in minimal time while standing in front of a sick patient using their iPhone for all clinical data. Developers have no idea exactly how this should look to a physician. Neither does the Product Owner, even though the Product Owner may be a physician. A carefully selected group of physician thought leaders must use working prototypes to determine exactly how it should look and feel to the physician while coming to a consensus and developers much exactly create their chosen approach or physicians may refuse to use the product. Physicians will not use a mouse. Most things must require one click and anything requiring more than three clicks will never be used as it will interfere with conversation with the patient. Any data corruption is life threatening. Lack of ease of use is life threatening.

For example, a small amount of the clincial data is lab results. There are dozens of lab tests, each producing a complex data set with multiple values and normals ranges. There is interaction between these results. Automatic alerts for critical conditions based on a complex relationship between multiple lab results is needed. These are regularly updated by clinical boards that determine best practice. All lab tests are graphed differently to exacting specification taught in medical schools. Often new lab tests are required. They are based on research data developed in labs. The developer must be able to quickly review all previous implementations of all lab results to fit this new result into the physician's workflow in the correct way. The physical implementation of the current product is not sufficient for this purpose.

Solution: The Product Owner creates a dccument that is just enough, and just in time called Lab Tests. It grows over time as there are more lab tests, and as research data influences lab test results. The Product Owner does high level analysis of screen shots, workflow, data structures, business logic and presents it as a very light weight use case to support user stories implemented at a point in time. The Product Owner has tested a fully working prototype of this implementation on a group of physician thought leaders before any story for these is ready to go into a Sprint. Developers refuse to develop any story that does not achieve this "ready" state. In fact, they are told to take the day off if the Sprint Backlog is not "ready."

Result: Over eight years and thousands of stories the global specification has grown to almost thirty pages. A developer can capture in his mind in less than five minutes the entire history of implementation of all lab results that is essential for implementation of a new blood test for treating diabetic patients.

The Product Owners are extremely disciplined in this environment. They know developers will take the day off if their "Agile Specification" is not in a ready state for creation of user stories in a Sprint.

The Team is also very disciplined and achieves a velocity that is 10 times as fast as their waterfall competitors causing revenue to quadruple in 2007.

Name for this thing: Up for grabs.
Need for this thing: Absolutely essential or you will risk killing patients Or even worse, the physicians will refuse to use it declaring it "a piece of crap" or it has too many alerts or does not alert to a critical condition on this lab test in the context of certain data on multiple other lab tests. Or it does not automatically populate the right clinical notes, or the developer is clearly so clueless about treating patients that he should be shot, or ....

Best training for developers: Send them to surgery where patient is opened up on the table and the surgeon starts screaming at him and the surgical staff making threatening gestures to hit them with surgical instruments for providing the wrong data leading to his decision to abort the surgery and try again at another date when they give him the right data and the right instruments at the right time when the patients lab results are exactly in the right constellation for the surgery to take place.

Jeff Sutherland

Saturday, September 27, 2008

Roots of Scrum: Object Technology

Scrum was originally designed to support emerging object technology environments, which have now become the dominant paradigm in software development. One of the goals was to get the organization of the team to reflect the potential flexibility of the software since software rigidity always reflects the organization that built it. This is Conway's Law. Fred Brooks cited Mel Conway's 1968 Datamation paper in The Mythical Man-Month and the name stuck. "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

Object-oriented languages have a small set of interoperating principles. Break any one of them in creating a language and many of the benefits of object technology evaporate. A similar analogy could be made about Scrum. So here is a candidate set of principles.

Inheritance

It is easy to extend the Scrum pattern to fit the local environment without modifying the metaClass represented by the Scrum organizational pattern.

Polymorphism
The same message sent to a different Sprint can produce a result dependent on the environment.

Encapsulation (information hiding)
Work is packaged in increments. Scrum teams can scale by making a Scrum of Scrums look like a Scrum tream to another Scrum of Scrums. Using an object-oriented network to scale allows potentially unlimited scaling.

Emergent Design
A small change can have a ripple effect that causes refactoring and a new design emerges.

Messaging
OO is a messaging environment. Constant high bandwidth communication works best.

Self-Organization
There is typically no "control" object. Behavior emerges from the interaction between objects in languages and between people in Scrums.

Aggregation
Objects can be aggregated into components. Components aggregate into an architecture. Scrums can be aggregated into Scrums of Scrums orchestrated by a metaScrum. A metaClass creates the framework for all classes. The Scrum framework could be viewed as a metaClass laying out the minimal attributes of a Scrum and the relationship between components.

Reflection
Constant review and analysis at a meta-level leads to increased functionality and flexibility. This is an extremely powerful feature missing from some languages, which tends to cripple them. It leads to the Retrospective in Scrum.

All software implementations of objects use the metaClass of a specific language to create coherent structures. There were hundreds of people who created new objects languages and 99% of them failed in the market. These are like homegrown implementations of Agile. "We are doing Agile" has no meaning. It is like saying we are doing object technology. In the last decade we would look into the code of a C++ application and see nothing but old C procedures. There was often not a single object to be found. Today we see hierarchical organizations implementing hierarchical teams and calling it Agile. They can't help themselves. They have to change the organization first to get it right or Conway's Law assures that they will fail.

Certain languages are structured to work together like JRuby with Java. This is analogous to Scrum and XP. Others like Java and C++ inherit features from a common ancestor but do not interbreed well. Those that take pieces of Agile languages and cobble them together get what you would expect - a horse designed by a committee. It can't run but maybe it can store water.

Wednesday, September 03, 2008

Shock Therapy: Bootstrapping Hyperproductive Scrum



Scott Downey, MySpace Agile Coach, has a way of bootstrapping Scrum teams to a high performing state in a company that is about 1/3 waterfall, 1/3 ScrumButt with project managers, and 1/3 pure Scrum with only Scrum roles. Scott consistently takes teams to 240% of the velocity of MySpace waterfall teams in an average of 2.9 days per team member where the team includes the ScrumMaster and Product Owner.
At OpenView Venture Partners, we see portfolio companies with aggressive implementation of Scrum triple velocity in three Sprints (usually 2 week Sprints). Scott uses one week Sprints and it takes him about three Sprints.
I heard similar stories from an Agile leader at JayWay in Sweden. Using a forceful and mandatory way of implementing Scrum and good engineering practices, that Agile leader got similar results to MySpace.
Rob Mee at Pivotal Labs in San Francisco uses a forceful total XP immersion experience to bootstrap teams. They do everything exactly his way for three months. After that they have full body understanding of the Agile motion and he can send them on their way. It has worked well on 40 startups so far.
It may be that great Scrum teams need to go to boot camp or give themselves Shock Therapy in the same way a student of the martial arts gets thrown for a loop the first night on the mat and it never lets up until he masters the practice with his body as well as the mind.
I encouraged Scott Downey at MySpace to share his strategy with Björn Granvik, the CTO of JayWay in Sweden, and he wrote the details below. I'll be sharing this at Google in New York tonight along with thoughts on the Cosmic Stopping Problem and Punctuated Equilibrium and how they relate to the effects seen by Scott. For that, you will have to wait for the Google video.
--------
Hi Björn,

I'm sorry to say that I don't have anything formally written as yet, but I am working on it! I'm in the process of being a full time employee for MySpace while consulting for a few other companies on jump-starting their Scrum so my quiet time for writing is a bit rare these days. I'm happy, though, to describe roughly what I do that makes me the "hated" character Jeff described for the first 2-3 weeks. :-)

Scrum, as a framework, provides teams a ton of options for how to customize it to their own environment. In my experience, most teams just starting out are so overwhelmed with choices that they can't find a constructive way to start. I have known of teams that spent so much time designing their Scrum Board, for example, that Management lost patience with them and the Scrum process because a Scrum Board was all they ever produced.
It occurred to me one day that Scrum Teams are the customers of the Scrum Master. We all know that customers of our enterprise don't really know what they want until they have seen it. So why do we expect Scrum Teams to know how to set up their Planning Meetings if they haven't seen a prototype? So when I join a team as their Scrum Master, I issue a few non-negotiable rules (gently if possible, firmly if necessary). My rules remain in effect until the team has met three criteria:
  1. They are Hyper-Productive (>240% higher targeted value contribution)
  2. They have completed three successful Sprints consecutively
  3. They have identified a good business reason to change the rule
The rules are roughly these:
  1. Everyone on the team will attend a Scrum Training session.
    I conduct an extremely condensed Scrum at MySpace course in about four hours, and the entire team comes together to a session. Until everyone has been trained, we won't begin our first Sprint.

  2. Sprints will be one week long.
    I justify this by pointing out that there is a reason geneticists study mutations in Fruit Flies instead of Elephants – they want to see the mutations quickly and adapt their studies accordingly. So do I. Teams generally hate this part as much or more than anything else I require of them but I have been able to coax every team into giving me at least four, one-week Sprints as a trial. Here's a favorite exchange of mine that almost always comes up – feel free to use it:
    Engineer: "But I can't do anything in a week!"
    Scott: "Then simple math suggests that you can only do four nothings in a month."
    Interestingly, by the time the teams have met the three criteria for changing this rule, only one so far has ever elected to change it.

  3. They will start out by using my definition of "Done".
    This is often one of the thorniest issues to iron out with a team, so I take it off the table until they have some shared success as a foundation. My initial definition of "Done" is this:


    1. Feature Complete
    2. Code Complete
    3. No known defects
    4. Approved by the Product Owner
    5. Production Ready

  4. All estimates will be exclusively in Story Points.
    Again, this one is sometimes met with a ceremonial rolling of the eyes but – so far, anyway – they have all eventually come around to this. It's usually at about week three when I can intentionally spark a debate over whether a card is a 3 or a 5, then have the pleasure of pointing out to them the passion with which they are debating these recently-meaningless values. I also make a point of shouting "BA!" whenever they all vote the same value for a given card. My intent is to show them how often they actually agree in their vote. As the mood on the team lightens up, some teams begin scanning the other votes and "baa"ing like sheep when that happens. Only one has returned my "Ba!" with a "Humbug!" In any event, they all start having fun with it and that's important.

  5. We will use a physical Information Radiator.
    Not only do I insist on a physical Information Radiator, but I have a basic template that I use initially for all teams. I choose the location of the Scrum Board unilaterally and use it as the focus of the Daily Stand-Up Meeting. When the team is first formed, I let them focus on the interaction with their teammates (the three Achievement questions ) and I move their cards across the Radiator's surface myself. Within a couple of weeks, they start moving cards themselves without having been asked. This is usually my first indication that I can begin slowly stepping back and relaxing my demands.

  6. Sprint Planning Meetings will be four hours, once per week.
    The first complaint of most Engineers is that they perceive Scrum imposing a highly disruptive schedule on them, with more meetings than they somehow think they have ever had before. To minimize this common concern, I consolidate everything but the Daily Stand-Up meetings into a single, four-hour meeting. Within a few weeks, the teams usually only needs a couple of hours. And by the end of about eight Sprints together, the meetings are becoming ninety minutes or less in duration for a one week Sprint. My initial agenda is as follows:
    1. Demonstrations where the Team shows the Product Owner the work they achieved and receives Story Point awards based on their accuracy.
    2. The Retrospective comes next, aided by a host of metrics that I track. I only track whole-team metrics, never individual metrics. Initially, though I publish many metrics, I only focus on Velocity, Burndown, Work Capacity and Commitment Accuracy.
    3. Product Backlog Presentation follows, during which the Product Owner discusses the content of the Backlog at that point in time. The Team is free to question motives, suggest alternatives and add requirements at this point. I reject any improperly formed User Stories on behalf of the team.
    4. Estimation and Negotiation signals that the meeting is nearly complete. They happen in a single motion with my new teams, though more mature teams eventually choose to split these activities into unique meetings. The Product Owner participates in an advisory role only during this phase of the meeting. I spend most of my time in this phase trying to keep the teams from unnecessarily breaking Story Cards down into task sequences, which some tend to do. The INVEST mnemonic is really handy here.
    5. Sprint Backlog Commitment is the final act of the Planning Meeting. In the first few Sprints, I literally read aloud what "Commit" does and does not mean so that there is no doubt in anyone's mind. Once the team commits to the work, the meeting adjourns.

  7. Multi-Tasking is Forbidden. Work must be in Priority Order.
    Some Engineers understand this right away. Others feel most productive or fulfilled when they have multiple projects in progress and they don't appreciate my pointing out that there is no value in incomplete work – but point it out, I do. And often. I insist and enforce that they work on cards without multi-tasking and in priority order.
I also have standard layouts that I use for their initial Sprint Planning Boards, User Stories, Story Cards, Burndown Charts and Velocity tracking. I take full responsibility for entry and management of the (horrible) Scrum tool that we have at the moment so that they don't have that misery to deal with on top of learning everything else.
As I said in the beginning, I do try to get all of this done with a friendly smile and a "please" but generally have to insist -- sometimes quite forcefully -- to get all of them moving. Although the beginning is rocky, we usually start laughing and having fun in the meetings within a week. And as they become more compliant and competent with Scrum, I quickly relax my grip on some of the rules and let them redesign their environment to their own liking – so long as they continue to respect the principles of Scrum.

Three key reasons that I believe I am successful with this approach are:
  1. I find the biggest, nastiest problem that the team has and solve in within a day or two of the first Planning meeting. Some teams quickly volunteer this problem to me in their first Retrospective while others require observation, careful listening and behind-the-scenes reconnaissance to tease it out. Especially for those teams who haven't worked directly with me yet, having that very large problem go away underscores that they are important to me, that I take them seriously and that I am working hard to make their world a better place.
  2. Since I am the Master Scrum Master/Scrum Evangelist for the entire company, I am almost never their permanent Scrum Master for any given team. This gives me the freedom to create a bit (but only a very small amount) of "Us vs. Him" atmosphere at first. It causes the team to bond in an entirely new way than they have before, and also sets up their permanent Scrum Master to be the "good cop" down the road. It also allows me to be more firm about standing during Stand-Up, keeping your estimates private until the vote is called during estimation, etc. Keeping in mind that I generally have to bow out and move on to another team after 6-12 weeks, by which point they are functioning very well and are (on average) around the 500% mark, most teams tolerate this very well and learn good habits more quickly – even if it does leave me feeling a bit a schoolmarm.

  3. I think Socrates was on to something. When I see something going wrong – say, someone sitting during the Daily Stand-Up – I don't always address the transgressor directly. Instead, sometimes I stop the meeting and ask the team, "Team, do any of you see something going wrong with our meeting right now?" Ironically, it is almost always the most skeptical person who is the first to correct the insolently perched teammate. Soon, they start calling one another on leaning or sitting long before I stop the meeting and ask what's going wrong. It helps them begin to police themselves so that I don't always have to be around to elicit good behavior.
This is roughly how I have driven teams into hyper-productivity in as few as four weeks, and why one of my co-workers calls me "The Scrum Whisperer." I have one team that has achieved 1,650% higher targeted value contribution per week after just four months (16 Sprints) together. We are pretty proud of those numbers. I've also noticed that teams using this "quick format" approach tend to hit their Velocity elbow much sooner, giving Product Owners a greater and more stable view of the roadmap than teams who use longer Sprints or spend their inaugural period hashing out where they want their Scrum Board to be located.


It's a fairly large culture shock for most teams and doesn't yield a lot of "let's go to lunch" invitations at first. But, per feedback from my VP of Engineering, "They only hate [me] for about 2-3 weeks. Then they're indifferent to [me] for another few weeks. Then they scream bloody murder if [he tries] to take [me] away from them." I do stay in touch with teams that I've kick-started like this and, with one notable exception, they have all continued their trend of improvements in my absence.

I hope you'll find some of this helpful as you try to slingshot your teams into optimum Scrum performance. If I can be of further assistance, I would be happy to help. I'm also very interested to hear of your experiences, and your opinions of my techniques which are always evolving.

Best,
Scott Downey
http://www.MySpace.com/PracticalScrum