Before today I knew a little about agile project management. It’s not a new model, especially if you’ve been involved in software development. On the surface it looks like another form of incremental and iterative development, but it’s actually a little more than that. It’s certainly got some interesting ideas that on first glance look like they will transition to the hardware manager role.
I’m in the process of developing a couple of complex tracking tools that if it goes well will allow me to lean out my job and automate a couple of the more time consuming functions. The idea has a lot of potential, but will blow up the way things have been done for a while and start over again. Not always a popular more.
My proposal involves a lot of process changes in addition to the development of the tools. It’s a huge project and I’ve been given some resources and buy in to create a pilot over the next couple of months. One of the aspects of agile that separates it from regular incremental/iterative spiral PM is the speed of the release cycle and role of managers in enabling the rapid turns.
One of the issues I’ve come across outside of my home org is managers that have vast experience and knowledge of the product, I don’t mean to be disrespectful, but they are really the very definition of “anti-agile”. They don’t so much just coach people, as direct them. As a result, the people are not empowered to do what’s needed and with that comes a certain level of frustration from those in the trenches. The managers are not doing management work.
In my org Managers may have lived with the product for a long time, but have never lost focus of who is in the offices and cubes everyday dealing with the issues close up. I think they have done a good job of getting the right people and putting where they are needed. Let people do their best and lead out teams and we will move heaven and hell to deliver a good product. I’ve yet to have my actions second-guessed in this org, and that’s quite the testament to my managers and the freedom they give the leads.
I spent a little time today talking about “agile PM” today with an experienced practitioner, it’s gained quite a lot of exposure in the PM world recently. As I’m getting back into that role figured I should learn a little more about it. Some of the idea fit rather well with my proposal. I’ve got to pitch it next week to the peer review group, which is always a tough audience. Once I’m through that and my idea is not totally shredded, I get to rebuild and present it to the program managers. That’s not as hard, but way more nerve racking.
Back to agile, as I said it’s got some very interesting concepts, especially on the difference between iterative and incremental releases that at first glance look like they will apply rather well to hardware and configuration control.
It seems that an important aspect of lean is the role of managers. They are there to support and empower, rather than direct, from what I got today managers have a couple of major tasks in agile.
First as program managers whose main responsibility is to directing a multi-project portfolio in their org. They are interested in more than a straight cost/benefit business case; they also want me to show where we will leverage the work into complementary projects in the future.
Second is creating an environment for success. This can mean ensuring resources are available, of making sure the minutia of day-to-day in a big org are taken care of and finally running interference with other groups. My group is lucky we have someone who takes care of the minutia part rather efficiently, but seemingly trivial things like signing up for training or booking travel takes significant chunks of time. The final part, running interference and allowing us to concentrate on the projects is becoming more and more important, and I work for a manager who is very good at it.
I’ve got some reading to do when I get some quiet time next week, probably while sitting on an airplane.