Right we need to talk about the project managers. Okay? They’re-they’re going through changes, changes which they may not entirely understand yet. The transition from Waterfall to Agile, project manager wise,
is a really big transition and the mechanical part is: Okay, before we made big plans, now we work in these two week intervals. It’s, kind of, what’s supposed to happen mechanically but it’s also has nothing to do with what’s supposed to really happen and how you get these agile outcomes. So the real difference is actually a lot more radical and a lot more fundamental.
This whole area of, you know, project management which is pretty well adapted to something like we’re going to build a bridge and it absolutely has to be done, and there’s going to be workers that string cables up, and they can only come at this time, and all the cement has to come and be laid at the same time or whatever. Those things are, kind of, what traditional project management is really good for. And it’s terrible for innovation and digital where the point is really how do we quickly respond to changes and iterate because we can do that and our competitors are doing that.
And the point is, is here in Waterfall, the people the team members are kind of like, you know, cogs in this, like, elaborate structure that the project manager is trying to perfectly orchestrate with these Gantt charts and stuff, like I don’t know. Is that what a Gantt chart looks like? I don’t use them. I don’t know. In Agile the way that really works together is actually fundamentally different. The whole idea is that we have this, sort of, environment that we create through the application of Agile methodologies which are not so much rules but guidelines about, you know, we work in these, we work in a one week interval or we work in a two week interval.
And we do or we don’t change the list of stories during this and that’s the methodology but the real point is that the team is self organizing. So, we’re not, as a Project Manager, we’re not telling, you know, this person. It’s not like being a football coach. It’s, kind of, like being a, I don’t know, motivational coach that creates a little bit of structure around what the people do but then you hope the sort of paragon of practice with Agile is that the team is self organizing, meaning that we have certain inputs and certain ways of working and then just everybody figures out what they should do on their own initiative. And that is a big change.
So, to do on the one hand go from, you know, spokes and wheel and, you know,
carefully orchestrating all these things to saying: alright, well, we’re going to sort of set up the right preconditions, create the right working environment, and then just, you know, like let people do their thing. That’s a big change and it’s hard in all honesty. So, they have a big challenge. You can help them again by bringing in strong inputs. Nothing’s going to help that coherence pull together like bringing in really strong inputs about who is this customer, what experience do we want to create for them, and how are we going to know if it’s working when we when we finish this stuff so that we enter the next iteration with a nice clear view of what worked and what didn’t.
That’s really the best thing you can do. Understanding Agile is great and if you are in the role of product owner it’s important because you’ll be participating in this process on a day to day basis. But the most important thing you can do is bring in good inputs. That’s really going to help your project manager pull things together and create the right kind of focus.