I'm Moving

I'm joining the Wordpress bandwagon. Please follow me to my new blog: www.agilist.net

When Coaching an Underdog Team

In a perfect world, members of a newly formed Agile team are highly skilled, and the role of the coach is to overlay Agile so the skills are employed in the right way, in the right place, and at the right time. But many of us don’t live in a perfect world.

As a coach, I have often been challenged with team members who lack fundamental software development skills. This can distract efforts to be successful with Agile…and when core skills are missing, there is risk that the organization will peg Agile as the culprit for poor results.

I have met a number of people who told me that Agile was abandoned at their company and dubbed a failure. Agile cannot ‘heal’ poor software development skills, rather, it helps teams that possess skills experience an order of magnitude improvement in results.

When tasked with coaching a team of underdogs, the first order of business is to assess the presence (or lack) of core software skills. If an underdog team is what it is, a successful coach recognizes the obligation to clearly separate Agile coaching efforts from those of teaching/mentoring fundamental skills. This will help a company balance it’s needs: To emphasize skills development, or to place more emphasis on successful delivery. If the latter is the emphasis, it may not choose to pursue that particular project with a team of underdogs.

Cards Don't Build Software, People Build Software

I've been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I've seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.

So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.

From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it's assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?

Just because I'm Agile, doesn't mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision - If I don't write down or draw models of the software I need, I'm bound to forget. What tends to be lost on a lot of new Agile adopters is: It's okay to write things down, just don't try to write down absolutely everything before you start building.

Go Ahead and Eavesdrop

A few years ago I managed a team of learning content developers for an international consulting firm. One of my many trips brought me to Paris, France to check on the progress of a course being developed there. One of my friends and colleages, Thierry, honored my visit by organizing a dinner for some of the employees and their spouses.

We went to a hotel at Versailles and were seated at a large round table on the back patio - I think there were 12 of us. It was a beautiful summer night, and everything was perfect. The food was great, and everyone was chatting up a storm, so all seemed to be having a good time. In the midst of the chatter, Thierry shouted, "Hey everyone, you're all speaking in French. Ken doesn't speak French, so please speak in English." I was a bit embarrassed, and I can imagine that some of the wives may have been thinking, "The lazy American comes to our country and he can't even speak our language."

One of the wives said out loud, "But why? We're not even talking to him?" Although everyone laughed, she made an interesting point which begs the question, "What would have been the point of me hearing all those conversations that I wasn't intended to be a part of?" I believe that in an informal setting like this, people are expected to eavesdrop a bit and jump in and out of conversations at will.

Recalling this story caused me to think about all the collateral and indirect communication that occurs in a team room. At times, the dynamics in the team room involve any number of impromptu conversations. Often times, others could contribute to (or learn from) those conversations, even though they didn't receive an engraved invitation to participate.

The informality of impromptu conversations includes an implicit invitation to tune out, listen, or jump in fully and contribute. I contend that much of the high value communication that moves a project forward occurs this way.

Now Hear This!

For those of you (like me) who didn't make it to Agile 2008, I found the next best thing. There are some great podcasts of interviews with folks from the conference, as well as from the prior two "Agile 200n" conferences. These podcasts are professionally produced and well done. Last night driving home I listened to a discussion with John Stahl about gimmics they use in the team room to keep the mood fun. For example, they got a gong that gets gonged during the SCRUM meeting every time somebody reports completion of a task. Even if you're not so much into gimmics, I'm sure you'll find some other useful nuggets on these podcasts. Click here for the RSS feed with links to all of the Agile Toolkit podcasts.

I subscribed to the Podcast on iTunes so I can keep up with all of them up on my iPod automatically. I don't know how to link you to the iTunes subscription, but if you go to the iTunes store and search for "Agile Toolkit Podcast" you should find it. If you don't know how to do that, give me shout and I'll try to help.

Hoarding Tasks

They finally restocked the Splenda in the break room this morning. I have an unquenchable sweet tooth, and usually put a couple packets in my tea. The bin has been empty all week, so when I saw it fully stocked this morning I was half tempted to grab several of them to keep in my desk to use the next time they run out. It dawned on me that if each of the 400 employees in this office grabbed just 20 packs, there would be 16 cases – or 8000 packets sitting unused throughout the building.

The same thing happens when we hoard work. If I grab a handful of tasks and only work on one or two at a time, I could be blocking others from pitching in to help with the ones that are just sitting there. Granted, everyone else on a project team may likely be working on some of the tasks they nabbed…but what if their time would be better spent on the pending tasks in my queue?

This gets to the heart of the reasoning behind meeting as a team daily and pulling work from the backlog that is doable that day and only that day. For tasks that multiple team members are qualified to complete, it allows the highest priority tasks to get continuously burned down. If tasks requiring specialized skills possessed by few team members start stacking up, it provides an opportunity to pull in additional help to eliminate the bottleneck. Ain’t it sweet?

Balancing Mechanization, Psychology, Sociology and Business on Agile Projects

I'm not frustrated by Brett's comments about assertions in my Blogs. I'm actually flattered, and happy that he's reading them. Tenure doesn't necessarily earn me any more credibility than smart successful people with fewer years of experience.

My eclectic undergraduate training (Mgmt Science/Operations Research + Psychology minor) augmented later by an MBA illustrate where my interests lie. I've always been a fan of Franklin and Lillian Gilbreth's time motion work in the early 1900's, and later of Goldratt's Theory of Constraints. On the other hand, my interest in Psychology and Sociology tends to clash with the concept of applying a pure process optimization approach to software development. I'm further fascinated that software developers took so darned long to pay any attention at all to those old proven methods. It's all these things that I find so fascinating.

When it comes to human behavior in a social environment, there are few wrong answers. There are far too many uncontrollable variables to be able to treat human processes as a science. I am fairly certain that most humans don't want to be cogs in a machine. Even those who are willing to be cogs will probably dislike it after a while. (Then again, I'm sure you can't say that about everyone.)

I do agree with Khan that lag time is the primary cause of delays on projects. (btw - per your comment, I updated my blog with a link to the referenced work.) The Ops Research bug in me says to attack the lag time to compress the duration of work. The Psychology bug in me tells me to evaluate the personal motivations and interactions that cause people to do (or not do) things that waste time. And the MBA bug in me causes me to look at projects from a purely P&L and ROI perspective. I believe that proper balance of all three perspectives will lead to true optimization.

Is Agile Too Noisy?

A common complaint from folks new to Agile has to do with all the noise and interruptions when working in a team room environment. Are the noise and all the interruptions causing your tasks to take longer than you'd like? Don't worry.

In Rashid Khan's book Business Process Management: A Practical Guide he references a 2001 study which showed that 90% of the time spent on a task is “lag time”, and the remaining 10% represents actual task time. The 90% represents the time that work is spent waiting in someone’s inbox, in transit, or blocked by other tasks. If an efficiency expert were to drive workers to crank through a task in half the time, they may be disappointed to see only a marginal impact to the overall productivity of the project. If a 10 hour task is completed in 5 hours, and nothing is done to reduce the 90 hours of lag time, the 5 hour savings is hardly noticeable.

To compound the lag time issue, a 2002 study by Safari found that technology workers spend an average of 31 hours per month looking for answers, researching issues and solutions for problems, and helping colleagues do the same. This constitutes 20% of their time spent seeking out information.

Tactics employed on Agile projects can attack these barriers to productivity. When a team is brought together in a team room, some will complain that the noise and dynamics interfere with concentration, negatively affecting productivity. Even if these factors cause a 10 hour task to take 15 hours, the project still benefits when lag time is slashed from 90 hours to 20 hours. Additionally, imagine the additional time saved when a missing knowledge item is announced in the team room, and (because all information experts are present) the knowledge gap can be filled immediately.

Are We Ready for the Guitar Hero Employee?

I have been trying to learn how to play the piano for almost 30 years, and on my best day, I’m a poor piano player. Although I know how to read music, and I know which keys correspond to each note, I usually resign myself to pounding chords with my left hand and tapping out the melody with my right hand.

Two of my sons were home for Thanksgiving weekend, and each sat at the piano and played beautifully. I’m talking full two hands on the piano, hitting every note - harmony, melody, arpeggios, style, the whole nine yards. I was in awe of the music each of them was able to eek out of the piano. And here’s the surprising thing - neither of them has looked at the sheet music, and if they did, it would likely just be a distraction.

So what’s the explanation? Music prodigies? I think it has more to do with the fact that they are in touch with how they best learn. The same skills that allow them to excel at Guitar Hero and Wii Bowling can apply to other real world skills. They are kinesthetic learners – they learn by seeing, touching, and emulating behavior. They each learn tunes on the piano by watching YouTube videos with close-ups of talented players fingering the keys. The interesting thing is that this is not an isolated phenomenon – there's a multitude of these learn piano videos on YouTube that are getting tens of thousands of views.

To the other business folks out there, this phenomena is representative of our incoming generation of workers. The video game culture has created a generation of kinesthetic learners. My wife commented, “Wouldn’t be great if school subjects were available as video games?” Imagine Playstation Physics, X-Box Calculus, and Wii History…

And if we resist? What will happen when these kinesthetic learners enter the workforce and struggle to integrate them into a business world littered with dazzling white papers, PowerPoint slides, and weekly status meetings? I believe there is a change coming that is going be fun and interesting. Stay tuned…

Gestalt and Agile Adoption

When helping companies adopt Agile, the first instinct is to start wiring in tools and processes. Ironically, some mentors tend to teach a highly prescriptive form of Agile. As an llustration, reflecting back on Kent Beck’s Extreme Programming, critics complained that it was prescriptive, inflexible, and full of “must do this”, “must never do that”. Having met and learned from Kent Beck years ago when I was a Smalltalk developer, I know that prescribing a process was far from the spirit of what he was trying to do. Perhaps he was pushing an extremist view, expecting rational people to bounce back a bit.

Changing the behavior of individuals, teams, and organizations is a tough row to hoe. At its core, the Agile Manifesto conveys principles that rational people would have a hard time disputing. Look at the picture posted with this article. The obvious elements of the picture are the four colored triangles. A Gestaltist perspective indicates that the cross can be seen too, even though it isn’t emphasized.

Similarly, the core elements of Agile: Collaboration, behaviors, teams, accountability, progress transparency, focus, efficiency, etc., are all concepts that few would dispute. So the real challenge for an Agile mentor is not to teach what these concepts are, rather it’s to help remove organizational and sociological blocks that prevent teams from employing them.

Oh the Irony!

My previous post was about brevity in communication by choosing models over narrative requirements. That's not necessarily an endorsement of writing/drawing over talking.

Most writing is a unidirectional activity, with varying latency. Responses to IM messages can take seconds or minutes, responses to emails can take minutes or hours, and responses to published documentation can take hours to days...and what is the meaning of no response at all? Was my brilliant writing not seen? Ignored? Acknowledged and put aside? Conversations can unlock the mystery of what others think, and more important, collaboration allows good ideas to blossom into great ideas.

I ran across a well written post that emphasizes this point: http://edgehopper.com/did-we-forget-how-to-talk-to-each-other/

Now having said (written) all that, an intuitive colleague at Improving, Jef, pointed out the sheer irony of commenting on this very subject via blog. Touche'

Comprehensive Brevity

When requirements analysts are thorough, those who read and use the requirements can easily get lost in the muck and mire of the details. I have found that diagrams can add much more specificity to requirements than lengthy narratives describing business rules. This diagram depicts a small excerpt from a requirements model of a financial system.

This tiny drawing eliminates the need to write out all of the following business rules, because they are all clearly shown in the model:

• Every account must be associated to one customer.


• An account cannot be associated to more than one customer.


• An account cannot exist if it does not have a corresponding customer.


• A customer must have at least one account.


• A customer may have more than one account.


• An account must be either an individual account or a corporate account.

Some restrict the use of drawings like this for design, others argue that domain models are old school. I have had great success using this approach for describing business rules. The economy of words eliminates ambiguity, is much more thorough, and can be easier for a designer/developer to use when designing a solution.

Yin and Yang Go to Work

Many software projects seem to me to have inherent opposing forces present at all times. Analysts wrestle with business folks about what’s needed, developers wrestle with analysts about too much / too little documentation, QA folks wrestle with developers about the sufficiency of unit testing, management wrestles with development about cost and schedule, and on and on.

Many of us are naturally repelled by conflict. We try to prevent it from happening, and when it does happen, we try to get away from it as soon as possible. (With the sole exception of people from New York.) On a software project, the easiest way to avoid conflict is to burrow in a cave and do work. Unfortunately this is totally contradictory to the collaborative best practices that make Agile projects work, and rather than avoid conflict, it just defers it.

Agile projects tend to expose conflict early and attack it head on. Since this is unnatural and uncomfortable for many people, it can slow the adoption of Agile practices. Embracing Yin-Yang and cultivating opposing forces on a project into an efficient process with quality results is the very first hill to climb when starting your first Agile project.

Avoid Doh! with "Intentional Delay"

C'mon, admit it. At some point you have experienced email regret - you sent an email and then slapped your head and said, "Oh no!" Disciplined emailers proof before they send, and one person once told me he counts to 10 before sending emotionally charged emails. Instead, consider building in a preventive measure - set up intentional delay.

If you follow these instructions (for Outlook users) every message you send will remain unsent in the Outbox for one minute before being sent. If you have second thoughts, just go to the Outbox and delete the unsent message, sending the embarrassing or career ending email straight to the bit bucket.

To set this up in Outlook,

• Click the Tools, Rules & Alerts menu option.
• Click Start from a blank rule
• Tick Check message after sending, and click Next
• Choose on this machine only, and click Next
• Tick Defer delivery by a number of minutes.
• Click a number of and enter 1.
• Click ok, then click Finish.

The one minute delay is a small price to pay to avoid the burden of "What was I thinking!"

Are You Kidding Me? Pres O' and CollegeFootball

I'm pretty guarded when it comes to sharing my political views, but I heard a news story this morning that caught my attention. President-elect O' is using his new pulpit to profess the need for a college football playoff system to replace the BCS (details here.) You may be suprised to know that his opinions and comments aren't what irk me. He is a (albeit powerful) citizen stating his opinions, which we are all entitled to do. I trust our governmental system to prevent this from becoming a distraction that mustn't consume time of those we have hired to run our country.

What irks me were the reactions of citizens I heard on NPR. Individuals commenting to the effect of "It's about time we elected a President to deal with this important issue." C'mon, gimme a break. Those people who believe that our newly elected President is going to change everything they don't like about their lives are in for a rude awakening. When I was listening to these interviews, I honestly thought I was hearing a parody (The Onion style.) Alas no, it was real.

So maybe I should just jump on the bandwagon. Maybe there's now hope that Pres O' can get those writers of Lost to start giving us some explanations instead of twisting in more puzzles.

Best Free Imaging Software Program - Ever!

Ok, maybe I'm overstating - "best" is subjective, and everyone's software needs are different. If you work with graphics, images, or photos, you probably have the need to do editing or touch up work. At work, I frequently edit graphics for use in presentations. At home, I have been scanning hundreds of old photos that need to be cleaned up.

I used to use Photoshop Elements, which was great, but the version I bought stopped working when I upgraded to Vista. I have also had the chance to play with the full version of Photoshop in the past - it's a wonderful tool, but I can't spend the hundreds of dollars it costs.

Picasa is a terrific tool for very light editing - cropping, rotating, color correction, and red-eye and blemish removal. However, it lacks comprehensive color and light correction tools, and has limited support for filters. It also lacks my favorite Photoshop tool, the clone stamp.

Then I found the best Photoshop'ish tool available, and it's completely free of charge - It's called GIMP, which stands for the "GNU Image Manipulation Program". It has all the features I used in Photoshop, and is completely spyware free. You can find it here.

Even better, if you need to take GIMP with you to use at work or on somebody else's computer, it's also available in a portable version. Just install it on your thumb drive and run it from there without having to install it on the PC. The portable version is available here.

The Top 10 Things I Hate About Agile Projects

10. The Product Owner keeps dropping by to see what we’re doing.
9. I have to prove that I got work done every single day.
8. I have to work with other people, constantly.
7. I am expected to demonstrate imperfect, unfinished software.
6. Senior management looks at our burn-down chart every day.
5. Developers keep bugging me with questions.
4. There’s hardly any down time.
3. Everybody else gets an opinion about my task estimates.
2. I am expected to work on tasks that aren’t in my job description.
1. My project could end before the target date!


What's on your top ten?

So You Want to Build a Better Mousetrap?

The first mousetrap was invented over 100 years ago. To this day, many have pursued the perfect mousetrap. Ralph Waldo Emerson added fuel to the fire when he said, “Build a better mousetrap and the world will beat a path to your door.” So what is “better”, anyway?

The de facto mousetrap choice is the “two for a dollar” Victor snap trap (pictured.) It’s easy to use and has a nearly 90% success rate in achieving its intended goal. So if that’s the case, why have over 4400 mousetrap patents been issued by the US Patent Office? What are we looking for in a mousetrap anyway?

In surveying the market, I found everything from mouse electric chairs to mouse gas chambers . (The latter actually sends you a text message when the deed is done.)

If building a better mousetrap were a software development project, I’d be fascinated to learn what the world really wants in a mousetrap. My guess is that some want cheap, some want exotic, and still others want humane. If I were assigned to the "build a better mousetrap" project, there may truly be 4400 viable (and vastly different) solutions. Therein lies the problem for requirements analysts - The primary functional requirement of all mousetraps is the same (don't make me say it.) Nailing the surrounding requirements, the values of the stakeholder, the attributes of the target solution -- it's all this stuff that can turn a simple project into a huge project. In my many consulting assignments around the world have encountered very few requirements analysts who truly know how to manage these requirements very well...and it's these surrounding requirements that can make the difference between project success and project failure.

Agile Dot Net

For folks in Texas and the surrounding area, don't miss out on a great free learning opportunity about Agile development with .NET. The event is on Friday November 14 at the Microsoft office in Irving. Improving Enterprises is proud to sponsor this event with Microsoft. Again, it's free of charge, but you must register ahead of time if you would like to attend. To see more details about the event, and to register, click here.

Seven

On Tuesday at ProjectSummit/BA World, I was invited to be moderator of “Agile Analysis: Can it Work at My Organization?” During and after that session I had numerous discussions centered around this recurring question: “What Should I Document, and What Can I Document?” There’s a common perception that on an Agile project, the only thing I’m permitted to write down is a User Story – the remaining communication occurs through verbal interaction. If Agile is all about effective communication, is it presumptuous to assume that verbal communication is the most productive? In 1956, George Miller proposed a theory that the capacity of a human’s short-term memory is seven plus or minus two things. This was proved, and has been proved and re-proved many times. To free up short term memory to make room for the next batch of information, I have four choices: discard it, pass it to someone else and be done with it, encode it in long term memory (this takes time), or write it down. On a project aimed at building anything larger than small and trivial, chances are that if you don’t write things down they will be lost or forgotten. So, the remaining question related to project efficiency is, “If I write information down, what form works best, what do I do with it once it’s written, and what should I do with it after we are done using the information?”

Turn Your Thinking Upside Down - in Boston

For those of you attending "Project Summit" or "Business Analyst World" next week, I hope you'll drop by my presentation titled "Better Software Requirements Through Mapmaking". Expect a few suprises as I turn your perspective on business and software modeling upside down.

I hope to see former friends and colleagues as well as folks from former clients in the area: RSA Security, Applied Biosystems, JP Morgan, Quantum (now Maxtor.) Stop by and let's catch up!

Great UML Cheat Sheet

A while back I went in search of a great, concise, and up-to-date notation summary for UML and was surprised not to find a decent one, so my colleagues at Improving and I created one. We're happy to share it, and I hope you'll pay it forward by passing it around to others who are learning and/or using UML. The link to the cheat sheet, or as we prefer, "Improving Sheet" is on my sidebar (see the UML logo) or click here. By the way, if you forget who we are, just Google "Improving" and you'll find us at the top of the list. ;-)

Business Requirements vs Technical Requirements

I wanted to blog about the difference between business requirements and technical requirements (because I know you're dying to know.) Instead, I found a clear exlanation/illustration here. You can't go wrong with a whoopie cushion example -fart humor is always a clear winner.

Harder than I thought!!!

So I re-read my previous post on "facts" vs. "opinions" and underlined anything that is an undisputable fact. Of the 20 or so sentences in the posting, I could only tag five as facts. That's 25% fact / 75% opinion - way more slanted than I thought. If that's the nature of blogs, I'm still puzzled (and flattered) that people who don't know me go to the trouble of reading my blog, and hence, my opinions. This is a heavy responsibility that I don't plan to take lightly.

I'm inclined to think that opinions are more interesting than facts. When smalltalking about the weather, I could say, "It's unbearably hot outside today." An alternate: "The temperature today is 20 degrees warmer than the 5-year average temperature for this date" - is completely factual, more thorough, and indisputable. It makes for far less interesting conversation. There's no conflict, no tension, no points to argue. Maybe we like opinions because they provide for more recreational conversation. Or maybe not. Just one man's opinion...

Facts vs. Opinions and Cred Factor

Throughout the U.S. we're in the midst of opinion season. It's time for politicians to gaze into their crystal balls and paint a picture of the future state of the country as they'd like us to believe they can create. Since facts are always about the past, any projection of the future is an opinion, a conjecture, an educated guess, etc. Sometimes blogs are used to convey facts; more often they are used to express opinions. So why should you care what a blogger thinks? Every day we feed our brains with the many facts and opinions we encounter. First things first, separating fact from opinion is not always as cut and dry as you may think. Test your ability to discern facts from opinions here.

When it comes to opinions, we each have our own built-in credibility filter. Many parents followed Dr. Spock's parenting advice. Years later, Dr. Spock's family suffered the tragedy of the loss of his child to suicide. Does that erase his credibility? In a non-gray world some choose to believe that either his advice is credible or it's not. True or not, some believe that Dale Carnegie committed suicide - does that make his best seller "How to Stop Worrying and Start Living" a crock? Both Richard Nixon and Bill Clinton lied to us all on TV - did that completely erase their ability to get people to subscribe to their opinions?

Thoughts like these cross my mind as I blog. I try to be careful not to blabber opinions without consideration of fact-based examples. My blog has had a lot of hits worldwide lately, and I've discovered that factual entries get much more traffic than those that are predominantly opinions. I'll bear that in mind as I blog on. (By the way, due to the high number of hits, I am now the #2 spot on google when you search for "Fast Vista". My home FTP/NAS Server setup instructions are also very popular. In the future I plan to stick to fact or fact-based as much as possible.)

Requirements Antipattern # 312: Never Always Follow All of Some Rules

(The title actually really does make sense if you study it a bit.) When it comes to prescribing process, the goal is supposed to be to repeat a positive experience. Pilots are required by the FAA to explicitly follow and check off items on a checklist every time they follow pre- and post-flight procedures. There is no latitude (no pun intended) given regarding this rule because there is sufficient evidence to demonstrate that positive results can be expected when procedures are followed.

On projects, prescriptive processes can be helpful to newbies. I've always felt that project participants ought to earn the right to change or bypass the process. That right is earned through experience and positive results. As a consultant I've worked with many large and small companies over the years. Larger companies have a tendency to over-prescribe process primarily because there is less confidence and knowledge about the wisdom and experience of project participants. Smart companies (large or small) tend to hire skillful facilitators/leaders to run projects. A skilled and wise leader can keep the project ahead of the many unpredictable things that occur on projects - things that a prescriptive process could never anticipate.

Undesirable things can happen when someone rotely follows the rules without question, as this true story from this months' Readers Digest illustrates: Hospital regulations require a wheelchair for patients being discharged. However, while working as a student nurse, I found an elderly gentleman already dressed and sitting on the bed with a suitcase at his feet-who insisted he didn't need my help to leave the hospital. After a chat about rules being rules, he reluctantly let me wheel him to the elevator. On the way down, I asked if his wife was meeting him. "I don't know," he said. "She's still upstairs in the bathroom changing out of her hospital gown.

Requirements Anti-Pattern #267: Unknown Knowns

A perfect engineering storm happened in Warsaw this week. The project was carefully chunked into separate well bounded smaller projects, which would all be integrated near the end of implementation. Team 1 built the train tunnel, and team 2 was responsible for the train tracks. It wasn't really necessary for the tunnel builders to talk to the track builders, after all, they had all done similar projects many times before. After construction was complete, inspectors discovered that the newly engineered tracks are taller than previous installations, therefore, the tunnel is not tall enough to fit a train.

Thanks to Rumsfeld, we've all heard of Known Knowns, Known Unknowns, and Unknown Unknowns. This Polish project fiasco introduces another phenomena I refer to as Unknown Knowns - Requirements folks make assumptions based on what they think they already know, but due to change, they're wrong.

So what are the engineers in Warsaw to do? Raise the roof? Lower the tunnel base? Reengineer the track height? I suggest they look into building smaller trains. ;-)

Fast Vista - Finally!!!

I've been a frustrated Vista Ultimate user for a while now. Frustrated at how painfully slow it was running on my 1.83 Ghz Dell Laptop with 2GB RAM. After making the following adjustments, I'm thrilled with the performance of my machine:

1) Deleted files I didn't need. My hard drive was near capacity, so this had to be bogging down the virtual memory. Old media files can be huge, and an 80GB laptop hard drive is no place for them.

2) Uninstalled programs I'll never use.

3) Cleaned out additional junk files using CCCleaner (freeware). I'm not really sure if this helps, but the cleansing process feels good nevertheless.

4) Turned off the Vista Sidebar. It's cute, but seemed to consume a lot of system resources I'd rather use for something else.

5) Turned off most of the Vista visual effects. Again, cute, but after the initial appeal has worn off, they didn't do much for me.

6) Ran MSCONFIG and un-ticked a few startup programs and services I didn't need.

7) Turned off Google Desktop. Vista's search works great, so Google Desktop is redundant.

8) And now the biggie - I installed the Vista Service Pack. I thought I already had it, but as it turns out, Windows Update had repeatedly failed to install it. I searched the Microsoft site and downloaded and installed it manually, and it made a HUGE difference to the performance of my laptop.

9) And by the way, I also bought a replacement battery. When I ran a battery utility I discovered that my battery was only operating at 10% of its design capacity. Every time my PC went to sleep, it would run out of juice and perform a total shut-down. Now I can avoid time consuming boot-up, and just wake up my laptop when needed.

Next on my to-do list is to set up my flash drive for ReadyBoost, which is supposed to add up to 2GB additional RAM.

Cherish Now

I'm stunned. Another fellow school parent died last night. That's two this week, three this year. Two heart attacks, one car accident. These are all people close to my age, with kids who still desperately need a parent. They must still need a parent, I know I do. Another wake-up call to remember that every day matters, to live for now not later, cherish the treasures in my life, and to re-read the famous "wear sunscreen" speech.

Tear Down This Wall (not really)

There's going to be a lot of fuss about The Wall over the next couple weeks. The picture is at the very rugged Mutianyu, around an hour northwest of Beijing. While it's awesome and inspiring to see, it is highly reminiscint of times of endless war, slavery, oppression, and death. The original intent was to keep others out, but in modern times it could be representative of holding people in.

Hopefully the Beijing Olympics on the world stage will move China toward a freer society with complete and utter protection of human rights and dignity.