Jurgen interviewed me via email, 5 Easy Questions for Johanna Rothman. The questions were not easy!
Subscriptions
- Dale Emery (feed)
- Don Gray (feed)
- Duncan Pierce (feed)
- Emmanuel Gaillot (feed)
- Esther Derby (feed)
- Johanna Rothman (feed)
- Laurent Bossavit (feed)
- Marc Evers (feed)
- Nynke Etk Fokma (feed)
- Pascal Van Cauwenberghe (feed)
- Rachel Davies (feed)
- Tim Bacon (feed)
- Willem van den Ende (feed)
Last updated:
July 23, 2008 07:45 PM
All times are UTC.
Syndicate:
OPML RSS 1.0 RSS 2.0
foafroll
Powered by:
July 22, 2008
Jurgen’s Interview with Me
July 16, 2008
Why Everyone Needs to Manage Their Own Project Portfolio
John Cook wrote a blog post, Scaling the number of projects, that starts addressing the issue of why it’s everyone’s job to manage their own project portfolios. Here’s an example of the problem he’s noticed:
It sounds easy to manage independent projects: if the projects are for different clients and they have different developers, just let each one go their own way. But there are two problems. One is a single developer maintaining an accumulation of his or her own projects, and the other is the ability (or more important, the inability) of peers to maintain each other’s projects.
I’ve seen this in IT organizations, where one or two developers work on a “small” product, which, of course needs “maintenance” (more features, some problems fixed, more documentation, whatever). Since that developer wrote it originally, somehow that project is supposed to stay with the developer forever. (That’s a bad idea.)
I’ve seen this in product organizations, where even if it’s a larger team, once you’ve put your hands on the serial driver, or the engine to drive the application, or the version control system, or any other piece of a product or infrastructure, you couldn’t get rid of it no matter what you do.
Developers (and testers and writers) need to let go of old work. Their managers need to stop assigning everything that smells like that old thing to those specific developers, and add in the new requests to the entire project portfolio.
The interesting question is: Why does this happen? Why are people stuck with these old projects and legacy work (not in a negative legacy way, just that they’ve always been assigned to it and it looks like they always will be)?
Because the work is invisible. No one realizes all the little pieces of work. You’ve got to make that visible, and I like to make it visible in a portfolio.
One way to do that is to start collecting all the work you’re supposed to do. (I’ll address a product’s backlog at some other time). Here’s a template to start you off. I like to put this table on a whiteboard or a flip chart. If you must, use a spreadsheet, but please, not the first time. You will be moving stickies around.
Here’s how you collect all the work. Make a yellow sticky of all the work you are supposed to do. If you are working on a project for several weeks, make a sticky for that project for each week. Put all the stickies in the appropriate week, above the unstaffed work line. Just get them all in.
Now, be honest with yourself and put the work you can’t do in a given week into the unstaffed work row. Now you have something to discuss with your manager or your customers. (I’ll talk you through how to do this in my next podcast, which is already recorded, but not posted.)
If you receive a lot of little requests for products you can’t get rid of, you can create a product backlog for each product, or a product backlog for your time. (You either fix the requests by product, or fix your time and allow your customers to negotiate among themselves for what you do first. Sorry this is rough, but I haven’t written enough about this before to be articulate yet without gesturing with my hands.)
The key is for everyone to know what they are working on for a short while, and what their personal backlog is. That’s why I only ever plan for 4 weeks at a time. If you’re working in shorter timeboxes, plan for the shorter iteration. But using the portfolio like this allows you to do some rolling wave planning for your work as a whole, especially when you have lots of pieces of work to do.
July 15, 2008
Podcast Posted
July 13, 2008
Agile FAQ and MTA
A fellow agile coach told me recently about his project to write the Ultimate Agile FAQ list - solutions to problems people recurrently have when installing agility somewhere. There were sparkles in his eyes. My reaction may have been harsh.
I've started wondering why we feel compelled to write FAQs about agility when the Most Typical Answers are always the same - "Yes, it's important," "It doesn't matter (as long as you do it one way or another)," "Trust your judgement" and "It depends."
"Yes, it's important."
Typical answer to questions like "do I really have to write tests before production code?" or "I don't like pair-programming, do I still have to do it?" Don't get fooled. These aren't real questions - someone is just asking for permission to do something the easy way without having to face consequences (remember - "Mommy, do I really have to wash my hands ?"). You may decide the person is wise enough to understand the "right" (?) answer - I'm not going to tell you which it is - but were the person wise enough, they wouldn't ask the question in the first place. They'd try and experiment not following a practice to see how it goes, and would accept to rock the boat on their behalf. So be patient, smile and remain firm. Yes, it's important to write tests before production code. Do it.
"It doesn't matter (as long as you do it one way or another)."
Typical answer to questions like "What tool should I use to track progress - Excel or Marker&Paper?" Yes, I know, you have your own preference and I have mine. Face it, though. It's not about how you (or I) would do it, but how they will. I find it's more efficient to leave to the doer the responsibility of chosing the tools work best for them. It engages them toward action instead of submission - or rebellion. More important than your relationship with them is their relationship with their work. So take a deep breath, stop (believing you have the power of) controlling others, trust them and nurture them. What's important is to track progress. The way the tracker prefers doing it is important too, and it's up to them to choose.
"Trust your judgement."
Typical answer to questions like "On what practice should I focus for now?" or "What techniques do I need most beside agility?" Typical answer could be "all of them" or "it doesn't matter" but that's not what the person's ready to hear, really. Again, it isn't so much a question than an attempt to delegate you the responsibility of a learning process. Unlike the "Do I really have to..." questions, "What do I need to do now?" questions bear some hope though, for they're open questions. The person is ready to try out something, and maybe the best thing they could try out is thinking for themselves.
"It depends."
Typical answer to questions like "How do I get my manager support our learning TDD?" or "My team and I want to go agile - where do we start?" I like questions that bring up "it depends" answers. It means they're context-sensitive and that you'll need to assess the situation in some way before being able to give some practical, useful answer. Since answers to such questions depend from context and every context is a bit different, giving more precise answers than "it depends" prior to knowing more of the context bears the risk of creating an illusion - that the person may follow blindly the answer you've given. Of course, you may have valuable, relevent answers to more specific questions, wrapped with a context. And here's the dilemma - the more precise the question, the less frequently it's going to be asked. The more your answer will be valuable, the less it'll have its place in a FAQ list.
So - where does that lead us?
Should one write FAQs?
Well, it depends. The way I get it, being agile has more to do with experimenting different things at different times than with litterature knowledge. And yet, FAQs on other subjects aren't useful. And also, others may know better that I do.
How do we get new ideas about what to try when we're stuck?
It doesn't matter - as long as you seek to try something different everytime something isn't working for you.
Is it actually important to find answers to our burning questions?
Yes, it is important. Honestly.
... And how much can we trust you on this?
The answer to this question is left as an exercise to the reader ;^)
Why bother with bottlenecks?
Why?
Portia writes about a participant of our Bottleneck session asking her about the relevance of a session on (industrial or manufacturing) process improvement techniques at an IT conference. Portia already told me she had the same reaction when she attended this session at XP Days London in 2005. If you look carefully, you can see Portia at the right, a bit bored as she’s waiting for the bottleneck.
Moreover, with terms like ‘exploit’ and ’subordinate’, the 5 focusing steps don’t sound very friendly. Is this just another management fad ‘to squeeze the workers’? Can we apply manufacturing ideas to IT? Isn’t the manufacturing metaphor (or the house building metaphor) responsible for some of the worst ideas in IT?
That participant took the first step in understanding: they asked “Why?”
What is it about?
The session (and the Theory of Constraints) is about creating meaning and value by really understanding systems.
To do this, you need to:
- Design systems that fulfill a meaningful goal.
- Take a step-by-step approach to diagnose problems.
- Find real cures by going beyond your area of responsibility, beyond your comfort zone and considering the system as a whole.
- Involve everybody, to continuously challenge assumptions and long-standing traditions to create lasting improvements.
These are things I use every day in my life and my work. Are these things you could use in your work, in your life, every day?
Thank you to Portia for excellent writing advice and helping to edit this entry.
July 11, 2008
Traceability Matrix and Agile
I received two questions this week about how well does agile allow you to do traceability matrix. Very well is the short answer. Here’s why.
If you commit to implementing features (not chunks of architecture) based on user stories in an iteration, you know what you’re planning before the iteration starts. Because you’re working in a timeboxed iteration, and the testing is incorporated into the iteration, there’s no (ok, very little) time lag between the time you know what a requirement is supposed to be, and the time the requirement is implemented and tested. Now it’s a simple matter of paperwork (ok, maybe not trivial) to match the requirement with the code and the test. If you do test-driven development, and start with user-facing tests, it’s even easier.
The shorter your timebox, the easier traceability is. That’s because you have fewer features and fewer tests to manage.
Some of my clients keep their index cards and organize the traceability that way, with notes about where the tests are. They lock the index cards (post-iteration) in a fireproof safe. Other folks use a spreadsheet for the organizing. They use a source control system to manage the changes to the file.
Remember, the requirement is to trace the requirements through the code and tests and to be able to show you did that. The fewer artifacts, the better.
July 10, 2008
Pragmatic Manager Vol 5 #4 Posted
I write a roughly monthly email newsletter, the Pragmatic Manager. I (finally) posted Refocusing: Emerging from the Split Focus Schedule Game. Yes, I’m working on the July issue now. Enjoy!
XP Game v5.0 released
XP Game
A long, long time ago, Vera Peeters and I developed the XP Game to explain the interaction between Developers, Customers and Coaches in an Extreme Programming project. In one fun simulation, participants learn about estimating, planning, embracing change, stories, acceptance tests, velocity and collaboration.
The game was born out of necessity. Our development team was applying the XP developer practices (refactoring, TDD, pairing, continuous integration, automated acceptance tests…) with success. We found it a lot more difficult to explain the concepts to customers, salespeople, support, management. We needed to involve them to take the next step: agile release planning. Explaining didn’t work; examples didn’t work; presentations didn’t work. They were baffled. This ‘XP thing’ was too weird…
Vera came up with the idea of a game. We started working on the game on Wednesday and played the first version on Friday. Shortly after, we played the game with a new customer, to kickstart our largest project to date. The game convinced them to participate in an agile project and to allocate an onsite customer to the project. The fact that we committed to deliver the project in a quarter of the time of our nearest competitor might have helped too 
Grown up games
We played the game at several conferences since 2001 and came into contact with other people who used games to teach. We started to become more aware of the mechanisms and techniques behind teaching games. Our own experience and feedback from others who played the XP Game shows that simulation games are great teaching tools.
The XP Game has been played all over the world. We’ve received feedback and ideas from those who have played it. We still use the game to teach the basics of agile planning to our customers.
The XP Game evolves each time it is played.
XP Game v5.0
Vera and I updated the documentation to reflect how we currently play the game. The new version is available on http://www.xp.be/xpgame
The game is licensed with a Creative Commons license, so you can use it and remix it. Play the game, play with the game and let us know how to improve it.
Expect some news about a new game soon…
The XP Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.
Does Exploratory Testing Have A Place On Agile Teams?
I have a Stickyminds column up, Does Exploratory Testing Have A Place On Agile Teams? The column arose out of an email conversation I had with Jon Bach. Please leave comments there.