One thing I have seen a lot of is validating requirements with a completed system. This has been sometimes misnamed "User Acceptance Testing".
This typically means that someone shortchanged requirements gathering, by making a guess at what the users need, and having the developers do it.
In its most pathological mode, "User Acceptance Testing" also suggests that the users are doing functional testing as well, and that developers do not need to test their product.
Sunday, December 11, 2005
Requirements Uncertainty Anti-Pattern
One strategy I have seen for 'managing' requirements uncertainty is to hire permanent or contract developers so that they are available to respond to requirements changes. I call this the 'embrace and extend' anti-pattern. Instead of minimizing the chances of this risk materializing, or limiting the effect of this risk in the event it does materialize, this approach accepts the maximum penalty for risk materialization from the outset, and actually encourages requirements changes. Why do managers engage in this anti-pattern? What are some alternatives?
"We're not a software shop."
Working as a developer in IT organizations, I hear this objection "We're not a software shop" come up a lot when people suggest things like using revision control, or writing down requirements, or formalizing change management.
Saying that because we are not a software company, we can do a good job of developing software without employing the techniques of professional software developers is like saying that because I am not an athlete, I can win a triathlon without training.
Saying that because we are not a software company, we can do a good job of developing software without employing the techniques of professional software developers is like saying that because I am not an athlete, I can win a triathlon without training.
Thursday, October 27, 2005
Contentious Issues Aren't.
Often we will waste tremendous amounts of time debating a choice between alternatives. Where to have lunch, how to implement a feature, how to model some data, blah, blah, blah, ad nauseum.
Funny thing is, we usually don't get into debates like this unless there are compelling arguments on both sides of the issue. The more heated the arguments, the more likely it is that either alternative provides near equal utility.
In these cases, you might as well flip a coin. Make an arbitrary decision; move on.
Similary, don't bother defending the alternative you chose under such circumstances. You made a choice because you had to, not because you had a clear superior alternative. If you could have defended your alternative, the decision wouldn't have been arbitrary.
Funny thing is, we usually don't get into debates like this unless there are compelling arguments on both sides of the issue. The more heated the arguments, the more likely it is that either alternative provides near equal utility.
In these cases, you might as well flip a coin. Make an arbitrary decision; move on.
Similary, don't bother defending the alternative you chose under such circumstances. You made a choice because you had to, not because you had a clear superior alternative. If you could have defended your alternative, the decision wouldn't have been arbitrary.
Thursday, October 13, 2005
Boing Boing: FIling system optimizes documents by use-frequency
This rather different approach to filing treats the file cabinet as a "stack". When you file something, you put it at the front of the shelf. When you pull it to work with it, you return it to the front of the shelf when you're done. This results in the files naturally moving to the back of the shelf if you're not working with them, and staying near the front of the shelf if you refer to them frequently.
On the one hand, intriguing. On the other hand, sounds an awful lot like the pile of folders I had on my desk before I learned to file things away.
On the one hand, intriguing. On the other hand, sounds an awful lot like the pile of folders I had on my desk before I learned to file things away.
Wednesday, October 12, 2005
Two great online resources
CreatingMinds.org is a collection of creativity methods for generating and selecting ideas.
ChangingMinds.org is a collection of persuasion methods.
Both of these sites are maintained by David Straker, author of the cult classic Rapid Problem Solving with Post-It Notes
ChangingMinds.org is a collection of persuasion methods.
Both of these sites are maintained by David Straker, author of the cult classic Rapid Problem Solving with Post-It Notes
i d e a * i d e a - How to Bubble Map - drawing your To Do the stress-free way -
Great idea for visualizing your to-do list in terms of how much mindshare each item has. Could also be adapted for how Important or Urgent.
Thursday, June 09, 2005
Meeting folio
I've been crazy busy lately. What has it been, a month since I've posted? Here's a quick around-the-office hack to tide us over:
Keep a padfolio with its own pad and pen, which you only use for meetings. When you print out agendas or other materials to distribute, stick them in the folio so they'll be ready for your meeting.
You can also keep spare reading material there, to get to while you're waiting, in case of delays. Having something to read or work on beats sitting, twiddling your thumbs.
You don't have to buy an expensive padfolio of "rich, Corinthian leather", either. I actually have 2 expensive padfolios that I received as gifts, but never used because I thought they made me appear a little too self-important. I got a down-to-business, plastic, yet still presentable folio at the local office supply store for under $5.
Keep a padfolio with its own pad and pen, which you only use for meetings. When you print out agendas or other materials to distribute, stick them in the folio so they'll be ready for your meeting.
You can also keep spare reading material there, to get to while you're waiting, in case of delays. Having something to read or work on beats sitting, twiddling your thumbs.
You don't have to buy an expensive padfolio of "rich, Corinthian leather", either. I actually have 2 expensive padfolios that I received as gifts, but never used because I thought they made me appear a little too self-important. I got a down-to-business, plastic, yet still presentable folio at the local office supply store for under $5.
Tuesday, May 03, 2005
More on the deck of revolving strategies
So, I mentioned in my previous post that I have created a deck of index cards with different strategies for choosing what I'm going to work on that day.
I decided I would give this method a trial week. So every morning this week, after I process my inbox, I look over my task list quickly to get an idea of everything I have to do in context. Then, I flip through my strategies, and consider my energy level, focus, available time, and various pressures and priorities. And then I pick a strategy.
Then, I choose the tasks to work on that fit in with my strategy, and build a quick list of to-dos for the day.
So far, it's working really well - I'm impressed. Here's what I think is going on for me: By deciding up front what my overall strategy for the day will be, it is very easy to pick and choose exactly which tasks I'm going to work on. If I choose to work on Squeaky Wheels - I can stop hemming and hawing about whether I really ought to include some high-value stuff, too. I'll get to that tomorrow - today I'm oiling those squeaky wheels. I know exactly which projects those are, and I've made a choice to hammer on them for the rest of the day. Planning is easy.
Another thing - it doesn't come naturally to me to do a lot of task switching. So, a strategy like "Touch as many projects as possible" is something I wouldn't naturally decide to do. It just feels wrong. Or it did, until yesterday.
Yesterday, I considered my priorities, and after looking at my deck of strategies, I surprised myself by deciding that "Touch as many projects as possible" would serve my needs best. It was one of my most productive days in weeks.
Today, I worked on Squeaky Wheels. It served my needs. Two of my coworkers commented on my high output today.
I think I like this - we'll see how it holds up over time.
I decided I would give this method a trial week. So every morning this week, after I process my inbox, I look over my task list quickly to get an idea of everything I have to do in context. Then, I flip through my strategies, and consider my energy level, focus, available time, and various pressures and priorities. And then I pick a strategy.
Then, I choose the tasks to work on that fit in with my strategy, and build a quick list of to-dos for the day.
So far, it's working really well - I'm impressed. Here's what I think is going on for me: By deciding up front what my overall strategy for the day will be, it is very easy to pick and choose exactly which tasks I'm going to work on. If I choose to work on Squeaky Wheels - I can stop hemming and hawing about whether I really ought to include some high-value stuff, too. I'll get to that tomorrow - today I'm oiling those squeaky wheels. I know exactly which projects those are, and I've made a choice to hammer on them for the rest of the day. Planning is easy.
Another thing - it doesn't come naturally to me to do a lot of task switching. So, a strategy like "Touch as many projects as possible" is something I wouldn't naturally decide to do. It just feels wrong. Or it did, until yesterday.
Yesterday, I considered my priorities, and after looking at my deck of strategies, I surprised myself by deciding that "Touch as many projects as possible" would serve my needs best. It was one of my most productive days in weeks.
Today, I worked on Squeaky Wheels. It served my needs. Two of my coworkers commented on my high output today.
I think I like this - we'll see how it holds up over time.
Saturday, April 30, 2005
high octane moron: Revolving workflow strategies
I ran across the article below earlier in the week, and finally got around to playing with the idea a little bit last night:
high octane moron: Revolving workflow strategies
In classic hipster style, I decided to print myself up a deck of "daily strategy cards". I'm going to start playing with these as a means to quickly pick an organizing strategy to plan my work day.
I've played with and added to the list of strategies, and this is what I have in my "deck" so far:
Any other ideas for work strategies?
high octane moron: Revolving workflow strategies
In classic hipster style, I decided to print myself up a deck of "daily strategy cards". I'm going to start playing with these as a means to quickly pick an organizing strategy to plan my work day.
I've played with and added to the list of strategies, and this is what I have in my "deck" so far:
Touch as many projects as possible: Keep things moving.
Lots of small tasks: Reduce the task list, work on low hanging fruit.
Newest First: Get things started.
Oldest First: Break through procrastination, maintain focus.
Goal driven: Keep your activity congruent with your goals.
Big chunks of time: Flow.
High Value: Avoid the urgency trap.
Most interesting: Stay engaged.
Most guilt inducing: Work through your blocks.
Squeaky Wheel
Any other ideas for work strategies?
Monday, April 11, 2005
Writing better Transact-SQL code with good comments
So, I write IT software, and much of the time, that means I'm dealing with Microsoft SQL Server. Funny thing about that... I've worked with a lot of programmers over the years, good programmers... but it never ceases to amaze me how all of their good coding habits go out the window when they need to write some Transact-SQL code.
Here are some tips to make life easier on yourself and those who will need to read and maintain the code you've written, through effective and creative use of comments.
Positive patterns:
1. Use descriptive comments
Comments in code should always describe what the code needs to accomplish, rather than how the code functions. For example:
Rather than:
2. Use comments to clarify the structure of your code
Structural comments can be used sparingly as part of a coding standard to introduce useful structure where the language elements do not provide enough. Some useful "structure" comments include using comments to "name" code blocks enclosed by BEGIN and END statements, such as:
Another kind of structure comment can add a "THEN" to the T-SQL IF statement:
Implementing the above structure for if statements particularly enhances readability where there is a long test expression IF clause, by clearly seperating the expression from the nominal case, just as the ELSE seperates the exception case from the nominal case.
3. Distinguish explantory comments from planning comments
I recommend using /*...*/ style comments for anything meant to live on as comments in production code.
For to-do notes, or pseudocode, both of which should be removed before the system moves into production, I recommend using "--" comments. This makes them easy to find.
4. History comments
I have never personally found these helpful, although capturing data about how often particular code is touched, and for what reasons, can be useful. If they are used, they are best put in a footer to keep the routine declaration close to the code.
5. Summary comments
A very brief header summary, which describes the requirements of the routine (but not the implementation) is useful. However, structured comments which include Author, Create Date, etc., offer very little value, IMHO.
Comment Anti-Patterns:
1. Reduntant comments
Comments that describe how, rather than what, are worse than useless.
2. Dead code
Commenting out code which is no longer executed because of requirements or implementation changes. This should be removed from the code. If you need to see it later, you can get it out of your revision control system.
3. "Paper-trail" comments
Eg. -- column added 2/2/1993 by JC
Why?
4. CYA comments
Eg. -- This code will break when two customers try to buy the same product
Comments like this give carte blanche to do almost anything, no matter how low quality. This leads to better solutions not being sought out.
If this is the only place risks and quality problems are captured, there is no opportunity to see them all together in order to prioritize fixes, or to see emerging patterns that require a pattern-based solution
5. Planning comments
For positive patterns in planning comments, see number 3 above. Negative planning comments include things such as "need to implement xxx" or "should update to include xyz". If this is the only mechanism for capturing technical needs, there is no visibility during planning activities, and there is no opportunity to see them all together in order to prioritize.
Further reading:
Steve McConnell's treatment of use of comments in Code Complete is excellent.
Here are some tips to make life easier on yourself and those who will need to read and maintain the code you've written, through effective and creative use of comments.
Positive patterns:
1. Use descriptive comments
Comments in code should always describe what the code needs to accomplish, rather than how the code functions. For example:
/* insert reward discount for referring a customer */
Rather than:
/* execute insert on CustomerRewards table */
2. Use comments to clarify the structure of your code
Structural comments can be used sparingly as part of a coding standard to introduce useful structure where the language elements do not provide enough. Some useful "structure" comments include using comments to "name" code blocks enclosed by BEGIN and END statements, such as:
BEGIN /* customer record is new */
...
END /* customer record is new */
Another kind of structure comment can add a "THEN" to the T-SQL IF statement:
IF EXISTS
(
SELECT
*
FROM
CustomerDiscounts
WHERE
CustomerID = @CustomerID
)
/* THEN */
BEGIN /* customer has a discount */
...
END /* customer has a discount */
ELSE
BEGIN /* customer does not have a discount */
...
END /* customer does not have a discount */
Implementing the above structure for if statements particularly enhances readability where there is a long test expression IF clause, by clearly seperating the expression from the nominal case, just as the ELSE seperates the exception case from the nominal case.
3. Distinguish explantory comments from planning comments
I recommend using /*...*/ style comments for anything meant to live on as comments in production code.
For to-do notes, or pseudocode, both of which should be removed before the system moves into production, I recommend using "--" comments. This makes them easy to find.
4. History comments
I have never personally found these helpful, although capturing data about how often particular code is touched, and for what reasons, can be useful. If they are used, they are best put in a footer to keep the routine declaration close to the code.
5. Summary comments
A very brief header summary, which describes the requirements of the routine (but not the implementation) is useful. However, structured comments which include Author, Create Date, etc., offer very little value, IMHO.
Comment Anti-Patterns:
1. Reduntant comments
Comments that describe how, rather than what, are worse than useless.
2. Dead code
Commenting out code which is no longer executed because of requirements or implementation changes. This should be removed from the code. If you need to see it later, you can get it out of your revision control system.
3. "Paper-trail" comments
Eg. -- column added 2/2/1993 by JC
Why?
4. CYA comments
Eg. -- This code will break when two customers try to buy the same product
Comments like this give carte blanche to do almost anything, no matter how low quality. This leads to better solutions not being sought out.
If this is the only place risks and quality problems are captured, there is no opportunity to see them all together in order to prioritize fixes, or to see emerging patterns that require a pattern-based solution
5. Planning comments
For positive patterns in planning comments, see number 3 above. Negative planning comments include things such as "need to implement xxx" or "should update to include xyz". If this is the only mechanism for capturing technical needs, there is no visibility during planning activities, and there is no opportunity to see them all together in order to prioritize.
Further reading:
Steve McConnell's treatment of use of comments in Code Complete is excellent.
Sunday, April 10, 2005
Google Maps + Real Estate Listings = Wow
So beautiful I almost cried
And it uses listings from Craigslist - it's like somebody put chocolate in my frickin peanut butter.
And it uses listings from Craigslist - it's like somebody put chocolate in my frickin peanut butter.
Thursday, April 07, 2005
Google Maps: Yeah, me too.
Like seemingly everyone else, I continue to be somewhere between impressed and astounded by Google Maps, and now, with the recent addition of satellite photos, I can't hold it in any longer.
My wife and I are currently house shopping. Enough said.
Well, maybe not quite enough. I have a couple different options for viewing online real estate listings on the web. They're disappointing. The search criteria are restrictive and clunky.
Go to Google, find a location... Now do a local search, say for pizza. Oh, my. Realtors, are you listening? Give these guys a call!
Or, perhaps give these folks a call. They are working with data from a local fire department to use Google Maps to display recent fire alarms in their area.
Or these guys. We are only scratching the surface, here.
My wife and I are currently house shopping. Enough said.
Well, maybe not quite enough. I have a couple different options for viewing online real estate listings on the web. They're disappointing. The search criteria are restrictive and clunky.
Go to Google, find a location... Now do a local search, say for pizza. Oh, my. Realtors, are you listening? Give these guys a call!
Or, perhaps give these folks a call. They are working with data from a local fire department to use Google Maps to display recent fire alarms in their area.
Or these guys. We are only scratching the surface, here.
Friday, April 01, 2005
Wednesday, March 30, 2005
Escaping the Email Black Hole
I thought I'd take a moment to share my email "system". This is the method I use to keep from becoming overwhelmed by the volumes of email I get, and also make sure that nothing important slips through the cracks and is missed.
I've cribbed heavily from David Allen's Getting Things Done in putting this together for myself - if you try this out and like what you see, consider it a teaser for the complete time management system David describes in his book.
On to my system...
I have six mail folders. The first two are Inbox and Sent. Most email software gives you those by default.
I have added four others: Actions, Reading, Waiting, and Saved.
So my complete email folder list is:
Inbox
Sent
Actions
Reading
Waiting
Saved
The key to this system, and to many other methods, is that the Inbox is always empty. Always. Whenever I check my email, the goal is to empty my Inbox.
How to empty the Inbox:
One by one, open each email.
Can I delete the email immediately? If yes, then I do so and move on.
Can I deal with the email in the next minute or so? If so, then I deal with it, and file the email in Saved.
Otherwise, I file the email in one of my folders.
Actions is for mail that I need to respond to, or requires some action on my part.
Waiting is for mail I need to somehow follow up on, or wait for a response.
Reading is for things I want to read, but require no follow-up from me, and are not especially time-sensitive. This is the only folder I use "rules" to automatically sort mail into.
Everything else gets filed in Saved. Yikes! How will I ever find it again??? More on this in a minute.
There's one more folder in my system: Sent.
I treat the Sent folder just like my Inbox. I keep it empty. Quite a lot of the time, I can just file the email in Saved. But if I've committed to further action, or delegated a task to someone else and want to maintain awareness and follow-up, I will file the email in Actions or Waiting.
Ok, what about this filing everything in Saved? How can I organize all my email by project, or recipient, or month sent, or priority, or whatever other method I want to use?
I used to spend time filing my email into different folders for different purposes, but I don't bother with that any longer since I started using a good search tool for my email. I've been using Copernic Desktop Search, and am very happy with it. I can always find anything I'm looking for much faster than the bad old way, and I never have to maintain my filing system, or decide where something goes.
If you like what you've seen so far, check out David Allen's Getting Things Done: The Art of Stress-Free Productivity.
I've cribbed heavily from David Allen's Getting Things Done in putting this together for myself - if you try this out and like what you see, consider it a teaser for the complete time management system David describes in his book.
On to my system...
I have six mail folders. The first two are Inbox and Sent. Most email software gives you those by default.
I have added four others: Actions, Reading, Waiting, and Saved.
So my complete email folder list is:
Inbox
Sent
Actions
Reading
Waiting
Saved
The key to this system, and to many other methods, is that the Inbox is always empty. Always. Whenever I check my email, the goal is to empty my Inbox.
How to empty the Inbox:
One by one, open each email.
Can I delete the email immediately? If yes, then I do so and move on.
Can I deal with the email in the next minute or so? If so, then I deal with it, and file the email in Saved.
Otherwise, I file the email in one of my folders.
Actions is for mail that I need to respond to, or requires some action on my part.
Waiting is for mail I need to somehow follow up on, or wait for a response.
Reading is for things I want to read, but require no follow-up from me, and are not especially time-sensitive. This is the only folder I use "rules" to automatically sort mail into.
Everything else gets filed in Saved. Yikes! How will I ever find it again??? More on this in a minute.
There's one more folder in my system: Sent.
I treat the Sent folder just like my Inbox. I keep it empty. Quite a lot of the time, I can just file the email in Saved. But if I've committed to further action, or delegated a task to someone else and want to maintain awareness and follow-up, I will file the email in Actions or Waiting.
Ok, what about this filing everything in Saved? How can I organize all my email by project, or recipient, or month sent, or priority, or whatever other method I want to use?
I used to spend time filing my email into different folders for different purposes, but I don't bother with that any longer since I started using a good search tool for my email. I've been using Copernic Desktop Search, and am very happy with it. I can always find anything I'm looking for much faster than the bad old way, and I never have to maintain my filing system, or decide where something goes.
If you like what you've seen so far, check out David Allen's Getting Things Done: The Art of Stress-Free Productivity.
Slacker Manager: Manager-chair philosopher
Brendon Connelly at Slacker Manager offers these thoughts about the importance of having a philosophy of leadership or management, and particularly about his own philosophy. The bottom line, he says, is this: "Model the behavior you're looking for and you'll start to see it".
I couldn't agree more, particularly when it comes to attitude. If you bring a negative attitude to your leadership style - if you focus on what not to do, or what is wrong with things, or why someone's idea can't work - that attitude will permeate the people around you. If instead, you "remove roadblocks", focus on what works - that will spread, too.
If you're stuck in a negative frame of mind, then take a minute to shift gears. Try saying to yourself (or to the person you're talking to): "Okay, those are some reasons this thing hasn't caught on yet. Let's think of some ways that we can make it work for us."
I couldn't agree more, particularly when it comes to attitude. If you bring a negative attitude to your leadership style - if you focus on what not to do, or what is wrong with things, or why someone's idea can't work - that attitude will permeate the people around you. If instead, you "remove roadblocks", focus on what works - that will spread, too.
If you're stuck in a negative frame of mind, then take a minute to shift gears. Try saying to yourself (or to the person you're talking to): "Okay, those are some reasons this thing hasn't caught on yet. Let's think of some ways that we can make it work for us."
Tuesday, March 22, 2005
Schedule Slippage and, um, Golf
Around the Boston area, golf is a seasonal activity (well, for most of us). With a couple days of good weather ushering in Spring's return, I've been itching to hit the links again.
I started playing a few years ago - and I'm not very good, but it's a fun game. Par is usually around 72 strokes for an 18 hole course. I consider myself extraordinarily fortunate to break 100 strokes. Well, ok, I did it once. Alone. In the rain.
So, a typical round of golf for me is to be about 2 strokes over for each hole. On a par 3 hole, I'll get a 5. On a par 4, I'll get a 6. I'm thrilled when I make par for a hole - and occasionally I do. And then occasionally, it'll take me more than 2 strokes over par to get the ball into the cup.
Still, ever the optimist, if after 3 holes, I'm 6 over par, I'll estimate my final score at 78, because I assume I'll make par on the remaining 15 holes.
Of course, I know that's not really what will happen. I'll probably get about a 106, because I'll probably be a similar amount over par on every single hole. And if by chance I make par (or even under par) on a hole or two, I'll probably make up for it by being even more over par on another hole.
Ok, I'll stop talking in code now. This is a real-world problem with the usual approach to updating software project plans to account for slippage. (We lost a day? Add a day to our rosy optimistic schedule.)
If after two months of a six month project, you're a month behind - I've got news for you. You're probably on a 12 month project, not a seven month project.
I started playing a few years ago - and I'm not very good, but it's a fun game. Par is usually around 72 strokes for an 18 hole course. I consider myself extraordinarily fortunate to break 100 strokes. Well, ok, I did it once. Alone. In the rain.
So, a typical round of golf for me is to be about 2 strokes over for each hole. On a par 3 hole, I'll get a 5. On a par 4, I'll get a 6. I'm thrilled when I make par for a hole - and occasionally I do. And then occasionally, it'll take me more than 2 strokes over par to get the ball into the cup.
Still, ever the optimist, if after 3 holes, I'm 6 over par, I'll estimate my final score at 78, because I assume I'll make par on the remaining 15 holes.
Of course, I know that's not really what will happen. I'll probably get about a 106, because I'll probably be a similar amount over par on every single hole. And if by chance I make par (or even under par) on a hole or two, I'll probably make up for it by being even more over par on another hole.
Ok, I'll stop talking in code now. This is a real-world problem with the usual approach to updating software project plans to account for slippage. (We lost a day? Add a day to our rosy optimistic schedule.)
If after two months of a six month project, you're a month behind - I've got news for you. You're probably on a 12 month project, not a seven month project.
Good, Fast or Cheap Part II: So what?
So, despite the fact that the old rubrick "Good, fast, or cheap: pick two," does nothing to help us improve our software devleopment efforts - why does it still resonate so much with us, as developers? I think it's a refuge where we express our frustration with schedule and budget pressure that seems unreasonable to us, given that we need to produce software that works.
Nonetheless the reality is that any software effort has to deliver within the constraints of time, budget and quality. What we should really be doing when we're faced with time and budget constraints that seem inadequate to the task, is to express that. If we are sincere, then the effort should be avoided to begin with - or negotiations need to be made which will produce a valued product within reasonable constraints.
Nonetheless the reality is that any software effort has to deliver within the constraints of time, budget and quality. What we should really be doing when we're faced with time and budget constraints that seem inadequate to the task, is to express that. If we are sincere, then the effort should be avoided to begin with - or negotiations need to be made which will produce a valued product within reasonable constraints.
Thursday, March 17, 2005
Communication skills for software developers
In my previous post, I suggested that just improving communication skills could have a powerful effect on your efficiency in developing software. What was I talking about?
Let's take meeting skills, for one. Software developers facilitate and participate in a lot of meetings. There are some skills you can bring to bear to make those meetings more effective.
1. Are you a good meeting scheduler?
Do you prepare an agenda in advance, and distribute it to the participants, so that they know how they will be spending their time?
Do you make it clear what results you want to achieve by the end of the meeting?
Do you give participants suffient time to prepare for a meeting before holding it? Or do you grab a few people (or a single person) in the hallway while it's on your mind and just get their gut reactions?
Do you make sure to invite everybody who has something valuable to contribute, or has a say in decision-making? Otherwise you may find yourself revisiting everything again later.
2. Are you a good meeting facilitator?
Do you follow the scheduled agenda?
Do you make sure everyone gets a chance to provide their input, and assure nobody dominates the meeting (especially yourself)?
Do you steer people back to the topic at hand when they get off track?
3. Are you a good meeting recorder?
Do you make sure to accurately capture important information and decisions? Do you confirm with the group that you've done so before moving on?
Do you write legibly on whiteboards and flipcharts? Do you use them at all?
Do you provide complete meeting notes to those who attended the meeting, and to other interested parties?
There are other, more specific skills and tools you might bring to a brainstorming session, or a requirements gathering session, or a decision-making session.
As you become better at conducting good meetings, you'll find that you spend less time on them, and the results are more valuable.
Interested in learning more about effective meetings? Try How to Make Meetings Work: The New Interaction Method.
Let's take meeting skills, for one. Software developers facilitate and participate in a lot of meetings. There are some skills you can bring to bear to make those meetings more effective.
1. Are you a good meeting scheduler?
Do you prepare an agenda in advance, and distribute it to the participants, so that they know how they will be spending their time?
Do you make it clear what results you want to achieve by the end of the meeting?
Do you give participants suffient time to prepare for a meeting before holding it? Or do you grab a few people (or a single person) in the hallway while it's on your mind and just get their gut reactions?
Do you make sure to invite everybody who has something valuable to contribute, or has a say in decision-making? Otherwise you may find yourself revisiting everything again later.
2. Are you a good meeting facilitator?
Do you follow the scheduled agenda?
Do you make sure everyone gets a chance to provide their input, and assure nobody dominates the meeting (especially yourself)?
Do you steer people back to the topic at hand when they get off track?
3. Are you a good meeting recorder?
Do you make sure to accurately capture important information and decisions? Do you confirm with the group that you've done so before moving on?
Do you write legibly on whiteboards and flipcharts? Do you use them at all?
Do you provide complete meeting notes to those who attended the meeting, and to other interested parties?
There are other, more specific skills and tools you might bring to a brainstorming session, or a requirements gathering session, or a decision-making session.
As you become better at conducting good meetings, you'll find that you spend less time on them, and the results are more valuable.
Interested in learning more about effective meetings? Try How to Make Meetings Work: The New Interaction Method.
Tuesday, March 15, 2005
Good, Fast or Cheap: BS Alert
You'll hear a lot of developers talk about the old saw: "You can have software good, fast, or cheap: pick two". Now, given an unchangeable set of people, processes, and technology, that might hold true. However, the reality is, you can have things better, faster, and cheaper, simply by improving the efficiency of your approach. That usually boils down to just improving the way you conduct the activities of software project management, and the specific activities that contribute to creating the software. Even just improving communication skills can have a dramatic effect on software project efficiency.
The other issue with this good/fast/cheap BS is that it implies once you've picked the two you care about, you can stop worrying about how to achieve the other one, and that is simply not true. You can't ignore quality, time, or expense - these are all constant considerations.
Similarly, it suggests that by throwing money, or time, or bugs(!) at a system, you can get the other two factors to go up, and again that is absolutely not true.
So the response this always gets from me is: That's an interesting observation... so what?
There are always real-world business constraints on time, quality, and expense. The real blood and guts of the matter is this: What is your capability to produce a given project within those constraints? The only way to improve your capability is to improve your efficiency.
A side effect when you improve your efficiency is that you improve on all three indices - better quality, shorter turnaround, and lower costs.
The other issue with this good/fast/cheap BS is that it implies once you've picked the two you care about, you can stop worrying about how to achieve the other one, and that is simply not true. You can't ignore quality, time, or expense - these are all constant considerations.
Similarly, it suggests that by throwing money, or time, or bugs(!) at a system, you can get the other two factors to go up, and again that is absolutely not true.
So the response this always gets from me is: That's an interesting observation... so what?
There are always real-world business constraints on time, quality, and expense. The real blood and guts of the matter is this: What is your capability to produce a given project within those constraints? The only way to improve your capability is to improve your efficiency.
A side effect when you improve your efficiency is that you improve on all three indices - better quality, shorter turnaround, and lower costs.
Subscribe to:
Posts (Atom)