1. valuable software – a small piece of functionality that adds to the system ; not necessarily a complete feature, but not dependant upon any other story.
2. shippable software – software that can be released to the end-users; probably a combination of several pieces of valuable functionality.

While talking with a team recently it came up that completing an individual scenario wasn’t valuable as it couldn’t be delivered without the remaining system. For me, this seemed an alien concept and raised questions.

• Why are we producing this if it isn’t valuable?
• Can a user story have no value until it is part of a completed feature?

Can a simple scenario add value?

So, you are busy developing a new customer service system, working on a set of stories that allocate incoming calls to a service representative.

Taking the simplest case first: a call comes in and is allocated to the first representative found. Does this story have value? For me, yes it does. The simplest case gives you the basis from which every other scenario will hang off. Is it the most valuable scenario? Probably not, but it makes sense as the first one to tackle.

Valuable isn’t shippable, not always

So valuable software isn’t necessarily shippable in its own right. However, it is potentially shippable. The fact that it is an independent part, not requiring undeveloped functionality to work, means it could be shipped as part of the product. The end-user may not think the feature is complete but what they have works and provides some functionality they didn’t have before.

Cave jumping © wowblog

The first session I proposed at the Agile Coach Camp in Germany was on comfort zones; a topic close to my heart as I was in a foreign country, unable to speak the language, talking to a group of people I’d never met before. I may have been slightly outside of my comfort zone. Oh, and I’m not the biggest fan of talking in front of large groups, though that is more lack of practice than anything else.

Initially I wanted the conversation to flow from what comfort zones are through to how we could use this in coaching. Turns out what comfort zones are is a big area in itself.

What is a comfort zone?

The comfort zone is a behavioural state within which a person operates in an anxiety-neutral condition, using a limited set of behaviours to deliver a steady level of performance, usually without a sense of risk.

- From Comfort Zone to Performance Management by Alasdair White

Everyone knows what a comfort zone is to them, however the discussion showed that we have slightly differing understandings of the phrase. Throughout the conversation we had to revisit what we meant by comfort zone and see if it still held true. Occasionally we changed our minds slightly, but in general we agreed that it was a stress-free place, where we are normally at our happiest, for a given context.

An important point to note is that your comfort zone is your own, and while people or circumstance can strongly influence it, no one can change it but you.

One of the most interesting ideas that emerged, for me at least, was the idea that comfort zones are contextual. We accept a different level to risk, and show these differences in many ways, for the varied aspects of our lives: you may be very conservative about your work, but happy to jump out of perfectly good planes in your spare time.

Are you safe or just think you are?

While exploring our definition of the comfort zone it became clear that there is a space outside of the comfort zone where we are, while not comfortable, still within an acceptable level of discomfort: this we named our safety zone. While digging deeper into the idea of what a safety zone was yet another concept began to surface, the safe zone. This is where you are actually safe within the context of your comfort zone.

The language we were using seems difficult, and it was with the large group, but we didn’t want to stray far from our discussions to sort it out. I’m using the same language here as I haven’t as yet come across better terms.

An example may help explain the differences.

Do babies have safety zones?

When a baby is born it comes into this world defenceless and unaware of the dangers around it. Parents work hard to protect their baby from pretty much everything (at least for the first one). So, this baby learns to move about but has no concept that doing certain things can hurt them.

If you take our theoretical baby and place them on a table they are going to move about and explore. At some point they are going to get close to the edge and look over. Given no external influences or earlier experience, such as the parent jumping to grab them or having fallen off before, it won’t dawn on them that there exists the potential for them getting hurt.

Baby on table © jiva

Given they are no longer safe, are they in a state of raised anxiety? Probably not (whether you are is a different matter).

Are they safe? No.

Are they comfortable? Yes, nothing has influenced them enough to change their world view.

Comfort, safe and safety

While playing with these types of idea, it started to become clearer that while comfort, safe and safety zones are different concepts they have some commonality  between what can influence them, but differing greatly in the power those influences can exert.

• Comfort zones are internal, encompassing areas we regularly explore, influenced by strong or frequent exposure to different experiences.
• Safety zones are also internal, covering those areas we explore infrequently and are more easily influenced, both positive and negatively.
• Safe zones are external spaces: the environment, be that physical, cultural or other,  where you find yourself. How much you can influence them, if at all, is dependant on the situation.

In future posts  I intend to cover how these zone interact, what factors can affect these zones, how a coach can use an understanding of this to influence a situation and some of the ethical implications of doing so.

Oh, and please don’t leave babies unattended on table tops just to prove me wrong.

Most of the people who attended the session had questions as well, but each had different insights and we bounced ideas back and forth to see what we felt was best. The discussion centred around two main areas:

Planning the workshop content

1. Define the goal of the workshop: while no one disagreed that you need a goal, should you have more than one? The consensus seemed that you could have multiple non-conflicting goals within the workshop, either acting as way-markers to a final goal or to cater for different types of stakeholders.
2. Prepare an opening/introduction: similar to how you’d set the scene in a retrospective you should introduce the workshop, and yourself, to everybody.
3. Set the mindset: to change how people are thinking and move them into a more productive mindset you should run a quick game or simulation to break them out of their normal thought processes.
4. Focus on the topic: plan on using one, or maybe more, of the normal methods to gather data and experiences and focus the work-shoppers on the task at hand.
5. Play it by ear: at this point there were several ideas: either plan as normal, or just run with it. I prefer a compromise between the two camps, and will have ready at least one quick and one normal technique to generate new insights, accepting that the results from the data gathering may not fit either and I’ll have to use something else from the play book.
6. Have a closing ready: even if you run the workshop on the fly you should still have an idea of how to close the session, ensuring people are able to take actions or ideas away from the workshop.

An agenda will really help everyone to know where they are in the workshop and if they’ve gone off track, so putting a quick one together and ensuring everyone can see it might be a good idea too.

Planning the workshop experience

An area that may easily be over-looked is the environment where you are running a workshop: it doesn’t matter if the content is great, if the people can’t concentrate they’ll never find out. The main points to consider are:

1. Location: where is the workshop being run? is there sunlight? next to a busy corridor? is the room appealing, or at least not falling apart?
2. Layout: do you have a big table but want to run small group work?
3. Catering: is it a long workshop? do you need water/coffee? maybe lunch?
4. Materials: do you have enough paper, pens, flip-charts, sticky notes?
5. Breaks: anything over 90 minutes needs to have a break, people just can’t stay interested that long. Rather than plan them in religiously, allow time for them and let them happen when the attendees want. Just remember to give a time for them to return - say “we’ll restart at 10:30″, rather than “we’ll break for 15 minutes”.

Before the Open Space session I was talking to Marc Löffler, Marc Bless and Rachel Davies about this and they all agreed: follow the same process as planning a retrospective. Pretty much what we came up with ourselves.

1. how to run a retrospective, and
2. activities to make the most of your time when running a retrospective.

The first section deals with how to run a retrospective. The book spends very little time on why you should run a retrospective, but this isn’t a bad thing; if you want to run them I hope you know why practitioners are so ardent about them. Starting with a conversation between a team and their facilitator the section continues in a chatty, informal way, regularly using stories and pictures to help convey their ideas. In particular, I like the tips dotted throughout the chapters highlighting things you can do to make your life easier and the retrospective run smoother.

The second part of the book gives activities for each stage of the retrospective. Each activity follows a standard template so you can flip through them quickly, looking for the one that fits best with your goals. Apart from the necessary steps to complete the exercise there are details such as materials needed, time required, possible variations and, something I find of great use, in what situations they are most useful. Similar to the first section , examples and pictures are liberally sprinkled throughout the exercises, showing how things can look before or after the exercise. These pictures help you to understand and layout the activity and reassure you that you are on the right track.

I can’t really fault the book, it does exactly what it says it does. It is fun, easy to read and follow, and acts as a great place to get ideas for retrospectives I run.

There was a real energy about the day that seemed to come from not only the calibre of the speakers stranded in the UK but also the very real passion and enthusiasm of everyone present. Topics were wide-ranging: covering coding, environmental factors learning models and more.I’m sure there’ll be blog posts and tweets appearing on each session and will appear on the blog soon, as such I’d rather focus on what thoughts and ideas I can take away from the conference and how they’ll impact my thinking.

Plain language

Throughout the day I heard acronyms and buzz words used with abandon, meanings were left to the audience to either know or track down. As a profession the IT world is littered with these, but do we really need to talk about the Dreyfus model or NLP*? Can we not talk about levels of competency and conscious use of language? That isn’t to say these things aren’t very relevant and bring great value to what we do, but we are a group of practitioners, not academics; refer back to your source but don’t assume that we’ll immediately know what you are on about.

If we want to bring more people into the agile fold we need to talk their language, not expect them to learn our language and those of half a dozen other fields that we are currently referring to and experimenting with.

What is Agile?

We just had a whole conference about Agile, but each person you talked to seemed to differ in opinion about what is was, based not only on experience but also what influential thinkers and blogs are talking about at the moment. I’m now more aware that my concept of Agile probably differs from yours. To me Agile is more a brand than a state you can reach, you are never going to “be” Agile.

The community is evolving everyday and even if you reach some quantifiable level of agility today, tomorrow the theory will have moved on. This thought has led me to reconsider “Agile adoption” – what is it and when has Agile been adopted? That is something I’ll definitely have to look further into.

Evolutionary community

During one session Chris Matts said that a “gap” in Agile was its lack of recognition as a learning community. If I understood his point, it falls back to the idea that we are a Community of Thinkers, from Liz Keogh, Jean Tabaka and others (one of which may have been Chris?). We, as a community, are progressive thinkers, we should push the boundaries of what we know and bringing other industries knowledge to the table and seeing how we can re-use that. Re-use is what we are good at, right?

While I agree with Chris I don’t believe it goes far enough, we are an evolutionary community using both experiential learning and study to constantly advance, or change, the boundaries of what we know. We aren’t only learning new things to deliver better software, we are using those same things to re-examine what we already do and improve how we improve the delivery of better software. For me the word evolutionary becomes an important part of how the community views itself, inspect and adapt is still a cornerstone of what we do – at all levels.

Is a learning community enough?

Following on from Chris’ thoughts about how we are a learning community, it hit me later (too late to run a OpenSpace, though I may bring it up at the CoachCamp in a week or so) that while a learning community is great, what we really need to foster is community that actively helps others to learn as well. That is not to say that mentoring and coaching doesn’t happen within the community, just that I don’t see it actively encouraged – many people I look up to and respect are readily approachable at conferences, but it’d take a whole different level of confidence to ask them if you could shadow their work.

Maybe I just live too far out in the sticks and it all happens in the bright lights of London, but I’d like to explore the possibilities further.

As ever, the best part of the conference were the coffee breaks.

* Both NLP and the Dreyfus model are the first examples that popped into my head, by no means were they the worst offenders I heard during the day.

Starting with a few twitter messages and no fixed home the conference captured many an agilist’s imagination either stuck in the UK or that have to live here. Demand for places was high even though there was nowhere for this to happen, but I’m guessing it’d be run in a pub if need be. Yesterday I was lucky enough to get a ticket and decided to skip work for the day. How often are you going to get Roy Osherove, Uncle Bob, Jeff Sutherland and many more in a room at one time? Well probably a few, but for free? Not something I was going to miss if I didn’t have to.

Towards the end of the day more tweets circulated, calling for ideas from those that couldn’t attend the conference – pretty nice of them I thought. It will all be recorded and there has been talk of streaming out to the world at large, so people can at least get some involvement and maybe interact through attendees they know.

A second theme I saw at around the same time was that it’d be nice if something big came from Open Volcano, something really groundbreaking. While a nice sentiment, and I hope somewhat tongue-in-cheek, I felt it at best missed an important achievement of the organisers in particular, but also the Agile community at large – a conference was set up in a single day: sponsors were found; a venue booked; and attendees gathered and registered. Talk about practicing what you preach!

I’m writing this on the train down to London, so we’ll see what a conference-in-a-day is like, but with the right people, which we’ll have, it’ll be a fantastic day, full of geeks talk about what they love.

The course did not seek to explain Agile techniques or methodologies, instead focusing on the people skills an effective coach needs. For me this was a real plus of the course, the group were all seasoned practitioners with a good understanding and we didn’t have to stop and make sure everyone knew what we were talking about – on the rare occasion that someone didn’t know they just asked for a quick explanation. I have taken many new ideas and skills from the course, some being:

ORID questions

• Objective – the facts about the experience or event.
• Reflective – how you felt about the experience.
• Interpretive – consider the meaning and value of the experience to the team.
• Decisional – decide on an action or response to the experience.

While I’ve not consciously used this questioning technique yet, I feel that it provides a good place to fall back to. If I’m ever unsure of how to carry on with a conversation I can fall back to working through the stages and end up with a useful, and relevant, decision.

Hackman model of coaching interventions

• Motivational – addressing effort.
• Consultative – addressing performance.
• Educational – addressing knowledge and skill.

This model raised my awareness of the decisions I make. During the course I pretty much always thought of a consultative approach to any problem first, but, using the Hackman model, when I stopped and thought further I found I could normally come up with at least three options, one in each group. These three options mean that I can make sure I not only have more than one way of approaching an issue, but each action is going to try to tackle the problem from a different angle.

Would I do this course again? Yes, and I’ll probably be looking for a more advanced version in the future to take my coaching skills to the next level.

As you would expect from the title this book deals with the coaching of agile teams; not only does it give sound practical advice on coaching a team through the software process, but also hints and tips on improving your own coaching ability and talks the about the frame of mind required for a good coach. However the book is not just for coaches: anyone working in an agile team will find lots of helpful information to increase their understanding of the process, and as the first book to deal with coaching in an agile setting specifically it couldn’t have come soon enough.

Contained within Agile Coaching is information that will be useful to not only someone new to the agile world but also old-hands, whether working in a coaching capacity or as a member of an agile team. The personal anecdotes make it easy see that the authors have already been through the pain and are allowing you to learn from their suffering and not experience it yourself. The structure of the book means it can not only be read cover to cover, which I have no doubt you will do, but will also act as a reference that you can dip in and out of as circumstance demands.

This is definitely a book I can see myself coming back to regularly.

I started to look for a way to highlight the impact of these decisions to the programme management and stakeholders.

Talking to a couple of team members one of the things we realized is that we don’t have a good idea of who the team talks to and the influences on, and impact of, changes and delays to the system.If we don’t, how can we expect the programme team and business?

We started to map these out on the whiteboard and produced a few relationship maps to show how the team interacted with different parts within the organization. While quite team-centric the first map we produced shows how the team fits into a system of relationships and the complexity involved in what many feel is a simple process. The diagram is a very basic model, but further information was felt to distract from the information we have tried to show.

The relationship map won’t solve our problems of vague requirements and volatile stakeholder commitment; the hope is that it will impart a little more information on how the team interacts with other and help to explain the impact of delaying decisions on the project. Another suggested potential use that is to help pin down external stakeholders that the team can contact with questions, leaving them to work with the wider business.