I’m on a new account this week and my colleague Julias Shaw coined the phrase in the title.
We have been trying to get our client to realize that the solution to people not reading huge requirements documents all the way from development to QA to support is not more documentation, but more communication.
We are all for documentation, but only the kind that people will actually read.
Joey at 7 Years By Ruth
Last night, as I sat with my grandsons reviewing their five and seven year old accomplishments, I was drawn again to memories of my own childhood experiences. Joey, my seven year old, proudly displayed his ability to write in handwriting, which had mostly been learned through self teaching, some of his capital letters. This, despite the fact that his mother was repeatedly requesting that they say goodnight and get ready for bed. “Let me show you a capital T, Gramma”, he said, laboriously outlining his project. “Oops!” I remarked, “You shouldn’t have crossed the T, honey, that makes it an F.” There was a stricken look on his face, and with an “Oh no!” he left the room. He returned shortly with his specially wrapped gift for his parents which had a large beautifully made capital F in “Fo Mom & Pop.” I whispered to get an eraser and we would fix it and he went and desperately began searching the drawer where such things were kept. Mom, by this time, and not knowing what was going in, demanded that bed time was now! And she forcefully directed him toward the stairs. The enormity, to him, of his predicament, started a totally frustrated cry, but he went upstairs. When she returned I briefly told her what was happening and went to call the sobbing child for just one minute. I explained to him that if he added a small “r” to the “Fo” it would change the word. With brimming eyes, and a moment’s thought, he realized it would say “For” which was perfectly acceptable. Tears stopped, the correction was made, and a true weight had been lifted in his young mind.
It is the tendency of busy adults to forget the importance of the little tragedies that are as monumental to a small store of experiences in children as larger ones are to adults. Showing them how to deal with and minimize error is one of the best and kindest tools to give them. The humiliation and lack of self esteem that comes from not doing what is acceptably correct can leave a scar no different than the scar an adult gets from the same type of things. The child has within him the adult he will be. Treat him with the respect you would afford, and the kindness you should use, in your dealings with all people.
The enormity of unresolved calamities of my own childhood, though they are small by adult standards, still come back to haunt me. Not that adults were uncaring, but there was an opinion that because children were small, their feelings were relative to their size. Not so! The adult is wrapped in a small confining package, straining to find answers to enormous complexities in the child’s body.
I miss you Grandma.
When you have to evaluate someone, it is easy to err on the side of being nice. When you really like the person outside of work or they are your friend, it becomes doubly hard. It is still important to be honest with feedback for someone so that they can improve and important for future teams so that they can make sure the person is the right fit.
I tend to use a lesson learned long ago to escalate problems I’m having with people.
First, talking to the person is often the earliest and easiest way to give someone feedback. Often people will not know something is wrong and are more than willing to fix it.
Second, if the person doesn’t respond, let them know you will take your feedback to their boss if needed. Give them a timeframe to improve and tell them what you will do if they don’t.
Third, evaluate how the person is doing and possibly even get a second opinion.
Finally, putting honest feedback into a review will help teams evaluate the person’s strengths and weaknesses for the future. Even bad feedback with a good outcome can help someone’s review for the future. Who doesn’t like to see someone improve?
When you sugarcoat a review, you hurt the person by not letting them improve and future teams they will work with by not letting them see where they need to cover or help someone.
I’ve seen many teams using Mingle as a card wall instead of using real index cards. Usually the teams are distributed, so real cards wouldn’t help anyway. They all run into the same problem that Mingle doesn’t have a feature to automatically refresh a page throughout the day as the team updates cards. I’ll show you a few simple solutions you can choose from to refresh Mingle automatically.
A quick and easy solution is to use a Firefox extension that can automatically refresh any page called ReloadEvery. This is probably the least amount of work and works just fine.
I’ve also created a small bit of HTML that uses Javascript to refresh an IFrame that takes up the whole page. Just change the google URL to whatever page you need to point to and the amount of seconds you want it to refresh (set to 5 right now). It works in all of the browsers I could find.
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.
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 Files\Mozilla Firefox\searchplugins
and for Mac is something like
/Applications/Firefox.app/Contents/MacOS/searchplugins/
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.
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.
Bliss.
[via]
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.
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.
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.
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 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.
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.
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.
You don’t have to wait for the Mingle team to make improvements to your project list. It’s been requested in “the forums”:http://studios.thoughtworks.com/discussion/, but I got tired of waiting for a simple CSS change, so I did it myself with “Stylish”:http://userstyles.org/. Just copy the code below (or better yet, find the base.css file that you need to edit to make this change).
1 2 3 4 5 6 7 8 9 10 11 | @namespace url(http://www.w3.org/1999/xhtml); @-moz-document domain("my.mingle.installation.com") { .project { float:left; height:100px; width:300px; } .action-bar { clear:both; } .round-corner-wrapper { height:91px; } } |
Your project list will then look like this:
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.
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):
http://your-mingle-installation.com:8080/profile/change_password?ticket=123
That will let you reset your password.
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.
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.
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.
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.
I stumbled upon a question in the “ThoughtWorks Studios forums”:http://studios.thoughtworks.com/discussion/forums/1/topics/60 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”:http://userscripts.org/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(http://www.w3.org/1999/xhtml);
@-moz-document domain("my.mingle.installation.com") {
/* #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}
}
This will probably only be interesting to a few people, but I’m putting it out there anyway. I’ve gotten tired of the orange header and yellow background in input fields in Mingle and decided to make a quick user stylesheet for use with “Stylish”:http://userstyles.org/stylish/.
Here’s the code you’ll need to make the header look like what you want and get rid of the yellow behind the input boxes when you are working on them. You can either paste this directly into Stylish as a new style or you can use the CSS rules in your own way. Just change the “my.mingle.installation.com” to the URL where you installed Mingle.
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("my.mingle.installation.com") {
/* Header Styles */
#hd, #hd-bottom, #hd-nav li.menu-item, #hd-nav li.menu-item a.first-link {background: #000 !important;}
#hd-nav li.current-menu-item, #hd-nav li.current-menu-item a.first-link {background: #FFF !important;}
/* Input Boxes */
input:focus, textarea:focus {background-color:#FFF !important;}
}
I may create a Firefox extension that will integrate more features like this for people if there is interest.
Have you ever been editing a card in Mingle and you lose your data because the session timed out? Well, if you are comfortable editing a config file in <mingle directory>/config/web.xml you can make the session timeout much longer. Here is what it looks like by default:
60
You can change it to be something like this:
6000
That works out to be around 4 days for the timeout, so all you need to do now is restart Mingle on the server and you shouldn’t be bothered by it any more.
In some projects, there are sometimes people that want to stay informed of what is happening without having to login to Mingle constantly.
One good example is someone that has to verify that work has been completed by the development team.
Our fictional customer, Sandy, is a busy person and would like a way to keep informed of when she needs to look at the work the development team has done so that she doesn’t get behind. She doesn’t have time to check Mingle all day and lives in email and feed readers all day.
Fortunately for Sandy, Mingle has a simple and powerful solution for her. By simply going to the History tab in Mingle, she can see all of what is going on in real time. But wait, there is too much information that Sandy doesn’t need to look at. Sandy needs to take a few steps to give her just what she needs with all of the steps highlighted in the image on the right.
# Sandy only wants to know what she needs to act on. She doesn’t care about updates to pages or code checkins. So clicking on the cards checkbox limits her search just to cards that are changing.
# This is still too much information, so she further narrows her choices down by selecting only to look at stories because she doesn’t need to know about defects.
# Her final choice is to select that the card changed to a story status of “In Customer Review” because that’s where she knows she’ll need to take some action and look at the work her team is doing.
# Sandy can then choose how she wants to stay informed via feed or email.
Mingle now keeps Sandy up to date on what she needs to review. She’s happy because she can keep up to date even while she’s out of the office.
I’ve been using Mingle a lot lately, so I’ll be posting some quick tips that I’ve found useful in my projects.
Did you know that you can add a set of quick links in the header of your project?
Mingle’s help pages show how it’s done, but oddly, the help page seems to be hard to navigate to unless you know what you are looking for. It’s under Content > Customizing Projects > Project Environment and Navigation > Setting Up Quick Header Links.
First, you’ll need to create a wiki page called Special:HeaderActions. That’s where you’ll store all of your links. Once you do that, you can enter in links like this:
<a href=”/projects/{{project}}/wiki/Project_Metrics” accesskey=”m”>Project Metrics</a>|
<a href=”/projects/{{project}}/cards/new?properties[status]=new&properties[type]=defect” accesskey=”b”>+Defect</a>
<a href=”/projects/{{project}}/cards/new?properties[status]=new&properties[type]=story” accesskey=”s”>+Story</a>
Save the wiki page with these new links and you’ll see new navigation links for your project that look something like this.
With the access keys we’ve put on the links, you can even use keyboard shortcuts to these new links.
Finally, I’d like to mention that currently Mingle is free for 5 users or less and that academic, open source, and non-profit projects can get a license to use it for larger teams for free too. Contact me directly or talk to the ThoughtWorks Studios team to get set up. We’ve even got people that will help you configure it to your team’s needs.
Science Daily is reporting today on new research from scientists at the University of Portsmouth says that says smiling affects how we speak, to the point that listeners can identify the type of smile based on sound alone. Here is the abstract for the paper:
The present study investigated the vocal communication of naturally occurring smiles. Verbal variation was controlled in the speech of 8 speakers by asking them to repeat the same sentence in response to a set sequence of 17 questions, intended to provoke reactions such as amusement, mild embarrassment, or just a neutral response. After coding for facial expressions, a sample of 64 utterances was chosen to represent Duchenne smiles, non-Duchenne smiles, suppressed smiles and non-smiles. These audio clips were used to test the discrimination skills of 11 listeners, who had to rely on vocal indicators to identify different types of smiles in speech. The study established that listeners can discriminate different smile types and further indicated that listeners utilize prototypical ideals to discern whether a person is smiling. Some acoustical cues appear to be taken by listeners as strong indicators of a smile, regardless of whether the speaker is actually smiling. Further investigations into listeners’ prototypical ideals of vocal expressivity could prove worthwhile for voice synthesizing technology endeavoring to make computer-simulations more naturalistic.
This is real science folks. Remember all those times you had to cold call and you heard “smile and dial” from your biz dev manager? Well, it turns out she was right. Your customer sub-consciously heard, not only that you weren’t smiling, but that you were gritting your teeth in anger.
Play to People’s Fantasies
The truth is often avoided because it is ugly and unpleasant. Never appeal to truth and reality unless you are prepared for the anger that comes for disenchantment. Life is so harsh and distressing that people who can manufacture romance or conjure up fantasy are like oases in the desert: Everyone flocks to them. There is great power in tapping into the fantasies of the masses.