Alistair Cockburn

A short note on Time and Patience

Time has patience.

And patience has time?


I think time has more patience. It is already infinite. Patience should have time. But only for as long as it has patience. Patience needs more than just time.

If time contains patience why isn’t patience as infinite as time?


To me, time is empty, and uncountable large, say infinite for convenience, although I don’t like’infinite’. I don’t have any relation to infinity.

So time does not move. Ergo it has infinite patience.

The same cannot be said of patience. Patience is already “with respect to”. So it already relative, bounded. It can be as big as it is with respect to something, but that is already finite.

Patience also contains another thing, something between not-caring and forgiveness. Not-caring is not necessarily infinite, except that time is infinitely not caring. But time does not contain forgiveness. People forgive, time doesn’t care.
And so I write, time has patience – not because it is forgiving, but because it doesn’t care. When we step into time for patience, we pick up the not caring. We have to add our own caring. (Which may not require any forgiving ).

I think that’s the full thought

.p.s. this photo is from http://static.rogerebert.com/uploads/review/primary_image/reviews/the-patience-stone-2013/hero_PatienceStone-2013-4.jpg : a review of the film, The Patience Stone. Already so remarkable the photo, the story, even the review. I wish now to see the film.

Solutions Focus aka Delta Method


alternate name: Solutions Focus
alternate name: Delta Method

Intro:
Thanks to Hans-Peter Korn a few years back, I finally got to meet Mark McKergow, one of the founders of the Solutions Focus approach to problem solving. (OK, the point is, it’s not about problem solving, in Solutions Focus language, but until people get Solutions Focus’ view of the world, that’s the bucket to put it in). We met in London in Nov 2009 with Andy Pols and discussed Solutions Focus and Agile development.

Mark McKergow wrote up our meeting on the SOL blog line. I challenged him to change the language of their excellent approach so it doesn’t appear so ‘la la’ (my words :). I challenged myself to do the same, to see if I can get this method to appear as strong as it really is. This note is my first take on the subject.

First of all, it’s not solutions focus, because it’s not about solutions at all.

I prefer to call it the Delta method, because it’s about ignoring the solution, and only paying attention to getting a little bit further along a desired gradient.

The Solutions Focus, or as I’m prefering to refer to it, the Delta method, is about paying attention to the Things You Do that make a situation A Little Bit Better. (even though I’m writing like Winnie The Pooh).

Fig 1 illustrates:

Normal problem/solution thinking goes, “I am here, I want to be there; Why am I stuck here? How can I get there?”

Fig 2 illustrates the Delta method (ahem, Solutions Focus) thinking:

Delta thinking goes: “In what direction would I like to be? What would perfect look like? How far along am I? How on earth did I even get this far? Wow, look what’s alredy working! even though I maybe feel possibly miserable about it? How can I make a tiny little delta bit of progress along that gradient from where I am?”

The important thing with the Delta method is not to look at the “perfect” place, but only to notice what moves you a small (delta) distance from where you are.

As I wrote in a poem way back in 1987:


© (copyright) Alistair Cockburn, 1987.


A little, plus a little, plus a little, plus: a little, plus a little: plus a little, plus a little plus a little, plus a little plus a little, plus a little . is a lot.

© (copyright) Alistair Cockburn, 1987.

Postscript: Don’t worry about reaching perfection. Your notion of perfection will change as you get closer (not unlike trying to reach the speed of light). Your deltas will change likewise.

cheers

(How’d I do, Mark & Hans Peter?)


Hans Peter Korn writes:

“What’s the difference between Kaizen and Solutions Focus?”

Well, Alistair, I will start with my understanding of Kaizen:

The Kaizen philosophy is drawn from the Japanese word kai which means “continuous” and zen meaning “improvement” or “wisdom”. The Kaizen management philosophy, therefore, is defined as making “continuous improvement”—slow, incremental but constant.
The Kaizen way (in the meaning of an attitude of life, not a set of “techniques”) encourages small day-to-day yet continuous and never-ending improvement process involving everyone from managers to workers using the most basic tenet of survival: Common sense.
As opposed to the Western brand of pragmatic why-fix-it-if-it-ain’t-broke philosophy, Kaizen extends a more optimistic philosophical view: “Everything—even if it ain’t broke—can be made better!”
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. This philosophy differs from the “command and control” improvement programs of the mid-twentieth century. Kaizen methodology includes making changes and monitoring results, then adjusting. Large-scale pre-planning and extensive project scheduling are replaced by smaller experiments, which can be rapidly adapted as new improvements are suggested.

The five basic elements of Kaizen are:

  • Teamwork
  • Personal discipline
  • Improved Moral
  • Quality Circles
  • Suggestions for Improvement

The key principles of Kaizen are:

  • Eliminate waste (& inefficiency)
  • Housekeeping rules:
    • Tidiness
    • Orderliness
    • Cleanliness
    • Standardized Clean Up
    • Discipline

Based on this there are some similarities with SF: (For more information about SF please have a look at: http://www.solworld.org/notes/Jumpstart_into_Solution_Focus)

  • Small Actions – tiny next steps that make big differences
  • Inbetween – the action is in the interaction

and in addition to this in SF there are many principles and “tools” which might be useful to “multiply” the benefits of Kaizen:

The SF-approach is based on simplicity and building on what works. Many people have attempted to sum up the subtleties of SF. Some descriptions which come close to capturing the flavour include:

  • Finding what works and doing more of it
  • Putting positive difference to work
  • Radical simplicity

Mark’s book The Solutions Focus (co-authored with Paul Z Jackson) describes the approach in terms of six SIMPLE principles and six solutions tools. The SIMPLE principles are:

  • Solutions – not problems
  • Inbetween – the action is in the interaction
  • Make use of what’s there – not what isn’t
  • Possibilities – from the past, present and future
  • Language – simply said
  • Every case is different – beware ill-fitting theory

The six solutions tools are:

  • Platform – where are we starting from?
  • Future Perfect – suppose the problem went away overnight – what would happen instead?
  • Scaling – where are we now?
  • Counters – whatever helps us forward
  • Affirm – what’s already going well?
  • Small Actions – tiny next steps that make big differences

And – in my understanding of Kaizen – there are some important differences between SF and Kaizen:

SF does not encourage for a “never-ending improvement process”. In SF we ask: “Is it good enough now?” and we don’t invest a lot of energy to “come from an 8 to 9” (on a scale from 0 to 10) if we think that the “8” will be good enough now. This will give us the chance to consolidate and appreciate our success instead of continously craving more and more.

SF is a very pragmatic way focusing on “observable facts and changes” and on those “tasks” which can be really done by a person – and not on humans as if they are driven from the inside by some kind of mentalistic (or even molecular) framework, or from the outside by systems or social forces. So, “abstract things” like “Improved Moral” or the “Kaizen Housekeeping rules” (Tidiness, .... , Discipline) for me seems to be on the level of such “mentalistic frameworks”.
Attention: In SF we do not deny or reject them. We simply do not actively address internal mechanism which needs to be found and followed or changed like:

  • Beliefs
  • Personality Traits
  • Attitudes
  • Motivations
  • Values
  • Thoughts
  • Emotions
  • Psyches
  • Mental Maps
  • Weaknesses
  • Strengths
  • ...
    or external mechanism which needs to be found or followed or changed like
  • Systems
  • Family structures
  • Power structures
  • Narratives
  • Cultural norms
  • Karma
  • ...

People working solution focused can and do change their lives and leave all manner of problems, diagnoses and other ailments behind them without any use of, reference to or mapping of these internal or external ‘things’. Indeed, even problems declared by persons (e.g. co-workers or team members) in such terms can be handled quite satisfactorily by using and building everyday descriptions of their problems.

This “Inbetween – neither inside nor outside” (see http://www.sfwork.com/jsp/index.jsp?lnk=6d8) for me is one of the most important “specifics” of SF. And – for me – this does not stand in conflict with the “Japanese Tradition” (which is the platform of Kaizen):

I am learning “Iaidō” (http://en.wikipedia.org/wiki/Iaid%C5%8D) in a group of about 4 to 6 persons since many years – and we all still are learners, doing “only” such simple (or mostly much simpler) “katas”: http://www.youtube.com/watch?v=MIHwUrQ7x9A

And our learning is a permanent step by step improvement to reach more of Tidiness, Orderliness, Cleanliness, Standardized Movements, Discipline. BUT: The goal is NOT the “perfect tidiness” or “perfect discipline” .... the goal is to “observe ourself”: How do I recognize in my body, that a stroke is done more clear? What is helpful for me to do a clear and energetic stroke? How can I manage it to do a clear and energetic stroke with a slow movement? How can I do it fast – keeping the clearness? So, for me, Tidiness, Orderliness, Cleanliness, Standardized Movements, Discipline are means to enable such self-observations concerning the own body. So, this way is a way of mediation. And after about two hours of such work I feel much more distressed ….

Maybe Kaizen also is much more “a meditative step by step way towards wisdom” then a “method” to produce better Toyotas….

I wish you all a happy and distressed 2010!

Hans-Peter

Dr. Hans-Peter Korn
www.korn.ch: kreatives Training, Mentoring & Coaching
für agiles Management, Leadership und Teamwork

Turnweg 13 CH 5507 Mellingen SWITZERLAND

Phone: +41 56 491 3341 Mobile: +41 79 461 3379
Fax: +41 86079 461 3379 Skype: hans-peter.korn


Thanks, Hans Peter and Mark (see his comment below).

Based on your comment, Mark, I’m trying again with this double delta image (from Solutions Focus double delta view.png):

It still misses out on the specific techniques, the “action is in the interaction” part, and the “don’t think you know” aspects, but captures the “celebrate how far you already got part” maybe.

Keep comments coming and I’ll keep trying over here.

thanks – Alistair

Re: Are agile and scrum frameworks or methodologies or what

To understand the application of scrum, one must know how it originated. Scrum was first implemented in the year 1993 by Jeff Sutherland, who along with John Scumniotales and Jeff McKenna, was inspired by the1986 HBR article “The New New Product Development Game”. This article provided a holistic approach in which management could be followed to achieve desired results, something along the lines of the game ‘Rugby’. go through Simplilearn website for more details

-by Helen Cooke on 2/2/2015 at 2:05 AM

Crystal light methods

*Alistair A.R. Cockburn*
Humans and Technology

(from Cutter IT Journal, 2001)

In the early 1990’s, Alistair Cockburn was hired by the IBM Consulting Group to construct and document a methodology for object-oriented development. They had no preferences as to what the answer might look like, just that it work. His approach to the assignment was to interview as many projects as possible, writing down whatever the teams said was important to their success (or failure). The results were surprising.

Team after successful team “apologized” for not following a formal process, for not using a hi-tech CASE tool, for “merely” sitting close to each other and discussing as they went. A number of failing teams puzzled over why they failed despite using a formal process – maybe they hadn’t followed it well enough? He finally started encountering teams who asserted that they succeeded exactly because they did not get caught up in fancy processes and deliverables, but sat close together so they could talk easily, and delivered tested software frequently.

As Alistair says:

These results have been consistent, from 1991 to 1999, from Hong Kong to the Americas, to Norway and South Africa, in COBOL, Smalltalk, Java, VB, Sapiens and Synon. The shortest statement of the results are:

To the extent you can replace written documentation with face-to-face interactions, you can reduce reliance on written work products and improve the likelihood of delivering the system. The more frequently you can deliver running, tested slices of the system, the more you can reduce reliance on written “promissary” notes and improve the likelihood of delivering the system.

People are communicating beings. Even introverted programmers do better with informal, face-to-face communication than with paper documents. From a cost and time perspective, writing takes longer and is less communicative than discussing at the whiteboard.

Written, reviewed requirements and design documents are “promises” for what will be built, serving as timed progress markers. There are times when creating them is good. However, a more accurate timed progress marker is running, tested code. It is more accurate because it is not a timed promise, it is a timed accomplishment.

Recently a bank IT group decided to take the above results at face value. They ran a small project, simply put the 3 people into the same room, and more or less left them alone. Surprisingly (to them), the team delivered the system in a fine, timely manner. The bank management team was a bit bemused. Surely, it can’t be this simple?

It isn’t, quite. The third result of all those project interviews was that:

*Different projects have different needs.

Terribly obvious, except (somehow) to methodologists.

Sure, if your project only needs 3-6 people, just put them into a room together. But if you have 45 or 100 people, that won’t work. If you have to pass Food & Drug Administration process scrutiny, you can’t get away with this. If you are going to shoot me to Mars in a rocket, I’ll ask you not to try it.

As the number of people involved grows, so does the need to coordinate communications As the potential for damage increases, so increases the need for public scrutiny, and so decreases the tolerance for personal stylistic variations. Some projects depend on time-to-market and can tolerate defects (web browsers being an example), while other projects aim for traceability or legal liabilility protection.

The result of collecting those factors is shown in Figure 1. The figure shows three factors that influence the selection of methodology: communications load (as given by staff size), system criticality, and project priorities.

Locate the segment of the X-axis for the staff size (typically just the development team). Move right one box for a distributed development project to account for the loss of face-to-face communications.

Identify on the Y-axis the damage effect of the system, loss of comfort, loss of “discretionary” moneys, loss of “essential” moneys (e.g., going bankrupt), or loss of life.

The different planes in the figure reflect the different possible project priorities, whether “time to market at all costs”, “productivity and tolerance”, or “legal liability”.

The box in the grid indicates the class of projects with similar communications load and safety needs, and can be used to select a methodology.

The grid characterizes projects fairly objectively, useful for choosing a methodology. I have used it myself to change methodologies on a project as it shifted in size and complexity. There are of course many other factors, but these three select methodology quite well.

Suppose it is time to choose a methodology for the project. To benefit from the project interviews mentioned earlier, create the lightest methodology you can even imagine working for the cell in the grid, one in which person-to-person communication is enhanced as much as possible, and running, tested code is the basic timing marker.

The result is a light, habitable (meaning actually rather pleasant, as opposed to oppressive), and effective methodology.

Repeating this for all the boxes produces a family of lightweight methods, related by their reliance on people, communication, and frequent delivery of running code. I call this family the Crystal Light family of methodologies. The family is segmented into vertical stripes by color: The methodology for 2-6 person projects is Crystal Clear, for 6-20 person projects is Crystal Yellow, for 20-40 person projects is Crystal Orange, then Red, Magenta, Blue, etc.

Shifts in the vertical axis can be thought of as “hardening” of the methodology. A life-critical 2-6 person project would use “hardened” Crystal Clear, and so on. What is currently surprising me is that the project interviews are showing rather little difference in the hardness requirement, up to life-critical projects.

Crystal Clear is documented in a forthcoming book, currently in draft form on the web [Clear]. Crystal Orange is outlined in the methodology chapter of Surviving Object-Oriented Projects.

Having worked with the Crystal Light methods for several years now, I found a few more surprises.

The first surprise is just how little process and control a team actually needs to thrive (this is thrive, not merely survive). It seems that most people are interested in being good citizens, and in producing a quality product, and use their native cognitive and communication abilities to accomplish this. This matches what Jim wrote in Adaptive Systems Development. You _need_one notch less control than you expect, and less is better, when it comes to delivering quickly.

More specifically, when Jim and I traded notes on project management, we found we had both observed that a critical success element of project management is that team members understand and communicate their work dependencies. They can do this in lots of simple, low-tech, and low-overhead ways. It is often not necessary to introduce tool-intensive work products to manage it.

Oh, it is necessary to introduce one thing into the project:

Trust and communication.

A project that is short on trust is in trouble in more substantial ways than just the weight of the methodology. To the extent you can enhance trust and communication, you reap the benefits of Crystal Clear, XP and the other lightweight methods.

The second surprise with defining the Crystal Light methods was XP. I had designed Crystal Clear to be the least bureaucratic methodology I could imagine. Then XP showed up in the same place on the grid and made Clear look heavy! What was going on?

It turns out that Kent Beck had found another knob to twist on the methodology control panel: discipline. To the extent that a team can increase its internal discipline and consistency of action, they can lighten their methodology even more. The Crystal Light family is predicated on allowing developers the maximum individual preference. XP is predicated on having everyone follow tight, disciplined practices:

  • Everyone follows is a tight coding standard.
  • The team forms a consensus on what is “better” code, so that changes converge and don’t just bounce around.
  • Unit tests exist for all functions, and they always pass at 100%.
  • All production code is written by two people working together.
  • Running, tested function is delivered frequently, in the 2-4 week range.

In other words, Crystal illustrates and XP magnifies the core principle of light methods:

Intermediate work products can be reduced and project delivery enhanced, to the extent that team communications are improved and frequency of delivery increased. or, Intermediate work products can be reduced and project delivery enhanced, to the extent that team uses shorter, richer communications channels and running function is delivered more frequently.

XP and Crystal Clear are related to each other in a certain way.

  • XP pursues greater productivity through increased discipline, but is harder for a team to follow.
  • Crystal Clear permits greater individuality within the team, and more relaxed work habits, for some loss in productivity.
  • Crystal Clear should be easier for a team to adopt, but XP produces better results if the team can follow it.
  • A team can start with Crystal Clear and move themselves up to XP. A team that falls off XP can back up to Crystal Clear.

Agile Advanced Masterclass

The Center of Agile Advanced Masterclass with Alistair Cockburn

“Can I say on a personal note , since I came back from the AAD it has relit the fire in me , I can only thank you for providing the spark.” -Tony

An inspiring 2d w @TotherAlistair learning #AdvancedAgile from the 1 guy in the world capable of teaching it… Now time to repack my brain. – Tyson

“It was a great experience and definitly changed my mindset. Anyone doing scrum should take the class and get some “agile inspiration” :)” – Kosta

Move to the next stage by learning from one of the authors of the Agile Manifesto!
  • Level: Intermediate and Advanced :
    • This is the course for you if you have been doing agile development for 3-15 years, have read many of the books and are ready for a deep dive into what agile development is all about.
    • This is the course for you if you have been doing agile development for 1-5 years and want to amp up your capabilities to the next level.
    • This is not the course for you if you are a hot shot programmer or PM and want to strut your stuff.
    • This is not the course for you if you are looking for an introduction to agile, basic of Scrum, CSM, or project management (attend instead the Fundamentals of Agile Development public course (discussion: Re: Agile Development Class with Crystal and Certified ScrumMaster)).
    • This is a course for those who want to inquire and to get themselves ready for whatever comes next.

This is the advanced masterclass in agile development from industry guru Dr. Alistair Cockburn.

The Center of Agile Advanced Masterclass with Dr. Alistair Cockburn

Modern “expert” agile practitioners have mastered the practices – but not why they work, not how to adjust practices to situations, not how to approach new and surprising situations, not how to apply agile practices to non-software projects, not how to incorporate results from other fields back to their own projects, not how to tailor the practices to different organizational cultures. This advanced course from industry guru Dr. Alistair Cockburn addresses those areas.

  • In this discovery-filled course,
    • Learn why agile works, in software or outside of it,
    • Learn how to articulate and deal with the weaknesses in agile development,
    • Test yourself and your partners with the Test-Driven Carpaccio exercise.
    • Learn to reduce risk and maximize results by viewing design as a Knowledge Acquisition activity.
    • Practice backing up your recommendations with solid theory, not just an appeal to authority,
    • Learn how to plan and track larger, more complicated projects using Story Mapping or Blitz Planning (time permitting),
  • . . . and most of all
    • Come face-to-face with yourself, your strengths and your weaknesses, as you confront one situation after another with equally inquisitive classmates.

Bring along bring gnarly problems you have been challenged with and objections as to why agile can’t work in whatever context: We will work through those problems as a class, using the skills taught in the class.

This is not a course for the beginner or the faint of heart. Expect to do homework, expect to be put through your paces, expect to dialog and argue, have your beliefs challenged.

You need not prepare for the course, but you will get more from it if you have read Agile Software Development: The Cooperative Game and “The Seven Properties of Highly Successful Projects” from Crystal Clear: A Human-Powered Methodology for Small Teams prior to the start of class.

At the end of the course, walk away with a rich, robust set of tools for approaching your project and organizational situations.

Instructor:

Dr. Alistair Cockburn (pronounced Cō-burn) was voted one of the “All-Time Top 150 i-Technology Heroes” for his work in creating and steering Agile software development. He co-authored the Manifesto for Agile Software Development and the “Declaration of Interdependence,” created the first Agile Software Development Conference, co-founded the Agile Project Leadership Network, served on the board of the AgileAlliance, designed the Crystal family of agile methodologies, and co-founded the International Consortium for Agile. Three of his books have won Jolt awards and been listed in “The Top 100 Best Software Books of All Time”. He consistently receives high ratings for his presentations and courses. Much of his material is online at http://Alistair.Cockburn.us.

What Students Wrote After Attending One of Alistair’s Master Classes: “Huge emotional learning about self.” -@ksteffe “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe ”#AdvancedAgile with @TotherAlistair is like walking in as an agile Jedi then some dude with pointy horns pulls a double ended light sabre.” – Todd “Inspiring, I will be going back into the cooperative game with a refreshed strategy and some new moves” – Kelsey ” Best part of the course: Learning how to ask questions without jumping to a solution” ” It was interesting to see how we forget important known stuff when we face a crisis” – Pavel ” THE forum to test every theory and stalk even the sacred cows of agile practice ” – Kim “I don’t care what they say, being with you is a pleasure.” – CM “Really great master class with @TotherAlistair” “Mind exploding like crazy.” “Definitely inspired to up my game!” “Ego obliterated, mind expanded, much to ponder after the masterclass. Thanks” “I had to call in sick the next day.” “Huge emotional learning about self.” -@ksteffe “I feel a lot better this time around after coming out of Alistair’s class. Learned a lot and my mind is clear” “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe “Alistair is the Chuck Norris of Use Cases. Applying use cases to the project life cycle has re-instilled my faith in project management.” “Alistair provided a non-intimidating environment to allow for mind stretching. I feel like I’ve been put through a mental wringer but all in a way that can only improve my value for my team.” –Nicole Hopkins “The deep level of experience Alistair brings to the training adds significant insight to the domain.” –Dave Pugmire “Excellent course… well worth the investment of time and money. I especially appreciated Alistair’s depth of knowledge and breadth of experience. I will be watching for other courses offered by him.” –Chuck Stoner “Course goes well beyond novice level in terms of cognitive complexity. Pushes into analytical/critical thinking skills.” –Cristina “I want my boss, my boss’s boss and my boss’s boss’s boss to take this course.” “I would certainly agree with Alistair’s characterization of what he does being the height of voodoo witchery and other eldritch practices, at least to the untrained eye. Stretching the metaphor even further I’d also say that some of those that he coaches are left with a feeling much like what I would imagine a visit to the voodoo shaman would engender – glad that he was there to help, but equally glad that he has taken his rum and chickens elsewhere.” –Jonathan “In 20+ years of attending courses in software development this has been the best course. Great balance of theory and lab (hands on) work.” –John W. Cooley “Fantastic course for practitioners who want to think about what they do and improve their teams. Cuts through the Agile hype to communicate deep insights and truly useful techniques.” – Kay Johansen “This course was simply amazing! Dr. Alistair Cockburn has one of the best minds period. I have so much to learn. This course should be mandatory for all project managers.” – J. K. “Excellent job of imparting knowledge without creating dogma.” – J.S. “Your teaching style/positioning as a methodologist fit exactly what I was looking for, not dogma but the base/broad thinking behind the practices” – Anastasia “Alistair combines the theory with practical experiences and exercises that reveals the hows and whys of agile.” – Richard Thomson “It is great to be able to tap into Alistair’s years of experience!” – Sean Landis “It was great to take this course from one of the acknowledged leaders in the field.” – Jeff Romine “Very enjoyable course. More please.” “Exceeded my expectations! Great class; excellent presenter!” “Alistair is a wonderful instructor! Very knowledgeable, easy to listen to, and funny!” – Anne Marie Kimberling It was awesome! It broke my head! – Maria Fernanda “OMG @TotherAlistair u broke me!! I am seeing holes in everything that we are doing. Hugh improvement opportunities!!” – Supriya “I wanted to be challenged – and I was not disappointed – participants got kicked out of their comfort zone before morning tea on day one, by lunchtime you knew there is no going back.” http://www.betterprojects.net/2014/03/advanced-agile-review.html “He set out to challenge all of our preconceptions about agile, deconstruct them, and then help to rebuild our understanding using different lenses he’s crafted from his deep and extensive experience. The result being, that people walked away with more insight, understanding and approaches with which to advance their own agility and those of the people around them.” http://www.tabar.com.au/advanced-agile

Re: Waiting for Arrival

Lovely.

It seems to me that the text of this blog describes a more active engagement with a challenge than the title implies. More “Working towards arrival” than “Waiting for” it.

-by Seb Rose on 12/14/2014 at 11:35 PM


“I don’t know you in the distance. I only know you near me”
“I was shaking this morning as I was shaking now”

Are those yours?
They are beautiful

-by Gabriela Szulman on 12/15/2014 at 11:00 AM

Thank you, Gabriela. Those are special poems. They arrived at a unique moment, which I don’t expect to repeat.


An aspect of the “Release” concept the authors talk about in the book sounds a lot like Czikszentmihalyi’s “Flow.” Interesting book. Thanks for the tip.

-by Todd Webb on 12/16/2014 at 4:31 PM

Re: Poems

“I don ‘t know you in the distance, I only know you near me”
“I am shaking this morning as I am shaking now”

Are those yours?
So beautiful

-by Gabriela Szulman on 12/15/2014 at 10:20 AM

Yes, thank you. Those were unique moments. I might hope that someone else finds similar moments. Alistair

Waiting for Arrival

“Usually we try a scene or a moment so many different ways that the right choice makes itself known. And everybody in the room know what that right choice is. We work until we find that”.
— (Abigail Adams, director of People’s Light and Theatre Company, “Artful Making” p. 19)

That moment, I call Arrival.


http://www.paulbondart.com/paintings/thumbnails/cropped/In-Between-Here-And-Not-Here.jpg
(What a great title for what this blog post is about!)

“Failure isn’t the right idea. In rehearsal, the iterations all interact with each other. The current run-through provides the main material for the next run-through. Each trial is a necessary step on the way to what’s good and essential to the final success. To call an essential step toward success a failure merely tortures language. What’s more, the word “failure” applied to routine work could poison the growth of Ensemble, a quality of group work essential to rehearsal, and to artful making.” — (p xxviii “Artful Making” Rob Austin & Lee Devin)

What is Arrival?

“When Stella burst into tears … even the director had to get a grip. Something big was happening. Something beyond work came into the room. The stage manager called, “And, lights.” There followed a moment of hush, a deep and happy silence of accomplishment. Then, from someone in a far corner of the room came … the flat, empty drawl of NASAspeak: “Ahhh, Houston? We have play.” ” (“Artful Making”, p.13)

Arrival: Not Experiment, Not Discovery

“Not Quite Experiment, Not Quite Discovery” _(“Artful Making”, p.22) :

“Scientific experiments look for causal relationships … ‘Discover’ suggests there is a right choice waiting to be found.”

so what is it, then?

“the importance of individuals’ efforts to release themselves from restraining preconceptions and inhibiting circumstances; the intensity and interdependency of these collaborations; the understanding of “wrong” choices as advances rather than setbacks; the sense of the emerging product as something better and more interesting than anything a single person could have preconceived, greater than the sum of it’s parts; an unpredictable result that in retrospect seems investable.” (“Artful Making”, p.14)

“Touch a hot stove and burn your hand… touch it again and burn your hand again… same injury, no new information. ... you may need to make the same mistake many times on the way to an innovative leap. Burning your hand is a small price to pay for a good idea.” (“Artful Making”, p. xxiii)

“every choice an actor makes enters the play and, in some form other, remains there. ... experience becomes the material that future choices are made of. ... People are people, and they don’t have Delete keys. ... Inclusion of past actions into the materials of creation is the force that drives emergence” (“Artful Making”, p. 21)

What he calls “emergence” there, I call Arrival here.

Communication is touching into shared experience

There is a little fake being inside us who demands too much attention: the little ‘i’, the little voice from our prefrontal cortex, commandeering our vocal cords to make sounds to our heads that sound like they are our voices speaking. Except the little ‘i’, utilizing only the vocal apparatus, denies external access to the many parts of our brain and bodies that also are looking for expression. Our minds are full of ideas we can’t know about as long as we listen to ourselves.

We have to act.

As we act, interact, act by accident (tripping over a bump), act in accidents (different modalities of expression take differing lengths of time to reach the outside world, creating accidents of timing between different parts of our bodies), we do things the little ‘i’ inside our minds did not have any idea existed. We create new realities, new moments of experience. Shared experiences, if we are with a group.

Each act, action, enters our shared experience, becomes a building block for future actions.

“by running-through many times with variations and accidents, we build new shared experiences, new building blocks for action and for communication.” (“Artful Making”)

If one of us burns his/her hand on a stove several times in a row and does not learn, that by itself becomes a ‘meme’ for the person, for the group. Thus, “the current run-through provides the main material for the next run-through.”

The moment of arrival is when something shows up that we recognize as being an advance.

And so we wait for it. We act, we experiment, we stumble, we shout, we make nonsense, we do the same dumb thing 10 times in a row. We are waiting.

And it arrives.

Arrival

I am using the word ”arrival” to name that thing that was never there in the first place, but which we suspect can be there, but we can’t find it, we can’t hunt for it, we can’t discover it, we can’t invent it. We have to wait for it.

Arrival happens to poets, to musicians, to comedy writing groups, to theater groups, to programmers and designers discussing an idea together.

Constructing an Arrival

“Artful Making” (Austin & Devin) describes constructing an arrival as well as I have ever seen (the description of working on the play Streetcar Named Desire.) They describe theater as a process that generates arrival moments reliably, although no one knows when the arrival will arrive.

The only way to get the arrival to arrive is to play, to experiment, to push things past their boundaries. To do dumb things, crazy things, the same thing over and over; and wait for some hitherto quiet part of someone’s being to express itself in some way that has not been seen before.

As a person in a design group, I watched as one person mis-wrote what someone said, and someone mis-read what was written, and what he said was just what the group needed to hear. It was the winning idea. I have often seen designers discuss an idea at a whiteboard, and every time one person made a comment or drew, another person said, “But in that case…” and made a new, great observation. In minutes, the group designed something that none of them could have designed alone.

You don’t say Sorry in hackey sack

Hard for me to not say “sorry” when I drop the hackey sack. But I had to learn it. It’s part of hackey sack to drop the hacky sack. You can’t have a group saying “sorry” every time they drop the sack.

You don’t say “sorry” when making a fault in an improvisational dance. You might restart, or you might continue, but “sorry” isn’t in the game.

Similarly, in constructing an arrival, you don’t say “sorry” for each version that doesn’t produce an arrival. You just add to the stack of available material and keep going.

You can say Thanks and High-Five

I wish to thank Diego Fontdevila, who pushed “Artful Making” under my nose years after I had first seen it, but just at the moment when I could read certain sentences in it. Thanks, Lee Devin, for pushing Rob Austin about the topic of “failure”, and to the two of them for getting the book published. Just these pages alone changed my life.

For my part, I immediately put this new knowledge of Arrival to use. I dance a lot, but am terrified of making mistakes with a partner on the dance floor. Just after reading this book, I went to a free-improvisation tango class, and although still sweating, stopped saying “sorry” and only froze once on the dance floor, viewing now each faulty move as just a brick in my construction of an Arrival for better tango dancing. My partner, too, (since we were taking turns leading in this free-form tango class), had to learn to not say “sorry” with faulty moves, but to replay or just continue after each one. We do, however, high-five after great accidents and arrivals.

cheers,

The Center of Agile Advanced Masterclass

The Center of Agile Advanced Masterclass with Alistair Cockburn

An inspiring 2d w @TotherAlistair learning #AdvancedAgile from the 1 guy in the world capable of teaching it… Now time to repack my brain. – Tyson

“Can I say on a personal note , since I came back from the AAD it has relit the fire in me , I can only thank you for providing the spark.” -Tony

“It was a great experience and definitly changed my mindset. Anyone doing scrum should take the class and get some “agile inspiration” :)” – Kosta

Move to the next stage by learning from one of the authors of the Agile Manifesto!
  • Level: Intermediate and Advanced :
    • This is the course for you if you have been doing agile development for 3-15 years, have read many of the books and are ready for a deep dive into what agile development is all about.
    • This is the course for you if you have been doing agile development for 1-5 years and want to amp up your capabilities to the next level.
    • This is not the course for you if you are a hot shot programmer or PM and want to strut your stuff.
    • This is not the course for you if you are looking for an introduction to agile, basic of Scrum, CSM, or project management (attend instead the Fundamentals of Agile Development public course (discussion: Re: Agile Development Class with Crystal and Certified ScrumMaster)).
    • This is a course for those who want to inquire and to get themselves ready for whatever comes next.

This is the advanced masterclass in agile development from industry guru Dr. Alistair Cockburn.

The Center of Agile Advanced Masterclass with Dr. Alistair Cockburn

Modern “expert” agile practitioners have mastered the practices – but not why they work, not how to adjust practices to situations, not how to approach new and surprising situations, not how to apply agile practices to non-software projects, not how to incorporate results from other fields back to their own projects, not how to tailor the practices to different organizational cultures. This advanced course from industry guru Dr. Alistair Cockburn addresses those areas.

  • In this discovery-filled course,
    • Learn why agile works, in software or outside of it,
    • Learn how to articulate and deal with the weaknesses in agile development,
    • Test yourself and your partners with the Test-Driven Carpaccio exercise.
    • Learn to reduce risk and maximize results by viewing design as a Knowledge Acquisition activity.
    • Practice backing up your recommendations with solid theory, not just an appeal to authority,
    • Learn how to plan and track larger, more complicated projects using Story Mapping or Blitz Planning (time permitting),
  • . . . and most of all
    • Come face-to-face with yourself, your strengths and your weaknesses, as you confront one situation after another with equally inquisitive classmates.

Bring along bring gnarly problems you have been challenged with and objections as to why agile can’t work in whatever context: We will work through those problems as a class, using the skills taught in the class.

This is not a course for the beginner or the faint of heart. Expect to do homework, expect to be put through your paces, expect to dialog and argue, have your beliefs challenged.

You need not prepare for the course, but you will get more from it if you have read Agile Software Development: The Cooperative Game and “The Seven Properties of Highly Successful Projects” from Crystal Clear: A Human-Powered Methodology for Small Teams prior to the start of class.

At the end of the course, walk away with a rich, robust set of tools for approaching your project and organizational situations.

Instructor:

Dr. Alistair Cockburn (pronounced Cō-burn) was voted one of the “All-Time Top 150 i-Technology Heroes” for his work in creating and steering Agile software development. He co-authored the Manifesto for Agile Software Development and the “Declaration of Interdependence,” created the first Agile Software Development Conference, co-founded the Agile Project Leadership Network, served on the board of the AgileAlliance, designed the Crystal family of agile methodologies, and co-founded the International Consortium for Agile. Three of his books have won Jolt awards and been listed in “The Top 100 Best Software Books of All Time”. He consistently receives high ratings for his presentations and courses. Much of his material is online at http://Alistair.Cockburn.us.

What Students Wrote After Attending One of Alistair’s Master Classes: “Huge emotional learning about self.” -@ksteffe “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe ”#AdvancedAgile with @TotherAlistair is like walking in as an agile Jedi then some dude with pointy horns pulls a double ended light sabre.” – Todd “Inspiring, I will be going back into the cooperative game with a refreshed strategy and some new moves” – Kelsey ” Best part of the course: Learning how to ask questions without jumping to a solution” ” It was interesting to see how we forget important known stuff when we face a crisis” – Pavel ” THE forum to test every theory and stalk even the sacred cows of agile practice ” – Kim “I don’t care what they say, being with you is a pleasure.” – CM “Really great master class with @TotherAlistair” “Mind exploding like crazy.” “Definitely inspired to up my game!” “Ego obliterated, mind expanded, much to ponder after the masterclass. Thanks” “I had to call in sick the next day.” “Huge emotional learning about self.” -@ksteffe “I feel a lot better this time around after coming out of Alistair’s class. Learned a lot and my mind is clear” “I’m breathless from drinking from the firehose.” – Resetley & Restarting Best part about the course. “Alistair’s mastery of the course/industry content and ability to respond and support any student requests.” – Scott Wolfe “Alistair is the Chuck Norris of Use Cases. Applying use cases to the project life cycle has re-instilled my faith in project management.” “Alistair provided a non-intimidating environment to allow for mind stretching. I feel like I’ve been put through a mental wringer but all in a way that can only improve my value for my team.” –Nicole Hopkins “The deep level of experience Alistair brings to the training adds significant insight to the domain.” –Dave Pugmire “Excellent course… well worth the investment of time and money. I especially appreciated Alistair’s depth of knowledge and breadth of experience. I will be watching for other courses offered by him.” –Chuck Stoner “Course goes well beyond novice level in terms of cognitive complexity. Pushes into analytical/critical thinking skills.” –Cristina “I want my boss, my boss’s boss and my boss’s boss’s boss to take this course.” “I would certainly agree with Alistair’s characterization of what he does being the height of voodoo witchery and other eldritch practices, at least to the untrained eye. Stretching the metaphor even further I’d also say that some of those that he coaches are left with a feeling much like what I would imagine a visit to the voodoo shaman would engender – glad that he was there to help, but equally glad that he has taken his rum and chickens elsewhere.” –Jonathan “In 20+ years of attending courses in software development this has been the best course. Great balance of theory and lab (hands on) work.” –John W. Cooley “Fantastic course for practitioners who want to think about what they do and improve their teams. Cuts through the Agile hype to communicate deep insights and truly useful techniques.” – Kay Johansen “This course was simply amazing! Dr. Alistair Cockburn has one of the best minds period. I have so much to learn. This course should be mandatory for all project managers.” – J. K. “Excellent job of imparting knowledge without creating dogma.” – J.S. “Your teaching style/positioning as a methodologist fit exactly what I was looking for, not dogma but the base/broad thinking behind the practices” – Anastasia “Alistair combines the theory with practical experiences and exercises that reveals the hows and whys of agile.” – Richard Thomson “It is great to be able to tap into Alistair’s years of experience!” – Sean Landis “It was great to take this course from one of the acknowledged leaders in the field.” – Jeff Romine “Very enjoyable course. More please.” “Exceeded my expectations! Great class; excellent presenter!” “Alistair is a wonderful instructor! Very knowledgeable, easy to listen to, and funny!” – Anne Marie Kimberling “OMG @TotherAlistair u broke me!! I am seeing holes in everything that we are doing. Hugh improvement opportunities!!” – Supriya “I wanted to be challenged – and I was not disappointed – participants got kicked out of their comfort zone before morning tea on day one, by lunchtime you knew there is no going back.” http://www.betterprojects.net/2014/03/advanced-agile-review.html “He set out to challenge all of our preconceptions about agile, deconstruct them, and then help to rebuild our understanding using different lenses he’s crafted from his deep and extensive experience. The result being, that people walked away with more insight, understanding and approaches with which to advance their own agility and those of the people around them.” http://www.tabar.com.au/advanced-agile

The Center of Agile Workshop

An exciting, informative day for all roles and at all levels, learning the Center of Agile from one of the founders of the Agile movement.

  • An opening lecture to catch you up on the state of product and software development right now.
  • Two fast-moving activities, cooperating, developing, drawing, sharing, in short, being agile.
  • A facilitated small-group discussion to work out what to do with all the insights from the day.

Set your organization’s expectations for agile adoption, create a shared experience for everyone to refer back to, ask difficult questions of one of the founders of the agile movement.

Duration: One or two days, as desired. The one-day version is level-setting; the two-day version contains specific techniques.

Level: Beginner.

This is an excellent day for an entire organization, from execs to receptionists, business to technical people, novices to experts (yes, even the experts will learn!). Use it to level-set vocabulary and expectations for agile, to create a shared experience to refer back to, and create new small improvement initiatives within the organization. General comment heard during this workshop is, “I wish my boss were here!”

Location: Taught on location, by request

Class Size: Any (class sizes have varied from 20 to 150 people)

Course statement: What we call agile is an attitude giving priority to efficiency in the process, and maneuverability with respect to changing requirements, technology and team. Having the agile attitude does not yet make for a successful project. The team needs a certain understanding of core practices: incremental scheduling and staging, reflecting on its working style every few weeks, concurrent development, paying attention to the strong points of humans without building on their weaknesses, among others.

Course Description:

This workshop, based on the award-winning book, Agile Software Development, and on Crystal Clear: A Human-Powered Methodology for Small Teams, consists of a mixture of lecture, exercises, and discussions. These are constructed to give attendees a sense for how it feels to be doing some of the key practices as well as what how it feels not to do them. The techniques reviewed are valuable in carrying out any kind of project, not only agile ones.

The workshop is non-technical in the sense that it is non-programming; it is technical in that it contains material that is core to the modern life of professional developers, project managers, and business managers. Because the issues cover all aspects and stakeholders in the development process, this workshop is recommended for business executives, project managers, business analysts and developers alike.

Lecture:

The opening lecture introduces key concepts and ideas needed to make use of modern agile development:

  • Decisions flowing through an organization,
  • Cooperative games of invention and communication,
  • Disciplined learning,
  • Craft,
  • Trimming the tail on product development.

Communication Exercise:

In this 90-minute activity, the room is broken into teams of 5-7 people, each with specifiers and artists. The specifiers are given a drawing to have the artists reproduce, but they can only use simple-text messages to communicate. The teams go through this activity three times to learn how to reflect and improve during a project, how to spot impediments to communication and collaboration. This is a high-energy, highly enlightening activity.

Carpaccio (Programming) Exercise:

In this 120-minute activity, people work in pairs (or trios) on a computer with either a programming environment or a spreadsheet. Programming is best, spreadsheet usage also works. Any development language and environment is OK, whether JavaScript, .NET or Java, whatever. The spreadsheet version is used when there are not enough programmers present.

The purpose of the exercise is to show business people how to slice their business requests thinly enough to fit into any size of iteration or sprint, and to show programmers how the best programmers currently work, working in 15- to 45-minutes episodes that result in fully functional, end-user-visible, tested code ready to be checked in and used.

This is an intense exercise that shows business-side and development-side people, both, how to work in the fine-grained style needed for modern agile development.

Facilitation Discussion:

In this final activity, discussion groups are formed, to discuss what parts of the agile concepts learned during the day will be easy to adopt, and which will be difficult. This section of the day serves so that every person can discuss how to take the day’s learnings home.

Some learnings you might take away:

  • What software development consists of, and how considering software development as a “cooperative game of invention and communication” sheds light on common project failure and winning strategies.
  • The characteristics of human cooperation and communication, and how those shed light on program documentation, UML and offshore development.
  • The role of trust, amicability and goal alignment in a project team.
  • The role of individual talents and personalities; how to adjust for them.
  • The speed of the project is the speed at which ideas move between team members; harness this idea with office layout and information radiators; avoid or handle offshore development.
  • How to adjust different projects for their specific characteristics.
  • How and when to reflect on what is happening to the project while it is in motion.
  • How to understand incremental development and keep it under control.
  • What concurrent development looks like in practice and how to think about it.
  • Named agile methodologies: XP, Scrum, Crystal – how they take advantage of the core properties of the cooperative game principles, how they differ from each other and how to extract and combine them.

The day is very full. Depending on where the group gets more deeply focussed, some of the topics may get more or less emphasis

Alistair Cockburn

The Instructor: Dr. Alistair Cockburn.

One of the original authors of the Agile Manifesto. Voted in “The All-Time Top 150 i-Technology Heroes” for his work in Use Cases and Agile Software Development

Internationally renowned strategist, author of the Jolt award-winning Agile Software Development and Writing Effective Use Cases, he co-created the Agile Manifesto, the Declaration of Interdepen-dence, the Agile Project Leadership Network and the International Consortium for Agile. Dr. Cockburn is an expert on agile development, project management, process design, use cases, and object-oriented development.

Contact:
Alistair Cockburn, totherAlistair@aol.com, +1.801.824.1211

What engineering has in common with manufacturing and why it matters

Alistair Cockburn, Humans and Technology

Humans and Technology Technical Report HaT TR 2006.04, Sept 6, 2006.

Abstract

Engineering – software engineering in our case – is remarkably like manufacturing, once we shift to view the unvalidated decision as the unit of internal inventory. The parallels with manufacturing allow us to borrow from results in manufacturing theory to understand how to better structure our software processes, and the teams involved.

Preface

It is generally considered frivolous to compare software engineering with manufacturing. Manufacturing consists (so the argument goes) of making the same thing over and over, while engineering is about making something different each time. In software engineering, the design is the hard part, production is the easy part, often as easy as pressing CDs or publishing onto the internet.

Once we shift to considering decisions as the items being handed from person to person, gathered into larger and larger assemblies, then suddenly, there is a very real parallel between design and manufacturing. This is useful to us because manufacturing has been heavily studied over the last hundred years, and we can learn from their lessons.

In what follows, I shall talk about software development, but it should be clear that the same argument applies to every team design activity, including theatre, publishing, engineering, and much of business.

Waiting for Decisions

We start by recognizing that in team design activities, people wait on each other for decisions.

Figure 1 shows a simplified view of the dependencies between people in software development – it is missing the feedback loops, in particular (which are shown in Figure 2).


Figure 1: People wait on other people for decisions

In Figure 1, the dependency of one person on another is shown with a large gray arrow. The person at the head of the arrow is waiting for or being handed decisions from the person at the tail of the arrow. A small pyramid represents the actual decision being passed from one person to another.

In Figure 1, we see

  • business analysts and user interface (UI) designers waiting for users and sponsors to decide what functions and design styles they want,
  • programmers waiting for business analysts to work out the business rules, and UI designers to allocate behavior to different pieces of the user interface,
  • testers waiting for programmers to finish their coding.
    A nice thing about considering individual decisions as connecting people is that we can move away from stereotypes about how a company’s process or decision-making activities ought to look like, and instead focus on what it actually looks like – what decisions actually get made by which people, who is really waiting for whom.

There is no ideal software process any more than there is any ideal manufacturing process. Each company has its own strong-minded people, who make a disproportionate number of decisions that might, in other companies, be made by people in other roles. Each company has its own shortage of UI designers, programmers, testers, or even sponsors, which causes its process to have a certain characteristic shape – people working overtime, or perhaps sitting idle because other people can’t get their work done fast enough. Each company has its own reasons to have a large, external test department, or perhaps no test department at all.

Figure 2 shows the feedback loops in a common sort of organization. The feedback loops complicate the math, but don’t change the basic results we’ll be discussing.


:Figure 2: The decision-dependency network showing feedback loops

Different Bottlenecks, Different Processes

In any organization, we can find a backlog of decisions stacking up at some particular work group. The presence of that stack indicates a bottleneck, a place limiting the speed of the overall team.

Bottlenecks are of great concern in manufacturing, and have received much study. The obvious thing to do is to increase the capacity of the bottleneck group – hire more people, or better people, or get better tools, and so on.
Sooner or later, however, the organization hits its limit as to what it can do to improve the speed of the bottleneck group. At that point, what comes into play is the process definition itself.

Figure 3 shows three different, but fairly typical organizations.

  • In the first (top) organization, there are not enough user interface and database designers to keep up with the work. We see decisions stacked up at their work centers.
  • In the second (middle) organization, there are not enough experienced programmers, and work requests stack up in front of them.
  • In the third (bottom) organization, the users and sponsors are notably missing from the discussion. What happens in these organizations is that the business analysts and UI designers end up making the business decisions, and then sending those decisions (or running products) back to the users and sponsors for comment. The picture shows those requests for review stacking up in front of the users and sponsors.
  • The third (bottom) picture also shows the programmers and database designers sending decisions back and forth to each other. Both groups need to come to agreement on the domain model and how that will be represented in the code and in the database.


Figure 3: The optimal process varies with the decision-dependency network

There are two points to draw from these pictures:

  • First, they should be using different processes;
  • Second, these drawings help us to see how those processes should be different.
    The organization at the top, assuming that they can’t or won’t hire more UI and database designers, should look at ways to have programmers and business analysts pick up sections of the UI designer’s and database designer’s work. Even assuming that UI design work is specialized, parts of that work can be automated, carried out by assistants, or handled by programmers.

In the second organization, the reverse is more the case. The programmers, being few and probably inexperienced, might need to have much of the problem “digested” for them as much as possible.

In a case that I participated in, we recommended that the business analysts write quite detailed use cases (not containing the user interface, but containing the business rules more explicitly than we otherwise might), and also the layouts of the data needs, plus discussions of different business scenarios. The business analysts then sat with their respective programmers as they started on each use case, and discussed the use case, the scenarios, and the data. They left the paperwork with the programmers, and made themselves available for discussions and tutorials as needed.

The process in this second organization was aimed at minimizing the trouble the programmers had to undergo to understand the problem at hand. This is quite different from the process in the first organization.

In the third organization, the process might call for prototypes and early samples to be produced and put in front of the users and sponsors. Since those people have the least availability, the material should be as fully prepared as possible. Also, since close collaboration between the programmers and database designers is required, those teams should be seated together, or at least have frequent meetings and joint design reviews.

The purpose of this article is not to make these recommendations, which any good manager or consultant would be likely to spot, but to show how they come from mapping and considering the bottlenecks in the flow of decisions through the organization.

Lessons from Manufacturing

To complete the mapping to manufacturing, we use the unvalidated decision as our unit of internal inventory, or “work in progress” (WIP). Each decision that has been made but has not yet been validated by someone (the sponsors, the testers, the marketplace) is still “pending”, still waiting to show its quality.

Move Inventory Out

The first lesson that we draw from experiences in manufacturing is to keep work-in-progress (WIP) down. This is as important in software development as it is in manufacturing, since every decision that is pending costs the organization money.

The value of decisions decays over time:

  • Each “requirement” is a decision based on a business climate; when the business climate changes, the decision may become incorrect. If the software isn’t yet earning value for the company, the requirement is waste.
  • An “architecture” is a decision based on technology and business. If the technology changes before the software is earning value for the company, those decisions are waste.
  • Each line of code is a decision based on requirements, domain, technology and aesthetics. If anything causes it to become obsolete before the software is earning value for the company, it is waste.

To the extent that it is not earning value in the business, each decision loses value and quality with time. The more decisions stuck inside the pipeline, the more decaying “inventory” the organization is carrying.

Inventory stacks up quickly, even exponentially. Assume for reference an organization that is so fast that when a new requirment arrives, they can implement and deploy it by the next morning:

  • The company with a 1-day turnaround has about 1 day’s worth of inventory lying around the office.
  • The company with a one- to two-week turnaround has about 10 days worth of inventory lying around the office.
  • The company with a quarterly delivery system (assuming they deploy from fresh requirements every quarter) has about 100 days of inventory lying around.
  • The company delivering a 3-year project has 1,000 days of inventory (decaying) around them.
    The message, in software as much as in manufacturing, is: get the inventory out the door and earning value! Find ways to shorten the pipe.

Move Small Amounts, Continuously

The second lesson to draw from manufacturing is to reduce the size of the transfer batch between working groups. That is, move small amounts, continuously.
Figure 4 shows two ways of transfering work from the programmers to the testers.

In the first case, the programmers hand over 100 lines of code (each week, let’s suppose). The testers get a regular weekly arrival rate of about 100 lines of code, and have to integrate and test them against the rest of the system and against the known defect log.


Figure 4: Feed systems run more smoothly with small transfer sizes

The actual size handed over will vary, of course, and the actual length of time needed to work through the new code will also vary. That variance is very important.

The lower part of Figure 4 shows the programmers handing about 1,000 lines of code to the testers (each quarter, that would be, to keep the rate of production about the same as in the upper picture).

The problem with the lower picture is that all 1,000 lines of code show up at one time. The responsiveness of the testing group suddenly becomes much more variable, with the large arrival of an unknown number of bugs of varying sizes.

Equally bad, when they start handing over bug reports back to the programmers, the programmers suddenly see a large spike on requests on their input queue coming from the testers (see the arrow in Figure 2, from the testers back to the programmers). The programmers are now juggling two input queues, requests for new features and requests for bug fixes.

Manufacturing lines have experienced and studied all the above, and concluded that these sorts of feed systems run best when small amounts of work get handed from one group to the next. The ultimate goal is to hand over just one part from one group or person to the next.

Toyota pioneered this idea in its lean or just-in-time manufacturing lines. They aim for continuous flow, the flow of just one piece of material from one person to another (what to do when a queue backs up is the subject of another lesson we’ll see).

It is not clear exactly what continuous flow might mean in software development. Some decisions affect large parts of the system, and some decisions can’t be validated for a long time. However, the experiences in manufacturing are backed up by both mathematical models and experiences in agile software development.

It is rare to find development teams able to deploy fresh requirements every week, but I have been able to find a few teams who both deploy weekly and have a low enough defect rate that they get only one or a few requests a day. On one team I talked with, a person was assigned each day, on a rotation, to handle any incoming requests, whether bug reports or requests for small enhancements. That person would stop other work, do the work and redeploy the system before rejoining the main group. The average time to redeployment was half a day. With such a small, steady flow of requests on the feedback queue, the team was able keep from being diverted from their main assignment.

Cross-Train People

The lean and agile manufacturing literature contains the recommendation to cross-train people at adjacent stations. The idea is that when a small bubble of inventory grows at someone’s input, the neighboring person having a spare moment steps over and works it down. In this manner, small variances in work flow can be evened out and not disturb the organization’s overall flow.

We see this in software development, when programmers help testers, user interface designers and business analysts, or when business analysts help testers. Unfortunately, programming is a technical enough activity that UI designers, testers and business analysts are unlikely to be able to help the programmers. Programmers can help other programmers, though. We see front-end developers, middleware developers and back-end developers helping each other in some companies when one of the groups has a sudden bump in work.

Extend the Network

All of the above ideas are good – so good, in fact, that a company using them soon finds that their bottleneck lies somewhere in their supply chain, whether their sponsors, their subcontractors, or their distributors. These companies start to draw the queuing or decision-dependency network for the larger system in which they sit, and start including their supply chain partners in their discussions.

Toyota is well known for working with its suppliers. Less well known are cases of software development groups doing it. The same team I referred to earlier, having the the daily programmer rotation for fixes and enhancements, also wrote automated acceptance tests for their subcontractor’s parts of the system. They reasoned that their time was better spent writing automated acceptance tests and catching bugs on arrival than debugging and finding those same faults in the integrated system when their supplier’s code broke it. The supplier was, of course, surprised but delighted to find they didn’t have to write the automated acceptance tests.

The lesson from Toyota and the other companies who are streamlining the wider network is: the wider the network of ‘we’, the faster we all go..

Who’s Writing About This?

Once you see the mapping between manufacturing and team design activities, suddenly a lot of literature becomes available.

Toyota’s production system, also called The Toyota Way, Toyota Production System, and lean manufacturing, is widely documented. The Toyota Way Fieldbook [1] is a good place to start.

The application of lean manufacturing principles to design work is described in Managing the Design Factory [2]. The Poppendiecks have appled lean manufacturing principles to software development [3, 4]. Agile Software Development [5] contains an experience report from a software product company (Tomax) that is including its customers directly in it dependency network.

Goldratt wrote about bottleneck stations in manufacturing [6] and then widened the disussion to constraints in general (theory of constraints) [7]. David Anderson applied the theory of constraints and queue size to software projects [8]. I have written about strategies for dealing with bottlenecks that have reached their capacities [9].

Summary

It is not immmediately obvious that software development teams can learn from manufacturing. However, once we map the network of dependencies between people in a software development organization and make the shift to think of unvalidated decisions as comprising the “inventory”, then the parallels become startlingly clear.

We learn 6 lessons from the parallels:

  • Drawing the decision-dependency network helps us see the bottleneck stations, where decisions-to-be-made are piling up.
  • From the different decision-dependency networks in various organizations, and their varying bottlenecks, we can see how the optimal process varies from organization to organization.
  • Move inventory out: Decisions decay over time, so it is important to find ways to shorten the pipeline from arrival of a request or decision to the deploymnet of the system.
  • Move small amounts, continuously: Transferring large batches of inventory (decisions in our case) between workers causes unpredictable variations in the organization’s output. It is better to move small numbers of decisions more often. This reinforces the idea of incremental development, with the smallest increment size possible.
  • Cross-train people: When people can help each other across specialties, they can move quickly to eliminate small bubbles in each others’ input queue, thus smoothing the organization’s output.
  • Extend the network: By widening the network included in the dependency analysis and queue-size reduction, a company can smooth its own input stream and simplify its working.
    h2. References

  1. Liker, J., Meier, D. The Toyota Way Fieldbook, McGraw-Hill, 2005.
  2. Reinertsen. D., Managing the Design Factory, Free Press, 1997.
  3. Poppendieck, M., Poppendieck, T., Implementing Lean Software Development: From Concept to Cash, Addison-Wesley, 2006.
  4. http://www.poppendieck.com/publications.htm
  5. Cockburn, A., Agile Software Development: The Cooperative Game, 2nd Edition, Addison-Wesley, 2006.
  6. Goldratt, E., The Goal,
  7. Goldratt, E., What is This Thing Called the Theory of Constraints?,
  8. Anderson, D., “Managing Lean Software Development with Cumulative Flow Diagrams,” May 2004, BorCon 2004 (online at <).” target=”_blank”>http://bdn1.borland.com/borcon2004/article/paper/0,1963,32096,00.html>).
  9. Cockburn, A., “Two Case Studies Motivating Efficiency as a "Spendable" Quantity”, Humans and Technology Technical Report HaT TR 2005.00..

What is Sprint Zero?

Rumor has it that Sprint One delivers software, in just two weeks. Some teams prefix this with Sprint Zero, also two weeks long, in which a starting architecture is created. I have even seen talk of Sprint Minus-One, where something else happens.

Where did Sprint Zero come from, and what is it, really?

I have an apocryphal story to offer for the origin of Sprint Zero, which a Senior Source tells me is very close to the what actually happened.

There was a village of earnest Sprinters, who shunned any form of advance thinking. Code! Code! Code! was their byword.

A senior designer fell afoul of the villagers, because he was caught spending time working out what his team should do, looking at the technology and the choices for architectural decisions, trying out some ideas.

The villagers gathered at his door one day, carrying pitchforks and flaming torches, to carry him off, burn him at the stake, tar- and feather him, and run him out of town on a rail (all of those, of course, one after the other).

The designer, thinking quickly, said, “But this is, don’t you see, ah, the necessary part of Sprint Zero! That’s when we get things lined up for Sprint One!”

And the villagers turned to each other and said, “Sprint Zero! Why of course! Of course there is a Sprint Zero.”

And they went off and instituted Sprint Zero on all of their projects.

.

Postscript: Some time later, there was another designer, who also wanted to do some investigation that was longer than two weeks long, something he felt had to be done before Sprint Zero. When the villagers gathered at his door with pitchforks and flaming torches, he said, “This is Sprint Minus-One, don’t you see?”. And they carried him off, burned him at the stake, tore out his heart, tarred and feathered him, and ran him out of town on a rail, in that order.

.

Scrum is a tool for running a project. Sometimes investigation precedes a “project”, because having a project already implies having made certain decisions. Those decisions are made before the project is running. Or, possibly, the project is funded, but there is investigation about aspects of the project that are good to do before development starts.

Like:

  • Who are the stakeholders in this project, and what do they care about?
  • Who are the users we care about, and what do they care about?
  • Who are our competitors, and how do we get around them?
  • What is the narrow market segment we should address first, before we take over the world? And what does that segment care about the most?
  • Is there technology suitable to our purpose? What might it look like?
  • Can we get good enough people to build this?
  • Where is the funding going to come from?
  • What should we be trying to build at this point?

This is “The Swamp”. The sticky, gooey period where sometimes nothing happens, and sometimes everything happens too fast and you have to sort it out. Answering all that may not be a two-week sprint.

In Programming as learning too late, and dialoguing with the design and Disciplined Learning (discussion: Re: Disciplined Learning), I describe how having an idea of what to build and how to build it, grows over time. During the Swamp Period, the team still has a bad idea of what to build, who to build it for, how to build it. In this period, they are are building up understanding and sorting out ideas. There can be a lot of staring at each other and saying, “What do you think?” “I don’t know, what do you think?”

There are a number of good exercises for how to get out of the swamp: a Exploratory 360, user surveys, stakeholder analysis, user trailing, and others; and some of those can and should be put on a schedule. However, to be honest, I don’t think I’ve seen a single case where it either all fell into a two-week period, or even a neatly predictable period. That’s why it’s called a Swamp.

Once you get out of the swamp, then there is information and direction, and you can put things on periodic time boundaries with code coming out. An architectural spike or a Walking skeleton (discussion: Re: Walking skeleton) makes good sense in the first such period; getting the integration and delivery systems in place, having the team complete an assignment together so they learn how to talk together.

I don’t particularly know that it needs a special name like “Sprint Zero”; it’s just work, as usual. Making incremental progress toward knowledge and toward deliveries. But if there is a sprint zero, that’s probably what’s in it.

Exploratory 360

Strategy: Exploratory 360°

At the start of a new project, usually during the chartering activity, the team needs to establish that the project is both meaningful and they can deliver it using the intended technology. They look around them in all directions, sampling the project in all ways to test for viability and meaningfulness.

The entire Exploratory 360°for a Crystal Clear project takes a few days up to a week or two if some new and peculiar technology is to be used. Based on what they learn, they decide whether it makes sense to proceed or not.


http://3.bp.blogspot.com/-JgLdIONG8js/U9klrHBPKTI/AAAAAAARoEU/mAbX1hs6MH0/s1600/Mercedes-360-0.jpg

Extract from Crystal Clear: A Human-Powered Methodology for Small Teams
Alistair Cockburn, 2004

Strategy 1.Exploratory 360°

At the start of a new project, usually during the chartering activity, the team needs to establish that the project is both meaningful and they can deliver it using the intended technology. They look around them in all directions, sampling the project’s

  • business value,
  • requirements,
  • domain model,
  • technology plans,
  • project plan,
  • team makeup,
  • process or methodology (or working conventions).

(They may check other aspects of the project, but these are the usual.)

The entire Exploratory 360°for a Crystal Clear project takes a few days up to a week or two if some new and peculiar technology is to be used. Based on what they learn, they decide whether it makes sense to proceed or not.

Business-value sampling consists of capturing, with key stakeholders, what the system should do for its users and their organization(s). This should result in the names of the key use cases for the system, along with the focal roles the system should serve, the personalities and functions it should present to the world.

Requirements sampling consists of low-precision use cases that show what the system must do, and with what other people and systems it will have to interact. Often that drafting exercise turns up interfaces between organizations or technology systems that had not formerly been identified.

Concurrently or from the use case drafts, the developers sample the domain-model. This sample serves to highlight the key concepts they will be working with, the core of the business, the programming and discursive vocabulary. It also helps the team to estimate the size and difficulty of the problem at hand.

The developers create a technology sampling, running a few experiments with the technology. Ward Cunningham and Kent Beck call these Spikes (see http://c2.com/cgi/wiki?SpikeSolution). The assignment is to ask: Can we really connect these technologies? Will they withstand the intended loads? Can our developers master the technologies in time? The programmers perform the smallest programming assignment needed to make it clear the project is not running down a blind alley. The experiments establish the technical plausibility of the project.

The team creates a coarse-grained project plan, possibly from the project map or a set of stories and releases. It might be done using the blitz-planning technique described later in this chapter, or XP’s planning game. This plan is reviewed by the Lead Designer, the Executive Sponsor and the Ambassador User to make sure the project is delivering suitable business value for suitable expense in a suitable time period.

Finally, the developers discuss their process, either in a Reflection Workshop or a Process Miniature.

***
Here is the story of one project that failed three elements of the Exploratory 360°:

During the technology sample, the developers found, much to their surprise, that they could not connect the organization’s email system to their intranet and browser system. It was not clear how they could actually deliver the software services they had envisioned.
The project planning sample showed the cost to be about three times higher than the Executive Sponsor was interested in spending.
The business value sample showed that the organization should not allocate very many developer resources to this problem; it would be better outsourced (or simply bought), and the development team allocated to a more significant business problem.

You would think that canceling or outsourcing such a project would be obvious to all involved. However, the developers were keen to experiment with the new technology, and therefore kept the project alive, under the guise that this project would serve as a good learning vehicle. Fortunately, the executive sponsors paid attention to the Exploratory 360° results, stopped the programmers, outsourced the project, and put these key developers on a project of much greater value to the organization (which, I am happy to add, they enjoyed much more).

Agile in tables

©2011 Alistair Cockburn

Humans and Technology Technical Report HaT.TR.2011.01.

I’m not much of one for running a project in tables, but other people are, and we are now at a point where some of the tables are looking interesting and useful. Here are a few I would consider using:

Risk-Value-Tail table

The RVT table shows a set of projects, features, or user stories against their risk or knowledge-acquisition aspect, their value aspect and their tail or gloss aspect (see Trim the tail (discussion: Re: Trim the Tail)).

Figure 1. Three stages of developing a feature: risk, value, gloss.

Project/feature/story Risk (knowledge) Value Tail (gloss) P1 Whatever it might be Whatever it might be Whatever it might be P2 Etc. Etc. Etc. P3

The purpose of the RVT table is to expose the 3 schedule aspects of each project, feature or story, thus allowing the team to tackle them in any order they might prefer – column-first, row-first, or some funny diagonal.

The good thing about this table is that it permits all possible implementation schemes, and maps to the trim the tail (discussion: Re: Trim the Tail) curve.

Knowledge acquisition table

As I’ve been exploring the front section of the knowledge-acquisition or Trim the tail (discussion: Re: Trim the Tail) curve, four risk or knowledge acquisition areas keep showing up:

  • Business risk: Are we building the right thing?
  • Social risk: Can these people build it?
  • Technical risk: Will all the parts of our idea work together?
  • Cost/schedule risk: Do we understand the size and difficulty?

These can be gathered and framed as a single question: “What are we trying to learn right now?”, which is quickly followed by, “What is the cheapest, fastest way to get that information?”

We can put these into an extension of the RVT table just for the risk/knowledge question, the Knowledge Acquisition table:

Project /feature /story How can we learn what we should really be building? How can our people learn how to work better together? How can we learn where the design isn’t working? How can we learn how much money, time it will take to get done? F1 experiment experiment experiment experiment F2 etc etc etc etc F3 F4 Feature Grade table

This table is due to Jeff Patton and his grades of quality idea (link?), turned into a table by Gery Derbier.

Grade each feature or story separately as F (not acceptable), D (minimally acceptable but not something you would want to ship), C (minimally usable), B (quite nice), and A (top quality).

One strategy for using this idea is to get every mandatory feature to a C level first, before trying to get any of them to a B or A level. Then use the time available to get the important features up to B or A as desired. In principle, this delivers the highest “perceived” quality of the final product.

Feature Grade F1 D F2 C F3 F F4 C Micro-incremental development (“hexagonal architecture”) table

This table comes from the Hexagonal architecture (discussion: Re: Hexagonal architecture) description, particularly the “barn door” image.


Figure 2. Hexagonal architecture “barn door” sequence.

This picture suggests developing features in three stages:

A Test harness functionality loopback in lieu of database
B Real UI functionality loopback in lieu of database
C Real UI functionality real database

(where the UI and the real database can be added in either order)

I first came up with this table when contemplating a serious piece of multi-site development on a large portfolio of projects, being shipped to multiple countries, where we were not sure what the quality of the programmers might be.

In order to regulate the development and keep track of the quality, we proposed setting into place the following rules:

1. Every developer must first check in A, with tests. The build manager or iteration manager or customer or product owner would reject any feature checked in without it being (a) free from the UI and (b) with automated tests

2. Then the UI and the database are added in any order at any time, with the caveat that the A version must still run at all times.

This yields, as with the Risk-Value-Tail table, a rich set of possibilities for sequences in which the feature set might be implemented: all A sections, then B, then C, or some of each, as long as the two rules are followed. It also allows the UI and database work to proceed somewhat disconnected from the feature set, allowing them to go slower or faster, as needed.

Here is the resulting HA table:

Feature Test-app-loopback +UI +database F1 Due/done date Due/done date Due/done date F2 Due/done date Due/done date Etc F3 Etc etc etc

Four tables is a lot of tables – I’m not sure how to use them together… However, one of them might do your project some good, perhaps even a couple of them. Write me and tell me if you use them.

Alistair

Pages