Detail-oriented without micromanaging, scrumfall, and it’s been a long week

So much fail. It’s at the end of the project that you really feel the mistakes you made at the beginning of the project, isn’t it? It’s been a tough week.

One of the projects I’m managing is a classic enterprise middleware type project — it’s all about The Integration. While it’s ostensibly about building a next generation microservices platform, really it’s just straight up integration work. But it’s very chaotic integration work. The microservices endpoints are the easy part.

Tracking the details without micromanaging

There are at least two big mistakes I made at the beginning of the project, which have come to visit me now. First, the project was unique for me in that I didn’t have much technical leadership in it. I always had a heavy tech leadership role in the past. This time I adopted a pure project manager posture, and I didn’t track the technical details like I used to.

Looking back on the past few months, I think a lot of my anxiety was related to the fact that I didn’t fully understand what was going on at the level of detail I’m used to. I’m a technical guy, so I need those details. Since I’m still managing multiple projects and will continue to do so in the near future, I think there’s a way for me to alleviate some of that anxiety. It might look something like this, at least for a middleware-style project:

project-map

Scrumfall

Second, it’s been a while since I’ve been in a waterfall-style project so I didn’t track the work that actually mattered the way you would in an old school project. My most recent big application development project was in the media and entertainment industry using a purer agile methodology. We delivered builds in increments and features were ready when they were ready.

This project caught me off guard because it pretends to follow agile, so I was tracking work on stories, trying to get acceptance, etc. But I was fooled because it’s not an agile project; it’s a waterfall project. Instead of going through shippable iterations, we’re doing the classic death march phases: development, SIT, integration, UAT, release cycle. Now that I know this client better, I won’t be fooled again.

It is what it is, so the question now is what to do about it in the future. It’s probably been over five years since I’ve done waterfall, and I completely forgot how completely lame it is. Here are some things I’m thinking for the future:

Do agile anyway. I wish I had actually been shipping our work on regular increments even though the client didn’t fully understand. We could have led by example, and the whole project would be in better shape. I really don’t want to follow “water-scrum-fall” and besides, it’s usually just scrumfall anyway.

Micromanage the work. Ugh. I never really made waterfall work, so I’m not sure what else to do but micromanage the team, the work product, and my dependencies. This is an option when I just have one or two projects, but I don’t think I ever want to take it.

Leave a Reply

Your email address will not be published. Required fields are marked *