BrainScrum

I just got back from the fourth Italian Agile Day and I’ll write more on this in the next few days but I want to share with everyone an interesting Italian campaign my friend Francesco Cirillo - the oldest (not as in age :-D) and greatest Italian eXtreme Programmer - has launched:

It’s called The Anti-IF Campaign (the page is in Italian)

It reads: “anti-if campaign, you can quit if you want to!”

Francesco talk at the Agile Day (about, among other things, proper Object Orientation) was funny, entertaining and full of meat as usual. Imagine a great public speaker addressing the crowd wearing an Anti-IF t-shirt and saying, while showing snippets of real code with a McCabe’s Cyclomatic Index > 110, “be honest guys: you like this code, don’t you!”

I believe the campaign should have international visibility and that’s why I’m writing this post. Go Francesco, go!!

Lots of people (including me) keep saying you need to understand the fundamentals of Agile before tinkering with it. We keep saying working in iterations, doing stand-ups, doing TDD, sitting altogether in a room is not enough to claim you are “doing Agile”.

This is true for any approach, Agile or not: you have to understand how, when and why it works before starting to customise it.

IMHO this is the main reason why you are supposed to apply an approach sort of “by the book” before starting to change it (through retrospectives, of course! ;-)). This is also why people talk about Shu Ha Ri as a way to approach Agile.

A common advice is to always change things once you got the core values behind them. Even better once you got the principles who fill the gap between values and practices. The real problem, as usual, is the complexity surrounding these aspects and the far-from-the-books reality of the day to day troubles.

To help organising ideas and possibly cut through this complexity many interesting and useful perspectives have been proposed both on the Agile side of the pond and the other. For example, David J. Anderson’s Recipe for Success:

“Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize”

Nonetheless people keep having problems with the complexity that often prevents us from seeing the bigger picture. We have problems in cutting through this complexity and go back to the building blocks.Most of the people I meet though don’t even consider these building block, their focus is on the process/approach/method/methodology itself.

This is limiting, this is not why we have (and discuss) methodologies in the first place. This is what I was referring to at the end of my “From Technicality to Business Awareness: now what?”.

Everyone agrees that not all the processes should be managed the same way. Processes differs in particular depending on the four Vs:

• volume - high volume ones can exploit economies of scale and be systematized
• variety - high variety ones require enough built-in flexibility to cope with the wide variety of activities expected of them
• variation - high variation ones must be able to change their output levels to cope with highly variable and/or unpredictable levels of demand
• visibility - high visibility ones add value while the customer is present in some way and therefore must able to manage customers’ perceptions of their activities

Generally speaking high volume with low variety, variation and visibility make it simpler to have low cost processes while low volume with high variety, variation and visibility all increase process cost.

Nonetheless all these situations have common building blocks and to make them very clear and easy to understand and remember I’ll borrow some definitions from the business world:

- cash generation
- return on investment (as combination of margin and velocity)
- growth
- consumers

That’s it! Everything else emanates from these core ones. These are what any process/method/methodology/approach/whatever should ultimately enable. If they don’t they are getting in the way of the fundamental building blocks. If they don’t it doesn’t matter whether your are doing all the good Agile stuff or not: you are not doing the right thing.

These building blocks exist, with the appropriate adaptations, at every level of the supply network of any organisation. From the strategic level down to the operational level and that’s why any process MUST address them.

In the next few posts I’m going to write a bit more about these building blocks, why they are relevant and I’d like to introduce the three levels which constitute any business operations: the operation itself, the supply network and the single processes. This way I hope that by the end it will be clear why I’m putting together all these things.

The single most important benefit Agile approaches brought to the IT industry is neither technical, nor process related, nor organizational. Let me explain.

From what I can remember, before the Agile movement emerged, the software engineering crowd rarely moved away from the technical argumentation. I think the only time it moved a little was at the beginning of the pattern movement which, by the way, was blamed by many to contain a romantic element like the research of the “quality without a name” clearly at odds with the mainstream technical soul.

Issues like what values and principles stand behind an approach and what beliefs are considered true were almost always lacking while others like in what contexts those values, principles and beliefs are meaningful were usually present in a latent form (aka: you needed to look hard to find them scattered as they were among all the technicalities).

Agile approaches, on the other hand, start from the values and the principles. The beliefs are a little more explicit than before even though still not fully uncovered or better, not everyone yet is ready to accept even the possibility that there might be beliefs behind them which might not be true for every single reality.

Yet again this is not what I consider the single most important benefit brought by the Agile movement to the industry: the single most important benefit is a sort of Business Awareness.

I finally see and hear people, regardless of their official role, talking about business value and how they can help delivering it. Not just theoretical discussions about it but actual actions, contributions, body of knowledge, experience sharing. I see technical people interested in return on investment, opportunity cost, GDP and sometimes cash flow.

I’ll go so far as to say that nowadays if a team is doing all the good Agile/XP stuff like TDD, refactoring, continuous integration, etc, etc but I don’t hear people talking about delivery of business value I’m usually worried because more often than not it means some fundamentals are missing and people are in a sort of “agile Assimilation mode”.

As the title of this post says: now what? Well, this is the first step! The second actually. Often business value is repeated so many times it becomes an empty mantra and even I cannot stand it anymore. To make a parallel is like repeating ad nauseam OOP or TDD or pick_up_the_thing_you_prefer: it’s not gonna make it happen! Now we are aware of it but we still don’t know how to affect it, what it exactly means, why it works the way it works and what we can do about it.

For the same reason we keep saying that we need to understand values, principles and beliefs behind Agile in order to fully understand it and be able to adopt it and adapt it to our reality we need to understand the fundamental building blocks of any business in order to understand why we do what we do, regardless of the chosen approach.

The next step is developing Business Acumen and I hope to find the time to write more about it in the near future.

From an interesting article published on IndustryWeek: “Companies that consistently innovate are ones that invest in working conditions that enable workers to be creative. Simply ordering people to work harder and innovate probably isn’t a great strategy.”

Update: just realised the article is discussed in a post on one of the best blogs out there (IMHO): http://www.evolvingexcellence.com/blog/innovation_illusions/index.html

Among other things it discusses “where to find the time needed”

For the third year in a row I managed to organise the Italian Agile Day: a one day free conference on Agile methods. For the first time I decided to try and support the conference using donations instead of commercial sponsors. It was a bit of a gamble but it worked!

Some numbers:

- 2 plenary sessions (at the beginning of the day and after lunch)


- 18 open space sessions “pre-semi-organised” (first time for an Open Space conference in Italy)
- an on-going XP Game throughout the day so that as many people as possible could attend

- lots of space for spontaneous discussions
- 180 partecipants

It was a great day, IMHO the best of the three we had. Of course there is a lot of space for improvement (for example all the sessions were in the same big room and it was a bit noisy, in particular when the guys at the XP Game started playing with balloons )

Thanks to everyone: speakers, supporters and partecipants. See you next year!

From this email by Mary Poppendieck:

“you are wise to be skeptical – as a general rule, manufacturing practices do not move easily to any kind of development, because the two activities are so different. Development is like a chef creating a recipe – manufacturing is like cooks reproducing that recipe every night in a restaurant“

From this article published on the Harvard Business School’s Working Knowledge website:

“In the early 1990s, Taco Bell’s management was faced with a dilemma. It wanted to create thousands of new locations, including stores and kiosks, at which its line of Mexican-themed products could be sold. At the same time, it was experiencing a shortage of capable managers in a fast-food industry known for low-paying management jobs. One part of the solution was to create fewer, higher-paying management positions. The other was to train thousands of entry-level workers at its stores to manage themselves.”

Give it a read

I’m going to quote an email Jeff Sutherland sent to the Scrum Development mailing list with the title “The Importance of Scrum” because I strongly believe it’s the essence of what I (try to) do:

“Prof. Peter Senge of MIT was asked to update “The Fifth Discipline” for republication as one of the leading business books of the 20th century. He sent a note to Edward Deming asking him for comment on the book. He wasn’t sure Deming would respond as he did not know him and Deming was over 90 years old at the time.

Deming, the father of the Japanese post-war industrial revival was regarded by many as the leading quality guru in both Japan and the United States. Scrum roots are in Japanese lean development and that was started by Deming. So really, what we are doing is a U.S. initiative that had to be repackaged by Japan because of dysfunctional management in the U.S.

Deming responded to Senge:

“Our prevailing system of management has destroyed our people. People are born with intrinsic motivation, self-respect, dignity, curiosity to learn, joy in learning. The forces of destruction begin with toddlers—a prize for the best halloween costume, grades in school, gold stars—and on up through the university. On the job, people, teams, and divisions are ranked, rewarded for the top, punished for the bottom. Management by Objectives, quotas, incentive pay, business plans, put together separately, division by division, cause further loss, unknown and unknowable.”

Prof. Senge comments:

“I believe that the prevailing system of management is, at its core, dedicated to mediocrity. If forces people to work harder and harder to compensate for failing to tap the spirit and collective intelligence that characterizes working together at its best.”

The importance of Agile processes and particularly Scrum is that we are changing the way people work all over the world. While we are often surprised at the resistance to change we see, we can take confidence that we are driving forward Deming’s vision and not just in the world of software. If he were alive today, he would certainly be encouraged by this.

Jeff Sutherland”

Thanks Jeff!

[rant]
Please tell me it’s a joke. Scott W. Ambler has published some interesting data related to a surveys done via Dr. Dobb’s Journal. Questions, raw data and summary can be found at http://www.ambysoft.com/surveys/

In the last slide of the summary presentation (ppt) I read: “There was a statistical correlation between adoption of “Agile 2.0″ methods such as Agile Unified Process (AUP) or MSF Agile and adoption of Agile Model Driven Development (AMDD)”.

Please please please can we try to avoid such a thing as Agile 2.0? And who says that AUP and MSF Agile are Agile 2.0? what do we/you/they mean by Agile 2.0? I still am not sure AUP and MSF Agile are “Agile 1.0″…
[/rant]

Note: this post is longer than expected and is mainly about introducing and summarising the ideas that led me to wonder if there is a way to use the skills developed by using retrospectives (reflection on action) as a way to experiment while an event is still occurring (reflection in action).

Thanks to the work done by Norm Kerth retrospectives - a ritual held at the end of a project to learn from the experience and to plan changes for the next effort - are spreading nowadays in many different contexts and certainly in every Agile project that is really Agile. In time different types of retrospectives have been developed like project, heartbeat, alignment and incident (more info in the article Agile Project Retrospectives by Tim Mackinnon).

The first week of April I've been lucky enough to attend the Retrospective Facilitator Gathering 2006 in Germany and as often happens with events of this type those 5 days have helped me in reorganising some scattered thoughts I have on the subject and after more than a month I'm able to (start) write them down.

First of all why do I value retrospectives? Many different reasons but mainly because they let's you:

• learn from experience
• bridge the gap between theory and practice
• cope with ambiguity and change
• develop a critical awareness

Reflecting is something that we all do and Piaget found that this is one of the advanced skills adolescents develop as they approach adulthood. In fact I like to think that when professionals/teams/organisations move towards their adulthood they start to develop, value and apply a reflective approach to improve and grow. Or, to put it in another way, if they don't do it they still haven't turn the tipping point of maturity.

Learn from experience

Reflecting on experience provides the basis for forming more abstract ideas which can then be applied and tested in further experience. It enables us recognise new opportunities and learn from them.

Bridge the gap between theory and practice

As everyone has experienced in his life studying something doesn't necessarily means being able to apply it. We need to know how to apply the knowledge to real problems. Reflecting help us to identify how best to apply in practice what we know in theory.

Cope with ambiguity and change

Reflecting is essential in recognising the uncertainty we face in the modern world where the demand for fast and reliable results often increases stress and workload. This is particularly true in an Agile environment in which we tend to work closely with our customers and often have to cope with new and unique problems never met before.

Develop a critical awareness

We usually reflect both on our own behaviour, the behaviour of others and on the social/organisational context. This leads us to develop self-awareness and to become aware of things we need to change. Reflecting is then a key point for improvement and is far from being an innocuous process because it challenges the status quo, the way things are done.

Donald Schön began his research on reflection to challenge the predominant technical rationality which suggests that problems can be solved following a set of rules learnt during education. The result is a huge stress because we are seen as experts only because 'we are presumed to know, and must claim to do so' regardless our own uncertainty.

In reality the problems we face are often composed by a unique set of circumstances and the result is that the uncertainties as well as our knowledge of the other people involved are both relevant to solving the problems. Feelings, intuitions and critical thinking therefore play an active role and cannot be reduced to a set of rules learnt during formal education.

When we critically analyse our work we do it through reflection and this is when, in my experience, the tension between assimilation and accomodation happen.

In fact we may reflect in action (during an activity) or on action (after the event has been completed). In his book The Reflective Practitioner Schön analises how reflection is used by professionals to tackle the problems they face in their work and concludes that when faced with a new problem they become 'researchers in the practice context' conducting real world experiments.

He calls this approach reflection in action because the behaviour is an experiment itself. The general pattern recalls the scientific enquiry in which the professional experiences feelings and maybe anxiety that something is wrong, something is new and unique, never encountered before. A critical reflection then happens and he is ready to challenge his assumptions. At the end he may reframe the situation and come up with a new hypothesis and test it out.

It is also possible to develop the reflection skill after an event and Schön calls this reflection on action. This process is usually facilitated by another person. Retrospectives are then reflection on action and I wonder how we can use them to develop the reflective skill up to the point in which we can move from reflection on action to reflection in action.