Reduce Your Meeting Dependency

I had a client almost two years ago that was plagued by meetings. Many employees would have back-to-back meetings lasting all day. All of the common symptoms were there: unessential people, no agenda, no clear goals or tasks at the end of a meeting. I remember being annoyed by this the whole time, but the straw that broke the camel’s back was having back-to-back meetings about the same thing.

We coined the term MDD or Meeting Driven Development for them and helped eliminate a huge percentage of their meetings with a few simple rules and tricks to show them him much a meeting really cost them.

First, if there was no clear agenda over email at less an hour before, there was no meeting, period. Initially it was just the consultants that wouldn’t show up, but the full time staff eventually did this too. Often this would eliminate meetings entirely as questions could be answered over email.

Second, we set up a mailing list for people to post to on topics that were relevant to the business including off-topic boards so people could have fun and not clog inboxes. This helped kill meetings by giving them a searchable repository of knowledge.

Third, a wiki was set up with many common threads expanded in a more readable format. Wiki pages were updated and constantly referenced in the mailing lists.

What was the result? More productivity due to more time not wasted in meetings. People actually had time to do work again.

People often wonder why consultants can be so effective at a client site. There are many reasons, but a good one is not being subject to all of the administrative tasks and processes that an employee is put through. Sometimes it is simply that consultants cost too much for the client to be willing to foot the cost of a distracting meeting. Employees are no less important.

Note: agile principles dictate people over process which encourages talking rather than documenting. I’m not against all meetings, only unimportant ones that are wasteful of everyone’s time. Don’t invite 10 people for an hour when 2 for 5 minutes will do just fine for now.

Mingle Tip: Search Mingle Projects Directly In Firefox

Do you love using Firefox’s built in Google search? Wish there was a way you could do that with your Mingle projects? Well, now you can with the code below.

I’ve provided a download of the xml file here.

You’ll need to edit the file to point to the Mingle project you want to use the search tool with and then you need to install it into your searchplugins directory for Firefox, which for Windows is probably something like

C:Program FilesMozilla Firefoxsearchplugins

and for Mac is something like


Drop the xml file in the folder and restart Firefox and you’ll have your new Mingle search up and running. It should look like this

Note: I’m working on getting this to work as described in this mozilla dev article for Mingle. It shouldn’t be too hard since we can modify views in Mingle. I’ll blog about it if people are interested.

PSA: Tab Between All Controls On Mac

I normally love the Mac’s design decisions, but one thing that’s always maddened me is that by default you can’t tab between all controls on webpages, etc. I finally got that fixed today with an article from lifehacker.

Click the “All Controls” radio button at the bottom of the Keyboard & Mouse pane in System Preferences to right this wrong.



When Distrust Turns To Disdain

While taking computer science classes in college, I was taught to distrust a user’s input in all cases. The theory goes that a user’s data can’t be trusted because it could be malicious or just a simple mistake that causes your program to have an error with input it didn’t expect. So you protect your system from incorrect user input and sanitize it. It always felt like one of our dirtier secrets to me, however I fully advocate the practice in code.

My problem comes when the people building software turn from distrusting their user’s input to having a level of disdain for the users themselves. It starts innocently enough with the engineering principles I described above, but can sometimes turn into small things like, “Our users won’t understand that,” and starts to slip into things like, “Our users are dumb, so we won’t do that.” If you’ve started to hate your users, you’ve gone too far. If something is too complex for your users to understand, it’s your job as the developer/engineer/analyst/etc. to make it so that they can understand it. If you think of your users like idiots, your system will reflect that and they will notice.

If your job is to design software for people to use (which, is pretty much all software), make sure you work with the user, instead of against their best interests.

Developers Don’t Read Stories, So Talk To Them Instead

In Jakob Neilsen’s How Little Do Users Read? he sites an ACM study that has found that people typically only read about 20% of content on a page on average, with a max of around 28%.

This just confirms my suspicion that developers fully don’t read the stories that I write for them, even though they are highly focused and relevant to what they are looking for. Instead of reading, they skim and look at the screenshots I provide.

What can we take away from this? Treat stories as a conversation point, rather than a full design spec. If your devs have to read thousands of words in your stories, they are too big. Talk to your team and make sure people understand what you are trying to do.

At 130 words above, most people have read only 26 words in this article, meaning they’ve barely read the first paragraph. Scary.

What Is The Shelf-Life Of A Requirement?

I like to think of requirements as being perishable. They have a certain shelf life before they are developed and then they start to smell funny and eventually go bad as they get out of date. Different sorts of requirements have different shelf-lives.

Master Level Story

The high level stories written at the beginning of a project and turned into a master story list can either have a long shelf life or a short one. If the requirements are not beginning to be broken down and worked on within a week or two, they get stale. Longer than a few weeks, into a few months or more, they should probably be thrown out and at the very least reevaluated. Why? Because your business may have changed in that time. It may not make sense to build those features that made sense a month or two ago.

Release Level Story

Release level stories are good for planning and immediately getting started on detailed analysis and development. They have a short shelf life based on their master level story freshness, plus any ongoing work in an application. For instance, if some implementation was decided on in a release level story and some technology change has made a card obsolete because it is building the wrong thing or makes the wrong assumptions, it’s useless.

Iteration Level Story

An iteration level story only has a shelf life of a few days after it’s been analyzed and not developed. More than a week or so and things can change so drastically in a project that they are not accurate anymore.

Shelf-Life After Development

After development, stories have a much longer shelf life. They can be referenced through various parts in the development lifecycle with the exception of stories that have been overwritten by new ones and those should be tracked as they occur.

Domain documents like systems architecture design, major domain concepts in your app, etc. are useful even longer.


Keep in mind that all of these levels of stories interact. Master > Release > Iteration. They flow in that order and if the master level stories are old and no longer good, they need to be reevaluated. Otherwise, spending time to break them down will be a waste of time and even worse, implementing them can cost real money in the marketplace.

Constant prioritizing and re-evaluation will keep stories fresh for use by the development team. Don’t expect to be able to pull bad apples from storage and make some great apple pie.

Mingle Tip: Make A Better Project List

You don’t have to wait for the Mingle team to make improvements to your project list. It’s been requested in “the forums”:, but I got tired of waiting for a simple CSS change, so I did it myself with “Stylish”: Just copy the code below (or better yet, find the base.css file that you need to edit to make this change).

@namespace url(;
@-moz-document domain("") {

.project {
.action-bar { clear:both; }
.round-corner-wrapper { height:91px; }

Your project list will then look like this:

Mingle Project List

One thing to note is that it doesn’t currently handle long project descriptions too well right now. I’ll try to get that fixed and I welcome any fixes to the above CSS changes to make it better.

Mingle Tip: Change A Password When Mingle Won’t Send Email

This trick probably won’t be used that often, but it might be nice to have if you get stuck. If you have a Mingle installation that isn’t configured to send out emails and you have forgotten your password for some reason, you can change your password if you’ve got access to the database.

mysql> update users set lost_password_key = 123, lost_password_reported_at = CURRENT_TIMESTAMP where login = your_username;

Once you do that, you can go to this URL (substitute values for your installation):

That will let you reset your password.

Mingle Tip: Pipeline Your Team

Working on a larger team can really show off some of the flexibility and power of Mingle. Often, teams use Mingle as a virtual story wall. The grid view is a valuable tool to manage cards this way, but it can become overwhelming when actually working with the cards on a daily basis. Different parts of the team are not always concerned with all of the stages their cards are in. Creating segmented work areas for your team can help them get to exactly what they want with minimal searching. I call this Team Pipelining. Let’s take 3 examples and see how pipelining your team can help.

h3. Analysts

Analysts need a view of their own for upcoming story management. Without all of the distractions of current development, analysts get a focused view of what work they need to complete. Iteration or Project Managers can get a quick view of all of the stories that will be ready for development and can use their area to prioritize it. This view is simply a grid view on 3 card statuses for this project which is a card property.

Mingle Analyst Pipeline

h3. Developers

Developers want to find stories that need to be picked up or are being worked on quickly, so this view is more for them as well as anyone that’s interested in the development progress of the iteration at a low level.

Mingle Dev Pipeline

h3. Testers

Testers want to see when cards get past development and how they are being tested. Sorting their cards by another property called “Test Status” and applying some filters to only show cards that have been finished by the development team, testers can get a work area all their own that only shows that they need to immediately work on.

Mingle Testing Pipeline

h3. Coming Up

Sharp readers will notice that I didn’t use Iteration Planning as an example here. That’s coming in another Mingle Tip because it deserves it’s own special treatment.

Mingle 2.0 will make Pipelining even more powerful by adding story trees and all sorts of cool filtering abilities that will allow Mingle to fade into the background, so to speak, and let your teams focus on what they need to get done.

Mingle Tip: Make Your Own Full Screen View

I stumbled upon a question in the “ThoughtWorks Studios forums”: that never really got answered about having a full screen mode in Mingle. Using the steps I showed you from my last article, I’ll show you how to get rid of some interface elements that you may not need once you’ve got Mingle set the way you like using “Stylish”: again.

The code below will give you what dpattins wanted with comments explaining what each of those CSS selectors do. Note that you could further scope your stylish script to the card list in case you want the navigation back on other parts of Mingle.

@namespace url(;
@-moz-document domain("") {
/* #hd = header navigation
   #sidebar = filtering sidebar
   .basic-panel-one = card adding section
   #lanes-header = group/color selection  */

#hd, #sidebar, .basic-panel-one, #lanes-header {display:none !important}