|
|
Summer in Toronto
 I enjoyed Toronto very much last year, when attending Agile 2008. It has all the attributes of a big, vibrant city but also quiet parks and lakeside where it’s easy to relax.
The most striking thing about the city is its people: they seem very relaxed and easy going, they take the time to enjoy life, they serve Belgian beer and they stop for red traffic lights. Toronto’s inhabitants come from all over the world. The city is one big melting pot where people from all sortsd of backgrounds live and work together. Of course, I’ve only seen the city in summer. I wonder what the city looks like in winter.
Agile in Toronto
This fall, on October 20th, the Toronto Agile community organises their first Agile Tour Toronto. An energetic group of organisers ensures that this will be a day of fun, learning and meeting other people interested in everything Agile. When Gino Marckx is involved you can be sure that it willl look good, be well tought-out and be enjoyable. Gino is also one of the organisers of XP Days Benelux. He’s clearly applying the lessons we learned organising the XP Days. It’s great to see ideas spread. I’m looking forward to the Agile Tour Toronto retrospective results, so that we can learn more.
Go to Toronto
I won’t be able to be there, unfortunately. But you can! Why not send in a proposal for a session? The deadline is September 10th, but if you send in your ideas now you will benefit from feedback to improve your proposal.
If your company wants to connect with the local Agile community, why not sponsor the event? You’ll reach the smartest IT people in the area.
Have fun in Toronto!
Agile Team Roles
Rob Bowley has picked up the Agile Roles and Responsibilities Portia and I described on the Agile Coach site.
I had several goals when we published these:
- Explain what’s expected of people as they join an Agile team
- Create a smoother transition from traditional roles into Agile roles
- To emphasize the importance of every Agile Team member implementing the Agile values
- To make it clear that the whole team works together to take up all the responsabilities we’ve listed
The role and responsibility descriptions are a starting point for your team to agree on responsibilities. Each team should customize the responsibilities to fit their changing circumstances. I’m sure we can improve the descriptions and explain the responsibilities better.
I am not my role! I’m a free man!
S: So, you’re a java developer.
P: I’m not a java developer.
S: I’m sorry, I thought you said you developed in java.
P: I currently develop in java. That doesn’t mean I AM a java developer. I keep my options open.
I now regret using the word ‘Role’. It is almost universally misused:
- People will identify with the roleand thereby limit themselves: “I am an X, so I can only do Y”
- People will identify with the role and thereby limit others: “I am an X, so I’m the only one who can do Y”
- Roles can lead to Silo Thinking: “It’s not my responsibility, it’s not my problem because it’s not my role”. This gets especially bad if the roles are equivalent to positions or even departments. Imagine the dysfunctions you could create if you had an Analyst department, a Development department and a Test department each trying to optimise their own little goals.
- Roles get tied to compensation and evaluation, so that every responsibility you take outside of your role is at best a waste of time and could well be detrimental to your career.
Because many people have had negative experiences with roles, they react negatively to those Agile roles. To me, roles are no more than convenient sets of responsibilities. The important thing is that we as team members take those responsibilities.
I’m just playing
I see roles as an actor sees them. Today, I play an Agile Coach. Tomorrow, I’ll play an Agile Project Manager. Yesterday I played Agile Business Analyst because we urgently needed to work out some User Stories.
Another metaphor is that roles are like programming interfaces. An interface means I can expect certain things of anyone implementing the interface. One object can implement many interfaces. An interface can be implemented through the collaboration of multiple objects.
A common misconception is that everyone on an Agile team must be able to play every role. We all play roles according to the need of the team AND our abilities (and interests). But the more people who can take on a role, the less chance there is of that role becoming a bottleneck. Multi-skilled teams can react quickly to changes in needs.
Which roles do you play? Which responsibilities do you take on? Do you get typecast?
Where would you rather work?
Would you rather be a member of a Cost Centre or of a Value Stream?
Even if you don’t know exactly what each term means, where would you rather work?
Which of the two would focus most on the customer?
Which of the two would be more open to Agile, Lean or continuous improvement?
Accounting matters. Not just for the numbers, but also for the words.
When was the last time you talked to your accountant or CFO?
I’m sorry, I can’t help you because the system is down
How many times have you heard this apology? Often, the apology is “The system is down again.” In some places the system is always down around certain times and you get the same apology every day.
Why are we suprised when systems are unavailable? There will be bugs, mistakes and scheduled downtime. We should not be suprised the system is down, we should expect it.
Some time ago, an IT architect asked me during a job interview if it was possible to build reliable systems out of unreliable parts. My response:
The only way to build a reliable system is to build it out of unreliable parts (or systems)
If you want to build a reliable system, you have to be aware that all its subsystems are unreliable. This allows you to take appropriate measures, like building in redundancy.
We need a paper process
A smart manager I once worked with insisted that every business-critical automated process also required a backup “Paper Process”. The Paper Process defined how the work would be done when (not if) IT systems were down, with nothing more complicated than pen and paper (and a battery-powered calculator if really needed). When systems were unavailable everybody knew what they had to do to keep the business ticking over as if nothing happened. They also knew how to catch up when the systems were available again. In this case, it was clear who the bottlenecks were, so the other people subordinated by entering the backlog of data on paper into the system. Did I mention that this department used less automation than other similar departments, yet had a better track record of delivering on time, was more efficient and brought in more money?
Defining an alternative Paper Process was relatively easy, because we really understood the real business requirements of our customer. Since then I use this as a test of my understanding of the real requirements: could I implement the requirements with nothing more than paper and pencil? If you have real requirements (and not a solution in disguise) it’s easy to define several different implementations.
Since that project I learned more about processes. If I had to do this project again I would do it the other way round: implement the Paper Process first and ask what, if anything, we would need if the Paper Process broke down. Maybe a whiteboard is enough.
Business Value Game v2.0 released
Continuous improvement, feedback and collaboration at work: the Business Value Game has been updated. Lots of people who played or organised the simulation have given us plenty of ideas for improvement. We’ve held retrospectives after each run. Laurent Morisseau has helped us to translate the game into French.
The result: Business Value Game v2.0 is now available in English and French.
What’s changed?
- There are now more projects at the end of the game with new challenges
- The Accountant’s job has been simplified by making the score sheet clearer
- There are more opportunities for process and technical improvements
- Reduced fluctuation in development team velocity as some players felt that “luck” had more effect than sound strategy
- The Development Team and the Accountant now also have pictures, thanks to Janina Köppel’s South Park Studio
- All playing elements have been translated into French. The session leader manual is only available in English
If you want to help translate the game into another language or if you have ideas for improvement, let us know.
What hasn’t changed?
 The Business Value Game is still a fun way to start a conversation about business value, prioritisation, working with stakeholders and company values.
The Business Value Game still has a Creative Commons license and we encourage you to download it, use it and reuse it.
Next Stop, Chicago
 Portia and I will present the Business Value Game at the Agile 2009 conference in Chicago.
We’ll play the game on Wednesday August 26th at 16:00. In the morning we’ll play the Bottleneck Game to experiment with Theory of Constraints, Lean, Agile and Real Options. Come and play with us!
 The Business Value Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.
|
I enjoyed Toronto very much last year, when attending Agile 2008. It has all the attributes of a big, vibrant city but also quiet parks and lakeside where it’s easy to relax.