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.

User Beware - Translate Server Error

Thanks to my good friends at Schlumberger, I had the tremendous opportunity to do some work in Beijing around five years ago.

With all the buzz about the Olympics, which start this week, I've spent a lot of time reflecting on my time in China. Five years ago, there were marginal attempts to provide English translations on signs, but the quality of those translations was not always what I'd expect. For example, note this sign on a fire hydrant by the elevators at the Schlumberger office in Beijing...

Recently with all the visitors expected for the Olympics, there has been a mad dash to translate signs to attract commerce from visitors. So where to the translations come from? Maybe from an English-Chinese/Chinese-English dictionary...maybe from a bilingual friend or family member...or maybe from an online translation website such as Babelfish. I must admit that if I used an online tool to generate Chinese characters from my English phrase, I would probably accept the translation it provides me as accurate. Therefore, the reverse must also be true.

Check out this photo of a sign in front of a Beijing restaurant...

The Wisdom of Fireflies

Business sociology can be very interesting - the dynamics of departments, groups, teams, or other blobs of people working together toward a common goal. In business school they called this organizational behavior, but I think organizational sociology sounds much cooler.

Incidentally, the Org Behavior question was the only one I missed on the comprehensive final I took when I got my MBA, but I'm a lot wiser in they ways of how groups operate now. I'd probably still fail that exam question, though, because memorizing categories and lists of labels from theorists hasn't been particularly useful to me in the real world.

So, in terms of useful information we can use, I'm hip to how (despite the hassles and overhead of group dynamics) groups are more successful than individuals. Always. If you want to learn more about the science behind this; to hear about how fireflies the in Thailand all flash on and off in synchronicity; to hear the original exercise that inspired James Surowiecki's jelly bean jar guessing exercise -- tune in to the best Podcast on the web (imho) -- Radiolab. You can download a free standard MP3 or podcast of the "Emergence" episode here.

Afterwards, you can thank me for turning you on to Radiolab. Then you can join me in complaining that they only put out 5 new episodes per season.

There's no such thing as a $99 Brake Job

I have a rant today. This isn't my typical blog content, but I wanted to get it off my chest, and hopefully save others from the troubles I experienced yesterday.

My son took the car to Just Brakes yesterday for the $99 brake job that is the cornerstone of their advertising. Brilliant marketing - poor execution. Actually, brilliant execution if their goal is not to sell $99 brake jobs. An hour after my son dropped off the car I got the call - my $99 brake job was going to cost a minimum of $530 for just the rear. It was like pulling teeth to get a detailed breakdown of the costs over the phone- the manager kept telling me that they would all be on the printout I receive after I pay for my repaired car. Interestingly, he told me that in addition I needed to seriously consider new brakes in the front too. This was interesting since I just got new brakes in the front 3 months ago.

Anyway, to make a long story short, I discovered that $99 only applies to certain brakes that they have in stock. After some Googling I learned that this is a common ploy that they use. In Marketing 101 they called this "bait and switch", but that's illegal, so there must be a loophole that the Just Brakes folks have found a workaround for.

Anyway, I finally got the detailed breakdown of costs and called a reputable mechanic that I've used in the past. He quoted me a price that was half of the Just Brakes price, so I picked up my unrepaired car from Just Brakes and won't be back again.

Who else out there is modestly envoweled?

I suppose I was distressed to learn that because 31% of the letters in my name are vowels, and 74% of names have a higher vowel make-up, I am considered to be modestly envoweled. This 'fun fact' is one of several I discovered about my name, including a statistically based estimate of the total number of people in the U.S. who have the same first/last name combination as me.

You can check out fun facts for your name here.

More about Pigs

The reaction to the 3 Pigs was awesome - Yanic from Belgium put a lot of work into his thorough rework of the problem. Check it out here. I realize he's selling a product, but regardless, I really enjoyed his comments.

I agree with most of the feedback I received, although the spirit of the models was more conceptual'ish than design'ish, which tends to accommodate looser implementation precision.

The one choice I regret the most is sending the "eat()" message to each of the first two Pigs, which is actually telling the Pig to eat. To correct this, either the message to Pig is "getEaten()" or the message eat(Pig) is sent recursively to the Wolf (as Don suggested.)

Nevertheless, I'm really digging the idea of modeling a well known story as a means to hone my UML skills. Maybe I'll tackle Aesop next...

The Three Little Pigs - in UML

I like modeling. Not the kind Tyra does, although I do like it when Tyra does it, it's just not something that I do, not that I'd be any good at it anyway...

Sorry, got off track. Anyway, I like to build models that express information in an organized and precise way. The notation I use doesn't really matter much, as long as it's easily understood by the reader. I have used a lot of notations in my career. I still have that green plastic IBM flow chart template that my Dad gave me years ago (I wonder what that would fetch on eBay?); I suffered through the CASE tool years (thanks James Martin); and I used notation from OMT, Booch, and OOSE before becoming an early adopter of UML starting with version 0.9 in 1996. UML has stuck with me through the years, and it has become a casual and efficient way to take notes and express things.

Earlier this week I was talking with a coworker about models and modeling, and I proposed an idea: What would a children's story look like if expressed in UML? I took this to task that night and produced The Three Little Pigs, in UML. Check it out and let me know what you think. The PDF document can be downloaded here. (It's set up to print it double sided on legal sized paper.)

A Greener Work Week

Green this, green that...it's the buzz these days. So let's get real, how about a greener work week? During the first dozen years of my working life, I had the benefit of working for a forwarding thinking company that had a 4-day work week, or as we like to refer to it: 3-day weekends. If the majority of companies were to adopt the 4-day work week, the impact to the environment and the economy is staggering.

For illustration, let's say ACME employs 10,000 employees at it's various offices. Each employee commutes an average of 15 miles each way and drives a car which gets an average of 20 mpg. Based on $4/gallon, the savings is $300 per employee per year, and $3,000,000 for the company's entire workforce. I realize that employees may choose to drive on their day off, which offsets the savings, however, that expense becomes a choice rather than a necessity. Scaling up that idea, if 100 Million people (or less than 1/3 of the U.S. Population) eliminated one commute per week, the combined reduction is 150 million gallons of gas per week! That equals a $32 Billion reduction in gas consumption per year. Imagine what that could do to the supply/demand curve that causes the price of gas! Imagine the reduction in emissions, traffic congestion, accidents, injuries, commuting angst, yada, yada...

So back to the 4-day work week. If you're concerned that it makes slackers out of us, consider this: Companies that adopt a 4-day work week gain a week and a half of work days per employee each year. How? Employees work 40 hours every week, including holiday weeks. So if Friday is your normal day off and there's a holiday on Monday, you would be off on the holiday but would work Friday that week. Employees tend not to complain on those weeks because they get to enjoy a 3-day weekend every week of the year. Thuse, company gains 8 working days per year from every employee.

Additionally, those companies that put all employees on the same 4-day work week can reduce power consumption and costs by shifting to a weekend HVAC profile on one additional day each week. For companies that must have employees present 5 days a week, rotating the extra day off can reduce the need for parking and office space if managed smartly.

Mapping an FTP Drive in Vista

As an update to my previous post, NetDrive is incompatible with Windows Vista, and no, it won't run in compatibility mode (just tried it.) You don't need it though. Vista has built-in mapping to FTP locations. Just follow the drive mapping dialogue in Windows Explorer and select "other computer location", etc, etc. The steps are intuitive. By the way, I was surprised that SyncToy wasn't built into Vista, but the free download (v 1.4) works in Vista.

Personal Remote Backup Solution

I recently set up a 500GB NAS Head on my home network to use for backup of my home PC as well as for my sons to use to back up their computers when they're away at college. There were a lot of options, and there was a lot to learn to set this up properly. I thought I'd share what I learned and also welcome comments from anyone who has suggestions to improve the configuration.

Step 1: Get a NAS (Network Attached Storage) device. This is an external hard drive that connects to your Internet Router using a standard Ethernet cable. It has a built-in FTP server. These devices used to be epensive, but the prices are dropping. Last week Frys had a Buffalo 500GB NAS on sale for $139.

Step 2: Plug it in, connect it to your router, and install any software that comes with it on (one of) your home PC(s). This software is used to set up partitions, ftp, etc. on the NAS.

Step 3: The NAS should be instantly viewable by other PC's on your home network. The router will assign a unique IP address to it. You'll probably want to map it as a network drive so you can easily access it without needing to know the IP address.

Step 4: For local backup, I prefer to sync files. There is no compression on the backup disk, but it's easy to navigate and find files on the backup device using a standard sync. My two favorite sync tools are FileSync and SyncToy. I'm using SyncToy now with the "Echo" setup, because it's easy to schedule it to run each night. Check for instructions in the Help screen.

Step 5: For remote backup, several additional steps are required. For brevity, I'll assume that you have a dynamic IP address and I'll just tell you what to do without explanation:

5a: Find out your current "real" IP address (not the one assigned by your Router). Get this at http://www.whatismyip.com/.

5b: Go to http://www.no-ip.com/ and sign up for a free account. Assign an friendly name alias for your IP address. (e.g., johndoe@myftp.org)

5c: Still at http://www.no-ip.com/, download and install software on your home PC that keeps your alias updated with your IP address whenever it changes.

5d: Connect to your NAS to set up and start the FTP service. The easiest way to access the NAS software is to open a web browser and type in the local IP address of the NAS (probably 192.168.n.n) If you don't know the IP address, open a command window and type IPCONFIG /all. The NAS software should allow you to set up username/passwords and set NAS folder access (none, read only, read/write) for each user account. Once set up, this should run automatically when the NAS is turned on. Your home PC does not need to be powered on for the NAS to work.

5e: Connect to your router and find/follow the instructions for port forwarding. Make sure port 21 (the default FTP port) is set to forward to the NAS device. Port 21 can only be forwarded to one of the devices on your network. Any inbound traffic to port 21 on your router will then automatically be redirected to your NAS.

5f (option 1): Use this option for standard FTP access from a remote PC to your NAS. From a remote PC, install and run an FTP client. A good free one is Filezilla. You just need to enter three things: 1) your IP address alias from step 5b (johndoe@myftp.org), 2) your username and 3) your password from one of the FTP accounts you set up in step 5d.

5f (option 2): Use this option to set up synchronization (as described in step 4.) Get FTPSync here, and set up access using the same three items shown in option 1.

5g (option 3): This is the slickest option, which is what I'm going to try first. On your remote computer, install NetDrive (freeware download here), which let's you setup a virtual local drive. It looks and acts like a local Windows drive, but it processes corresponding FTP traffic behind the scenes. You'll need to set up the three security items from option 1 in the NetDrive configuration. Once the virtual drive is set up, you can use your favorite Sync option from step 4 to handle backups. Or you can just access and use the drive. NetDrive was developed by Novel and is unsupported freeware, so it may not stand up to future Windows updates. There is a similar product call WebDrive, but it's not free.

If anyone has any better ideas, please share!

The Immortality of Humans

Simply put, ignoring all other factors, scientists have discovered that all creatures large and small have one common characteristic related to mortality: their hearts beat an average of 1.5 billion times over their lifetime. Finally - a biology problem that can be solved using a spreadsheet! That is, all creatures except human beings, whose heart beats as much as double that number - closer to 3 billion. (Go ahead, do the math, I know you're dying to.) When you put your spreadsheet together, notice what happens to your life expectancy when you drop your average pulse from 70 bpm to 60 bpm. Makes all that that exercise you've been thinking about seem more important than you may have thought.

Humans weren't always so askew from the rest of the creatures. Over time, through science and other evolutionary changes, we have managed to throw a kink in an otherwise perfect correlation. It hasn't been easy, though. As we introduce technologies that extend our lives, we also introduce new risks that may shorten it. (There wasn't much risk of getting hit by a bus in 500 B.C.)

Some scientists believe that it's plausible to push the life expectancy of newborns born in the next decade up to the age of 100. If you think the Social Security system is in peril now, just wait!

If you find this stuff interesting, listen to Robert Krulwich explain in more detail in his Podcast here: http://www.npr.org/templates/story/story.php?storyId=12877984&ft=1&f=1007

The Immortality of Lobsters

Some believe lobsters could live forever if external forces left them alone and allowed them to continue to eat, molt, and grow. The largest lobster ever found (and recorded) was over two feet long and weighed 42 pounds! The reason that lobsters don’t live forever is that external forces seem to step in at some point, leading to the demise of the lobster: bacteria, lobster traps, predators. If we wanted to test the immortality of a lobster, we would probably have to create a highly controlled setting that blocks these external forces. Even then, it’s possible that the nature of the controlled setting itself could create additional emotional forces that negatively impact the lobster's life expectancy. These thoughts form the basis for a train of thought I’ll continue in the next blog: The Immortality of Humans.

Change Agent – Brubraker Style

In a fictionalized account of the 1960's Arkansas prison scandal, the 1980 film Brubraker depicted Robert Redford as a mole prisoner. In the film, Brubaker was imprisoned and subjected to abuse and corruption that had become de facto at the prison. After witnessing and experiencing the many problems at the prison, Brubaker eventually reveals himself as the new warden. His first hand experience with the problems at the prison provided Brubraker with insight to fix the problems that could have been impossible to discover if had taken over the prison more conventionally.

Around 15 years ago I was working on a large software development project at a major insurance company. A new employee named Bill was brought onto the team. We didn't know much about his background, but he was hard working, productive and he seemed to study everything and everyone around him with great interest. We would learn later that he had recently retired from a distinguished career as a military officer and leader. On the day it was announced that he was promoted to Vice President of our 250 person project, it was evident that this had been the plan all along. Bill had the enviable opportunity to lead an organization that he understood from the inside out. This is very different from the typical "promote from within" strategy, where the new boss has a history of relationships, biases, and un-repaid favors that could constrain his leadership effectiveness.

In my career as a consultant, I've had many opportunities to perform as an invited change agent. In those situations, I was often challenged with discovering deficiencies that were well hidden by those who felt threatened by me. I've also worked in organizations where I was a member of a dysfunctional team in a dysfunctional organization. A decent change agent ought to still be able to implement change in that situation, but macro-level change from within the organization is very time consuming, frustrating, and often impossible. What a tremendous opportunity it would be to quietly study an organization from within, then step forward to not only recommend needed improvements to the organization, but to take responsibility and full accountability for making those changes happen.

Do Your Second Best

A colleague recently told me about the struggles he and others experienced when working on their doctoral dissertations. He told me that many tended to struggle with perfecting their research and preparation for defense of their dissertation. Christian author and scholar Ramsay McMullen visited with them one day and listened to their rants about the challenges of completing their work. Ramsay told them, "If you are a perfectionist, then do your second best." There is a certain profoundness in that statement. I have been a victim of perfectionism in the past, and many I've worked with have experienced the same struggle.

By the way, for a less pragmatic version of the same idea. Look to philosopher and writer Voltaire, who said, "Le mieux est l'ennemi du bien.", or "Perfect is the enemy of the good."

Often, results offer greater value than perfection. So if your work tends to stall, and results come slowly, try your second best.