Joe Homs

One of the main duties I performed as a consultant was kicking off a project for a new client. The process went by many different names. Iteration zero, project kickoff, inception, and QuickStart. Sometimes a combination of them.

The thing I learned right away was that there was always plenty to think about and set up. All projects are different of course, but all projects are also the same in many ways. So, I began to do what I always do in a new situation and make a checklist.

I learned this skill a long time ago and it has served me well in many different ways. To my clients, I seem to have a super memory and intellect. Combining the checklist with GTD helps greatly. To my colleagues, I can share the list and get feedback and improvements for my own projects and help theirs. Now on with how to create your checklist.

First, I almost never start from scratch. I look to those who have done it before and have learned lessons the hard way. Nobody is smart enough to think of everything, and besides, why duplicate work? Look to retrospectives, post mortems, project wrap ups, lessons learned, bug reports, lawsuits (yep…), API versions, forums, email lists, etc. Anything where people are seeing 20/20 after something went well or, more importantly, something went wrong. Put it all on the list without filtering. If you don’t have stuff written down somewhere, try interviewing people and listen to their war stories. You’ll learn some good lessons. Write. Them. Down.

Second, once you have your list, try organizing it by rough topics: architecture, project management, QA, analysis, client relations, contracts, etc. This is a good time to take the list to your coworkers and ask them to fill in areas that you’ve missed. The important thing to remember is to keep things on the list unless they are incorrect. This list is for all projects, not just “your” project.

After you’ve created your checklist, put it somewhere it can be seen and used as well as collaborated on. A wiki is great for this because you can have multiple editors and you’ll get to see all of the versions. Tell people where it is and have them use it. Asking for feedback on how it works is a great way to get them to use it. They’ll improve things and add new items as they come up.

At this point, you’re probably expecting an example or even full version of my checklist. Sorry. That would rob you of the experience of creating it yourself which is well worth your time in just the collaboration alone.

Initially, people will complain that your checklist is too long. Ignore them. Explain that the checklist is there to keep them safe and spending a 30 seconds or a minute on each item on the checklist will save them loads of time and mistakes later.

One last thing. The checklist is a great tool to make sure you haven’t forgotten anything, but it isn’t a substitute for critical thinking. The checklist will help you to not look dumb, but you still have to be smart. Good luck.

Remember learning to ride a bike or drive a car? It was hard at first, with all of those things to remember and do at once. Put your foot here, your hands there, look straight, now look in your mirrors, gas, brake, turn signals, WATCH OUT FOR THAT TREE!

Driving that car or riding that bike seemed like a very complex activity. You didn’t know the simple steps to take and they weren’t natural for you yet.

What we didn’t realize then was that those things were sophisticated, not complex. They only seemed complex because we were trying to learn and remember and do things all at once.

Breaking something down into smaller, easier to understand parts allowed us to master those things. We had training wheels for a bike, someone to hold us and push us when we needed it. Learning how much pressure to put on the brakes of a car while going straight in a parking lot.

We could then put those things together into a sophisticated process that became more than the sum of its parts. It just looks complex to those who don’t know.

The next time you are learning something complex, remember it is probably just sophisticated and you need to break it down into smaller parts and master those things before trying to do the rest. Agile adoption is a good candidate for that breakdown.

So if you are learning something new like Agile, find out where you can break it down and learn small things at first. If you are being taught or coached by someone else, make sure they teach you this way. It is much easier. If they disagree, ask them why.

I’ve spent a good chunk of my life building houses with my family and also Habitat for Humanity.  Most people know the cliche that having a strong foundation is key to building a house.  That doesn’t make it any less important.  Today, Seth talks about the five pillars of success.

The five pillars of success

1. See (really see) what’s possible

2. Know specifically what you want to achieve

3. Make good decisions

4. Understand the tactics to get things done and to change minds

5. Earn the trust and respect of the people around you

It sure seems like we spend all our time on #4.

Seth doesn’t answer the question of why we spend so much time on #4.  The same reason we spend so much time on #4 and so little time on the others is fear.  Fear that we’re not good enough, fear that our dreams are too small, fear that we’ll make the wrong decisions, fear, fear, and more fear.  That fear brings all of the pillars crashing down.

For people who have never felt they could lead, I say take the first step.  Spend your time on something you find worthwhile and just start doing it.  Here’s the secret: you’ll make mistakes.  Probably a lot of them at first, but that’s often the best way to learn.  Learning to be alright with and recover from failure will help you get over your fear.  It will certainly help you with #5.

via Seth’s Blog: The five pillars of success.

I had a conversation with a colleague about doing consulting and that there’s really no such thing as an “organization.”  There really is just a bunch of people who need their minds changed.  The CxO’s I work with usually only need a minimum of technical help, mostly they need an outside change agent to help get their people in the mood to do their best work, so they hire me.

You already know how to deliver excellent service that blows people away. You just don’t feel like it. Your organization has the resources to buy that machine or enter that market or change that policy. They’re just not in the mood.

If I accomplish anything on a good day, it’s helping you change attitudes. I’m working hard at getting you in the mood to do the things you already know how to do. I think that’s what your boss/the market wants you to do as well.

via Seth’s Blog: In the mood.

My friends and fellow ThoughtWorkers Michael Schubert, Jay Fields, and Stephen Chu were just complimented by Martin Fowler.

This isn’t to say that there’s no benefit in a business-writable DSL. Indeed a couple of years ago some colleagues of mine built a system that included just that, and it was much appreciated by the business. It’s just that the effort in creating a decent editing environment, meaningful error messages, debugging and testing tools raises the cost significantly.

What Martin doesn’t go on to explain is that this project vastly improved efficiency for a whole organization.  They went from a situation where it took months with dozens of programmers to change some business rules in their software to minutes with all sorts of extras they couldn’t get before like “what-if” simulations.

Jay wrote about some of the things they learned in this presentation on InfoQ and much more on his blog about DSLs.

via MF Bliki: BusinessReadableDSL.

An occupational hazard of being a consultant is that you get to see lots of the same problems in many different organizations.

It seems that sometimes little thought is given to how an organization can move from one technology to another or to move from legacy systems (where legacy means it doesn’t fit the organization anymore) to better solutions.

Today’s decisions can be tomorrow’s botleneck or bad design. It’s just a matter of time.

What can you do to help your future organization? Things like SOA can help. Great tests around your application are essential if you ever make the choice to change.

I’m looking for something better. I don’t know if you can ever get to a system that is that responsive to change. I’d like to see one that is.

Agile is about a shift in attitude more than process. It requires a shift in focus that is easy to explain, but hard to put in practice.

A useful way to view making the change is as an investment. There are many advantages to thinking this way about how you change an organization.

Being disciplined about investing in people, testing out theory, evaluation and constant improvement go a long way.

When you look to implement this kind of change, process only takes you part of the way. The mechanics of analysis, for instance, can be taught in a few weeks, but it takes a deliberate shift in thinking as well as practice to get good.

Shifting language is a good first step to shifting attitudes. Language around collaboration rather than commitees and processes. Shifting from requirements to goals and priorities.

When you change language, you can start to change minds. It’s a long road and it helps to have experts to guide you along the way. Don’t expect a magic process and if you work with me, expect a conversation.

I’ve started a project to create some useful Ubiquity commands for Mingle.

Here is a video of it in action.

Ubiquity for Mingle – First Cut from Joe Homs on Vimeo.

You can view the project at github.

As we begin our latest downward slide in the economy, people are starting to lose their jobs at an alarming rate.

Instead of looking for some other job, why not create one for yourself? It is easier than most people think if they simply choose what’s right for them.

“What is the right company to start?” I can hear you asking. Something you know and that can be tested easily with minimal costs. I don’t know what that is for you, but you do.

It’s old advice, but worth repeating. Look for something that comes easily or happily to you. Something you are an expert in that you can turn into something to sell to others. If it is hard to replicate, even better.

Once you know what it is, start small and test out the results, but start today. That is the key. Your business model is only going to be perfect by accident. Be willing and able to change.

How does this help the economy? By creating jobs, tax revenue, etc.

If you’ve gotten this far, let me know. There are so many people out there that are willing and able to get you even further.

OK folks, I’m now on my 3rd client having problems with certain four letter words coming up in their automatically generated promo codes. It’s easy to get around this problem in a very simple way: Don’t use vowels in your promo codes if you’re using letters. No need for special filtering software or huge lists of banned words. You can always add complexity later, but that simple rule will help you more than the rest.

If you want to get more careful, you could alternate letters and numbers, or use some other strategy. To be kind to your users, be aware that some numbers and letters look the same to people and they will enter your codes wrong (or worse, enter in someone else’s code by mistake).

To help you, here’s a list of the numbers and letters I suggest people use because they won’t get them confused with each other and hopefully your system won’t create any bad words (if they do, let me know). If you’re worried about the number of combinations you can make, just add more characters to the length of your code or allow yourself the option to generate your own special codes.

letters = ['B', 'C', 'D', 'F', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'V', 'W', 'X', 'Y', 'Z']
numbers = [2, 3, 4, 7, 9]

You could then take this and make a simple ruby method that does something like this:

1
2
3
4
5

letters = ['B', 'C', 'D', 'F', 'H', 'J', 'K', 'L', 'M', 'N', 'P', 'Q', 'R', 'S', 'T', 'V', 'W', 'X', 'Y', 'Z']
numbers = [2, 3, 4, 7, 9]
promo_set = letters | numbers # combine arrays
promo_code = promo_set.sort_by{rand}[0..14].to_s # randomize array and take the first 15 elements and make them a string
=> "CS4FZLHVMPK3QJN"

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.

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 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.

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.

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.

Considerations

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.

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.