Brief Notes on Scheduling
Dev scheduling, and scheduling in general, plays quite a big part in my day-to-day work. Everyone comes to me for dates, estimates, status, release details, etc…
So, how does one go about it in a startup without going totally crazy? Well, by avoiding getting sucked in to the details, of course.
I’m really all about macro-level views. I like to keep things fairly hands-off, but know enough about what’s going on that I can provide guidance / assistance when required. The other benefit to doing things this way is, you can handle a lot more because you aren’t trying to manage all of the sub-tasks that sit below a milestone, but you can start to drive communication / efficiencies cross-functionally, which is also a big part of being a successful PM.
There’s an underlying theme with this that I’ve been told a few times by people way smarter than I’ll ever be: if you control the information, you have some degree of influence. I still have to think about everyone creating and sync’ing schedules and how to manage that in the sense of getting folks the right information in a timely manner - helping them execute where I can, and actually executing on your own stuff.
Part of the fun in all this is that no one group in an organization will handle schedules the same way. But of course, a PM needs to get team leads / project leads that are working on release-specifics, on the same page so it can all come together.
It’s a lot of fun, to be sure.
Quick / Quick & Good
Let me start this post off with the clear thought I’m going to attempt to discuss below. I say attempt because, god knows, I can very easily get lost in the writing and it easily becomes stream of consciousness. So, if you nod off while reading my blog, don’t feel bad. Because, I might be nodding off while writing it. But, I digress.
OK, the thought.
There is a MAJOR difference between doing something QUICKLY, and doing something quickly that’s of HIGH-QUALITY.
As you’re reading this post, remember the fundamental project management equation, which applies to product / project / program managers alike regardless of if you are working within an eXtreme or waterfall methodology.
scope + cost + schedule = quality
There’s been a lot of focus put on “speed” and “iterations” with the whole web two dot d’oh! craze going on these days, and I wanted to touch a little bit on that.
I don’t mean to rain on everyone’s “just get it up & out there parade,” but there’s still a need for attention to detail and quality. It seems to me that no one pointed out to the agile pushers (me being one of those folks) that while doing things iteratively and quickly is nice, it requires experience.
I’m going to go back to the age-old analogy of building a house. If you were having a house built and hired contractors to do things, not necessarily iteratively (because I don’t know how you could put up a house and then continuously improve it), but quickly and of high-quality, would you want kids that were just out of carpentry school doing it? No freakin’ way.
That doesn’t mean you need dinosaurs up there laying shingles on your roof, because they would arguably cause just as many problems as the people without any experience, but you still need that knowledge of having done this before to get it done properly.
I can’t talk too much, because I myself don’t have 15 or 20 years under my belt, but I have been in software (Web applications specifically) development for close to 7 years, so I do know some things about creating applications and working with customers / users to improve them.
Don’t expect to hire cheap labor, who hasn’t done the work you want to do and expect to move at lightening-speed AND get something up there that will propel you to the level of greatness. It just doesn’t happen that way. Again, one of the major elements to be successful at agile development is you actually need developers that know what they are doing to get things done in that fashion.
…and developers that get one iteration shipped and are chomping at the bit to tweak existing things and continuously improve what they produced so it’s the best it can be, while at the same time making the product more exciting by adding enhancements coming in from the market.
Another component that may get lost in this “agile” development way of thinking is actual accountability. It’s easy to lose the team and control, especially when the experience isn’t there, in the midst of, “we’re just going to get this done and up and then refine.” Quality needs to be minded, and those involved have to be held accountable for what they own. It’s still a project, folks. Don’t lose sight of that. Just because you’re not creating 1,000 page requirements documents and maybe you are writing your project plan on note cards doesn’t mean these fundamentals get thrown out the door.
Managing by Milestone
I wanted to let everyone (well…all 1 or 2 of you) in on a little secret a learned recently: there are two ways in which you can be accountable.
You can be accountable for work, or you can be accountable for communication. And yes, there is a pretty big difference.
Now, of course, in the fast-paced “hectic” start-up world where everyone has to be good enough to a) wear multiple hats and b) want to contribute and wear multiple hats and be excited, there are many (if not all) the folks in the company that are both accountable for some work, and some communication. However, I just wanted to post about this because what else are blogs for if not to ramble on until you get something in your own mind?
So, what to do with this revelation. Well, being a product-centric/happy guy, I float towards wanting to be accountable for communication on projects that are not directly product related. This means I favor a setup where you manage by milestone and not detail. Why is that? To me, it’s a boatload more effective to sit down for 30 minutes each week with a team lead, go over key milestones identified at the outset of the project and log the issues as opposed to sitting down for 1+ hours with everyone on the entire team and going through the plan point-by-point.
Why do I care what Suzy is doing on Tuesday of next week? If you do, you might be slipping into a trap of micro-management.
Now, of course, anything I say should be taken with a grain of salt. I know nothing from nothing and am simply a geeky pleeb trying to work all this out and how it can work the best in the scenario I’m currently in.
With that being said, development project management has to be done differently in a small environment in order to work. It HAS to be agile. I’m 100% - no, 1,000% - convinced of this. There is NO other way to go.
My first step? Tearing up any spreadsheet that I had related to tracking dev schedules. What goes in its place? I’m pulling out some flip charts and writing the following:
Product Name - Release Number / Date / Sundial Location / Whatever
- What’s in the backlog?
- What’s been planned?
- What’s in development?
- What’s ready to ship?
I then track the overall status of the release itself. Smiley face / sad face, thumbs up thumbs down, whatever. It needs to be clear, it needs to be somewhat interactive, and developers have to be able to walk over to this thing and scratch their names off, or move a sticky note with a requirement on it to the next grouping (for example, development to ship / qa, whatever) when it’s ready to go.
People love to check their own names / tasks off of lists. I love to see people checking their own names and tasks they have ownership of off lists.
So, let’s throw another kooky wrench into the mix? What if you want everyone to see this schedule so they know what is being worked on when it comes to the life blood of the company (i.e., the products themselves). Well, that’s easy if everyone is ass in seat, in the office. However, that’s not always the case.
I’m thinking a Web cam.
Will this invade privacy? That’s the initial concern. How can you avoid that? Get 1 camera, point it at the dev schedule that’s on a wall in a grid taped together or on flip chart paper taped to the wall.
Oh wow — didn’t I just recommend to violate a cardinal rule of product management? Never, ever give sales specific dates / info on the dev schedule! Blasphemy!
Ehhhh…I’m starting to think it’s not going to matter so much — especially now that I’m dealing in more of a consumer-based mindset. Which, I’m loving by the way (whole other blog post on that bad boy topic).
I doubt any of that made sense. Which is fine. It’s working for me, and in my head it all makes sense. The litmus test will be to see if it makes sense for everyone else that it needs to make sense for. And if I can keep it clear enough in my head that when I start to tape big pieces of flip chart paper to the wall behind my desk.
God, I love my job.
P2P (1): What is Necessary Right Now?
I have been working on a toolkit that will help out with “program management”. I wanted to jot down some things that I’ve discovered along the way that I thought others may find useful.
As I wrote this first entry, I realized that I had more to say than I originally planned. Thus, I’ve decided to split these apart into the first series on this blog. “P2P” stands for “Product to Program”. But, I digress.
The largest piece here is knowing that, yes, while you are establishing a whole big vision and set of things that you know are really going to help out, make sure you are clear on what’s short-term and what’s long-term. This is especially true if you are in a small, start-up environment. The last thing that’s needed is lumbering process and unncessary steps / tools that are going to bog down development and cause people to feel constrained and generally crappy. Blech.
With that out of the way, I’ve found that starting off with a simple set of goals is the best way to go. Yes, they can be lofty, but within the understanding of all parties involved in creating and using the tools being constructed. The communication of these goals, and the inherent vision, gets everyone on the same page and working together (fingers crossed).
Once you know what you want to do, the items that follow are a little interpretive. That may sound like a cop out, but it’s not — there are plenty of things that can be done, but it depends on the situation at hand. As opposed to using a specific example, I figured going through a set of questions that have helped me could be interesting.
- What is necessary immediately?
This first one can mean many different things. From my experience, it usually relates to having a bunch of stuff going on that key folks within the organization are unaware of, but should know about? If so, the solution is simple: write down what’s being worked on - the key stuff — nothing that a developer hasn’t touched and is still six months down the pipe. List creation is fun; a summary of each task, which can come right from your defect tracking system, a percentage of completion, who owns the task, its priority, and estimated timelines.
To be honest, if it’s the first time you are implementing this in a company, the list will go a long way — both up and down the line — and help out day-to-day. However, it’s critical to remember that once you’ve started to execute, expectations have been set. You will need to continue to execute regularly. We’re not talking every single day, in a regimented “same bat time, same bat channel” type deal. Casually works best, every 2-3 days, chat with those that have priority tasks being worked on.
Next post is question 2: How is the workload handled?
