Emergency Room or Wellness Visits?

Is your software development life-cycle an emergency room or a doctor's office?

Emergency rooms contain urgent requests and responses. ER patients don't have a choice because they've suffered trauma. However, others simply weren't proactive in their healthcare until a crisis occurred.

Doctor's offices service proactive patients coming for care before it reaches life or death. Their care is important, but it's unusual for the patient to die during the visit.

Software development teams can function as Emergency rooms. However, there are two conditions:
(1) The emergency is only for a short period of time and everyone shares visibility of the pathway out of the crisis.
(2) During the hiring process, Team Members are screened for the trait of enjoying / thriving with in a siege.

If you're not planning/needing to run an ER style software development shop, constant emergencies are the smell of mismanaged stakeholders or a failure to adequately anticipate/plan.

Someone once referred to a coworker as a firefighter. They worked great during a crisis. However, that meant a crisis was required for the person to be at their best. Teams led by firefighters (or ER doctors) experience fatigue and burnout from the daily life and death drama (and exaggerated/hyper-sensitive responses to failure). Most people will not maintain an edge of excellence in a string of never ending crisis.

What the solution?

Find calm leaders who insulate/protect their teams from external pressures that present every new project as a drop-everything emergency. Real life ER doctors deal with life and death, and they demonstrate the calm demeanor necessary to lead in a actual crisis. How much more much should we?

Format as Table

Do yourself (and others using your documents) a favor and take advantage of Excel's "Format as Table" if you're not already doing so. It's similar to naming a range.

There are a host of features more easily accessible once you format data as a Table.

There are tricks (some more laborious than others) that only Office gurus know which make documents stand out. However, Office products are increasingly making it easier for casual users to get the same results, and formatting data as a Table is one of them.

Note: Not all columns will format into a table without requiring changes (such as having a unique name for each column heading). However, the formatting effort is worth the time. 

The Problem Pyramid

Note: These are my opinions alone. I'm not employed or associated with The Problem Pyramid, Xmind, or Microsoft.

Looking for a technique to create User Stories in Agile/Scrum? After checking out The Problem Pyramid, you may never get stuck again.

Looking for a technique to create Software Designs which ensure the application works but allows developers the creativity they crave/need? Using The Problem Pyramid to define interfaces may be just what you need.

I'm surprised by The Problem Pyramid's muted reputation relative to its ability to equip everyone from business leaders to software engineers in taming unruly ambiguity and focusing everyone's attention appropriately.

Did I mention it's simple but effective?

One recurring challenge in business (and software) is separating "what needs to be done" from "how it should be accomplished". The Problem Pyramid fixes this.

The Problem Pyramid is an effective tool for guiding Stakeholders, Scrum Product owners, and Technical Leads through story creation and acceptance criteria. It allows teams the freedom to deliver creative solutions while the Stakeholder and Product Owners talk in terms of business metrics (instead of designing software which happens too often) during Release and Sprint Planning. (Software design should get worked out during Tasking, not in front of the Product Owner.)

Here is an oversimplification (but hopefully a fair treatment). Applying this mindset simplifies problem solving considerably because it helps everyone agree to a common vocabulary and context.

Part 1 - The problem

• There is a problem. (I need cash.)
• The problem can be measured as it stands today. (I only have 5 dollars.)
• The problem can be measured as solved. (I need 15 dollars.)

Part 2 - The cause

• What are the reasons the problem exists? (I borrowed money and need to repay a coworker.)

Part 3 - The requirements

• Are there any constraints to how the problem can be solved? (I need the money in the next ten minutes.)

Part 4 - The solution (aka The How)

• What is the best way to satisfy the requirements so the problem is resolved. (Go downstairs to the ATM .)

In addition, this enables groups of people to brainstorm, weigh options, and agree on the best solution by attaching pros/cons to the requirements and solutions.

Need a tool to wrestle all this information, try XMind (for brainstorming) or SmartArt (for summarizing/presenting).

Official explanation of The Problem Pryamid

Smarter people than us have failed

Nobody plans to fail, and nobody wants to. However, history is clear, everyone fails, including highly intelligent people.

Does this create an excuse to not do our best? Of course not. However, overreacting to failure is not a reasonable response to the inevitable.

People will work harder and respect leaders who do not view failure as unexpected/avoidable. Creating an environment where failure is treated as unacceptable only denies the truth - people far smart than us have failed.

What's the answer / solution?

• Leaders should not pretend to be above making the same mistakes as their teams.
• Team members should not pretend to be above the mistakes of other team members (including leaders).

Taming other people's spreadsheets

Spreadsheets are great for managing diverse information. There's nothing as easy and powerful. But, the power comes with a cost.

Other people's spreadsheets can be challenging to understand and manage because the structure of the spreadsheet represents how other's think about the information (or worse, it's been passed around and reflects multiple opinions). In addition, the spreadsheet represents what someone else is tracking/managing which may not be exactly what we care about.

One technique to help place your structure on someone else's spreadsheet is a pivot table.

1. Start by adding a column to the worksheet which represents your opinion/status of the row. For high level reviews, I add simple values in each row such as "correct", "needs review", "needs repair".

2. Create a pivot table from the worksheet.

3. Using the newly added column as a top row summary in the pivot table, we can quickly get a count of how many items need attention and roughly quantify how much work lies ahead.

The more columns you add to the spreadsheet the fancier the reporting. For example, if you add another column which represents "assigned to", you can track who owns what problems and how many are unresolved - instant project management.

The possibilities are as endless as the spreadsheet.

Shame or Explain

"This is not rocket science." and "C'mon, this is not that hard." are heard when stakeholders get frustrated. The implication is people aren't thinking clearly or smart enough for the job.

When this happens ask three questions.
1. Is the wrong person assigned to the task?
2. The right person is assigned, however...
2a. Are they missing some information?
2b. Are stakeholders missing information?


1. Wrong person assigned to the task. Embarrassing a person who is not a good fit for a task is rarely productive. If a person is not up to the task, make a change.

2. Right person but... While it's easy to lob a "C'mon, this is simple" and hope that fixes the problem, if you have the right person assigned to the task, sit down and understand what's happening in greater detail. Repeating "Fix it, fix it, fix it" is wishful thinking.

2a. .... they are missing information. Leading groups is like talking with children - neither are clueless. Consequently, clearly communicate assumptions to reduce confusion. Confusion leads to the unnecessary complexity which results in "What's going on? This is not brain surgery!".

2b. ... they are not at fault. Leading means having abstract/incomplete ideas about what others are thinking/doing. Something may appear simple to stakeholders because complex details are missing. Make time to understand where things are going wrong. It just may be stakeholders need to understand a more complex model of the problem.

Why Scala?

Why I like Scala

It compiles to java libraries that can be shared which means even though others may not know Scala, I can create libraries they can use and can use theirs as well.

It provides shortcuts like case cases that make object Creation, Decomposition, and Matching quick.

A non-programmer like myself can use it to quickly build apps (liftweb) or sling data around in scripts with the help of sbt.