July 17, 2009

The Case for Use Cases

It strikes me how often technical folks like me expect our customers (aka “users”) to know stuff that took us years to figure out. A big part of my job is designing and building computer software systems that enable the business to automate routine and/or complex tasks. Those systems help increase efficiency and thereby help provide (in theory anyway) profit to the bottom line.

I’ve worked with several leading technology vendors and methodologies to elicit the real requirements from the customers in order to build these systems. The purpose of documenting requirements is that we need to have a common understanding of “what” the system is supposed to accomplish. If we’re good, we try to leave out the “how” the system will accomplish that task until we get the requirements (the “what”) fully understood and agreed upon.

We break out these requirements into “functional,” which is a feature such as “allow the report to be sorted by any column,” and “non-functional” requirements. Yeah, we really call it that. Non-functional in this context has to do with things that aren’t really “features,” such as security, usability (remember how complicated it was to set the old VCR clock?), reliability, performance, etc.

Too often, I’ve seen the technologists go off and build something majestic – a real work of art – that becomes totally useless to our customer because it is too complex. The term is “over-engineered,” and that usually means that we’ve managed to make a really cool thing unusable.

So, this “requirements definition” portion of a software project is critical. We need to understand exactly what the user expects the software to accomplish. Only then should the technology folks go to the design table. Part of our job then, is to apply a logical approach to this process of definition of requirements.

A Use Case is an English representation of the interaction between the user of the system and the computer system itself. It is usually in the form of a scenario, whereby we methodically go through all kinds of iterations on how that interaction might go, in order to produce some result. It’s a kind of mini-story that can be told over and over again.

Use Cases were initially introduced to technologists in 1992 by Ivar Jacobson in Sweeden. As part of the “object oriented” approach to programming, it is a model that has gained momentum to the point where virtually all new systems are now build on the object model. Unfortunately, the adoption of the Use Case hasn’t been as quick, even though it is the foundation of all development, according to Jacobson. So, the sparkling new “object oriented” software still doesn’t meet users’ expectations.

The framework of the Use Case is one that lets us find all those hidden “gotchas” early in the process instead of after the software is delivered. It’s a way to capture the logic of the program on paper, before a lot of time is spent on coding. If we can run different scenarios through the Use Case, we know we’re in good shape to begin the next development step.

Our challenge as technical analysts, architects and developers is to help the customer community understand the value of a Use Case, and work with the users to define and build them early in the project. It should be in the top of the toolbox for every person involved in creating new computerized systems.


March 18, 2009

I Read You Loud and Muddled

“What we’ve got here is a failure to communicate.” That phrase was spoken by the prison captain (warden) to prisoner Luke in the 1967 film Cool Hand Luke. The captain had just knocked him down, both figuratively and literally. The captain was showing his superiority over Luke’s lowly position as a prisoner, and serving as a warning to others on the chain gang that he was indeed the boss, and his instructions were to be followed without question.

Unfortunately, around businesses in America today, that attitude can be found in many bosses. And, just like that warden, communication failure is typically the reason for the failure of leadership. Fredrick Taylor’s principle in 1911 that “the workman who is best suited to actually doing the work is incapable of fully understanding the science,” is no longer the best management model. It lacks the essential communication and feedback processes. The American Heritage Dictionary defines communication as “the exchange of thoughts, messages, or information, as by speech, signals, writing, or behavior.” Key to that definition is the word exchange, which implies a 2-way path.

But it's not just a matter of crafting a clear message. That same message will be heard by different people in different ways. When I went from leading a team of technical professionals to leading a team of call center employees, I learned an important lesson of “situational leadership”. Many years later, I took a course with that subject by Ken Blanchard. Blanchard describes the relationship of the development level of the staff to the appropriate matching style of the leader.

The idea hit home with me. Leadership expectations must indeed be situational. For employees who were at the beginning of their career, much more direction and mentoring must be given, compared to those who have experience and knowledge of their craft. In addition, the ability to identify where a person was in relation to their career was a skill that is more than just a review of their resume of work. Having effective one-on-one meetings with direct reports is an important activity toward understanding the individual’s progress and building a trusting relationship. Early in their career, a more directional approach is required. As the staff member matures in their responsibilities, the transition to more of a coaching model is preferred as they learn to handle the responsibility delegated to them.

I think that excellent communication skills, including both speaking and listening, are the most important proficiency that a manager needs. Communication is always better received when coming from a person with whom you have a relationship. Using that skill effectively will help achieve personal and professional satisfaction, and will most likely propel a qualified manager to a higher level of career growth.

February 14, 2009

Do You Value Anonymity?

I've always had the seemingly unpopular belief that, at least in the business world, anonymity is synonymous with secrecy. And it always seemed to me that secrecy among team members is a bad thing. Then why does HR seem to be all for an anonymous 360-degree feedback process?

In my job, I need to be challenged, criticized, and pushed to improve my processes, especially communication. Call me crazy, but I'm just not sure how anonymous feedback helps anyone communicate. For me, it's those one-on-one personal conversations from which I learn the most about myself and my approach to leadership.

Susan Scott, CEO of Fierce, Inc., and author of Fierce Conversations: Achieving Success at Work & in Life, One Conversation at a Time, agrees. Her recent article lists some "worst best practices," and puts the anonymous 360-degree feedback at the top of the list. Scott advocates the "365 Face-to-Face Feedback" process, which essentially is truly open and honest communication 365 days a year. She quotes Kevin Kelly, the editor of Wired and the author of Cool Tools.

"But if anonymity is present in any significant quantity, it will poison the system... Trust requires persistent identity. In the end, the more trust the better. Like all toxins, anonymity should be kept as close to zero as possible."

As Mitch Alegre wrote, we have to understand the ecology of our leadership; our environment and context. Do we value open honesty? As leaders, would our followers agree? And do you, as a follower, give open feedback to leaders in your organization so they can improve?

Check Scott's article here and let us know your thoughts.

January 30, 2009

Can you develop leadership?

Leadership skills. What does that make you think of? Last Monday, Mitch Allegre told a group of about forty professionals about the "Ecology of Leadership." We were gathered at the Leadership In Action's Dialog Series event at AAA of Western NY. His often humorous presentations tell it like it is. He referenced the stereotypical corporate "leadership development" events that we've all been subject to. Mitch likened it to someone being taught how to play tennis by practicing their swing indoors, learning the correct position for forehand and backhand. Maybe even hit the ball against the wall. Then, the lesson is over and it's back to work. Get out there and play championship tennis. We just taught you all you need to know.

But wait... there's someone on the other side of the net now! Hey! They're hitting a ball at me! I didn't practice this! What do I do?

The standard approach of academic training lessons on leadership fail. It's all good information, don't get me wrong. But how does it all come together? Only with practice. In his book Outliers, Malcom Gladwell talks about the "10,000 Hour Rule." Whether you are the Beatles, Mozart, or a championship tennis player, practice truly does make perfect.

So how do we apply this to "leadership skills?" Practice. Meet with your peers. Learn from their successes, and more importantly, their failures. Find a mentor. And mentor someone else.

Leadership In Action is a group started for this very reason. We wanted to not only provide access to leadership development skills, but also spend time interacting with other leaders in your peer group. That interaction is how we learn. Experience is the key... it's how we learn. Let's get all we can. Visit the website for more details about how you can be a part of it.

Become a fan!