Unspoken Cultural differences in Agile & Scrum

For a while now I’ve been convinced that a lot of “Agile” is about cultural differences. In particular I believe the canonical version of Scrum, which I often refer to as Hard Core Scrum or Scrum™ is rooted in 1990’s American software management culture.

Unfortunately the role of culture behind many Agile techniques and methods isn’t really stated. This make it even more important to work out what Agile means to you and which tools work in your environment and culture.

I first started paying attention to the cultural differences around teams and Agile after Steve Freeman said something along the lines of “Scandinavian teams just do this, they don’t see much new.” The teams I’ve seen in Scandinavia, and to a lesser degree Holland and the UK, don’t need big lectures in self-organization, left to themselves they do most of it.

I’ve pondered on this for some time and at Agile Cambridge last month I got the chance to talk a little about this with Dave Snowden. We only had a few minutes to talk about this - I was about to present - but it was clear we could have talked for hours.

Take stand-up meetings for example.

When I worked in Silicon Valley I worked in a cube. I hated it. I didn’t even know if my neighbours were in the office, let alone what they were working on or if they had achieved anything that say.

Working in the UK, in open plan offices, usually sitting opposite my co-workers we would certainly know who was in, most likely they would tell me when they had done something.

I believe that stand-up meetings are a good thing in all teams. However I believe they make a much bigger difference in cube and office dwelling environments than in open plan offices. In other words: stand-up meetings have greater benefit in US offices than they do in European offices.

In the original book of Extreme Programming Kent Beck talked of a “sustainable pace” and “40 hour work week”. Beck talks about his experience in Switzerland and contrasts it with the US norm. Although European workers - particularly in the UK - frequently work more than the 40, 37.5 or 35 hours they are contracted for they work hours don’t get excessive for too long. I’m not sure that is the same in the US. Sustainable pace means different things.

Personally I’ve always found “sustainable pace” does not fit well with the Scrum idea of “commitment”. I’ve written before - Two Ways to Fill an Iteration - about the contractions I see. Culturally it isn’t hard to see how “sustainable pace” is easier to do in Europe than the US.

(By the way, I’m limiting myself to the US and European, specifically UK, cultures because these are the ones I have some experience of.)

Now lets talk about the big one: Self-Organizing teams and evil managers.

(Apologies if this comes across as Scrum bashing, I believe Scrum works, or at least Scrum-lite works, and I believe self-organization is best. I just don’t believe hype.)

Some Scrum courses and advocates make a big thing out of self-organization. Personally I don’t. In my courses I I talk about it a little, more if people want to, but I focus on giving people experience of how it works. My style of Agile - yes I’m slowly writing up Xanpan - believes that self-organization is the result of the right approach not a stating point.

Self-organization goes hand-in-hand with an attack on Managers, and in particular Project Managers. Again this theme runs through all Agile but in Scrum is particularly strong. Hard-core Scrum really has it in for Project Managers but then replaces them with Scrum Masters which most companies think is just the same job with a different name. I’ve written about Scrum’s contradictions with Project Managers before so I won’t repeat myself, When did Scrum start loving project managers?

But Scrum’s dislike of managers only goes so far. After all, Scrum is the management friendly version of XP - see Scrum has 3 advantages over XP.

Now I’m not a big fan of Project Managers, in my programming days I too suffered a few managers who tried to hand out tasks and impose their way of doing thing. And I’ve been told No when I want to spend a little money - I once threatened to leave the company if they didn’t buy more RAM for my development box.

When I look back over my career I have to say most of the (project) managers who behaved like this made themselves irrelevant. We worked around them. Certainly removing them would have made us more effective.

But, most of my experience is that managers, even project managers, didn’t behave like this. They may not have been the most empowering of people but generally they left me, and programmers I worked with, to get on and do it. We worked out what needed doing, we divided the work up amount ourselves, we scheduled at the micro-level.

In other words: we did self-organization on a day-to-day level.

Again I think there is a cultural difference here. In my experience America is a more hierarchical culture than Europe (with the possible exception of Germany). Please, I’m not talking class systems here, I’m talking command and control.

I think Europeans are more likely to question their managers to their faces - perhaps it was the 1914-18 experience - or just plain ignore them.

National characteristics are not the only basis for culture. Industries have cultures too. Here again I’ve written before: Agile will never work in investment banking - one reason being that investment banks are very hierarchical.

Most of the managers, even project managers, I meet when delivering Agile training courses and consulting, like the Agile approach and want to work with it for the benefit of their teams. Few seems to be the whip-cracking project managers of folk lore.

Jon Jagger tells a story about one of his clients in Norway. The company was bought by an American competitor. When the engineers started to work together they would convene a teleconference. The American programmers would arrive with their managers while the Norwegians would arrive by themselves. The American’s would ask “Where is your manager?” The idea that the Norwegian could talk and make decisions by themselves was a new idea.

I had a manager in California - Irish as it happened - who used to practice “management by walking around.” Every morning he would appear in my cube and chat. Took me months to realise he was my manager and when I did I wished I had been more guarded with some of my remarks.

This all begs the question, why would American management be such a hinderance to software development? (Note I’m not saying European management is better, that has its own faults, I’m just exploring different cultures.)

For many years the USA was the world foremost manufacturing nature. Part of this success was the superior management practise implemented by the Americans. Such practices made a difference on the factory floor but even here they have been .

I can, and should, write more about managers and their role in the software team. Suffice to say for now: there is an awful lot of bad management out there. I believe good managers, good management practices, can be help companies massively. But on the whole, in the IT industry, there is a lot of poor management.

Bringing this back to Agile.

I think Agile’s anti-management slant is really a reaction to bad management. Hard-core Scrum is the Extreme in this respect. Scrum-Lite, as practiced by most teams, is less so.

Agile, and particularly Scrum, is the product of 1990’s culture, and particularly American work/management culture. Since American culture spreads the fact that Europe never suffered from quite these ills may down to the fact that we were not that good at copying American ways.

There may be a silver lining here: if America adopt Agile, Scrum, self-organization, etc. then we should see it spread out to the rest of the world.

If you disagree with me I’d love to have your comments on this blog. And if you agree I’d love to hear your stories to. Please, leave a comment.

Dialogue Sheets feedback and stories

Retrospective Dialogue Sheets continue to be a popular download, and I’m off to Sweden in a couple of weeks to present the sheets at Oredev. Unfortunately I haven’t had time to review the downloads to extract any useful information from the several thousand downloader details but I do continue to get some interesting feedback.

A few months ago Gail from Siemens Healthcare e-mailed me to tell me how she had used the sheets to conduct a distributed retrospective. The team in India had one sheet and conducted their retrospective in their work hours. Several hours later when the US team arrived at work conducted their own retrospective using another sheet. Gail then gathered the findings and reviewed the two sheets and conclusions which were complementary.

More recently I heard from a Scrum Master at Stattnett in Norway about their use of the sheets. What follows is a (slightly edited) account which nicely describes why many people like the sheets:

“thank you for the sheets! We've now used them in two retrospectives, and we will continue to use this technique for the future.

My main reasons for applauding their use:

• The sheet stimulates equality among team members during the discussions, by the fact that all must be seated around a table (no one standing up and facilitating the discussions).
• The sheet rules demand at least some contribution to the process from each team member during the session, by reading out questions loud - and also decide for themselves what is needed to read (and not to read).
• The sheet is very physical and with few/no barriers for participants to express themselves on the sheet for everyone to see - even if it is only by drawing "stick men" on the edge (next time, maybe even the stick-man-painter will write some words on the sheet).
• The sheet and rules (when followed) prevent the Scrum Master from falling into a "team leaderish" role when the rest of the team gets lazy and wont't bother to involve in the process - they all have to take their part of a common responsibility for getting through the questions and to the end of the "game".

...and there are more.

These characteristics make our retrospective sessions less bureaucratic and more inspiring than with our old technique. We have been using the more traditional technique for several years, with each team member preparing notes before the meeting, writing successes and suggested improvements (often as complaints...) on green and pink paper memos.

The notes were then collected on a whiteboard and discussed and voted on at the end - with the Scrum Master (me) as facilitator. This preparation of notes [was rushed] and no one really likes to do this. Going through each and every note was time-consuming duty with debatable value. [In the end] the retrospective meetings became quite uninspiring form for all of us.

But with the dialog sheet, we now have a better, more inclusive and more constructive climate in the meetings. We spend our time on issues of real value to the team instead of ceremony parts no one really likes, and more in line with the original intentions for this session.

The sheet can be put directly on a wall after the meeting, for everyone to see. I don't have to make any kind of additional summaries anymore (as I did, even if core scrum doesn't prescribe this). I can instead take a photo of the sheet for the record, if needed.”

I regularly hear that of teams who hang the completed sheet on the wall as a reminder of the discussion and conclusions. I have also heard of a team who hung a blank sheet on the wall at the start of an iteration and team members filled in the timeline as they did the work.

Finally, I recently discovered a blog posting from University College Dublin which used the Dialogue Sheets as part of student retrospective exercise. I don’t believe these are the first College to do so, University of Central Lancashire might have that honour.

Since I learned about the sheets from Cass Business School in London I like the idea that the sheets are going back to college!

Correction: Business Analysts & C3 project

In a couple of blog post, and on other occasions in other places I have talked about there being a Business Analyst working on the original Extreme Programming (XP) Chrysler C3 project.

I’m not sure where I picked this piece of information up but I was wrong. One, Chet Hendrickson of the original team read my post and the team actually had direct access to the payroll team to understand what was needed, agree acceptance criteria, etc.

The Wikipedia entry on C3 discusses a “customer representative” on C3 and indeed Extreme Programme suggests you have a onsite “customer”. Somewhere along the line I read, was told, or just got the impression that this person was, on the C3 project a Business Analyst. Now I see I was wrong.

Having set that, I would still suggest that a Business Analyst can fill the role of customer representative and often have experience and training in doing this. I will accept that sometimes a BA doing this might become a block and it would be better for the team to talk directly to the customers.

Why try Kanbnan?

In my last post “Scrum doesn’t work for us; should we try Kanban?” I gave a warning about adopting Kanban because Scrum doesn’t seem to work. Having given advise on when not to use Kanban I feel I need to suggest when choosing Kanban is the right decision.

Of course list that follow is only broad guidance, each and every team needs to make their own decision based on many factors I cannot even guess at here. Nor is this an extensive list, I’m sure Karl Scotland, David Anderson, Benjamin Mitchell and others would add more to the list but its a good start.

Here goes….

Use Kanban for maintenance: teams who fix bugs, especially teams who fix bugs in live system. Such teams work respond rapidly to unpredictable work, bugs are difficult to estimate and can come up at any time.

Use Kanban when predicting future work is difficult: this is a generalisation of the previous case but expanded. It is not just bugs which are unpredictable, sometimes the work which needs to be done is unpredictable.

Note: some teams fall into this position not because the work they do is really difficult to predict but because there is no effort put into predicting the work, usually because nobody is tasked with looking ahead or the person who is asked to do so isn’t allow enough time to do so. The easy way to spot this is the absence of someone with a title like: Product Owner, Business Analyst, Product Manager or similar.

Use Kanban when the team find Scrum style routines stop them achieving flow: for effective teams who focus on rapidly turning new requirements into working software Scrum routines such as planning meetings can get in the way. Nor is there a lot of point to running a product backlog if items are being delivered rapidly or not done.

Use Kanban when the system is too complex to model with Scrum(XP): the plan-it, do-it, deliver-it model which underpins Scrum isn’t too helpful when a process has a lot of wait states or dependencies. The standard Scrum answer is probably to remove these but that isn’t always possible (e.g. you can’t force a customer to respond).

Use Kanban when learning is a higher priority than delivering: to be effective Kanban requires to learn from what the system is telling you and adjust. If you can’t put the learning into effect Kanban will not be effective. However, Scrum’s pre-packaged solutions means that many teams seem to adopt Scrum and forget about learning (e.g. retrospectives are forgotten.) Worse still, because Scrum (claims) to fix so many problems “out of the box” teams may develop a learn dependency.

Use Kanban when you need to introduce the Agile approach more gradually: strict Scrum mandates a big-bang approach, sometimes this isn’t possible. Kanban provides a foot in the door which becomes a lever for opening it more. (This point flows directly from the previous when you consider change to be the result of learning.) However this also comes with a warning: change can quickly stall if people do not act on what they see and learn.

In the past there has been debate about which style (Scrum or Kanban) a team should start with and which is the advanced style. Personally I find it easier to start with Kanban although many people feel the natural order is the opposite: start with Scrum, get good and advance to flow and Kanban. Although it is easier - in my mind - to start with Kanban it is also a lot, lot, easier to get it wrong.

There is a paradox there: Scrum mandates the role of Scrum Master, I don’t usually see the need for a Scrum Master, an occasional Agile Coach is helpful, but a full time Scrum Master No. Kanban doesn’t mandate any such role, but you probably need someone with past experience far far more with Kanban than you do with Scrum.

Scrum doesn’t work for us; should we try Kanban?

Two and a half years ago I published a blog entry entitled “10 things to know about Kanban software development” which has consistently been the most read piece on this blog. At first I thought “Well there isn’t much published on Kanban relative to Scrum” but then David Anderson published Kanban and that wasn’t true any more.

Others have written about Kanban too over the last two years but still there is a hunger out there, people want to know about Kanban. I see this too when I deliver my Agile training courses, the moment Kanban is mentioned people want to know more.

Although Kanban is conceptually simple you really need a day or two to discuss it properly. Still, I regularly find myself squeezing an hour, or just 10 minutes, into a Agile training course because the audience want it. I say “I really need a day” but I can’t avoid it - they are paying for my time so they get what they want.

One of the reasons people give for buying an Agile (Scrum/XP style) course and wanting Kanban is, they say, “we don’t think Scrum will work for us so we might try Kanban.” Then when I return to coach teams I’ve given training to I’m regularly asked “Scrum doesn’t seem to work for us, should we try Kanban?”. I reserve judgement and enquire before I give my advice, and what I find is….

They haven’t really tried Scrum(XP).

Or rather, they have tried a Scrum(XP) type approach and they hit problems. Despite my telling them this would happen they think its Scrum. The thing is, Scrum fixes some problems “out of the box” but it doesn’t fix them all, in fact it exposes old problems and highlights difficulties which you then have to fix. Thats the way it works, that is the way it is meant to work.

Let me repeat that: Scrum and XP do, in and of themselves, right out of the box fix a lot of problems software development teams typically have. But Scrum and XP do not (despite what some people will tell you) fix all problems right off: you have to continue the work and fix them yourself. Sometimes Scrum, as officially described, will just not work, you have to modify it to your environment.

What worries me when teams say “Scrum doesn’t work, we want to try Kanban” is: if a team can’t make Scrum(XP) work because they cannot fix the impediments or make their own modifications then Kanban will never work. In fact, Kanban will probably be dead on arrival.

Some years ago Karl Scotland said “there is a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important - it just happens to be the best way we (or at least I) know at the moment.”

Thus: If you want to try Kanban because Scrum doesn’t seem to work for you then the chances are Kanban is only going to be a diversion. Set about fixing your problems.

Now there are reasons why Scrum doesn’t work, and there are reasons you should try Kanban, that should be a separate blog. One common case is because the development team has some support or maintenance responsibilities. In these cases my XP-Kanban hybrid Xanpan works quite well.

(I keep taking about Xanpan and a few people have asked me to write about it but a) I don’t think the world needs yet another Agile method, and b) until recently I wasn’t convinced there was enough difference between Xanpan and either Kanban or Scrum/XP to make it worth while. On the second point I’m changing my mind. If you want to know more about Xanpan let me know.)

Back to topic, although a team might not need to move from Scrum/XP to Kanban or Xanpan there might still be advantages to doing so. However moving because you can’t overcome your own obstacles is not a good reason for changing. If you can’t make Scrum work because you can’t fix your own issues switching to Kanban is not the answer.

Minimal Viable Team to create a Minimally Viable Product

Despite being a bit of a mouthful to say “Minimal Viable Product” and the even more difficult to say “Minimally Marketable Feature” (also known as a “Quantum of Value” or “Business Value Increment”) are very useful concepts. What makes gives them killer power is that they speak to a secret belief held by many people (not just managers) that teams gold-plate development and create products with more than is needed.

The trouble is, while we all agree the we should develop Minimally Marketable Features (MMF from here on) and delivery Minimal Viable Products (MVP) it is actually quite hard to do this. Nobody seems to want to sacrifice their favourite feature or the styling they have set their hearts on.

In Business Patterns I have a side box entitled “Strategy means saying No” in it I say “One of my personal rules of thumb is that strategy is about saying “No”. Strategy is not so much in what you decide to do – saying “Yes” is easy – but in the hard decisions about what you choose not to do.” The same applies to product development: saying Yes to a feature is easy, saying No is hard, but unless you say No a lot more than Yes you won’t have a MVP.

(After completing Business Patterns I discovered that both Michael Porter and Tony Blair have made the same argument, that No is more important than Yes.)

I have come to believe that one of the reasons teams find it difficult to create MVPs made up of MMFs is that the teams are just too big. I would like to suggest that if you want to create a MVP then you need a Minimally Viable Team. i.e. a team which is only just big enough to create the product.

Indeed, I will go further and suggest that your Minimally Viable Team (MVT) should be slightly smaller than you think you need.

Basically my logic is: if you have more people you will create more product. If you constrain the amount of effort that can go into a product then you will constrain the thing that is produced.

Way back I worked on Railtrack privatisation in the UK. When I joined the team is was 120 people (although only about 12 actual coders). The project was massive. Out of that came by belief that inside every large project is a small one struggling to get out. I sometimes call this Kelly’s First Law of project complexity: Project scope will always increase in proportion to resources.

A few years later I found myself working on a data feed project at Reuters. In retrospect the team was overstaffed. We didn’t need COM based system with interchangeable components. We made work for idle hands.

I know one team I’ve been visiting for over a year now, MMF and MVP frequently come up in discussion but I see the product backlog getting larger and larger and larger. The team is quite large by today’s standard - over 30 depending on how you count it. And ever since people started talking of enlarging the team the backlog has grown faster.

So much for the observations, lets try logic.

If you think about this the need for a MVT to create a MVP is a direct result of Conway’s Law: organisations will create systems that are copies of the organisation. (Seven years ago Lise Hvatum and myself investigated Conway’s Law in a conference focus group, the result was “What do we think of Conway’s Law now?”).

This can also be stated as the Homomorphic force: the structure-preserving relationship between two sets of things.

If you create a team which is too big it will produce a product which is too big. Once you have created a team which is too big it will find work for itself to do and it will be very very difficult to reduce the team size.

So start with a small team: actively try to break Conway’s Law, break the homomorphic force.

Staff the team with a fewer people than you think you will need, staff it with a range of skills but avoid making architecture assumptions in your staffing (if you include a DBA and you will have a database in the system.) As and when the team demands to grown then grow the team grow it.

Use Conway’s Law to your advantage: create a Minimally Viable Team to create a Minimally Viable Product.

How small is a MVT? I would say two people.

Really you need three people for it to be a team but in the belief that you should start smaller than you think I say two. One of these people should be focused on the business side of things - requirements, need, problem domain call it what you will; the other on the technology or solution domain. Let them work the problem for a while and see what happens.

Development Partners - branching out

My company, Software Strategy, has existed for over five years now and has been successful within the terms I’ve set for it. Now its time to try something new.

That doesn’t mean I’m giving up Agile - although I must admit to getting sick of the word - nor does it mean I’m giving up delivering training courses - if anything I’m expanding here, Giovanni Asproni now delivers the courses too. Nor am I stepping away from Coaching - although I increasingly prefer the term Consulting because I do give advice and I think true Coaches don’t.

No this is an addition. Software Strategy is now going to undertake work for clients - you can subcontract your work to us. I’m teaming up with Alan Griffiths and Giovanni Asproni, I’ve known these guys for years through the ACCU (formerly the Association of C & C++ Users if you want to know).

There are three reasons for doing this:

Opportunity: I believe that Agile working provides an advantage to companies, I also believe there are opportunities for companies that work this way.

Better: Alan, Giovanni and I truly believe we can do a better job than many of the companies out there, call it skills, call it experience, put it down to Agile or Craftsmanship or even the ACCU. We just do. And the engineer inside of me says: if you are better you will succeed.

Improvement: I believe that Software Strategy, and those who work for and with it, can benefit from adding this feedback loop. We can see how things work in our own practice and feed it into the training and consulting we do.

Thats the Why, but What?

To start off with we are focusing on the object oriented languages, specifically C++, Java and C#. We intend to provide requirements analysts, project management, coding and testing, i.e. full cycle. This might not be the fashionable end of development but it is where we have common experience and, despite fashion, is still a very active area of development.

We plan to undertake Greenfield projects (i.e. completely new code bases), Brownfield (i.e. enhancing existing products) and Rejuvenation. That last one deserves a few words, if only to say I expect large scale, significant refactoring, to be involved.

There are a lot of code bases out there which remind me of crippled Starship Enterprise, the Engineers are shouting “She cannae take it Captain” - well actually, they are probably saying “Technical debt, technical debt, technical debt…. can’t modify this system” and the more they say it the more the business switches off to engineering.

I, we, believe that it is possible to turn these systems around. We have the technology - or rather the tools and experience.

Anyway, as Software Strategy Development Partners proceeds I hope to have some interesting things to blog about. (And yes, there is a strategy map of business patterns in my notebook.)

So, if you have any work you’d like to sub-contract you know where we are.

Thoughts on Mind the Product conference

As I mentioned in the last blog posting I was at Mind the Product last week in London. For the first time in a couple of year I was just a paying punter at a conference, I was not speaking!

Here are a few notes on Mind the Product - partly as feedback to the organisers, partly for myself, and partly to encourage more people to attend next year.

Good points

• That the conference was happening at all in London was perhaps the best thing for me. 10 years ago product management (as practices in Silicon Valley) didn’t exist in the UK. 5 years ago a few forward looking companies got it. Now it is more broadly known but still not widely enough.
• Two concerns I had about the conference before hand both proved unfounded. One that it would be a little basic in terms of content and two that it would but all very Lean Start-up orientated. There was lots of mentions for Lean Start-up and “pivot” seemed to be the word on everyone’s lips but neither fear played out.
• Marty Cagan as a keynote, I’m envious, I tried to get Marty to speak at Agile on the Beach but he was already booked of this. I was interested to hear him say that he thought the UK was improving with product management over the last few years. I’ve been saying the same thing.
• Tom Hulme of Ideo London gave a great talk about purpose, although I think it was really a talk about business strategy.

Things that weren’t so good

• Some sessions really lacked focus or content - e.g. the talk on the games industry had lots of good ideas but they were not finished, they needed more research and thinking; some of the other presentations left me wondering “what is their point?” but then, Marty Cagan and Tom Hulme set a high standard to match
• The venue made things difficult, it was spread out, several vertically connected locations, getting food at lunch time involved finding the end of a queue and waiting. You could tell it was an old theatre where the intermission spaces were not meant to be occupied for long.
• The format (one track, presenter talking to the audience, no interaction) left us sitting in our seats for too long without enough breaks
• Recruitment is often an undercurrent in conferences but this time it was too much, everyone who spoke seemed to say “we’re hiring”. Many of the people at the conference had their tickets paid for by companies who would rather their people were not lured away. A bit of recruitment is to be expected this was too much. (At Agile on the Beach we made a conscious decision to not take sponsorship from recruitment agencies.)
• As is so often the case at conferences the wifi kept coming and going - maybe this was on purpose to stop too much twittering and checking of e-mail

I hope the conference runs next year, in which case, this is what I’d like to see change next year:

• Have two or three parallel tracks to give choice
• Have some interactive sessions to move away from the chalk and talk
• And thus allow for more frequent breaks
• Different venue: one that promotes mingling, discussion and interaction

Having said I hope the conference runs next year I have an even bigger hope: that product management becomes a feature of other conferences in the technology sector. Product Management shouldn’t be its own ghetto with product managers talking only to other product managers to agree that if only product managers ran the world everything would be right.

Agile Cambridge: Dialogue Sheets and Andy Warhol

Last week was busy with conferences. I was briefly at Agile Cambridge on Thursday and attended Mind the Product conference in London on Friday (more on that in the next entry).

I feel the need to apologise about Agile Cambridge, I was there for a little over half a day. If I go to a conference I like to be there for longer. As it was I saw Dave Snowden’s keynote (very good) and ran a Dialogue Sheets session.

As usual the Dialogue Sheet session was goo and I hope a few more people will try retrospective Dialogue Sheets - there were people in the workshop from the BBC and McKinseys who said they would be giving them a try. But the most amazing thing about this session was the room: there was an original Andy Warhol Marylyn hanging on the wall. I was warned by the organisers several times not to put anything on the walls or pictures!

As anyone who has used one of my Dialogue Sheets knows there are some thought provoking quotes around the edges. As chance would have it both sheets included an Andy Warhol quote: “They always say time changes things, but you actually have to change them yourself.”

Here are some pictures:

Postscript: The few slides I used are here Dialogue Sheets for Agile Cambridge 2012.