Where you put your padding makes a difference.
Padding schedules for risk is not an incredibly new strategy. But to do it properly isn't as obvious as it might seem. When you're sitting down staring at a schedule, most people think they're being pretty clever by tacking on 30% to the end of their schedule and calling it buffer. There are a number of hidden problems with this approach.
Firstly, big bosses are trained at management school to go right to the end of a schedule (or budget) and slash anything that starts with "B" and ends with U-F-F-E-R.
That way, they feel like they're leaning on people to "get the best/most" out of them. (Which is also a rookie management mistake, but that's another topic altogether.) Want to thwart this bad habit?
Rename all buffer items in a schedule with things like: "Recalibrate the discombobulator" - that will throw them off track for a little while. I'm only half joking here.
Second, in pure* software development, any buffer less than 100% probably isn't enough in many cases.
(* I say "pure" meaning higher degrees of complexity and invention versus "content development" which accounts for the bulk of standard commercial web-site development.) You may be better off thinking in terms of multiples. Even if that's not the case for your particular project, your buffer time (i.
e. "oopsies") isn't likely to get used all at the END of the project. It'll more likely happen in little pockets throughout the project.
Which brings me to my 3rd point:
The release date isn't the only date worth protecting. Besides when the quality control phase of your project starts (which is a HUGE milestone), there are likely components, tiers, or other important dates within your schedule that you're trying to predict the finish date for. Proper padding for risk should be sprinkled throughout the schedule so that when a slip on some small component does occur, there's enough elasticity after it that it won't linearly slide the remainder of the items off the chart.
This is important because there are likely other dependencies in your schedule where certain activities are being co-ordinated and planned around smaller phases, components or milestones inside your schedule. The more protected they are from individual slips, the easier it is to plan around them on a continual basis.
Of course, it's EASIER to just tack on 30% to the end of a schedule, but easier isn't always better.
This is where your choice of scheduling tool can have a dramatic impact on making your schedules stronger and your life easier. For example, automatically squeezes in little bits of risk padding after tasks by using trends it has observed with respect to the things that most often cause schedule slips: inaccurate time estimation, and dealing with distractions. Having these 2 top schedule killers accounted for in little bits and pieces sprinkled throughout your schedule gives you the most resilient schedule, for the least amount of work.
| We all know the "Less is More" strategy being popularized by 37signals.
Some very smart observations about the merits of both more features and less features. How can these smart people have conflicting opinions about which is better, less or more?
It's the experience level of the user. And that changes over time. Newbie users LOVE simple products because they're not intimidating.
They're easy to get started. They're cheaper to buy. When your needs are modest, a simple tool seems like a Godsend.
When your needs are complex, simple tools look like toys and feel like chains holding you back.
Simple products (in this context, meaning less features) are not unilaterally better than complex products (in this context, meaning more features). Nor are complex products unilaterally better than simple ones.
It all depends on where your users are in their own understanding and needs, related to whatever problem your product solves. Beginner users with simple needs love simple products. Sophisticated users with advanced needs view simple products as limiting and frustrating.
The important thing to remember is that beginner users eventually become advanced users. Oh oh. Now what do you do if all you have is ONE product that is either simple or advanced?
!
(By the way, complexity and feature count can be decoupled with good design, but that's another topic altogether.)
Personally, I view a user's needs as a kind of evolution.
The needs start off simple until the current product is mastered, and then users often want more features as they feel the need to excercise more finite control or power over their tool. If you give them this, then the tool no longer resembles the original "simple, elegant" design you first had, and you've simply traded beginner users for advanced ones (instead of adding new users).
What's a software designer to do?
Hmm, the words "one size fits all" seem to be whirling around my brain - like somehow they may be responsible for this conundrum.
Personally, I believe the best solution is to stop trying to design a single user experience that is exactly the same for the beginner user as for the advanced user. Once again, in trying to please everyone, you risk pleasing no-one.
Know your audience! If you must please users at varying levels of sophistication, the best strategy I've come across is to either split your product's user interface into "modes" where the user can select their own level of needs (don't ask a user how sophisticated they are: they'll always say "advanced"), or even consider splitting your users across different physical products that serve basic or advanced needs. In other words, the user experience should be like a highway on a journey of learning.
Give people a couple of different entry points and let them merge wherever they feel is appropriate. Then let them grow up with the product and show them that when they're ready, you've got the next step covered too.
As with all good things however, there is a cost.
Having separate user interfaces, or separate products, requires more planning and design, and more development effort - but wait...
You're getting more customers out of the deal right? And quite possibly even happier, more loyal ones too because you've more closely aligned your user experience with their current needs. Seems like everyone wins to me.
Many people might argue that it's too expensive to segment users based on sophistication levels for a single product, or to have multiple products for different levels. However, there is no arguing the fact that niche players in many product categories are stealing customers away from general purpose players in those spaces. In fact, one could argue that the general purpose approach only works as long as the space is not big enough to support those separate niches, and only as long as the barriers to entry in that space are so high that niche vendors can't get in the game and take away those customers.
For most software related fields today, the barriers entry are low, the markets are big (meaning they will support segmentation).
So if customers are being presented with a choice of products from different vendors at varying sophistication levels anyway, why not have those product choices under the same vendor's roof, and blended to look like they all come from the same family? Maybe ease the transition from beginner products to advanced ones?
Why do "enterprise" vendors ONLY make big, complex software? Why do "Agile" vendors only make small, simple products? Once a company builds up an expertise in a particular domain, why not offer a choice?
I believe that in most cases, it's because the teams building the software also grow up with the product and gain more and more experience and sophistication in their own domain, that they leave beginner users behind as they project their own advanced understanding onto the product's user interface. This process continues until they've left some users behind and have created a barrier for new users to jump on board.
We need a "leave no user behind" philosophy in product design!
One reader recently brought up the subject of using Story Points as a unit of measure for the "effort" or "duration" of a feature or capability, rather than estimating effort in days, weeks or months. You may have stumbled across this practice if you are following one of the variants of the Agile development movement.
For those of you that don't know what a Story Point is, it stems from another pillar of the Agile process.
The idea is that you get users to describe use cases for the application they'd like (called "User Stories"), and they serve as specification of sorts. Story Points are used to quantify the effort (and indirectly, how long it will take to build). The point of all of this is to have some way of trading off one feature request against another.
If you want a new feature that would cost 10 Story Points, you may need to drop 2 others at 5 points each. It's a "cost" system.
I'm not a big fan of this unit though, because I believe it's an unnecessary level of abstraction.
There isn't any clear advantage that I can find in using a new abstract unit instead of just plain old days and weeks. The trading still happens the same way: "Want something that costs 10 days? Drop two others that cost 5 days each.
"
The danger to the stakeholder that's asking for the feature is that they're being forced to work in a unit they don't understand. It forces them to try to learn a new piece of jargon that seemingly hides what they REALLY want to know, which is: how long is that going to take? It seems extra odd to me because part of the Agile method is to try to bridge the gap between users and developers, which is why the whole "storyboarding" theme exists.
But then turning around and using an abstract unit of measure for "effort" seems to be inconsistent with that, and actually clouds the topic of effort or duration. It seems to keep users in the dark about the "real" cost of a feature (time). Plus, the benefit of using real time units (days, weeks) is that stakeholders can see that development is actually a pretty slow and time consuming thing.
Sometimes it really can take you 10 days to "just add a button". By using real units of time, you "expose" them to this reality.
What really makes my Spidey-sense tingle about an abstract unit of cost like Story Points, is that it's value relative to time changes with the wind.
One month, each Story Point might be 3 calendar days. The next month, it might only be 1 day.
Another similar practice is to use "Pure Development Days" as the unit.
This I like better, but still not completely. I like this better because it uses "days", which we all share some intuitive understanding of, but it's still a little abstract because of the built-in disclaimer: "Pure Development". What is Pure Development?
Does it even exist? It's trying to demonstrate that over a period of 2 calendar days, you may only get to spend 1 day worth of development across those 2 calendar days, because of other things that come up that distract you from development. So, better, but still not quite there in my books.
The risk with Pure Development Days is that normal people will subconsciously drop the "Pure Development" and just think you're talking to them about regular old Days. Because that's all that coders do is code, right?
I do very much like the fact that with Pure Development Days you can derive a kind of productivity metric.
Like, for every 3 days we get 1.5 days of solid development time, and 1.5 days of miscellaneous "admin".
For those of you who've read about my pet metrics of "Time Estimation Error" and "Distraction Rate", you may recognize that Pure Development Days is kind of like Distraction Rate, turned upside down. A Distraction Rate of 50% means that a developer spends half the time doing things unrelated to the core project (development), so if you want 1 solid day of development, it's going to take 2 calendar days. This is really a similar formula to Pure Development Days, but it flips things across the equals sign for good reason.
By using (plain old) days as the unit of measure for effort/duration, you can set expectations with stakeholders about when (on their calendar) they can have something, as well as the relative cost of something (2 features @ 5 days = 1 feature @ 10 days), so long as you're internally marking up your numbers for Time Estimation Error and Distraction Rates before quoting the bottom line to your stakeholders.
So, you internalize these fancy metrics inside the dev team, but get you speak plain english with your stakeholders, and still get the extra visibility into "productivity".
| On Monday night, Ottawa had its first CaseCamp.
One of the presenters was Mitch Brisebois of (company) and (blog).
I've long believed that "Good Enough Isn't". It's just one of those things I've felt in my gut and I've tried to use as a guiding philosophy when building products.
Trouble is of course, not everyone shares that belief. In fact, I'd say the minority do. The much more popular stance is, "it's good enough, ship it now", or it's cousin, "is that extra polish REALLY going to make or break the product?
" (shudder).
Mitch whipped out a slide that I though was a wonderful illustration of what happens when you adopt a "good enough" philosophy with product development.
It goes something like this: If the user experience with your product is uneventful, they'll think it's "OK", probably won't remember you, and you'll have a deficit in terms of loyalty with that person.
Yet, on any modern software business plan, you'll invariably see themes like "viral adoption" and "word of mouth" dominating the marketing section. Hmmm. But the chart says you need "WOW" to get the "share with many" reaction.
Morale: if you're aiming for anything less than WOW, you're aiming too low.
I have a pet metric that I call Time Estimation Error. It's the percentage of time that a person is over or under, on average, for all of their time estimates over a given period.
For example, if over 10 tasks, a person estimated 20 days, but took 30 days to do, their Time Estimation Error is 50% (overrun).
This kind of tracking is built into so that it helps you get to know people over time and build better schedules by automatically adjusting for these kinds of factors. So eventually, when someone tells you something is 10 days work, you'd know that it's likely 12 or 14, depending on that person's accuracy rate.
It occured to me a few weeks ago that perhaps a percentage is the wrong unit of measure for a factor like this. What's in a unit, you ask? Well, for one thing, perceived boundaries.
Sure, we've all seen numbers like 300% and 400% (figures that are more than the soft maximum of 100%), but if you blindy ask someone what they think a good percentage is for something, anything, I bet there's a statistically better chance that they'll give you something within the bounds of 0% to 100%, not even considering anything over 100% - unless you really push them to think hard.
Now with estimating time on a software project, typically in clumps of days per feature, my experience has been that people are off by as much as several times their original estimate. Like a 2 day task that actually ends up taking 5 days (= 150% overrun or a 2.
5 times multiple of the original estimate).
I'm beginning to think that a multiple (of x times) or decimal value would be better at getting the point across, than a percentage which tends to "lead" people into giving certain ranges as a response to a question.
Of course, if Devshop's tracking it for you then it doesn't matter, you'll get an accurate figure anyway, but I think the unit of measure chosen to track a metric like this has a bearing on the results you get, if you're asking human beings for the answer (guestimates).
By the same reasoning, when a lot managers "buffer" for unforseen difficulties during a software project, you'll often see them use percentages - like a buffer of 20% for some particularly risky component. I think in many cases people would be better served by thinking of risky parts of software projects in terms of multiples, as if the not so risky parts of a software project (an oxymoron) aren't tough enough to nail time estimates for.
| I've often had discussions with people about the importance of design in software.
By design, I mean things like: usability (= learnability + productivity), ergonomics and plain ol' appeal (after all, you want people to use and like your software don't you?) I've been known to drive developers nuts moving things around on screen, and even became known to a few as "2 pixel boy", because I'd always be asking developers to move their textbox labels up or down 2 pixels to make sure the baseline of the text in the label matched the baseline of the text inside the text area. Basic stuff in my opinion, but continually overlooked by many.
Clearly there are a couple of camps on the relative importance of design. You know, the form vs. function debates.
I won't recreate that debate here, but I am pleased to see what I think will be a new bias being adopted by the general public in the coming years.
I believe that "elegance" is going to make a big come-back. I think we're exiting the age of utility development (having laid working infrastructure) and entering a new age of craftsmanship.
From a business perspective, here are the trends I see that I believe are the signals of a shift on emphasis from "cramming features onto the brochure" to "crafting" an elegant solution to each software problem:
We each take our little piece, and no-one holds the "whole" in their mind at any given time. By contrast, the individual (or small team) tends to gravitate towards the "craftsman" style of work. Everyone can see the whole of what they are building and how each of the little pieces interact with eachother to form the whole user experience.
There's a higher degree of association between builder and product, which leads to pride in worksmanship, which leads to higher quality design and products. This simple "bias" in how we behave depending on the size of the group, will influence the outcome of our designs.
This was largely due to the fact that once you bought a system for your people to use, you were "locked-in" with file formats, protocols and other various reasons why you simply couldn't live with having more, smaller apps floating around your company. Each app required an investment in training, so you'd want to make sure you had to train your people on as few tools as possible. When purchase decisions are being made by people that aren't actually going to use the software, the only major decision points are things like: the demo, the brochure, the price per seat.
Software was purchased at the top, then handed down to the people that were told to use it. Ergonomics were considered frivolous. There was no self selection going on.
Now that we're in the trough of disillusionment with big shaggy enterprise software, people are moving towards smaller independent apps that can simply talk to eachother (with less upfront investment, and much lower price points). When users buy their tools directly, elegance, usability and design become MUCH more important in the purchase decision.
The computer is so commonplace now that is has become invisible (almost) and the only thing people see is the software - it defines their experience to a large degree. I remember when I first started riding motorcycles. I was so thrilled just to be on the bike that it didn't matter how cold it was outside, or if it was raining, or if it was boiling hot underneath my leather.
I rode because it was thrilling. Then the thrill wore off..
. My view of the bike changed. I now saw it not as novel, but simply as a means of transportation.
When that happened, it was always too hot, or too cold, or too inconvenient to carry personal items (or a passenger). I stopped riding. People have used enough software now that the thrill has worn off and they are much harder to impress.
They aren't as easily hypnotized with all the fancy items on the feature list and the mere promise of new capabilities. They have seen well designed products and they have seen crap. And they are better able to discern the difference before they make their purchase decision.
All the promises on the brochure aren't enough to cinch the deal.
The power has shifted from the vendor who could sell products without actually letting people try them, to the consumer, who will try it first and make up their own minds about the wild claims made on the web-site.
Consumers are now software connoisseurs too though. When something is at the early adopter stage, its level of polish and craftsmanship is less important. Fanatics, hobbyists and the curious will "administer" their own software.
They'll do crazy things like rebuild kernels and configure until the cows come home. Now, people want stuff that just works. That's a lot harder to build and requires a lot more attention to detail and to the user experience in the design process.
Products that just work are now being chosen over competing ones that are cheaper and have more features! This is a new emphasis coming from our customer bases.
Personally, I think it bodes well for the future generation of software products.
I say bring it on! It's an exciting time to be a developer.
A while ago, I wrote , where I described the process of developing v1 of , starting with the user interface and working backwards through business logic and into data storage.
It worked REALLY well that way.
Today, on the drive to feed my Starbucks addiction, something else occured to me that might explain why it works so well (in case you're not already a believer).
Most of us in software development know that reverse engineering is WAY easier than forward engineering (building it the first time).
That's because when you have a living, breathing model of it already working in front of you, you are free to examine it from any angle and run any kind of behavioral test on it (what does it do when I do this?). And, quantum physics aside, it is fairly consistent and behaves the same way every time for months-on-end (unlike some bosses or customers who love to change their minds daily).
What is really happening when you're reverse engineering something? You're fiddling with the interface (user interface for applications, or API for platforms) on the surface, because the guts of it aren't readily visible to you. You're pushing and pulling screens, always able to see what the "response" from the application is, even though you can't see "how it got there".
Now, if you can't see how it got there, "how it got there" might as well not even exist! (It's magic.)
That's kindof like building it front to back.
You've got the model there right in front of you, you can at least navigate anywhere you want to go, and with sample data, that's pretty darn close to "real" data that was generated from magic business logic that doesn't actually exist yet (or is hidden from you). So, what's the difference?
See, this clearly proves that building it front to back is LIKE reverse engineering, which we already know is easier (more consistency and less loose ends) and easier is good, therefore building it front to back is good.
I don't know a mathematician who could have proved it better ;).
Huh. I wonder if customers changing their minds is a result of quantum leaping?
| I love producing software. I always have. From the time I got my first TRS-80 from Radio Shack at 9 years old and starting writing code, 'til now, mid-life crisis only a few years out.
I consider myself especially lucky now-a-days, because not only am I finally at the helm of my own ship, but the product I'm producing is for the very people I've been working with my entire career: other software teams.
We've all worked together under completely unrealistic timelines, had bosses that think they are product designers but who don't actually use their own computers to type their own letters (and hadn't quite figured out e-mail until a couple years ago).
We've given up countless evenings and weekends to try to bring horribly managed software projects back from the brink of disaster and out the door on time, all the while making "trade-offs" that we knew deep down just weren't right for the product but now had to be made just to ship something in a reasonable time frame.
One word that has taken on new meaning during recent experiences is inspire. When you're tying to create a new product and bring it to market, there are so many steep mountains to climb, each looming right in front of you. And beyond the ones you can already see, you just know there are more in the background not yet discovered.
Yes, you'll have to climb those too.
What I have found in many companies is a trend, that during each product life cycle, fairly serious trade-offs get made along the way so that the product that was once a beautifully elegant design in all of its mock-ups and presentations, turned out to be something that almost did the trick. Almost but not quite.
(When I talk of beauty, I'm not just talking physical beauty, but that it actually elegantly solved the problem at hand.) The popular thinking was that, "Well, if we ship it now even though it's not quite there yet, we'll at least make a little money, and then we can re-invest it to get the product to where we initially thought it should be. It's good enough for now.
" It's a common strategy. And it's the beginning of the end for a product company. (Even though you think you'll make "some" money now, enough to fund the rest of development, you soon find out that it's VERY difficult to sell something that "almost" solves the problem.
)
The trouble with the "good enough" strategy is that it doesn't inspire anyone. It doesn't inspire customers. It doesn't inspire employees.
Or partners. Or investors. Or the public.
Or the media. Who can get inspired by a product that is only 80% of what it was supposed to be, but has been discounted by 20% to make up for it? And all of this only so that the product can ship 1 month late instead of 3?
See, product development isn't a "management by numbers" game. That's for commodity businesses. Luckily software isn't yet a commodity business.
There's still enough variability in the kind and quality of products in the various categories that discounting price to make up for lack-lustre design or quality doesn't quite work. People aren't yet thinking "features per dollar" the way they do with fast food ("only 20 cents more for double the fries!").
Whenever I see a software company come out with "just another" product like everyone else's, but they've discounted it by 20% so that they're the cheapest kid on the block, I shudder.
There was a movie (darn I forget the title), where a crazy hitch-hiker was picked up and proceeded to explain his brilliant business idea: 6 minute Abs (a VHS tape). "Think about it.
..", he said, "When you're at the store, and you see '7 minute Abs' on the shelf, but right next to it is '6 minute Abs', which one are you gonna pick?
!". "But what happens when someone else comes out with '5 minute Abs?
'", the driver asks. GASP! I think you get the point.
If price (or "best value for the money") ever becomes your only differentiator, then it's time to come up with a new product.
This is partially why the word inspire has come to mean so much to me lately. I believe it should be the basis for development.
Not just product development, but company development, team development and personal development.
Here's what I mean.
If you're building software to sell, there are some pretty big hurdles you're going to have to face:
None of these things are made any easier by going down the "good enough for now, 20% cheaper" path. No one really cares.
But if you always start with inspire as your goal in everything you build, I have seen first hand, many benefits:
Good people like to work with other good people. This makes recruiting easier.
They'll tell 2 friends, and they'll tell 2 friends. This makes marketing easier. It is far easier to make money from something people love than to "popularize" something that they don't.
When a customer is inspired by a product, they associate the product with the maker. They are always thinking, I wonder what will come next? If you've inspired them at least once before, you'll get more of the benefit of the doubt with a new undertaking.
So what does it mean to build something inspiring? We know it's not "good enough but 20% cheaper". Here are some rules of thumb to help you tell:
If you quit here, you're quitting too early.
You have created something forgettable.
Here's the kicker. If you want to build an inspiring product, you're going to need a team of not just talented, but inspired people.
And who's going to inspire them? You are. How do you inspire a team?
Why, you infect them, of course. You find your own inspiration and people can just feel it. It oozes.
It starts with one person. Inspiration is not something you can fake. People see through it.
Easily. While you can't create inspiration, you can find it. Let's face it.
All of us would prefer to be inspired than not. In the hustle and bustle of daily life, it's so easy to forget what inspired us in the first place, or to lose it somewhere along the way. It's well worth taking the time to stop and find it again before you proceed.
It's infectious. So is the lack of it.
Go forth and inspire!
While I'm not thrilled with the title (sounds too demanding), I can certainly see the benefits of what's being advocated. All a software is, is people. The better equipped they can be, the better off the organization.
I know this is how it shall be at Devshop. A developer with poor equipment is like a sports car with a rev limiter. It just ain't right!
| I get asked somewhat regularly about the practice of resource loading in software projects. Now, besides the fact that it refers to people as resources (which reminds me of that horrible phrase: ), the practice is not all it's cracked up to be - for software projects that is.
For those of you not familiar with it, it's the process of loading up team members a little at a time (by x%) until presumably their allocation hits 100% and they are now fully booked and unavailable for more work.
So for example, you might add a bunch of part-time tasks (say 25% worth) to a person for a couple of days during a particular week, then look at a resource allocation view to see that this team member is 25% booked on Monday through Wednesday.
This practice has a lot of face value (face value = intuitively perceived value). However, it also comes with some serious draw backs that a lot of people aren't necessarily aware of.
First, the very existance of the ability to allocate people on part-time tasks comes with the cost of having to (often manually) manage this new variable (x% allocation) by team member, over time. This means constantly checking to make sure that no-one has become more than 100% booked for any period of time - otherwise, the schedule is no longer achievable. While some extremely organized project managers have built this into their daily routine (and are extremely hesitant to let it go), the average case goes more like this:
In reality, because of factors like Distraction Rates and Time Estimation Error, a good planner should only book people to some number less than 100% to account for these errors and delays. Especially in software projects.
Engineers really need to sit down for larger chunks of uninterrupted time to focus on particular features. Some have said that the amount of time that it takes for a coder to get "in the zone" can be hours before that coder reaches optimal productivity and quality output. This says to me that there is a serious productivity cost to actually scheduling by the part-day (which equates to this % allocation way of scheduling).
Third, often times when you're thinking about a particular "task" as being part-time over a period (say 50% over 2 weeks, for example), what you're really talking about is a short-hand for, "I've got a longer-term activity that I'm going to break into chunks and work on between now and then", which can often also structured as a task-group and broken into individual tasks. So for example, instead of thinking of "build the data storage layer" being something you do 50% of your time over a period of a month, why not break it down further into components and schedule those components for a day (or couple) days at a time? That way you avoid the cost of context switching (increasing productivity and quality) and get greater visibility out of your schedule.
Sure, little things will come up that take an hour here and there, but there are other ways of accounting for that, and at the granularity of a schedule (vs. a ), counting each individual hour offers a .
Finally, and I think most importantly, there are a lot really powerful things you can do with managing risk in a schedule (which is pretty darn important in software projects) that is modelled like a queue (a one dimensional space - like a timeline).
When your schedule is modelled in 2 dimensions (time and x% allocation), you lose the ability to make some very good assumptions (like no-one should be more than 100% allocated AND a person can only be booked on a single "large" task at a time). These important assumptions (or scheduling rules) can serve to reduce the complexity of working with your schedule. They can serve to reduce errors and time-suckage, and actually help you manage risk.
does this automatically by factoring in time for Time Estimation Error and Distraction Rates that have been individually tracked by team member over time.
My opinion of resource loading as a practice is that it is a short-hand notation for what should actually be broken down into discrete tasks. In the very short term, it feels like a good way to model work because our brains like to think in terms of patterns (doing something for y% of each day for 2 weeks is a lot easier to remember than 20 individual tasks, 2 per day for 10 days).
However, we're writing this stuff down anyway right? Might as well break it down and reap the benefits of those pretty basic assumptions about not overbooking someone and not incurring the extra time-suck factor for manually watching over x% allocation or worse - getting caught with your pants down one day when you notice the schedule you just promised someone shows some people double booked and isn't actually achievable.
Unfortunately no single model of scheduling will allow you represent with perfect precision the work as it will actually occur.
The trick is choosing a model that for a reasonable amount of input, produces the best result - and for software, that's all about delivering on time, and fending off risk. Your best bet is to choose a model that is designed to help you deliver on your mission. One model might be better for managing the schedule for part-time employees at a Home Depot, whereas another is more appropriate for the dynamics of a software team.
For software projects, your mission is delivering high quality products on-time. Choose wisely.
On To-do Lists, Calendars and Schedules
You might be wondering, which one is the best? But that's kind of like asking, "Which is better, a saw or a hammer?" The answer depends on what you're trying to do, of course.
Where I find people get off on the wrong track with managing software projects is that they haven't necessarily stopped to think about which tool is right for which job.
I personally believe all 3 have a place in a software shop. Knowing what to use where is the trick.
To-do Lists are perfect for tracking activities that take less than a couple hours each and someone is worried about them slipping through the cracks.
Big things get all of the attention. The little things tend to get forgotten (and if you've ever read anything I've ever written, you know that I believe it's the little things that often separate a good product from a great product).
To-do Lists are great for tracking the little things.
Since a To-do list is a queue (optionally with a priority, maybe some due dates or a few other tidbits of information), they work best when "managed" as a queue. That is, keep throwing things on the end as they come up (the "push"), and keep lifting them off the list whenever you have time to tick a few off (the "pop"). Every once in a while, you can re-order things so that the more important ones get done first.
They're great for tracking things that aren't yet scheduled, or for wish-lists that will later be moved from the To-do List to the Schedule.
To-do Lists are terrible for scheduling when you've got more than one person on a project. Because of their linear nature, To-do Lists trick you into using over simplified calculations like "add up all the work and divide by the number of people" to figure out when all of the work will be complete.
This method of estimating finish date is wrong almost all of the time.
Calendars are great rallying tools. Stick a couple high-level goals on them and put them on the wall in high traffic areas.
The 30 little boxes are just great for about 1 or 2 phrases on a couple of dates, or a couple big red X's. Try to put anything more than that and they become downright unusable (they have very limited visualization capabilities). I've seen quite a few people try to run a schedule off a calendar by drawing ovals that span across several days to show they last a while.
It gets far too messy when you're talking about activities that span weeks or straddle a month-end border. If your work breaks down from big activities into little activities (like most software activities do), then you're hosed.
I should also mention that I AM a very big fan of using Calendar tools (Outlook, Mail, whatever) for tracking of personal time after the fact.
That is, by jotting down a new item in a personal calendar every time you spend an hour on this or 2 hours on that, it's way easier to look back at how time is actually spent on a weekly basis. What I'm saying here is that a Calendar isn't a great tool for planning anything other than meetings, in the future.
The most popular visualization of a Schedule is the Gantt chart.
That word "Gantt" is sometimes enough to make some people laugh or cry depending on their disposition. I even hate to use the word sometimes because it tends to be synonomous with a particular project management tool that many people love to hate.
I think part of the mis-trust of Gantt charts stems from the fact that a lot of people have had bad experiences while trying to get it to be the one be-all-and-end-all view of a project - something it cannot do.
However, neither can the Calendar or the To-do List.
The Gantt chart is however, probably the single best visualization of an overall schedule for multiple people working on a project concurrently - especially if the work is complex enough that it breaks down from larger activities or goals into smaller activities or goals.
By now, you should be able to see where I'm going with this.
..
You wouldn't try to build a house with just a hammer (makes measuring and sawing awfully difficult).
Why would you try to manage a complex software project with only one view of your project? Well you probably would try because you thought it would be simpler than having multiple views, right?
Everyone on the team should have their own To-do List for the fiddly little bits that are on their plate, to be done some time during the project.
These lists can be public (at least visible) to the team so everyone knows who's on the hook for what fiddly-bits.
There should be a master "team" To-do List. Fiddly-bits first get thrown onto the team's To-do List and then get moved from there to some team member's To-do List when the appropriate person is identified.
Fiddly-bits are less than a few hours work by definition. They're important, but too micro to be gumming up a Schedule or Calendar view.
There should be a team calendar with only a few big milestones on it, that are important to the whole team.
These are rallying points. Don't go gumming it up with individual milestones, fiddly-bits, or to try to use it as a Schedule. The less big red X's on any given month, the more focus each will receive.
Use a Schedule for activities that are bigger than 1 day's work each. Use the Schedule to break down big chunks of work into little chunks of work. It's your main tool for managing a whole team of people working concurrently.
You can prioritize, shift work around and get a "whole project" view (even though you may be breaking your whole project into iterations or sprints, kudos if you are).
Each of these views has something different to offer, and the best managed project will typically make use of all of them to their best advantage.
People get the most frustrated when they either try to use one view in particular to manage the whole project, or start off with something simple because that's all they need at the time (a To-do List or Calendar for example), then get into that awkward phase where their needs have outgrown the "single view" but they haven't quite realized it yet.
If that sounds like the stage you're getting to, hopefully this article helped you spot it!
A couple weeks ago, a colleague of mine asked if I had any good questions I used when interviewing someone to lead a development team.
I came up with this list of questions and "things to listen for" in the responses.
Anyone else have any humdingers they ask interviewees?
A lot of software projects fail. Building software is really complex.
If we determine success as: coming in on time, on budget, with a rock-solid product, what would you say your success rate has looked like over the years?
It’s ok to fail. The ideal evidence you’re looking for, even better than someone that says they’ve almost never failed, is someone that started off average in the beginning (remember, 70% of software projects fail), but who turned it around and ended up with a consistently successful track record after that.
That tells you several things: the person is honest, confident in his/her abilities, willing to admit mistakes, learned over time and adapted.
What are the top factors that keep slamming software projects in particular?
Look for domain knowledge of the software space.
General purpose project management experience may not be enough for complex software environments. Look for tangible factors that can be measured and managed – that’s what good managers look for. Saying that “communication is important” is useless.
You can’t manage what you can’t measure.
Some examples of software killer factors that can be measured, and therefore managed:
Most people will telling you they manage them “internally” (with their gut, or in their head). Um, sure.
Ask for tangible examples or evidence that they do this.
Otherwise, they’re probably just telling you what you want to hear and don’t actually behave that way.
Managing all of those things starts with keeping a lot of notes and records. Really good ones will even model them in a spreadsheet.
There are so many fiddly-bits that go into software projects that if you can’t go back and look at the record for what happened, then it didn’t actually happen (people will forget and there is no proof of any problem).
Software managers usually come in two flavors: those that come up through the ranks from a technical background, or those that are professional managers (never been a developer). Which would you say you are?
Beware of “manager-only” managers. Coming back to the domain experience thing, “professional” (read: jack-of-all-trades-master-of-none) managers struggle with software projects.
There is far more complexity and risk in these types of projects than in others.
It’s easier to teach a super programmer how to manage than it is to take an otherwise very organized person (the professional manager) and teach them what they need to know about the software life cycle, the unique challenges and risks, and what to do about them.
Above all, look for people who are really passionate about great software. Someone who's solely going to tick items off a to-do list until they can say they're "done" isn't going to produce great software.
And, producing mediocre software on-time isn't as good as producing great software a little later.
| I couldn't have said it better. Check out the
You said it Kathy.
While I'm not sure every problem can be boiled down to five tabs, that should certainly be our constant goal.
| I read from Rick Segal, a Toronto based VC, where he describes sitting down with a big company, asking them if they ever worry about some small player coming up from behind and stealing their customers. The big company responds with "ha, that would take years.
" Rick then goes on to describe how he demonstrated right before their eyes (even coding some in front of them?) how this might be far easier for a grad-student to do than Big Company thinks..
.
What? A VC actually wrote code on the spot, that duplicated core functionality of a Big Company product?
Something's not quite right here...
Rick is clearly telling this story to make a point. Big Companies: don't sit on your ass. Development costs, marketing costs, and switching costs are all lower than ever.
If there's money to be made, the competition will heat up and people will be coming after you constantly.
And while I sense there may be a small bit of exaggeration in Rick's story, he makes a couple of good points:
All you read about now is "ship early and often." As if anyone building anything for longer than 2 months is a complete idiot and obviously "doesn't get it."
In general, I am also a believer that your bias in development should be to get "something" (anything) working end-to-end first (a complete skeleton) and then iterate like crazy to fill in the missing pieces and keep raising the value of your app - even if it means going back and re-writing some pieces later (classically trained developers hate to re-write code.
They want to design and write something once that will work for everything and live forever, which is, futile. Every day you wake up, you know more about the problem than you did yesterday when you wrote the code.)
These places really are scary.
They're like "broken homes" of development. They've sunk more than one company. But today, even though web development is still only a sliver of "all software development" going on world-wide (including embedded devices, server software, desktop software, etc.
), us Webbies have the biggest voice. Why? We're born and bread on a communications medium of course (the Web).
So now, what seems to be working for a pile of Web 2.0 companies is being pushed on everyone without stopping to think if it is really appropriate. (I say seems to work because sooooo many Web 2.
0 plays have yet to monetize anything, particularly on the consumer side [free stuff]).
So, while I believe "ship early and often" is a great bias to begin with, here are some things that you really should take into consideration before rushing something out the door, convincing yourself you'll iterate like crazy (a.k.
a. fix it later).
You may be better off taking the extra time to get it right the first time and not have to iterate to fix a bug or plug a feature gap.
A little more work up-front with respect to performance and scalability can go a loooooong way for you later in the game. One of the myths in the software world is that "we'll have more time later." Wrong.
You'll have less time later (for development) because you'll suddenly inherit a bunch of support and maintenance responsiblities that will eat up your dev time. The trick is to be realistic about not over-engineering. You likely won't have 1 million users in the first month, despite what your biz plan says.
After you've done the hard part (design) and they only have to copy and add their own spin? In this kind of world, you're better off making sure that when you do ship, you've put something in there that is going to make the competition scratch their head for a while before they can duplicate it.
!! Could your process do that?
" As a friend of mine said, "anything can be built quickly - the question is, how well was it built?". In other words, don't confuse a rapid prototype with a rock-solid, scalable, configurable, high performing product.
Those ones take much longer than 2 weeks (or 2 months) to build. If you are building one of those bigger apps, then I would simply tweak the mantra to "Build early and often" so that you do actually have a version that someone can use as early as possible and keep giving you feedback at every iteration - just don't automatically rush to ship it unless you've thought about the factors I listed above.
| I meet a lot of software project managers.
One of the things I see a lot of is people building schedules with tasks that have more than one person assigned to them. You know, like "Write documentation, 10 days, Billy Suzy".
This is an example of a tool giving a user just enough rope to hang themselves.
Most people wouldn't look at that and think twice about it. But let me ask you the following questions:
In reality, what people do is take a single "conceptual" task, and break it up into sub-tasks so that they can each do some. Unless they are both using the same pencil, the same sheet of paper, or the same keyboard and sitting in the same chair, then that one conceptual task should be further broken down into sub-tasks until you get one person assigned to one thing at a time.
As long as there are two names beside a particular task, each person has an increase of 100% in the number of people they can blame for things going nutty.
As long as there is more than one name beside the task, each person inherits the excuse that "I thought someone else was taking care of that."
Often times, people confuse "who's responsible" with "who's doing the work". It may in fact be that the odd task does take literally several people to accomplish (and those are rare), but even so, you're much better off choosing one of those people to be on the hook.
One person to represent the others. This one person is responsible for the time estimate for the task. This person is on the hook for delivery of the task.
This person can make decisions regarding the task if something comes up during it. Without a single point of responsibility, authority and contact for a single task, real accountability dwindles and risk increases with every name added to the list.
If what you're trying to do is simply show that 5 people are booked during a particular task and are unavailable for other work, consider assigning a separate task to each of the 5.
There are very few "work items" in software that get produced by more than one person, if you really break it down. The only think I can think of that truly takes more than one person in a software project, is a conversation, or a meeting. Hardly worth cramming into the schedule unless it lasts at least a half day or more.
"...
you can push as much as you'd like, but you still can't think any faster."
"9 women can't make a baby in a month."
"You can't fit 2 gallons in a thimble no matter how fast your pour.
"
There's just no excuse for planned overtime in a software project. And it's not just because people don't like it (though from a morale point of view, that's enough reason).
The trouble with overtime is that it begets more overtime if not managed very carefully (it's a slippery slope).
The concept of "making up time" for a late item is a fallacy. You're likely to think it will work after your first work item runs late. By the time the 2nd one also runs late, something should smell funny to you, and by the 3rd time a work item runs late, you should know better!
The reality is, if a couple items early in the project run late, and you work overtime to make up for them to get back on track, what makes you think that the rest of the schedule was actually estimated properly? Oops, there you are in a state of continuous overtime.
uses the analogy of a sinking ship to demonstrate how the knee jerk reaction of overtime actually hurts the chances of success.
If a ship is sinking at sea and the Captain orders all the sailors to bail water, this may help for a short period of time, but eventually all the sailors get too tired to bail and everyone goes down with the ship. Instead, they should be looking for the leaks..
.
I like to think of it as "good overtime" vs. "bad overtime".
Planned overtime is bad overtime. No matter how good you believe your project plan is, it is wrong and things are going to take longer than expected. So if you're already cranking up the overtime in the plan, you've left yourself absolutely no buffer to give a little extra push if some correctable slip does occur - you're already at maximum capacity.
Working overtime is like red-lining a car engine. You can do it once and a while to get maximum performance while accelerating. But if you constantly run your engine that way, it's simply going to blow up.
People that advocate regular planned overtime demonstrate their clear lack of understanding of the software development discipline. It is a highly creative activity and one that has many serialized pieces (this can only be done after that). In many cases it's tough to parallelize the problem to get it done faster by adding people or working evenings and weekends.
You're better off looking at the causes: Are we trying to do too much? It's there a simpler thing we could build that still solves the customer problem?
Whole books have been written on the subject of the effects of overtime, but basically it boils down to this:
How about we plan our projects so that we can have fresh, energized, motiviated, creative people who are passionate and commited build our software instead?
How long would it take if everything went wrong?
Geez, another really good post over at . Jeff is reading .
If you ask a developer to estimate a set of features, the developer will often come back with an estimate that looks like this:
Mention the words "maintenance programming" to a group of developers and they'll, to a man (or woman), recoil in horror. Maintenance programming is widely viewed as janitorial work.
A janitor.
But maybe that's an unfair characterization.
To manage the balance between "new" development vs."maintenance", one thing I've done is to say that if you wrote the code, you maintain it. It's far too easy to write sloppy if you know someone else is going to have to clean up your mess - same deal with coders throwing buggy code over the wall to Q/A. I like having people incented to write clean and maintainable (for themselves later) from the get-go.
Also, that way everyone writes new code and everyone maintains - so no bickering!
Um, and who's thinking about the janitors?!Does anyone think they appreciate being compared to maintenance coders?! ;) Just teasing.
We coders are a lucky bunch to get paid to do what we love. But that doesn't change the fact that work is work and sometimes it's hard and not fun.
| You've probably heard or read about the theory that being a "leader" is different than being a "manager" (a theory I'm sure I've mentioned before, that I emphatically do not believe - afterall, to be good at either, you need a little of both running through your veins - though I'd certainly admit that people do have preferences or affinities towards one or the other).
ANYWAAAAY...Here's a crack at trying to better explain what I think the originators of that theory may have been trying to capture. I've used the word Exec (Executive), but you could easily substitute manager, leader, overlord or any other word that means "person who makes the rules".
Throughout the life of a company, the company needs different kinds of executives.That much is pretty well commonly understood. However, a lot of people think that at one particular stage, you swap in one type of leadership for another, like the leadership that got the company to that stage is somehow no longer required. This manifests itself typically as the "founder ousting" stage.
I suppose in some lines of business this could possibly be true (I wouldn't know), but I don't buy it for software companies. And of course, I will explain...
Software is one of the most creative types of business there is. It gets compared a lot to manufacturing, which I've explained to several folks is not a very good comparison.
News RSS