People vs. process

September 23rd, 2007

This week I got a notification that our proposal for an interactive presentation called People vs. Process: Cultural Patterns of Software Organizations has been accepted for both XP Days Benelux (15 and 16 November) and XP Day London (19 and 20 November). I’ll run this session together with Willem.

In this session, we are going to present different cultural patterns of software organizations, as described by Jerry Weinberg in his 4-volume Quality Software Management series. We’ve found this model of cultural patterns useful as a tool to understand IT organizations and to know where and how we can intervene effectively. The model gives a fresh perspective on software organizations, with a people oriented instead of process oriented view. It focuses on subculture and people’s behaviour.

During the next few weeks, I’ll write a number of blog entries about these cultural patterns. If you want to read ahead, here are a few links about the patterns:

Piecemeal Growth

September 16th, 2007

I’ve decided to leave PricewaterhouseCoopers by November 1st and become a full time in(ter)dependent coach/trainer/consultant.

Through my company Piecemeal Growth, I can help you to get a better grip on your projects, to improve project cycle time, to reduce the number of defects, and to make your IT more nimble and able to cope with continuous change. I have a background in agile and lean software development, systems thinking, organizational learning, and (open space) facilitation.

Some of the services I offer are:

  • workshops that will give you a taste of e.g. agile development or systems thinking, to find out how you can benefit from it;
  • training and mentoring individuals and teams, both in technical skills (like refactoring and automated testing) and in the area of processes and project management; I can e.g. coach teams in adopting a cycle of reflection and continuous improvement through frequent retrospectives;
  • training and mentoring teams that would like to work and think in an agile or lean way;
  • coaching and training agile coaches, agile project leaders, and Scrum masters to become effective change artists;
  • facilitating Open Space and World Café sessions addressing the issues that really matter to you and your organization;
  • facilitating peer supervision groups, to increase the learning capability of your organization.

If you’re interested in getting better results faster, by focusing on doing what really works instead of what others say you ought to do, feel free to contact me. I’m also available if you need a sparring partner.

Keep on failing (in the small…)

September 14th, 2007

In How to Destroy your Company by Implementing Packages or Oursourcing, Hans Konstapel writes about his experiences with large, failing IT projects, in particular package and outsourcing implementations, and how lots of time, effort, and money is wasted on such projects. An excerpt:

Do you now understand why there is such a shortage in IT specialist? About 30% of IT-projects is succesfull. This means that 70% of the IT-specialists are working for nothing. If we add the amount of “succesfull” projects that were delivered too late or the amount of projects were the implementation phase took so long because the software was “not-usable” the percentage is even lower.

(…)

Adapt what is working as long as possible.

A team of 15 people is capable of doing more than a team of 1000.

Perhaps this is the key to solving the current shortage of IT people:? Just let everyone work on the 30% successful projects and don’t do the unsuccessful 70% - shortage problem solved ;-)

It’s not as simple as this. First, although there are lots of practices, principles, and processes (e.g. from the field of agile software development) that increase the chances of success, we often can’t predict whether a project will be successful. Predictable projects are not interesting, not in a strategic sense. If it’s predictable, there’s probably someone who has already done it or even created a product or service for it. Most interesting, strategic IT projects are in the complex space, where cause and effect are only coherent in retrospect and do not repeat. Best practices, recipes and step-by-step methods don’t work here. You need to steer based on feedback instead, through a cycle of probe, sense, respond (or apply-inspect-adapt in agile terms*)

Second, we need failures to learn from, especially if we’re in the complex space. But we do not need multi-million, multi-year failures. Instead, get early feedback by releasing early and often; fail fast, fail often, reflect and learn through retrospectives, apply the principle of poka yoke (mistake-proofing), and try again. Don’t hide your failures, celebrate them! (by avoiding bet-your-company ventures, you will actually get the opportunity to celebrate your failures…) Failures help you explore the space you’re operating in.

* The phrase apply-inspect-adapt was coined by Joseph Pelrine, as an improved variant of the well known Scrum phrase inspect and adapt.

We’re in this together

September 9th, 2007

Willem has written a nice blog entry about eXtreme Customer Collaboration - about getting into the skin of the customer and operating as a whole team. We’ve had some discussions lately about the different roles in e.g. Scrum and the effect that these roles have on teams. Scrum and Extreme Programming distinguish explicit roles for the customer/product owner and developers/rest of the team. This distinction helps to think explicitly about how to fulfill certain important responsibilities in a project. The pitfall here is taking it too far, so that people start focusing on their own defined role only and state things like “that’s not my responsibility”. The team slips into an us vs. them mentality.

Remember, as team members, you’re all in the same venture, whether you’re a product owner, developer, tester, project leader, or Scrum master. You’re all in the same ship and if it sinks, you’ll all go down together; finger pointing and saying “it’s his fault!” doesn’t help you a bit… In Holland we have a saying “samen uit, samen thuis”, meaning we’re in this together - if you start something together, you also finish it together.

Listen for phrases like “that’s not my responsibility”, “that’s her job, not mine”, or “we’ve implemented it as specified, it’s not our problem the customer isn’t satisfied”. If you encounter this, you might want to check the team’s shared vision. If there is no shared vision, (re)establish it as soon as possible and make sure the team owns it. Explicitly share your goals as team members - everyone has his or her personal goals and the project’s goal should be in the intersection of all the stakeholder goals and interests - if you find out it’s not, you have a different problem to work on - more about that in a future blog entry.

Physical distance between the product owner and the rest of the team also reinforces the us vs them thinking, e.g. if you’re a few doors away, in the other building, or even on other side of the country. Get the team physically close to each other; rearrange the furniture and walls, try to co-locate everyone if possible. If it’s not possible, get everyone on site together at least part of the time, e.g. 1 day per week. The overhead incurred is worth the productivity gain.

The roles as defined in Scrum and Extreme Programming (and in many other process models) are ‘just’ tools: they help you in getting your processes going. They’re not carved in stone, so make sure the roles won’t become a goal in itself. Keep trying, inspecting and adapting; and remember that you’re all in this together.

CITCON Europe 2007

September 4th, 2007

In October, I’ll participate in the CITCON Europe 2007 conference in Brussels. It’s a 1 1/2 day Open Space conference on continuous integration and testing. It will take place on Friday 19 October (starting in the evening) and Saturday 20 October, and it’s free! It’s part of a world wide series of Open Space conferences on continuous integration and testing.

This will be my first CITCON. I’ve heard positive things about previous ones, I’m looking forward to it.

See you in Brussels in October!

April 27th, 2007

People have been asking Willem and me for some time now when we were going to organise the next Agile Open conference. We finally got around to it - it is going to happen this summer, on 11 and 12 June.

This will be the third Agile Open conference in Europe. It is a peer to peer conference aimed at agile practitioners and will be run according to Open Space principles, where you co-create the conference while it happens.

We have found a really nice location in the center of The Netherlands, the middle of the woods. The conference fee is 215 euro (excl. 19% VAT) which includes 2 days of conference, all catering, and on site bed & breakfast. We have only 30 places available and we can guarantee an on site hotel room if you register before May 15th.

The day before the conference, we are going to run a small scale Open Space on Open Space workshop. We’ll use this workshop to prepare for hosting the conference and to improve our facilitation skills. If you like, you can also join us for this workshop. The number of places for this workshop is very limited, so be quick to register!