Category Archives: Project Management

First you’ve got Agile…

…and then you’ve got Management. That’s the main idea I remember from the excellent university presentation I attended this morning at Javapolis: the Zen of Agile Management, by David J. Anderson.

When the guy introduced himself and told us that he was working for Corbis, privately held by Bill Gates, a great deal of worry went through my mind because since the management fiasco with Vista, I don’t really see Microsoft as a reference in terms of agile project management. But then I remembered that Ken Schwaber has worked for Microsoft too. And it took Mr David only a few minutes to remind me that you can’t judge such a big company by only one of its mistakes, even such a big one.

First of all, it’s the first interactive presentation I’ve attended at Javapolis. Sometimes people can get a little disturbed when you ask them to bring their own content into the presentation. But at Axen, that’s something we are really promoting in our trainings, so we find it far worse when we do nothing. Here, there were 4 or 5 exercises that the audience were asked to do collaboratively. We gathered in groups, and discussed given topics and after 5 minutes, he came back to us with a microphone and we talked about what we had come up with. Interesting idea, especially for such a 3-hour presentation with such a big audience.

That was for the “layout”, now for the content.

There were really two parts in this presentation: first you’ve got Agile… and that was the main point of interest for me. First of all, he insisted on the importance of trust with knowledge workers, defining knowledge workers as people who know how to do their job better than their bosses do. And I love that definition. The thing is that sometimes it’s difficult to forget about the traditional role of a project manager, to remember that there are better ways to have visibility and control over the project than micro-management. And it’s even more difficult to limit yourself to just being a facilitator rather than a leader, to get out of the way when the team doesn’t need you and be there only when they do. That’s what a Scrum master is all about. And trust is obviously the basis for it to work.

I also saw a couple of very interesting usages of cumulative flow diagrams, reporting artifacts that I have never used before, but which give some interesting information. The main point there was that the best way to optimize your interventions as a Agile project facilitator is to consider a few metrics, but only the good ones, the best one according to him being the Lead Time, in other words the time it takes for a feature/task/use-case/whatever to go through your workflow from start to end. The thing is that if you implement things faster, you see bugs earlier so there are less of them, so you lose less time fixing bugs and you do things faster, and the virtuous circle goes. And how do you implement things faster? Simple! Do less in parallel. That’s what of the main things that I loved about this presentation: David destroyed many common beliefs, and at that moment, the way he explains this, it seems obvious. And it’s only when you think about it for a minute that you realize how most project managers do things the wrong way.

The second part of the presentation was more about making decisions at a higher level, analyzing metrics, identifying bottlenecks and reacting properly with surgical interventions. Sometimes I was a bit lost with all those numbers but it made it obvious to me that there should be more project managers at conferences like this. One of the exercises was about identifying the bottleneck in the project we’re currently working on, and what we would do about it now that we have some leads. I know exactly where the bottleneck is on my project, but what am I gonna do about it? That’s another question.

You could think it’s obvious…

… But it’s not!!! Since the beginning of my career at Axen, I’ve worked for 4 differents customers including the one I’m currently working for. And it always amazes me to see how difficult it is for them to deal with such a basic need as project management tooling. And apparently, judging by a few discussions I’ve had with a bunch of colleagues in the consulting busines, it’s not only the customers I work for!

The thing is that, even if Agility is gaining more and more attention these days, with tight collaboration and cooperation at heart, most companies out there are still managing their IT in a very procedural way. They have project baselines and plans, forms, excel sheets and time sheets everywhere. Every decision has to go through the proper validation channel, and believe it or not: it’s slowing down their business. All those mandatory procedures create an enormous need for tools that can make it simpler and more effective to create, share and collaborate on project-related information. Source code assets, planning, documentation, issues, releases are amongst the most redundant tasks in IT projects, tasks which need tools like version control systems, wikis, issue tracking, release management, etc.

You could think, where there is such a need, there is a market, and where there is a market, there are solutions available! Wrong! Or to be more precise, there ARE solutions, there are too many of them, and the worst thing is they’re incompatible with each other.

Let me give you an example. On the project I’m working on right now, we needed a version control system. The company-wide default one didn’t suit our Java development needs, so rather than trying to force a cube into a circular hole, we chose not to use any version control system… until recently. Now merging code from all the developers is really becoming a big issue and we are losing a lot of time and money on it. So rather than staying in that situation until a new company-wide standard VCS is chosen, we proposed to install Subversion. And believe me, that’s a huge step forward!

But recently, there was a demo of the application and the project lead noticed a few bugs while using it, a few bugs that he naturally wrote down in a non-collaborative but so common Excel sheet. And now he realizes that, if he wants the bugs to be fixed, we need to have some sort of system to register and monitor those bugs, in other words, an issue tracking system. First integration problem: we need an issue tracking system that is compatible with our version control system so that, when a code change fixes a bug, there is a link between the commit and the issue it fixes. And that of course is totally independant of the fact that we need an issue tracking system that makes it easy enough to register new bugs, so that users and developers are not slowed down on the way.

But wait a minute: now if there is a version control system, and an issue tracking system, everybody has to know where they can be accessed. That and the documentation for the project, like design specifications, requirements, coding conventions, and all the information that the teams needs to know in order to work efficiently. First reflex, why not a wiki? A simple editable website where anyone can create and modify pages with just a few clicks. Sure thing! But hey, it must use the same user base as our version control and issue tracking systems. Are you getting it?

Yes, there are a lot of tools out there, both commercial and Open Source, for version control, issue tracking, documentation management, release management, planning, and so on and so forth. But believe it or not: for each of the projects I’ve worked on in the past five years or so, I have looked for a single platform that could integrate all of those very common tasks into a single consistent environment, something so easy to install, maintain and use that it would just… work! I’m not saying it does not exist, but I don’t see it anywhere, and judging by the amount of time I dedicate to technology watch every single day, I think that if such a miraculous tool existed, it would be everywhere!

Well, you know what they say: if you’re not happy with a situation, what prevents you to change it? In that case, nothing! And that’s why I’m currently working with Axen on such a platform. All I can tell you right now is that it’s called Basement PMS (Project Management System), and I would love it to be open-source. We just have to figure out a few details, and I’m working on a proof-of-concept to show off. But I’m convinced it’s gonna be awesome.

What do you think about that problematic? Have you ever encountered or worked in a company with a single, consistent and reliable IT project collaboration environment?