A project manager should... - Part 1

For many reasons, recently I have been pondering the question of what a project manager in New Product Development (NPD) should do. In my case the product is software. Now, I am not a project manager myself, and I have no intention of becoming one, but I have worked with quite a few of them in my time and from that experience know that they can have an enormous impact on the people they are supposedly managing and the results they deliver. Good and bad. So, obviously, I have a vested interest in this issue.

As I continue re-reading Highsmith´s Agile Project Management I´m taking notes whenever Highsmith characterizes and describes his version of an Agile Project Manager. As always, Highsmith finds ways to help me grasp the fundamentals of his ideas in crisp and concise language.

His vision for project management is that it "should be seen as offering inspirational leadership focused on delivering business value" (for a great discussion on collaborating with the customer to define business value check out this from Bill Caputo). A project manager needs to obsessively focus on delivering what the customer values. So for anybody who has worked in companies with some kind of quality management system (think ISO 9001, CMM, ...), this statement is in stark contrast to what some PMs spend much of their time doing. In my experience, PMs put far too much effort into what Highsmith calls "compliance activities", when they should be ruthlessly eliminating as many of those activities as they can in order to have more time for their main task of creating and enabling the creation of value. Agile PMs should continually ask themselves: "How little structure can I get away with?".

Project managers need to take a long-term view of the projects they are managing. This means that each project has to be executed with a high focus on enabling the delivery of the next project. Highsmith states that championing "technical excellence is critical both to creating the product customers want today within the established constraints of time and cost and to reducing the cost of change so the product remains responsive to future customer needs".

To be continued...

Don´t specify and design, envision and experiment!

I´m currently re-reading Highsmith´s wonderful book "Agile Project Management" and I´ve been having one of those moments when I´m really understanding and internalizing a new paradigm. It feels pretty good. It´s not that I haven´t understood the ideas behind this paradigm, and why they represent a different mental model, it´s more that the ideas and the paradigm are truly coming together for me; I feel like I´m really transitioning internally to this mental model instead of just getting it on a cognitive level. My point is that even though I have been reading and practising Agile as much as possible for the last ca. 4 yrs, I´m only now feeling like I really "get it" in a fundamental sense.

More specifically, I´m referring to the shift from what Highsmith calls the "Plan-Do" paradigm to the "Envision-Explore" paradigm. It´s the shift from trying to plan all the things that you want to accomplish up front and then doing it, to creating a vision of what you want and then doing as many experiments as needed to fulfill that vision.

For anybody that gets Agile this is pretty standard stuff; use TDD not BDUF; employ iterative development instead of independent, serial phase development; constantly communicate with your customer, with others on the development team; etc... The Agile Manifesto is really as concrete an embodiment of this paradigm as you will find, I think.

What I´m desperately trying to convey here is that I feel I´ve started to live the Agile paradigm, not just understanding what it´s about!

Naming test methods

Dale posted a real gem the other day on the xp-yahoo mailing list about naming test methods. You can read the full entry here. What I found most interesting in it was how he breaks the name down into 3 parts:

(desired-result)(coordinator)(conditions)

He used the following example of this naming scheme:

GameIsNotOverWhenFirstCreated

which broken down is

Desired Result - GameIsNotOver
Coordinator - When
Conditions - FirstCreated

I´ve been trying this at work and I feel that this will help me name my test methods better.

Another discussion came from this, when it was suggested that refactoring the test methods with the same Desired-Result into another fixture might be beneficial. So instead of:

class GameTest
GameIsNotOverWhenFirstCreated()
CurrentFrameIsNotOverWhenGameIsFirstCreated()
NoScoreWhenGameIsFirstCreated()

you would have

class GameCreationTest/GameFirstCreatedTest
IsNotOver
CurrentFrameIsNotOver
NoScore

Which I think is a very interesting approach to experiment with, and I intend to do just that.

What do I want from my tests?

There has been a very interesting discussion on the xp-yahoo list these last few days about the possible need to "upgrade" the practice of TDD to BDD (Behaviour-Driven Development). In the course of a discussion I participated in, the eminent Dale Emery asked me what I really wanted from my tests. The following was my response:

What results do I want?

I want my tests (test classes) to be focused, only setting up one kind of state in setUp.

I want them to be as readable as possible without overly long method names.

I want them, naturally, to be correct, up to date and testing only what could possibly break.

I want them to act as good examples of how to use the classes they test.

I want them to tell me, as unambiguously as possible, if the code under test has bugs and if so what part of the code has the bugs.

I want them to detect bugs in the code under test caused by bugs in other code.

I want them to run fast and give me confidence in the changes/additions I´m making to my codebase.

I want to have a clear idea of how to organize them into packages and classes.

I want them to be independent and self-sufficient.

I want them to be comprehensive, testing units in isolation, the interaction of the units and the high-level system functions. I want to be able to run any one of these categories of tests without the others.

Wow, I want a lot from my tests it seems :-) and there might be more...

Focus on providing value

Focus on providing value to your organization, instead of focusing on reducing costs!

I feel like I “got” what this, slightly paraphrased, sentence means, when reading an introduction to a draft of a forthcoming book on continuous integration (CI), by Jason Yip. Jason uses this idea to examine the goals of CI, which he states are “to deliver Running Tested Features more quickly and to enable Incremental Deployment”. To me it sounds similar to the idea of slowing down to go faster.

Anyway, the way I “got” this was that in a never-ending effort to reduce costs developers cut a lot of corners and skip over practices that in the long run will provide the organization with more value and higher throughput.

Things I can think of that fall into the category of skipped throughput-enhancing practices are:

• Test-Driven Development (automated unit, integration, acceptance tests, test-driven design)
• Automation of builds, deployments, versioning and diagnostics
• Continuous integration
• Frequent releases of software
• Iterative design, planning and refactoring
• Pair design and programming
• Massive customer involvement

Instead developers do ad-hoc, non-repeatable testing of their code because it seems that this will make them go faster… They go through the same manual process of building their software, smoke-testing it by hand, deploying it with copy-paste, … They find out that their code broke some other code 2 days after they checked it in… They get a lot of bugs due to the wrong thing being built because they don´t want to “bother” the customer and hence act on their assumptions… They create rigid designs and only refactor intermittently… They only pair when they have painted themselves into a corner…

A focus on providing value, in the long run, will yield more benefits than reducing costs.