When the concept of agile was first being established, a very simple set of statements was written to help define it. Of the 12 principles behind the agile manifesto, five are related to interacting with people.
Being agile means putting people first, and that includes our stakeholders, managers, coworkers, and ourselves. For me as a manager, I have a customer that my team is working for, but my employees are also my customers. In a similar manner, I am a customer of my employees, and we all need to keep each other in mind.
Several years ago, my team had made a series of small mistakes. These were relatively little things, like getting an inventory wrong, or failing to notice something in a facility, or messing up a software configuration. But when you added the half dozen or so small mistakes together, it meant that my team had produced nothing but failure for two weeks. We had been screwing up over and over again, and now my boss expected me to drop the hammer on my team.
Many years ago, I had a friend who was trapped in a failed project. Progress wasn’t being made, costs were piling up, and the company didn’t seem capable of correcting the direction it was going. As he was leaving my house one evening after a game night, he told me about some of the recent troubles they had, and he asked if I had any advice. He knew that I managed a lot of different projects at work, and he wondered if I might see a way out, or some sort of advice that he could provide to his manager.
I haven’t used Dragon Naturally Speaking in a while. Like, maybe 2 months. I have no excuse, other than that I’m a swooper at heart. I don’t write for ever, then I write a whole bunch at once.
In this case, I now have 16 blog posts scheduled over at Meta-Manage. There are only 34 blog posts published, so I wrote almost half as many posts in the last couple of days as there currently are available. Craziness.
Next week at work, we’re writing questions and answers for the JIRA Service Desk certification exam. I suspect I’ll write the study materials sometime shortly thereafter, at which point I’ll have written a bunch of notes on three different JIRA cert exams. Maybe I’ll take my Dragon software and dictate a book about JIRA. And maybe not. It’s not super fun to write about work management software.
Maybe I’ll dictate a scifi novel that has been rattling around in my head. NaNoWriMo is coming up, after all.
Anyways, if you’re into agile project management, or just management in general, keep an eye on Meta-Manage every Tuesday and Thursday from now until November. Maybe I’ll write some more stuff between now and then to keep it going. You never know.
We were in the fanciest board room I have had the pleasure to sit in. Two large TVs took up one wall with a Crestron unit inset to their right. The large and beautiful table had electronics wired into it as well, and it comfortably sat 15 people. I had a slideshow up on the TVs and was talking through portfolio management and forecasting when the vice president in attendance said, “But none of this matters. There’s no way to estimate accurately. It’s all just made up.”
I was stunned. I literally got a degree in the science of project management. Developments in estimating project complexity and size over the last forty years have resulted in reasonably accurate estimation that lets us predict delivery times well. But she didn’t know that.
And that’s fine. I let it pass, because in the moment it didn’t matter, and I can build estimation into their project later. For now, I want to share with you a few tips for how to estimate accurately.
But first, a magic trick
Here is the magical trick that all pros use when estimating.
They don’t do it themselves.
The more I study project management, agile, and work in this industry, the more convinced I am that failing fast is the only way to make healthy progress. We delude ourselves when we create detailed project plans with 1-2 year horizons and try to lock everything down with quantitative analysis, or anecdotal experience, or optimistic chutzpah. I am beginning to think that large batch and long-term planning like this is 100% doomed to failure.
As Helmuth von Moltke said, “No battle plan survives contact with the enemy.” In this case, the enemy is reality, and the plan is our attempt to combat the chaos inherent in our world.
As part of my current job, I’m expanding my study of project management from traditional PMI practices to agile methodologies and the Scrum framework. Being the academic I am, I turn to books for a lot of my education and exploration, and reading through blog posts and reviews pointed me to Coaching Agile Teams as a good place to start. I’ve been reading this book for about two weeks, and it has resulted in adding two other books to my wishlist, but that’s for later.
The sub-title of this book is, “A companion for ScrumMasters, Agile Coaches, and Project Managers in Transition.” I was exposed to agile at least a year or two ago, but I’ve only really begun to study it over the last six months, and only received some formal training in it a month ago. I’m nowhere close to being a ScrumMaster, let alone an Agile Coach, but I think “Project Manager in Transition” might work for me.
This book was truly excellent, but I think that sub-title is really important. It identifies a target audience, and if you’re not part of that audience, Coaching Agile Teams may have limited benefit for you.