The Value of Daily ‘Stand Up’ Meetings

Posted on Updated on

In reading Patrick Lencioni’s “Death by Meeting” a few years ago, I came across a simple and effective idea: the daily ‘stand up’ meeting.  Often employed in Agile development, the concept is a simple one; the project team meets for 10 minutes each day for a quick meeting where everyone literally “stands up” and the focus is on three simple questions:

  1. What did you do yesterday?
  2. What are you doing today?
  3. What do you need from me (the project manager, business sponsor, etc.)?

I’m currently working with some great clients who are making good use of this approach.  We meet every morning, knowing the agenda (above) in advance.  After about 5 minutes of respective prep work, the participants are ready to go.  Everyone understands that issues that only impact several members of the team are to be addressed after the meeting in a smaller group, made up of those stakeholders.

I think there are several benefits of this approach:

  • Teaches participants to collaborate to conduct highly efficient, content-rich meetings
  • Allows everyone to hear each other’s expectations of the day and each person’s take on what they believe they did the day before, providing a great opportunity to catch any problems, miscommunications, accountability issues or potential risks
  • With strong leadership of the meeting itself, the team remains focused (the leader will need to work hard to enforce the ground rules while at the same time not taking a dictatorial approach to running the meetings)
  • Significantly reduces the chances of unpleasant surprises

If you choose to employ this method, a few tips:

  • Prepare ahead of time and insist that all participants do the same
  • Everyone should be on time
  • Minimize distractions – make sure everyone is focused on the speaker and not sending emails, texting, making/taking calls
  • Stay focused, but make sure that any topics brought up that aren’t appropriate for all participants but that are critical to the project are acknowledged and dealt with as soon as possible after the meeting

While the ‘stand up’ meeting isn’t a substitute for a more comprehensive weekly project team meeting, its great way to manage expectations, make sure the team is communicating, and to manage risk.

“Above The Fold” Email – Writing To Be READ

Posted on Updated on

In a world where we’re deluged with information on a daily basis, writing effective emails is an important skill.  I’m a big fan of the ‘above the fold’ approach.  In the publishing business, ‘above the fold’ refers to placing important information ‘above the fold’ of the newspaper to entice someone to buy the paper*.  In writing email, the concept is the same – enticing your reader to READ your email and perform the desired action.  Here are some tips and tricks on writing ‘above the fold’ emails:

DEFINE THE OUTCOME: What is the desired outcome of the email?  What do you want to happen?  ANSWER that question before you write, then use the answer as a litmus test, asking yourself “is this information absolutely necessary to achieve the desired outcome?”

BLOCK CAP THE SUBJECT: Make it clear what’s coming.  For example, if you’re asking the recipient to do something, try a subject line like “ACTION REQUESTED: Budget Review/Approval” or “REPLY REQUESTED: Input To Communication Plan”.

ASSUME THE RECIPIENT WON’T READ PAST THE FIRST PARAGRAPH:  This will keep you from rambling.  Refer back to your defined desired outcome to keep it concise.

CALL OUT THE REQUEST: If the subject line says that an action or reply is requested, call it out in the email.  Start the second paragraph with ACTION REQUESTED: <What you’re asking the recipient to do>.  You can even call it out by making the text red.

USE A FRAMEWORK: Using a framework not only makes it easy on you when you write an email, but it helps your regular readers when they know that emails from you tend to follow a framework that is respectful of their time and gets right to the point.  One that I like goes as follows:

  • What: What you need
  • When: When you need it
  • Why: What the business impact is if you don’t get it

MULTI-PARAGRAPH EMAILS:  Sometimes, even the best writer has to send a multi-paragraph email.  In such cases, you still need to assume that your reader isn’t going to read past the first paragraph so you have to catch their attention and give them a reason to read on.  The first paragraph should explain the situation that prompted the email and why YOU, THE RECIPIENT needs to care.  Here’s an example:

  • “As you know, we are currently working on a project to sunset our existing CRM application and replace it with a new application.  The project must be completed before the end of July, as our busiest time of the year begins in late August/early September.  There are several issues that must be resolved in the next two weeks if the project is to remain on schedule.  Each of these issues requires your approval.  The issues and requested actions are summarized below:”

Make sure that the first sentence of every paragraph summarizes that paragraph.  This will keep you focused while you write and will also protect you if your reader takes the ‘how to read a business book’ approach and skims the first sentence of each paragraph.

PROOF: Read the email before you send it, asking yourself if everything you’ve included is really necessary to create the desired outcome.

Writing clear and concise emails not only is respectful of your reader but helps build a personal brand that ensures your emails are read!

*My friend, Art Hopkins (President and CEO at Macquarium), also notes that the “above the fold” concept is also used in UX/web design for the same purpose.

© 2011, Mark E. Calabrese

Conducting Effective One-On-One Meetings With Your Executive Direct Reports

Posted on

Some executives assume that they don’t need to have regular one-on-one meetings with their executive direct reports.  The idea that such meetings aren’t really necessary “at our level” is short-sighted.  What is not necessary is using the same one-on-one framework that you’d use if your direct reports were front-line staff.  What is necessary is a framework more appropriate to the needs of an executive and his or her direct reports.

I highly recommend a weekly one-on-one with each of your executive direct reports (we’ll simply call them “managers” for this post), being flexible when needed.  In addition to gaining valuable information that you need in order to be effective in your job, these meetings are a valuable way to help your managers understand the nature of your job and what you need in order to be successful.  By doing this, you’ll not only get valuable information that you need, but you’ll be grooming your managers as part of your own succession planning.

Here’s the agenda I recommend, in this specific order (I’ll explain why shortly):

  1. Needs: How can I help you?  What do you need from me in order to do your job?
  2. Updates: Make me smarter.  What do you know that I need to know?
  3. Professional Development: How can we use opportunities in your current role to help you develop for your desired future role?


One of the three things that leaders owe their teams is to remove obstacles.  Since execution and delivery are your team’s top priority, this is always the first item on the agenda.  By so doing, you’ll know where you can add the most value NOW should your one-on-one meeting get cut short.  They key question to be answered in this part of the meeting is, “What do you need from me in order to do your job?”


While you owe your team THREE things, your team owes you ONE thing; to make sure you have the opportunity to never make a mistake.  Your managers can do this by providing you key updates, based on your needs.  First, help your managers understand what you need to know, why you need to know it and what level of detail is required.  Finally – and this is key – help your managers understand how you plan to use their updates.

Help your managers understand what “success” means at your level and how they can help make you successful.  They do this by updating you on what’s happening in your area based on your needs as an executive, and to make sure you have the opportunity to never make a mistake.   Don’t let them bury you in minutia; keep it focused and productive.  This way, you not only get what you need to do your job but you make your managers smarter by helping them understand how they can help you.


Part of your role as a leader is to develop your staff to maximize their contribution to the business as well as to foster their personal development.  Start by using the ‘Greed/Fear’ Framework to understand what each manager wants professionally and personally.  Make sure you understand their short-term (current role) and long-term (overall career) goals. 

Typically, business technology teams perform in one of three work streams:

  1. Operations and Production Support
  2. Policy and Procedures
  3. Projects and Initiatives 

Frame each development opportunity within the relevant work stream so that you can provide feedback and development opportunities for your managers within the context of businesses needs.


Investing in our teams is an important part leadership.  This is even more important when it comes to our executive level direct reports.  A well-developed management team functions as your personal brain trust, helping you be a more effective leader.  Such a management team also will earn the trust and confidence of your business partners and also from your managers’ respective organizations.  You’ll also be grooming your managers so that you can ensure a smooth succession when your next opportunity arises within or without your current company.  Take the time to meet with your managers on a regular basis and make sure you use a framework that meets your needs as a leader AND the needs of your managers as aspiring executives.

© 2011, Mark E. Calabrese

Greed and Fear: Part II – Applying the Framework

Posted on Updated on

In Part I of this post, we said that the ‘Greed/Fear Framework’ is focused on understanding others and is driven by a genuine desire to invest in others by actively listening and by empathizing.  This is easier on the ‘Professional’ level than on the ‘Personal level’.  Let’s look at an example:


Your business partner is responsible for Call Center operations in your firm.  The Call Center currently uses a legacy CRM system.  While the system is fully paid-for, it runs on hardware that is no longer supported by the vendor and the CRM itself is also out of support (though partial support can be obtained through a third-party).  Business operations depend on the predictable and reliable performance of the CRM.  Your business partner has sponsored a project to replace this legacy system.

Your business partner has been with the firm for some time and has been in multiple roles within the organization.  While not necessarily public knowledge, your business partner has been put in charge of this project as a ‘last chance’; should this project fail, part of the fallout may well be the elimination of your business partner’s job.  Therefore, in addition to needing a reliable CRM for Call Center operations support, your business partner also needs a win.

This is how the example above might look in the Greed/Fear matrix:

The ‘Professional’ column is usually the easy part.  An understanding of the business problem to be solved and the impact of doing nothing is generally enough, but it makes sense to gain a deeper understanding of the situation.  What happened in the past?  Why was the current system allowed to go so far out of support?  What drove that decision (or lack of a decision)?  These are all good questions to ask.  The goal is not necessarily to fill out a framework; the goal is to gain the necessary understanding of the ‘Professional’ wants/don’t wants involved in the issue so that you have a solid context around the issue itself.

The ‘Personal’ column is often times more critical than the ‘Professional’ and presents its own unique set of problems.  Most people at work want to look great and be successful in their job either because they want a promotion, want to get their full percentage of bonus or just because they get a deep personal satisfaction out of succeeding.  But most people aren’t likely to share their ‘Personal/Fear’ and asking them is likely to damage your relationship.

Your only hope in “populating” the ‘Personal/Fear’ quadrant is to rely on your ability to ask the right questions, listen effectively, empathize, and ultimately, to trust your instincts.  Some people are easier to read than others.  Other people will be more than happy to share the content of their ‘Personal/Fear’ quadrant (sometimes more than you want!).  Ultimately, you’re on your own to use your relationship-building skills to “populate” this key quadrant in the matrix.

You may also find similar challenges in “populating” the other quadrants.  People are not always as candid as you’d like with the ‘Professional’, either.  This is where the ability to build, maintain and leverage relationships becomes a key component in understanding the motivations of those with whom we work.  Don’t assume that you can simply ask about the ‘Professional’ and it shall be given.  You still need to sanity-check what you’ve heard against what you already know and what experience has taught you.  Trust your instincts.

Keep in mind that the intent is to use the matrix as a mental framework to understand the motivation and actions of others.  I don’t recommend telling others that you make use of this framework, as people may envision you analyzing them and writing down their motivations into little boxes.  I’d also recommend that you not share the “contents” of your matrix.  The purpose is to gain understanding so that you can communicate and work more effectively with others.  Branding yourself as a workplace arm-chair psychologist is not a brand that inspires trust and confidence.

© 2011, Mark E. Calabrese

Greed and Fear: Part I – Understanding the Framework

Posted on Updated on

In 2008, I had an interesting dinner conversation with a business partner, Vin Deschamps, CEO at Echopass.  Vin contends that humans are motivated by either “greed” or “fear” and I think he makes a valid point.  Thinking about that, it occurred to me that understanding these motivators from a personal and professional perspective could yield a simple, but effective leadership and communication framework.

Understanding the Framework

‘Greed’ is a loaded word with negative connotations, but at root, it’s wholly appropriate.  We may want more money, more free time to spend with our families, a new car, a better life for our children – any number of things – but ultimately we are motivated in part by what we WANT.

Conversely, we are also motivated by what we wish to AVOID – what we ‘Fear’.  We may fear losing our jobs, poor health, a downturn in the economy – again, any number of things – but we are similarly motivated by what we do NOT want.  If these observations don’t sound like rocket surgery to you so far, then we’re on the right track.

In the workplace, Greed and Fear come into play on two levels; the professional and the personal.  The Professional level revolves around the job or function we are paid to perform – completing project X, running your department efficiently, etc..  The Personal level revolves around your own goals for yourself – your personal brand, your career objectives, your clout, etc.

The matrix below shows how the framework might look:

The goal of the framework is to gain an understanding others, which is at the core of building, maintaining and leveraging mutually beneficial relationships.  Understanding people’s motivation (greed) and concerns (fear) at the personal and professional levels will help make sense of their words and actions, and how they interpret the words and actions of others.

The driver of the framework is genuine interest and the ability to listen and synthesize.  This means employing active listening and getting invested in the relationship.  You need to care about and have an interest in the other person.  You have to flesh out the framework with REAL content.

In Part II, we’ll talk more about how to use the framework, as well as its limitations.  As always, I welcome any comments either posted here or sent to me in email.

© 2011, Mark E. Calabrese

Keys To Successful Postmortems – Part III: Deliverables

Posted on Updated on

In Part I, we talked about setting up the postmortem meeting and in Part II, we discussed conducting the postmortem meeting itself.  In Part III, we’ll focus on creating a deliverable that can be used to exploit both short-term and long-term opportunities through Action Items and Lessons Learned, respectively.  Consider the following in completing your deliverable:

  • Respect The Framework: The framework focuses on Pluses or Deltas in each phase of the project or incident.  Therefore, only capture those practices that were successful and should be kept (Plus) or that were unsuccessful and should either be changed or discarded (Delta), by phase.
  • Action Items or Lessons Learned: Every Plus or Delta captured in the postmortem must result in either an Action Item or a Lesson Learned.  Action Items are specific actions that should be taken in the short-term and are assigned ONE owner and a due DATE.  Lessons Learned are easy-to-understand guidelines or principles that are understandable on their own and do not require extensive knowledge of the project or incident in order to make sense.  More on Action Items and Lessons Learned can be found below.
  • Simplicity: Use a simple template and keep the contents pragmatic (I’ve attached a sample template, below).  Some additional content, such as names/roles of participants, overview of the project or incident, etc., can be beneficial but the primary contents are Pluses and Deltas by phase and resulting Action Items and Lessons Learned.  KEEP IT SIMPLE, creating a deliverable that is READABLE and USEFUL.

If you plan to submit your postmortem document to your business partners as part of project or incident closure, you may wish to include additional content.  That said, strive to keep the content simple, direct and to the point unless circumstances DEFINITELY require otherwise.

ACTION ITEMS: Action Items can include, but are not necessarily limited to, any of the following:

  • Meetings or Discussions: Meetings to discuss a process change or process development, a potential risk mitigation strategy, etc.  In other words, setting up a meeting that might have otherwise have resulted in a problem-solving or sidebar discussion during the postmortem.  Do NOT conduct such discussions in the postmortem; conduct them on their own, with the appropriate stakeholders in attendance, and call out an Action Item to make the meeting happen.
  • Specific Actions: For example, any code changes, configuration changes, etc.  Any specific actions required in the short-term to address any issues that were raised during the postmortem or immediately after project go-live or incident closure.

Action Items have ONE owner, who is accountable for completion.  Even if multiple resources will be involved in completing the work, there is only ONE person accountable for ensuring the item is completed and closed by the due date.

Action Items have a Due DATE.  The postmortem facilitator should have the Action Item owner set the due date, but if the owner hedges, suggest a due date to them and NAIL THEM DOWN.  The due date can always change, but get a commitment during the postmortem and DOCUMENT IT.

LESSONS LEARNED:  Lessons Learned should be archived in a single Lessons Learned Master Document (e.g., a simple MS Word document with bullet points).  You can categorize Lessons Learned by phase, etc., but be careful; the more you play with the list, the more likely you’ll end up making a task out of maintaining the list.  Better to maintain a simple list that can be printed out and reviewed at the start of every project as a reminder of what was learned in past projects and what should be considered in the current project.

Each Lesson Learned should be stated very clearly and concisely and should be understandable ON ITS OWN and on a FIRST READ.  Lessons Learned should NOT require detailed knowledge of the project in order to gain context and understanding.  Therefore, it’s important to edit each Lesson Learned to make sure they are well written.  Have someone who is NOT familiar with the project or incident review the final Lessons Learned for readability before they’re added to the overall Lessons Learned Master Document.

Review the Lessons Learned Master Document after each project or incident to ensure there are no duplicates and also to ensure that, as noted above, each lesson is clear and understandable.  Production support/service restoration issues will now allow the luxury of a review of the Master Document at issue identification, so support teams may wish to review the Document on a regular basis as a risk mitigation strategy.

The template below is a baseline document to be stolen/edited it as you see fit.  As always, I welcome any comments, questions or thoughts and can be contacted at  Good luck!

Plus Delta Postmortem Template

© 2011, Mark E. Calabrese

Keys To Successful Postmortems – Part II: Conducting the Meeting

Posted on Updated on

In Part I, we talked about setting up the postmortem meeting.  The postmortem is part of a project or release close out and is also beneficial (and should be used) at the close of any security or production support incident, etc., as part of the RCA (root cause analysis).  Bottom line is that any time a project, incident or initiative is closed, there’s an opportunity to capture any lessons learned and leverage the knowledge going forward.

I’m a big fan of the ‘Plus/Delta’ framework for capturing postmortem findings. In this framework, a Plus is any practice, process or finding that worked well and should be kept or repeated in the future.  Conversely, a Delta is any practice, process gap or risk that resulted in a problem and should be changed or fixed.  Identify Pluses and Deltas for each phase of the SDLC/Project Life-cycle:

  • Initiating
  • Planning
  • Executing
  • Controlling
  • Closing

You can use this framework to conduct the meeting, as well.  Keep it simple; for each phase, discuss and document all Pluses and Deltas.  For incident postmortems/RCAs, you can be flexible on the specific phases (as the SDLC or Project Life-cycle may not be appropriate).  For example, incident postmortems can make use the following phases:

  • Identification
  • Communication
  • Short-Term Resolution (how was the problem fixed?)
  • Long-Term Resolution (how do we make sure the problem doesn’t happen again?)
  • Closure

The point is to go through the incident or project in a logical, chronological fashion, capturing Pluses and Deltas.


Here are some guidelines to consider in facilitating the meeting:

  • Who Should Facilitate the Meeting: The facilitator should NOT be a member of the project or incident team. The reason that the facilitator shouldn’t be someone involved in the project or incident is that you want THOSE resources to contribute content, while the facilitator is responsible for guiding the meeting, keeping it productive and acting as…..well….as the facilitator. It’s also best to have a neutral party facilitating the meeting in the case of a not-so-successful project or issue resolution.  This avoids anyone thinking that, for example, the developers got off easy because the facilitator was the lead developer on the project.  The facilitator should be someone familiar with the team who can keep the meeting controlled and productive. You can facilitate the meeting if necessary, but it’s always better if it’s someone at the same level as those on the postmortem team.
  • Pre-Meeting by Functional Teams:  The postmortem team should not just “show up” for the meeting and figure it out as they go along.  Each functional team (e.g., the Development team, the QA team, the network team, etc.) should meet on their own beforehand to discuss their specific observations.  During this pre-meeting, each functional team should use the framework below to document their findings, then publish these findings to the rest of the postmortem team in advance of the meeting.  This will help stimulate thought and discussion, resulting in a more productive postmortem.  Strongly encourage all participants to review the combined findings beforehand.  The facilitator can also combine all the findings into a draft document and send it to participants in advance as well as using the document on the overhead to guide the meeting.
  • Documenting: Use an overhead projector and a laptop to avoid any double-work in documenting the findings.  If that’s not an option, use a white board or easel and get everything written down and into the document as soon as the meeting is over (and throw all that paper away).  Only document findings that will result in an ‘Action Item’ or a very clear ‘Lesson Learned’.  For example, documenting that the QA team did “a really great job” feels great but it has no pragmatic benefit going forward.  The point is to create a deliverable that is useful beyond the project or incident.


Establish and communicate the ground rules in advance of the meeting and review them as the meeting begins.  Make sure you follow the same rules for each postmortem.  The facilitator MUST be very clear on the ground rules and tactfully enforce the rules while not quashing discussion (particularly with the ‘No Problem-Solving’ rule; that is the hardest to enforce, I guarantee!).  Here are some ground rules to consider:

  • No Problem-Solving: The purpose of the postmortem is to capture Action Items and Lessons Learned and NOT to solve all the problems that came up during the project or incident.  Problem Solving sessions are Action Items and should be conducted outside of the postmortem and will include all stakeholders in resolving the particular issue or process gap.  While you will DEFINITELY have people in the meeting who’ll want to tear into a problem and start kicking around ideas, the facilitator has to stop this and instead, note an Action Item to set up a meeting to tear into the problem and NOT do it during the postmortem (if you ever want the meeting to end, anyway!).  Trust me – this is the one rule you’ll be enforcing right up to the end of the meeting, so be very tactful and positive about this – again, you do NOT want to quash discussion and have people shut down/not participate.
  • Processes, Not People: When focusing on some of the Deltas, avoid focusing on the actions of specific people.  Focus on the process gap and not the person.  If someone’s actions caused a problem, this is evidence of a process gap that allowed something bad to happen.  If someone falls through a hole in the floor, firing the person who fell through the hole WILL get rid of the “faller” but the hole remains; fix the damn hole.  Besides, focusing on the people will lead to bad blood both during and after the meeting.  Don’t allow this to happen.
  • No Distractions: This one is obvious.  The “no sidebars” rule is important and, to my mind, goes without saying.  I also recommend a ‘no Blackberries/iPhones’ rule.  With the sole exception of someone who has a specific reason, production support issue, etc., that necessitates that they keep their phone near them during the meeting, instead set up a “coral” (i.e., a shoe box or something) to house everyone’s phones and allow a break every 45 minutes / 1 hour for people to retrieve and check their phones.  This keeps the meeting focused and is respectful of other people and their time.
  • Action Items: Action Items have ONE owner, who is accountable for ensuring the action is completed.  It’s true that Action Items usually have many stakeholders/participants, but only ONE person accountable for delivering – period.  Also, ‘TBD’ is NOT a due date.  Due dates have specific dates, months and years.  You can always change a due date but do NOT let anyone walk out of the meeting with an Action Items assigned to more than one person and with no firm due date.
  • Follow the Framework: Make sure you follow the framework in order to maintain focus.  For example, for a project you’ll start with the ‘Intiating’ Phase and discuss what went well and should be repeated/kept (Plus) and what went badly and needs to be fixed/changed (Delta).  The idea is to keep the framework simple and clean and focus on identifying the action items and lessons learned.

Basically, your facilitator ensures that the brainpower in the room produces a solid list of Action Items and Lessons Learned and makes excellent use of everyone’s time.  The facilitator should ask for anonymous feedback after the close of the meeting – what could have been done better/different?  Another good opportunity to capture some learnings.  Also, allowing others to facilitate and avoiding the task yourself is a good way to build leadership skills in your team.  If your team is new to this process, you facilitating the first few sessions to establish precedence is worth considering.

In Part III, we’ll discuss the postmortem deliverable and I’ll include a sample.

© 2011, Mark E. Calabrese

Keys To Successful Postmortems – Part I: Setting Up the Meeting

Posted on Updated on

Part of closing out any project, outage, service restoration team effort or any initiative whether succesful or otherwise (and it’s even more critical on the “or otherwise”) is the postmortem.  Too often, this milestone in the ‘Closing’ phase of a project is either ignored or not fully exploited.  I’d like to share some guidelines on conducting a succesful postmortem that net useable results.

While the guidelines below are not meant to be all-inclusive (I like to keep my posts short; no more than 2-3 scrolls as my friend Greg Hubbard at Cenage wisely advised).  Use your judgement on what to add, modify or ignore.  In Part I, we’ll focus on the meeting itself (timing, participants, etc.):

  • Setting Expectations: Make it known either at the start of a project, early in the SRT (service restoration team) effort during an outage or just as a general principle of your management style that you will hold a postmortem after project or issue closure.  This will help ensure that people will take note of the good, the bad and other learning opportunities.
  • When To Meet: Schedule the postmortem shortly after successful project go-live, or as soon thereafter as is practicable.  The key is to schedule the meeting so that doesn’t interfere with any critical post go-live activities but soon enough to capture any learnings while they’re still fresh in everyone’s minds.
  • Where to Meet: Pick a conference room that has lots of room and ideally, lots of natural lighting.  You want to keep people awake and talking in order to get good input that can be used well after the project is completely closed out.  Make sure there are plenty of white boards or easels with tear-away Post-It sheets as well as markers that work.  Finally, have some coffee, water, pop (or ‘soda’ as you east coast people insist on calling pop) on hand.  I’m not a big fan of food at a meeting, but that’s your call.
  • Conference Calls: Ideally, you want people to be there in person but these days that’s not always practical or possible.  Do the best you can.  In Part II, we’ll discuss how to ensure good engagement and input from those dialing in.
  • Who To Invite: Include everyone on the project team, especially business partners who were critical to both the decision-making process as well as in any UAT, JAD sessions, requirement gathering/approvals, etc.  Ultimately, you want to include everyone who did the “real work” on the project, as well as any key stakeholders or project influencers.  If you find that the list of attendees is becoming unwieldy, try to limit it to those who have the most knowledge of what went right and wrong on the project and also make sure they are people who will SPEAK UP AND GIVE THEIR OPINIONS!
  • Timing and Duration: Set aside at LEAST two hours and try to hold the meeting on a Tuesday or Wednesday morning.  Mondays tend to be busy and Fridays, people have other things on their minds (or may be working from home).  I prefer mornings, as afternoons can be “sleepy time” for some people, so earlier in the week and early in the day is optimal.  I like 9AM until 11 or 12.

In Part II, we’ll talk about conducting the postmortem meeting and in Part III, we’ll talk about the deliverables and putting them to work for you, your team and your organizations beyond the project so that you truly CAN leverage lessons learned.  Stay tuned.

© 2011, Mark E. Calabrese

Some Thoughts (and Some Frameworks) on Agile

Posted on Updated on

I had an interesting coffee meeting today with Gregg Wheeler with Solstice Consulting.  Solstice is increasingly becoming known as a solid Agile partner, both in applying the principles to their work and also in helping technology teams apply these principles to their own methodologies.  They’re hosting a workshop in April – find more information here.

Gregg and I discussed how Agile is now viewed not as the label to “keep things the same” as was the fad with many technologists in the 1990’s.  Now, both technology AND business teams are seeing the value in applying these principles that allow the business-technology partnership to quickly adapt to and exploit business opportunities before the competition.  Below are a few frameworks that are worth posting, reading and if applicable at YOUR shop, are worth swiping.  All of them are broken down into that most magical of numbers – three:


  1. Product Owner: Plain and simple, this is the business partner who has the business need and decision-making authority.
  2. Scrum Master: The “project manager” or team lead, whose primary function is to remove obstacles to progress and to coordinate discussions, decisions and where necessary, activities.
  3. Project Team: The people doing the work.


  1. Product Backlog: The prioritized “wish list” of enhancements, features, maintenance items, etc., that are required to meet the businesses needs.
  2. Sprint Backlog: The next level of granularity, consisting of a breakdown by task with ETC (estimate to complete)
  3. Burn-down Chart: The breakdown of tasks against the available hours.  For example, if a given Agile cycle is two weeks or X hours, the burn-down chart shows how the available time in the cycle will be consumed by the tasks within the Sprint Backlog.


  1. Sprint Planning: Breaking down the Sprint Backlog into the requirements that will ultimately drive the tasks.
  2. Daily Scrum: Led by the Scrum Master; these are typically 5-10 minute “stand up meetings” where the Scrum Master asks three key questions: 1.) What did you do YESTERDAY?; 2.) What is planned for TODAY?; and 3.) What OBSTACLES to progress need to be removed (the role of the Scrum Master, as noted above).
  3. Demo and Retrospective: The team meets with the Product Owner to demo the work to date and to perform a brief postmortem to identify lessons learned and action items with SINGLE owners (a single point of accountability) and with DUE DATES (e.g., not “TBD”)

I think it’s worth repeating the three questions that are at the heart of the Daily Scrum.  Again – they are:

  1. What did the team to yesterday?
  2. What will the team do today?
  3. What obstacles must be removed to ensure team success?

I really like the idea of the 5-10 minute “stand up” meeting.  I first read about these in Patrick Lencioni’s ‘Death by Meeting’ – a book I highly recommend as it’s full of good info and written in Lencioni’s parable-style that makes for a better read in my opinion.

Agile is a solid set of principles that, when employed by the right type of team, can not only provide exceptional business value to the “business” part of the business-technology partnership, but also creates a fun and rewarding working environment!

© 2011, Mark E. Calabrese

The Power of Indifference

Posted on Updated on

Preserving our sanity is an important part of being a leader.  Part of any good ‘Sanity Preservation Program involves understanding and properly embracing the ‘Power of Indifference’.  Let me start out by telling you what this is NOT.  The Power of Indifference does NOT mean being indifferent to the quality of our work, our team’s work, or our business partner’s and BT partner’s work.  Nor does it mean indifference to the consequences of our decisions, our partner’s decisions, our actions, the actions of others…hey, I could go on (and often do) but not now.

There is power, liberation and sanity in being able to “let go” and not let things bother you.  It’s only a job – it’s not life.  Just because work is part of your life (the part that provides the funding, anyway), doesn’t mean that work IS your life.  It’s not.  So don’t treat it as such.  You owe it to yourself to keep things in perspective and to preserve, protect and defend your sanity.

For most of us, almost nothing we do at work really matters.  Our work doesn’t end
war, doesn’t cure cancer and doesn’t make a better world for our children.  Some day in fact, all of our work will be thrown away and mocked by people who never even met us and life will go on.  Ultimately, there are only two things that matter at work:

  1. The relationships we build; and
  2. The deals we broker

Both of these help us grow as people and increase the value we can bring to our teams, each other and our partners.  So in the end, work is but the stage upon which we play out the drama of our careers – the value lies in your ability to keep things in perspective and to control events, rather than letting events control you.  When you are on the cusp of frustration, anger, or fury of the Russel Crowe or Mel Gibson variety, ask yourself this
question (and you have to ask it exactly like this):

“What difference does it REALLY make?”

Keep this in mind: Always be passionate about work; NEVER be emotional about work.

© 2011, Mark E. Calabrese