Goal Oriented Meetings in Software Development

I’m fascinated with the subject of meetings. It is a topic of discussion across the wide webbed world. There are nearly as many opinions on this subject as there are stars in the sky. So adding my own here cannot possibly disrupt our little corner of the multiverse, nor will it likely establish a new or even affect an existing trend. But before I bore you with my own opinion, let me share with you some links to some very cogent resources that have helped me, in addition to my own years of experience, to form my opinions here.

  • Firemen, donuts and meetings – Seth Godin: “Don’t bother to have a meeting if you’re not prepared to change or make a decision right now.”
  • Reduce Meeting Time by 30 Percent – Max Isaac: “Prior to the meeting, send an email with the proposed Purpose, Process and Preparation, and attach documents that should be reviewed.”
  • Meetings frustrate task-oriented employees – American Psychological Association: “…people high in accomplishment striving, who tend to be highly task and goal oriented, were most negatively affected by meetings...
    ...people who participate most in meetings, such as those who identify themselves as upper-level management, tend to view them most favorably...solely because they get to talk a lot, they inevitably miss other key pieces of meeting effectiveness, including their ability to successfully lead the meeting.”
  • Why Goal-Oriented Requirements Engineering – Yu & Mylopoulos: “The identification of goals naturally lead to the repeated asking of "why", "how" and "how else" questions... Stakeholders also become more aware of potential alternatives for meeting their substantive goals, and are therefore less likely to over-specify by prematurely committing to certain technological solutions.” (This paper is not about meetings but contributes to the opinions expressed below.)
  • Goal-Oriented Idea Generation – multiple authors, taken from summary of results: “The goals obtained from the ideas have high quality. During the activities for grouping ideas, it was frequently observed that the stakeholders could find their misunderstandings and tried to resolve them. As a result, the obtained goals were based on the consensus and the agreement of all of the stakeholders.” (Again, this is not about meetings but contributes to my ideas on the subject.)

It has been my experience that any form of software development, including my personal favorite: behavior driven design/development first introduced by Dan North, generally requires more than one person in the process. There is at least a user and a programmer, at least for any software that one might be paid to produce. And where there is more than one person in a process, there is the inevitability of a meeting.

The real question is what is the nature of the meeting. And by nature I mean how will it be planned and conducted, and what if any follow up will occur as a result of the meeting.

Bad Meetings: Vague, Purposeless, Meandering Time Wasters
The world of software developers could fill terabytes of hard disk space with examples of meetings that were a complete waste of time, ineffective, resulted in no change to the status quo nor the discovery of anything that was not already immediately discoverable in an issue or project tracking system.

Rather than go through any of these bad examples in detail, I will simply summarize that these meetings most typically include in the email invite only a vague subject line, a time and place, a dial-in number for remote attendees, and by virtue of the most commonly used tool to send the invite, a list of attendees, most often the entire team. Too many of these meetings and your organization has fallen hopelessly into the “Meaningless Meetings Machine.”

Goal Oriented Meetings: Purpose Driven, Limited, Action Packed
The very best meetings I have ever attended or conducted (yes, I’ve conducted my share of bad meetings too) have had the following qualities:

  • Goal oriented – the agenda focuses on stated goals. (See Mark Schiller’s cogent treatment in Fixing IT Productivity Destroyers.)
  • Limited scope – the time and agenda are limited to specific related goals.
  • Parking lot – good but unrelated ideas go into a “parking lot” to be discussed at another time and often in a different forum.
  • More listening (less talking) – participants listen carefully with their full attention and speak only when they have something relevant to contribute or need clarification in order to make a decision or understand an action item being assigned to them. And NEVER, NEVER, NEVER do participants rudely talk all at once.
  • Previous action items related to goals on the agenda are reviewed in summary fashion – discussion is limited to reporting outcomes and/or impediments that require attention by the group. This does NOT mean that the group attempts to resolve these impediments during the meeting. They are noted and may generate an action item for a participant, but under NO CIRCUMSTANCES will the meeting get side tracked to solve the problem in the moment.
  • Goals drive actions – starting with diverging opinions and working toward consensus in these steps:
    • affirming the goals are properly stated
    • identifying actions required to achieve the goals
    • identifying (or getting volunteers) to take those actions
  • Decisions are made – work toward a consensus but have a meeting leader who can make a final decision right there, right now, after having considered the input of meeting participants. Perfect consensus is not the goal. Decision and action from team input and reasonable discussion is sufficient. (And as Seth points out, don’t bother having a meeting unless you are prepared to change your mind. If you have already made your decision, just announce it, assign the tasks and follow through—don’t waste your team’s time with a meeting to maintain the illusion that you care about what others think—they know you don’t.)
  • Minutes, including action items and commitments, are recorded and published post haste. They are also maintained in a team public place such as a wiki or project portal for reference and follow up.

Goal Oriented Meetings Foster Better Software Development
I included some links already that talk about goal oriented requirements engineering and behavior driven development (BDD). In Dan North’s treatment of BDD, he presents two single sentence templates for defining each of the requirements of any software system. With my own explanations, they are:

To define a feature or user story:

As a [X], I want [Y], so that [Z].

Where [X] is the role of a user, [Y] is the feature, and [Z] is the benefit or value (the goals) of the feature.

And to define the acceptance criteria for that story:

Given [some initial context—the givens], when [an event occurs], then [ensure some outcomes].

The outcomes to be assured also define the goals of the user specifically within a certain behavioral or system state context.

When the goals of stakeholders are clearly understood and can be codified in a manner such as the BDD form, the development team can move forward more quickly and with greater confidence. And when meetings are equally focused on goals and achieving them, meetings will be an asset rather than a liability. And your team will have a much greater opportunity to succeed.

Enterprise Content Management for the Win in 2012

December was an interesting month with multiple pieces on the chess board moving all at once insuring an interesting and exciting new year for me. And that new year is upon us. I picked up my copy of CIO Insight magazine, the November/December 2011 issue, this morning and read with delight the article entitled Where the IT Dollars Are Headed in 2012.

One passage in the study mentioned in the article (included in the print version and linked to online) caught my eye:

“Elsewhere in enterprise applications, collaboration, and content and project management are rapidly gaining popularity, which makes sense given the new mobile opportunities for these categories. Collaboration and content management are seeing increases in 2012 over 2011 of roughly 10 percentage points in the number of organizations budgeting; and among those that already were spending in these areas, budget growths are averaging 14.6 percent and 7.3 percent, respectively—both significantly higher than 2011’s growth.”

I have a recently renewed and very keen interest in the potential growth of the enterprise content management market. And I will blog more about this in the coming weeks which are sure to open up new opportunities for personal and professional growth.

Attracting and Keeping Top Talent in Software Development Teams

A friend recently shared a Forbes article with me entitled Top Ten Reasons Why Large Companies Fail to Keep Their Best Talent which I found informative and useful in understanding my own recent thoughts on this topic. Rather than review each of those reasons here, I encourage you to read the original. Instead I would like to share with you the flip side of that coin based on my own recent experiences.

Attracting Top Talent
Before you can work on keeping your top talent, you have to find them and convince them to join your team. Here are five things you should be doing to attract top talent:

  1. Choose a competent and effective recruiter. This can make all the difference. Don’t just hire an agency and let them blast a job description to every Tom, Dick and Mary of the tech world. Know specifically who is representing your company. Make sure that she knows how to find and filter top talent for you. Ensure that she has the communication and people skills required to manage the phone and in-person interviews and coordinate with the hiring manager to make his job even easier rather than just dumping a pile of resumes on a desk and waiting to get paid.
  2. Do more than one phone screen. Give at least two top team members the chance to phone screen the candidate. Make sure they are prepared and understand what they should ask. Then have one or two managers or potential peers conduct a phone screen as well. Never rely on the resume alone to decide whether you will do a face to face interview.
  3. Have the candidate interview with more than just the hiring manager. Have potential peers and even potential subordinates interview the candidate as well. And when possible, have a peer or supervisor of the hiring manager conduct an interview. Meet with and collect the thoughts and opinions of every interviewer and carefully consider their input.
  4. Assure that every interviewer is positive and upbeat about your company but equally honest and transparent about the challenges and opportunities within the company which the candidate may be able to help resolve or improve. Don’t paint a dismal picture but don’t put a shine on a dull spot. Any intelligent candidate who gets different stories from interviewers will think twice before accepting an offer. Transparency and honesty from the bottom to the top of the company will be a refreshing and attractive quality. And don’t worry about scaring off a candidate who is afraid of a blemish. You don’t want to hire someone who wants to work for a perfect company with no opportunities to contribute to the solutions of the real problems that every company has.
  5. Follow up and answer a candidates questions after the interview process is complete and make a decision as quickly as possible. If you will have some delays before you can make a decision, keep the lines of communication open and keep the candidate up to date. This kind of follow through is often overlooked and companies often take for granted that the candidate will sit still and wait. They won’t. To keep a fish on a hook, as they say, you have to work the line. Let it go slack, and you’ll lose.

Keeping Top Talent
Once you have hired a key employee, make an opposites list from the Forbes article and work toward eliminating the reasons that top talent walks out the door. Of the ten, here are my top picks recast as things you should do to keep top talent on your team:

  1. Give your employees an opportunity to have a voice in key policy and process decisions. Listen to your people with an open mind, prepared to change your mind if you have overlooked something. Your top talent will often have better ideas than you may think.
  2. Take the time to provide regular feedback to your employees. Annual reviews are great, but follow up with periodic reviews of goals, professional development, projects and opportunities for improvement. And always find a way to share positive feedback. When you acknowledge achievements and performance, publicly and privately, you’ll get even more of the same.
  3. Make sure that your team members know that you care about their professional career development. The small amount of time you invest in helping your team map their future success will yield returns in happy, dedicated employees much greater even than the recent gains in the gold market.
  4. Steer a steady ship that can make tactical adjustments in course but is on a solid strategic heading. If you run into stormy waters, keep faith with your employees and stay on course. If you need to make strategic course changes, involve your top talent in that decision making. Getting on a boat headed for Hawaii and finding out that the captain has decided to go to Alaska instead without even talking to you can be more than demoralizing.
  5. Build teams of people who can work well together, who are talented and skilled and willing to pull their own weight and then some. Passionate people will help to bring out the best in team members who are having a bad day, but it is impossible to fix a team member who fundamentally lacks the requisite skills and desire to acquire them.
  6. Be open minded and tolerant of opposing points of view. If you do not invite honest discussion with your team at appropriate times, you will lose your top talent and end up with a team that affirms any decision you make, even those that will send you off a cliff that you did not have the foresight to recognize.
  7. You can teach management skills to a leader. But teaching leadership skills to a manager is not so easy. Look for leaders who can motivate and rally teams. You can hire a clerk or accountant to take care of the bean counting. But you may not recover from having a leaderless team and the resultant chaos and confusion and serial loss of top talent that will result. Do not be afraid to amputate and stop the bleeding. Keeping a failed manager long beyond the point of recognizing the problem to avoid the pain of change is an ominous sign to your top talent that you lack the leadership required to steer the ship successfully to port and they will abandon ship at the first reasonable moment.

If you’re making New Year’s resolutions with respect to your company, I urge you to review these lists, and the plethora of others available on the web from sources far more authoritative than me. Take positive action to attract and keep your top talent. And if you find yourself looking for a company that exhibits these desirable qualities, keep up your search. They are out there. And while no company is perfect, there are certainly some that far and away exceed others. So whatever you do, don’t give up hope of a better day.

Dennis Ritchie, RIP, Thanks for C

Dennis Ritchie, the Father of C, passed away a few days ago. A friend asked me today, “Would we have had a Steve Jobs without first having a Dennis Ritchie?” He made a great point. The most common programming language for the Apple platform today is Objective-C. Mr. Ritchie was not an attention hound it seems. I doubt more than 1% of the people who know who Steve Jobs is would know who Dennis Ritchie is, and yet, we in this business of programming owe him a great debt of gratitude.

I know there are C detractors, but the ubiquity of C and all it’s descendants cannot be denied. Andrew Binstock, in his column today on Dr. Dobbs, quoted Mr. Ritchie as having said:

“C is quirky, flawed, and an enormous success. [And UNIX] is very simple, it just needs a genius to understand its simplicity.” ~Dennis Ritchie

Oh yeah, and I forgot to mention he was also deeply involved in developing UNIX. And how many derivatives of UNIX are there? And how many other operating systems at their core are so like UNIX as to make the grand old operating system the true grandfather or at least uncle of every seriously utilized operating system in the world?

I will end by borrowing Mr. Binstock’s conclusion:

“Ritchie saw in language what others could not see, in operating system what others had not built, and in the world around him what others did not realize. His insight and the elegance of his work will be missed by all programmers, even in future generations who, as he would want it, might know nothing of him.” ~Andrew Binstock

Thanks, Dennis Ritchie. Thanks for C. And thanks for UNIX.

And whatever you do, don’t miss this farewell from MuppetLabs. Thanks for sharing it, Dave.

C# 5.0 Exciting New Asynchrony Features Coming

I’m gradually catching up with presentations from last month’s BUILD conference on Channel 9. Today I ran into a blog post by Samuel Jack in the UK on the topic of what’s new in C# 5.0. I recommend you read his blog, but more strongly recommend you watch Anders Hejlberg’s presentation on Channel 9 about C# 5.0 and VB 11.0.

Among my favorite goodies are the async and await keywords. For anyone who has put off learning how to write asynchronous application behavior because it is just too hard to understand, you are in luck. Wait a few more months, perhaps a year, and you can learn just a few easy concepts about how to use async and await keywords in your code and you will be an asynchronous coding wizard.

Exciting times!

Meaningless Meetings Meander Morosely Mostly

Recently I came across an interesting list of top ten time wasters at work. I jotted them down but have lost the source, so I apologize for not providing the link. Here’s their list:

  1. Instant Messaging
  2. Over-Reliance on Email
  3. Meandering Meetings
  4. Short Gaps Between Meetings
  5. Reacting to Interruptions
  6. Ineffective Multi-Tasking
  7. Disorganized Workspace
  8. Personal Communication
  9. Web Surfing "Breaks"
  10. Cigarette/Coffee Breaks

It’s a decent list that one might find on many top ten sites, I’m sure. But it’s not terribly accurate. You see, the biggest time waster in the enterprise is the Meaningless, Meandering Meeting Machine. So here’s my revised list:

  1. Thinking about meetings.
  2. Planning meetings.
  3. Doodling in meetings.
  4. Talking about meetings.
  5. Scheduling and rescheduling meetings.
  6. Meetings.
  7. Follow-up meetings.
  8. Looking or asking for minutes from meetings.
  9. Assuming people will do what was agreed to in meetings.
  10. Making lists about meetings.

I have seen good, productive employees become consumed by the Meaningless Meetings Machine. It is an endless recursive function leading to enterprise stack overflow. Sometimes executives are lost for months in the Machine and when employees smart enough or lucky enough to stay away from the Machine are asked if they have seen Mr. Soandso, they say, No, and hurriedly move on lest they too be sucked into the Machine.

Seek to Establish a Corporate Culture of Honesty

In April of this year, an executive of another company told me in a telephone conversation, "Everybody lies. You just have to get used to it."

I was stunned by the statement and have given it a lot of thought since then. It reminded me of a scene from Babylon 5 that went something like this:

Garibaldi: Everybody lies.
Edgars: That's a very sad view of the universe, Mr. Garibaldi.
Garibaldi: Yeah, well, it's the only one I got. And it works for me.
Edgars: The truth will be revealed in a couple of days. How many people can say that?
Garibaldi: I don't know. But I think the last guy got thirty pieces of silver for the same job.

Dishonesty in this technological age has even produced its own vocabulary, specifically the verb "to blag." The third definition of "blag" in the Urban Dictionary:

To convince another person that all the stuff you just made up is in fact true and worthy. Example: "Caught in a tight spot, Harry blagged his way through the conversation and somehow got the job."

I do not wish to accept the dim view that everybody lies. And I certainly do not wish to get used to it, in any way shape or form. And yet there is growing evidence both anecdotally in my own professional career and globally that the enterprise often creates a dishonest culture. Author Brian Amble in Management Issues filed a piece in 2005 entitled Corporate Culture Encourages Lying. The author mentions "blagging" and makes these three very interesting points:

"The rot starts at the top, revealing a surprisingly ambivalent attitude amongst...bosses towards the honesty – or otherwise - of their staff."

"The vast majority of company directors and senior managers believe it is wrong for their employees to lie to them. But almost half are comfortable with those same employees telling untruths on their behalf to their customers – with female bosses even more tolerant of this sort of behavior than their male colleagues."

"[Microsoft] encourages decision-making [using a] technology-based process that creates permanent digital records and maintains the integrity of the information on which those decisions are based."

In my experience blagging is most especially prevalent in the world of software development where management clings to the notion, and consultants sell the latest process magic to reaffirm the assumption, that building software is like building a house, sufficiently predictable and repeatable so as to accurately establish a firm budget, timeline and resource commitment before ground is broken. Software artisans then find themselves in the very uncomfortable position of feeling pressured to lie to their patron bosses who clearly do not wish to know that building software is often as much an unpredictable art as it is in any way a predictable science.

Software craftsmen who boldly stand their ground and declare, "I don't know how long it will take to build that," are more often attacked and labeled malcontent and misfit, shunned by managers who insist that they can bend reality to their will while they ignore what their experts have told them. And lower management who know better are caught in the ultimate catch 22. They may believe their lead developers or software architects when they say, "we cannot deliver all these features on that date," but they cannot report that fact to their own managers or customers, so they choose to lie in order to protect and even advance their own career knowing that if the implementation team fails, they may avoid accountability by throwing the developers under the bus, asserting the implementation team is incompetent and ought to be replaced.

Given the impossible circumstances in which software craftsmen find themselves, they often resort to lying to themselves and their bosses asserting that they can produce some piece of software, despite the general lack of specific requirements and understanding of the problem domain or the target users, within the time budget and resource constraints imposed by management. And then in order to avoid being exposed as just another blagger, the software artisan (or collectively the team) works impossible hours, makes imprudent quality compromises and desperately seeks for external circumstances which can be blamed for delays. Knowing that such responsibility diverting opportunities always arise, the software artisan begins to accept and even embrace the culture of lies produced by her circumstances until she does not even recognize the truth.

I know that this scenario is not universal. There are organizations who take great steps, incorporating technology and constant vigilance, to avoid the traps of dishonesty. These organizations are led by honest people who genuinely listen to their people and avoid the trap of boxing their software craftsmen into a set of assumptions that are untenable at best and downright foolish at worst. Dr. Rhonne Sanderson said it best in an article by Marcia A. Reed-Woodard entitled Don't lie to me: dishonesty can ruin professional and personal relationships:

"Although lying provides an easy out in the short-term, it comes with serious repercussions," says Dr Rhonne Sanderson, a Dallas--Fort Worth area licensed psychotherapist. He maintains that the fallout from lying can hurt others, ruin relationships, as well as rob the liar of integrity, credibility, confidence, and self-esteem. "Lying only exacerbates the real problem."

If we let honesty govern our dealings with our fellow man, we will all be the better for it. We do not need to sacrifice civility for honesty, nor should we mistake an honest disagreement for disrespect or insubordination, for when we do, we encourage others to be dishonest through their silence.

We can boldly speak the truth and expect others to do so. We can hold ourselves and others to account. We need not settle for the notion that everybody lies. And we certainly do not need to get used to it. We can and ought to do and be better.

Fear Corrupts Process and Assures Failure

A certain angel investor chose three companies in which to invest a relatively large sum. In the first, he invested $10 million. In the second, he invested $5 million. And in the third, he invested $1 million. A year later, the first had doubled in value because it had boldly used the capital to execute on its business plan. The second company had also doubled in size because they had taken the investment and worked very hard to grow their business. The third company had run into some problems and was afraid of losing their capital, so they did nothing and had nothing to show for it. The angel investor liquidated his interest in the third company and those people are now looking for work.

Yes, I’ve borrowed the plot for that story from someone much wiser than me. But it applies in today’s world of technology and software development as much as it applies to the context for which it was originally told. Fear paralyzes us into inaction or into making unwise choices which almost always result in the corruption of otherwise sound business processes and just as often leads to complete and utter failure.

One of the greatest fears in software development that corrupts process and assures failure is the fear to tell the client or customer no. In the world of software development, especially in internal enterprise software development, the fear of saying no can be so paralyzing that we often place impossible burdens on teams already pushed to their limits. The fear of saying no can lead us to short circuit our process, skip critical steps and gloss over real analysis and careful design. The fear of saying no can lead to general discord when a team member objects and the manager angrily brushes her off, dismissing her concerns as irrelevant or inconsequential. This fear leads to chaos and assured failure. Failure to deliver on time. Failure to communicate and manage realistic client expectations. Failure to establish credibility and confidence with the client and the organization. Failure to keep and foster a well organized, happy and productive team.

So how can one overcome this fear? You just jump. How does the diver overcome his fear of heights to jump from a platform so high the first time? He just jumps. How does a skydiver overcome her fear of falling to her death from an airplane? She just leaps or is pushed. And then training and preparation take over and fear is overcome. You may never completely overcome the fear of saying no. But if you jump, take a leap of faith, just do it, you’ll find that you have not died and that you will have an easier time doing it the next time.

When we overcome our fear and take a leap of faith, we can accomplish great things. Let us work like the first two companies in our story and succeed.