At XPDay Benelux we talked about how the traditional conference format squeezes conversations out into the hallways and how great it would be to have an OpenSpace conference dedicated to agile software development. The Agile Systems group have just announced registration for Agile Open.
I am looking forward to attending, for details see invite below:
The Agile Open conference is an international Open Space conference intended for software development and business people from all walks of life, taking place on 29 and 30 April 2005, in Mechelen, Belgium ... we invite you to an amazingly open, warm and lively community space where people spark new insights in and relationships for collaborative (software) development and doing business together.
Agile Open is for participants, by participants: we determine the actual program together at the start of the conference. We do not expect people to invent all the sessions on the spot, so we encourage you to put ideas for sessions on the conference wiki. Any ideas for sessions you would like to experience, or hear and see happen, as well as ideas for sessions you would like to organize and facilitate are welcome.
The conference will take place at Elewijt Center, in Mechelen (Belgium). We have limited the number of participants to 60, on a first paid, first served basis. Until April 8th, the conference fee is € 180 (exclusive of 21% VAT); from April 9th, the fee is € 230 (excl. VAT). The fee includes conference access, lunches, drinks, one dinner, and closing reception.
Click here to reach the Registration page.
Here's a technique that I encourage you to try as a team exercise. Imagine yourselves in the future and look back, what do you see? You can use this simple technique towards various ends.
At the Agile Development conference last year, Luke Hohmann presented some techniques that can be used to better understand what your customer really wants. One of these was "Remember the Future", where you ask your customer to imagine that they have been using your product for a couple of weeks and are now looking back to describe the benefits. Then you ask your customer to describe each of these benefits starting with the words "I remember when..". You will be surprised how this reveals some interesting new stories that did not get mentioned before.
In "Sources of Power" by Gary Klein (a book about how we make decisions), a crystal ball gazing technique is recommended to help develop critical thinking skills so that we become more sensitive to alternative interpretations of a situation. Simply imagine different ways your current plan has failed and explain why. These techniques can also help you and your organsation be better prepared for changed futures. In "The Art of the Long View" Peter Schwartz encourages us to use scenario planning to create 'myths of the future' that can get conversations started about how future changes in the world could impact our organisation.
A topic often neglected by agile teams is risk management. It's true that an iterative approach does go a long way towards mitigating risks early. The additional small investment of holding a risk brainstorming session with the team at the project start may pay for itself in time saved later. If they have thought about risks and their indicators then the team will be better prepared to recognise them when symptoms first appear rather than when they are ravaging your project. In their book "Waltzing with Bears", Tom DeMarco and Tim Lister also suggest an imaginary crystal ball can be used when brainstorming catastrophic outcomes. Working backwards, we can develop scenarios that might lead to these catastrophes and thus reveal the root causes that are our present risks.
Then there's the classic interview question, "Where do you see yourself in five years time?". Perhaps you tend to go with the flow or maybe you have a clear vision of what you want to be doing. It's likely that what ever state your plans are in now they will evolve and change along the way but imagining yourself looking back from the future may help you become better attuned to relevant opportunities as they arise.
We do not live in a simple deterministic world where we can assume a controlling stance. In software development, we are working within deeply complex systems. We need to learn to keep our eyes open for clues that tell us our assumptions may no longer be valid. After all, the XP motto is Embrace Change.
Those of you who do not subscribe to the scrum development list will have missed Ken Schwaber's response to the manager's Declaration of Interdependence (see my blog entry 3rd Feb). Ken's full post can be read here, I have quoted selectively from his post below:
'I think the project manager title is dead'..'The team is responsible for managing itself. The “declaration of independence” bestows all sorts of responsibilities on a project manager that they don’t have the authority or leverage to make happen.'..'I see the project manager becoming a change agent, someone who knows how software can be developed in an Agile manner and who teaches, coaches, mentors the customers and teams to do so. A coach, a facilitator, a leader … without authority.' ..'we aren’t building a new profession of “agile project managers” that will “do” project the right way, but we are removing an artifact that was only necessary because of the totally dysfunctional way that projects were formulated and set in motion.'
I have to say agree with much of this. Although the PM title is certainly not dead yet and there is a growing number of writings on agile and extreme project management. If we are of the opinion that traditional software development approaches do not work then why assume all traditional roles are simply transposed for agile projects. For agile software development to be successful, we may need to reconsider what roles are actually needed in an agile organization.
All too often I encounter teams with a proliferation of managers - in addition to the Project Manager, an Iteration Manager, Build Manager and QA Manager are installed. This smells to me of projects that are too large and organizations that do not appreciate that agile software development is about delivering value to customers in small chunks.
A traditional project manager wants to remove distractions from the developers so that they can get on with the specialized task of writing code but a risk inherent in this is that developers get left out of important conversations and lose touch with business realities. I know several project managers who really appreciate an iterative approach to development and love working with agile teams. However, in my experience, they struggle with redefining their role in relation to a self-organizing team. They know that they ought to let go of the reins but the trouble is that they have a strong reflex to get busy and control the action, unfortunately this can deter project team members from taking on responsibility and feeling empowered.
The values stated in the Declaration of Interdependence are fine and worthy - if these lead to new ways to run projects that will be interesting. Right now I share Ken's concern that this declaration is about reinforcing the role of the manager and this is at odds with establishing self-organising teams. I may well be wrong so let's wait to see what this grows into.
I just finished reading Working Effectively with Legacy Code by Michael Feathers, creator of CppUnitLite. The book is very readable, full of code examples of techniques that you can use on your own projects and I heartily recommend it.
Some cool quotes from the book:
* Remember, code is your house and you have to live in it,
* Programming is the art of doing one thing at a time,
* Encapsulation isn't an end in itself, it's a tool for understanding,
* One of the worst mistakes a team can make is to feel that the design is over at some point in the development.
It's a sad fact but without loving care our software designs can decay rapidly into a sprawling mess that is hard to understand and scary to change. All programmers encounter legacy code at some time and this book equips you with some tools to understand what complex code does and how to get it safely under test.
The book explains how to use "Effect sketches" to visualize dependencies that can then help you find "pinch points" - natural encapsulation boundaries - where you can start to inject tests. A catalog of dependency-breaking techniques are given with code examples and solutions for several testing gotchas - such as "The Case of the Irritating Global Dependency". And then you get to find out about Naked CRC...
An alternative way to develop a retrospective time line is to create a metaphorical map of your project journey.
This is quite simple to do. Start by listing a basic timeline of events. Now reflect on these events. Try to find a metaphorical picture to represent the obstacles and terrain. Maybe the experience was like traveling through a swamp, dark forest or tropical seas. For each landmark draw a representative cartoon on an index card and give it a fantasy name. Lay the cards out to show the path you took (you can stick them to backing paper to preserve your map). Now take a step back. For each obstacle try to find a lesson learned that helped you get through it and capture each of these as a map legend.
This technique was presented to the 2004 Retrospective Facilitators Gathering by Ainsley Nies, HP. She has used FractalMapper software to redraw these maps which become team artifacts recording their journey. One team she worked with took this a step further and create a ships log that they used to record significant events as they happened.
A simpler technique is to ask each team member to draw a metaphorical picture of their personal project experience on a plain index card. Creating a gallery of these pictures can be a powerful way to communicate the experience of the team. This is a similar technique to Peter Checkland's rich-pictures.
When we draw we use our right brain and express ourselves in a different way to speech. The techniques described may sound weird but I encourage you to try them for yourself, you may be surprised by the insights they reveal.
I have a couple of photos that show a map and gallery (right at the bottom of the page).
Reflection is a key step in refining our development process, without stepping back and reflecting on our experience we do not learn from it. Retrospectives are team reflection sessions that are held to uncover lessons learned. A heartbeat retrospective is the name for an interim retrospective held regularly within an iterative development cycle. This type of retrospective requires a different format to Project Retrospectives because the period that the team is reflecting on is very short - from as little as a week to a month.
I have facilitated heartbeat retrospectives for teams for one and two week development cycles and they can be facilitated effectively in as little time as one hour. My experience is that teething problems with using a new development method are normally resolved in the first few iterations and so as these trail off heartbeat retrospectives can be spaced out to a half day session once a month. For teams who hold heartbeat retrospectives I also recommend a milestone retrospective every three to six months that takes a wider organizational perspective and uses different timeline techniques.
The Whole Team should be invited - programmers, customer and project manager. The facilitator should make sure that everyone gets a chance to raise their concerns. Each member of the project team has different experience and when we share these perspectives we understand each other better and the team operates more smoothly. It is very easy for the programmers to think everything is running smoothly without realizing that they are causing problems downstream for other project team members.
Project retrospectives are normally held off-site but this is not usually practical for a one hour meeting so for heartbeat retrospectives find a room away from the team workspace where there will be no interruptions. The only equipment you will need is a whiteboard and/or flipchart and a digital camera to record outputs.
Project retrospectives start with creating a safety. An agile team quickly gets used to the retrospective ritual because they are held so frequently and the rest of their development process has a high degree of collaboration - creating safety needs less emphasis. Ground rules should be agreed by the team in their first retrospective and reviewed at the beginning of each new session.
I have found it useful to have Norm Kerth's Prime Directive ["Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand"] pinned on the wall in the space where retrospectives are held and refer to the directive if the team starts to engage in blaming. Typically, problems arise from forces created in the system rather than destructive individuals. The focus in a retrospective is on what we can learn from what happened rather than attributing blame.
Creating a physical timeline in the retrospective helps the team remember what their experiences were during the reflection period. I find that an emotional seismograph on a white board is a quick way to get this established. The facilitator draws the axes, asks for significant events to mark on the horizontal axis and then invites the team members to each draw their emotional experience curve on the graph.
As a facilitator, I mine the timeline for gold by asking questions to draw out observations of 'What Went Well' and 'Not So Well'. I try to capture the key points on flips with these headings - always checking with the team that my wording fits for the person who made that point. Sometimes observations may be a symptom of a deeper problem - as a facilitator I try to dig deeper to the underlying cause. If I have been working with the team as an agile coach I sometimes want to share an observation myself - when doing so I make it clear that I am stepping outside my role as facilitator for a moment. Once tip that can avoid this situation is to get coaches to facilitate retrospectives for one another's teams.
As we work through the timeline the team may note an 'Action' or something that 'Puzzles' them. Again I note these on separate flips with these headings. Once we have reached the end of the timeline, I may ask about how their new practices stand-ups, planning game and pair programming are working for them. Now we move into Action Planning mode. We review what the points captures on the flips and identify actions that the team want to take, each action has an owner. Actions will be pinned up in the team workspace and reviewed in the daily standup meeting and again at the start of the next heartbeat retrospective.
You can see some of my photos of retrospective timelines, here. The maps are a nice technique to use for milestone retrospectives.