Regular heart beat retrospectives are a useful tool for measuring how well the team is going. As someone responsible for project delivery, you want to maximise the amount of honest feedback you get (both positive or negative) as they all might pose risk to the project.

The amount of feedback you actually get is a useful indicator rating the team’s comfort level – either with each other, or with other people they report to. I’ve seen a number of feedback sessions stifled by one or two key people that sit inside the room, as people withhold their opinions for fear of negative consequences. Controlling people typically disengage individuals from the team and reduce the effectiveness of feedback you get. Uncomfortable silence or a minimal set of feedback are both signs that people may not be entirely comfortable.

Splitting the group into smaller teams might help to improve individual’s openness, introducing a speaking token so that one person is not always talking or even asking someone to leave is a last option.

The feedback I’ve most recently received on my latest project is how fun it has been. This enjoyment factor is common feedback I get when working on projects with agile values and practices. I do not think this theme is exclusive to agile projects but I definitely think it is more common.

I believe that projects run in this manner are a result of the Agile Manifesto statement of ‘Individuals and interactions over processes and tools’. A result of working closely together and striving for a common goal breaks down the focus on the individual and succeeds in building a fully functional team.

Why you should care as a Project Manager or as a Business Person?

Enjoying your work has a number of effects on the way that you work. I believe studies have disproved that happiness positively impacts productivity, but I believe that in the long term it still has a positive effect. More importantly I believe studies have proved that happiness positively affects staff retention.

If anything, my own opinions are that it works to reduce the overall risk of the project as each person builds on each other’s strengths and contributes positively when someone is at the low in their peaks and troughs. The similar alignment between all team members also leads to people improving the project in different ways because they want the project to succeed and not just because of individual motivations.

Note that working in this manner is not necessarily comfortable for all people but it’s usually because people have built up their own social barriers in order to work effectively in more traditional environments, or they don’t like working in teams.

Final day. More highlights include:

• Entertaining keynote with Kent Beck talking about what is more Extreme than XP, and leading on to the discussion about the Responsible Developer. Like XP, his talk focused more on the developer role in an organisation but talked about what comes next.
• A fun two-part workshop with Rachel Davies and David Hussman talking about Agile Project Parameters where we brainstormed and dicussed the questions we might ask as an agile coach during a Project Chartering session.

I’ve been having troubles posting things to my blog due to Internet access here, but this entry was written just after Sweden and England drew in the world cup (equivalent of midnight here in Finland), so here’s the recap of today’s goings on:

• Barry Boehm’s keynote – An interesting discussion in which he discussed different analysis models that could still be used in agile, considering risk management and balancing agility and discipline. He talked about the scaling of agile to scrum of scrums and research indicating where agile is most applicable.
• Panel of Notable Agile Leaders including (Angela Martin, Rachel Davies, Jutta Eckstein, David Hussman, Emmanuel Gaillot, Mary Poppendieck and Michael Feathers) holding a fantastic discussion on Politics and Religion in Agile Development. A lot of the advice they gave and their own ‘war stories’ struck a chord with me so much in my experiences and different projects I’ve worked on. It was great for them to all be so honest and give their opinions. Kudos to Angela for being an excellent moderator for the session!
• Value Stream Mapping – An excellent exercise with Mary Poppendieck, involving identifying waste in an entire value chain (i.e. when a customer requests a features and they are using it), and more interestingly the strategies or areas of focus for particular project examples.
• Coder’s Dojo – Coming half way through this session, I still had lots of fun with this hands of workshop presented by Christophe Thibaut and Emmanuel Gaillot. We did a bit of dynamic language group pairing adhering to a small set of well defined rules that I found fascinating from many different perspectives, most especially the social one.
• Final keynote by Jack Jarvik discussing methods he applied in the early 1990s that appear aligned or similar to many of the XP/Scrum practices.

What can I say, but what another fantastic day?

I’m keeping this brief since I don’t have time to write more and want to keep a track of significant things came up today.

• Pekka Himanen presented the keynote, The Hacker Ethic discussing environmental issues and attitudes that make up, not what I interpret as just a hacker, but someone who is passionate about their work and the things that can help sustain or maintain their energy levels. Things like building up a sense of community and trust certainly help.
• I was a little disappointed with Agile Development with Domain Specific Languages, in that it was fairly tool centric – with MS DSL tools for Visual Studio and Metacase. We had some post discussion had about whether or not a meta model was actually needed for a domain specific language (i.e. do you need to validate the language the user is using, or just trust that they are doing the right thing).
• Open space sessions – I think trialled for the first time in the European series of XP conferences, were extremely popular with well over fifteen dynamic sessions planned. I actually just got back from attending one scheduled for 10pm back in the hotel, throwing about DSLs vs FIT and which one was better.
• My presentation on building Agile GUIs went quite well – got some great feedback and helped some other developers writing client side applications to validate or assert the things they were doing.

I got some great feedback in that, yes, the acceptance tests I used as an example could be written in a script-friendly manner (with a few new tools such as JUseCase and Exactor), but there was nothing that would stop me from refactoring to FIT or any of these other frameworks. The focus of my presentation was not focused on how you write acceptance tests (since people like FIT have already addressed this), but rather how you go about building up the different components, and Acceptance Tests spawning additional unit and unit integration tests to get the Acceptance Test passing. It looks completely different from any normal Swing code you would ever see tutorials for.

• Great meeting with lots of people in the industry and lots of people you have read, but were great meeting. The workshop with Mary and Tom Poppendieck on the weekend was great, but now I’ve also met heaps of other interesting people such as Charlie Poole, JB Rainsberger, Mike Hill, Mike Feathers, Erik Lundh, David Hussman, and Jutta Eckstein just to name a few.
• The final keynote of the day was interesting about how, five or six years down the track, how successful has the agile movement been and where do we go from here. It was presented by Sean Hanly, who works for the main sponsor of this year’s conference and I think he put it together fairly well. Paraphrasing him, how do we keep the heart and principles behind agile as it continues to be used and ‘abused’ so that it doesn’t end up on the same process graveyard many other processes have been.

Whoops, I said I’d keep it short, but oh well…

Being on new projects brings lots of new opportunities for learning, especially when dealing with lots of new people. I consider myself one of the more experienced agilists on our current project and I realise that the way I am used to working on projects will be fundamentally different from one that hasn’t had my experience. I like things to be fast, dynamic, self-empowered and interesting but this isn’t always the case for everyone.

As I further refine my skills as an agile coach I like to approach projects with an observe-advise-implement mantra all based on developing trust and getting the most effective results for the project, team and business. It’s all a very tricky balance to maintain as often these goals are not aligned with each other.

One of the benefits of being fresh on a project is that you can bring a different perspective and suggest improvements to parts that others may have already developed a thick skin towards. One of the things that, as a new person, have to change is the way in which you worked on previous projects.

I heavily disagree with evangelists that need to apply the same practices on their current project simply because it worked on their previous project. As a change agent to a project, you want to avoid changing things simply because it’s not the way that you’re used to working. Applying the same practices from previous projects may never work because you are dealing with different people with different skills and strengths.

A better approach is to highlight any weaknesses or inefficiencies you might see incrementally and suggest alternative practices that might work better since there might be a plethora of them to choose from. You want to get as much of the team involved as possible with making a decision since people resent having change forcibly thrust upon them.

As a process coach, you need to respect that everyone has different abilities to cope with change and like with most good things, introduce them incrementally.