Transformers

Much of the agile literaure is focused on how difficult the transition from traditional to agile could be. They address the problem from many angles describing techniques how to help programmers to make peace with pair programming, how to get better at incremental design, some even suggest to use Organizational Patterns to introduce some of the practices to a team or a company. They all seem to be empathic with people who as a rule fear and loath change.
I don't see it that way. I actually think being a true "waterfall guy" helps you to accept agile, and helps you to execute XP practices and to a better outcome too(from this point on I'll be referring to XP, but probably most of what I have to say applies to other agile methodologies as well)

Having had been a true waterfall guy myself, with my precious UML diagrams, my very own modules and an ever strengthening habit of working alone on a laptop in pubs and cafes only occasionally checking in my work for my team to see, I had no problem at all transitioning to XP -- quite the contrary.
I enjoyed Pair Programming from Day 1, because I realised how much easier it is to pick one from the many possible ways to solve a problem, if you have someone competent to discuss it with. I learned not to fear to be stuck anymore, simply because it happens almost never, and even if it does, it's far less frustrating when you have someone next to you to share the pain. Becuse of all the implicit and explicit problems I had with the tradtional way, I appreciated Pair Programming a lot more then I would have otherwise.
To be able to do Incremental Design it's good to have had done a few BDUF yourself. It helps you to see the big picture - which some false interpretation of incremental desgin denies to be allowed - and it helps you to come up with sophisticated solutions quickly. But most importantly once you have seen first hand what's wrong with BDUF, you are ready to like Incremental Design for all of its benefits.
TDD is again something you appriciate more coming from a Waterfall world, because then you know how fustrating the bugfixing phase normally is, fixing and refixing bugs for months. You also know how frustraing and shameful it is not to make changes to code you hate and not to refactor at all due to either fear of breaking something, or an explicit order from your bosses, with something about changes are risky at this stage of the project, but the right stage for a change never seems to come. In which BTW they are absolutely right: without an extensive test harness, you can never be sure, even a little, that the changes you're about to make won't break the whole system.
All in all, the skills you learned and the bad experiences you had with waterfall all will make you a better agile developer.


Read full post...

The Navigator

Pair programming is one of the key practices of XP, and so there is a lot to know and learn about it(which you can start by reading Pair Programming Illuminated by Laurie Williams, Robert Kessler). Let's focus on the navigator for now.
The navigator's role in my view is to look ahead: while the driver is to keep us on the road without any accidents, the navigator is to know where we're going and why, also what we're gonna do when we get there.
I figured that the best way I can accomplish this as a navigator is if I sit back and don't even watch what my driver is typing.

Don't get me wrong, it's not without merit when the navigator and driver don't talk much, just simply understand each other through bits of code and a few words, though this benefits the team more on the personal and social levels, helps to build mutual respect, team spirit and so on.
But the navigator's sort of turning away from the screen makes it imperative for him and the driver to start talking about the problems and solutions. A lot of good things can come out of saying something out loud. For instance you can realise you can't say it: it's too blurry to be said, and then chances are that your solution or your model of the problem is way too complicated. Other times when you try to explain your implementation out loud, you realise that it's just simply wrong.
In our praticular office layout there is another, quite relevant side effect of my turning somewhat away from the monitor: I get to see other parts of the room: the iteration board, the release board, the burn-down chart, our product manager, our tester, our build machine - all of which remind me to look at the problem at hand from many, different perspectives: all of which I might have forgotten about, had I watched my driver and his code unneccessarily closely...

So you can try it next time when you're the navigator and let me know how it turned out...

Read full post...