Comments (0)

By Rich, August 13, 2010 11:43 am

was not choosing Menlo Innovations to do our software design and development.”

- a former prospect having coffee with me the other day.

Arrrggghh.

This is a common theme and there is no joy, no schadenfreude when I hear this.  My frustration does not stem from the lost revenue, losing to the competition or simply a missed opportunity.  The maddening part is that a good idea didn’t make it to market and the product wasn’t widely adopted.  There will be lost investor dollars and another company that one day soon will close it doors, or perhaps  just limp along rather than enjoy enough success to hire more people, expand into other markets, improve the overall state of the economy.

When I hear this lament from former prospects, I ponder why? There are a variety of reasons they chose another path two years ago.  Sometimes they have their own internal resources, sometimes they have an existing relationship, sometimes they just believe they can get things done less expensively.  Somehow, they decide they didn’t need what we had to offer.  We could see at the beginning that they were headed for trouble, but its way too self-serving to harp on that point.

So for those who are contemplating starting a software product effort, I encourage you to think about these things as you launch the effort to build the software product you dream about:

1.  Your budget may be wrong. You likely have a $number in mind for how much it will cost to build the software.  How did you pick that number?  What if you chose the wrong number?  What is the cost of being wrong?  Might you expend your entire budget and only be half done?  If you end up 50% done when the money runs out, the “market” will conclude you are 0% done!

2.  There may actually be strong evidence that suggests your budget is wrong. Have you thought about how much others have spent to build something similar?  Its amazing how much information is available to see how much others have spent on building something close to your imagined system.  Find that information and be mercenary about challenging your own assumptions about “how easy this is going to be?”

3.  Your plan has too many “Miracle Occurs Here” boxes in it. Designing and building solid, competitive software products that thrill end users is plain ol’ everyday hard work.  Miracles never happen when you need them, and each time they do, they are typically offset by “catastrophe occurs here.”

4.  Your plan to build a quality team is flawed. Too often the plan to build a great team starts with an e-mail akin to “Rich … if you know any good programmers who are looking for work, tell them we are building a team that’s going to bring an awesome product to market.”  How will you know they are good programmers?  How long will it take you to figure that out?  How will they organize the work?  How will you know they are doing a good job?  How long will it take to figure out if they are not doing a good job?  Who will do the “non-programming” work of project management, user experience design and quality assurance.  What approach will be used?

5.  Your plan lacks ruthless focus! Who exactly are you building this for?  Trying to be all things to all people means you will not serve anyone well.  Everyone will be frustrated.  Having a specific target end user audience in mind is critical to success.  Bad Example: This patient appointment product will be used by professional services firms such as doctors, lawyers and dentists.  Good example:  Dr. Alicia Zahn, DDS has her own small dental practice that she has run for 17 years.  She is frustrated with her current patient scheduling system because …

There are many other pathologies that lead to failure.  I will touch on those in future posts.

There is hope.  It can work.  Success is possible.  There can and should be joy in software design and development.  The ultimate joy is when a user stops you in a parking lot and thanks you for the wonderful software you built for them.

I wish you joy! in your efforts and results!

Comments (2)

By Rich, March 11, 2010 11:56 am

Not.

We received a comment the other day on the Do Cubicles Kill post where an assertion was made that one of the key challenges with adopting agile is that you can only make it work with experts. The implication of this statement is that you can’t make it work with mere mortals.

Our experience is just the opposite. We have found more challenges in trying to integrate “experts” into our team regardless of their experience with agile. Given we’ve been practicing agile for nearly 9 years, it’s probably worthy of exploring this topic and reflecting on how we make it work without only experts.

What are the ingredients? Here’s what we believe we do that helps make this work.

We invented and practice Extreme Interviewing. During this process we screen first for kindergarten talents — do they play well with others, know how to put away their toys, do they not swear or bite — then for technical talents. This allows us to be very intentional about our culture.

We practice pairing, all day, every day and we’ve expanded pairing beyond programming. It’s the most powerful managerial tool I’ve ever discovered.

We choose who you are going to work with for each iteration. This was a tool we used when we were first teaching the team the value of pairing. They later came to us and asked us to continue the practice. They valued avoiding the social awkwardness that might happen if they were the last kid on the playground and no one wanted them on their team.

We maintain experts within earshot. We love having experts in various technologies and techniques. We also love having experience on the team. We expect our experts and experienced team members to be good mentors. Our goal is to not have our experts work in their area of expertise, but be available when needed (i.e. they’re working in other domains with their pair partner). This means our experts also get to learn new things, which keeps them growing and learning.

Our weekly kickoffs, estimation, and show & tells ensure that the entire project team has a common understanding of the work being done across the entire project.

The most thoughtful process we go through every week is resource planning. This is where we decide who is going to be on which projects, and who is going to pair with whom. This is an opportunity for us to ensure we’re getting cross pollination across projects, across pairs, and throughout the organization. Essentially this means we get cross-training and mentoring for free, every moment of every day. Most teams dream about “continuous improvement.” We get to experience it.

We practice on-boarding new talent every year through our internship program. We bring in 6-8 interns each year from around the world. This gives us an opportunity to check how we’re doing in terms of teaching our culture and practices to new people.

Finally, this is made a lot easier by co-locating and working in an open space. As we’ve joked before, it is true that we do not use e-mail to communicate with each other, we use High-Speed Voice Technology™. This creates an energy and enthusiasm that keeps all the other pieces working well together.

We understand the concern that many have that agile can only be done with experts. We would never consider building such a process ourselves because of the peril of dependency on individual heroes. For those who wish to see a working alternative, stop by for a tour. Many people do.

Comments (0)

By Rich, February 1, 2010 11:24 am

Estimation is always a hot topic in software development. An even more important topic, and usually ignored, is not how to estimate but rather how to size a project. So what’s the difference?

By now you can probably imagine our world here at Menlo. When people walk in our front doors or send us an e-mail about their project, their first question is usually “How big is this?” It’s at this point that we know the least about the project and yet we know it’s important to be able to give someone an idea of the size of the project before we ever engage them in actual work.

People often ask us, “How can you do that?” The answer is actually quite straight forward, and it’s amazing to us how few people can actually do this.

We start by getting a basic description of what they’re trying to accomplish. We then seek to find other comparable projects we’ve done in the past. Now comes our favorite “parlor trick” — once we’ve found comparable projects, we look at the actuals. We’re able to do this because we collect “actual actuals” for all the projects we work on so we know — down to the quarter hour — how much time we’ve spent on previous projects. This becomes an amazingly powerful tool when doing these early project sizings.

While this process is straight forward, the ensuing discussions with our potential clients are anything but. When presented with such real data they almost always respond by saying, “There’s no way our project’s that big!’ We then ask them how big they think it is. They respond, “We’re not sure, but we know it’s not that big.” Perhaps what’s frustrating about this stage of the discussion is that many of the projects we are asked to size are to rebuild an existing system with new designs, new technologies, and extra features. When we ask them how much effort it took to build their existing system, they have no crisp answer because they’ve never tracked actuals.

As an organization, Menlo is still learning how to best convey these early sizings because we know that our reality-based sizings conflict with the fantasy-based sizings our industry frequently produces.

Many times we lose these projects because our potential client finds another resource who agrees with their perceived project size. Our experience, however, also tells us that we were better off for the loss. I’ll explain this with two examples.

The first was a project that someone was convinced was only a third of the size we predicted. We didn’t get the deal. Years later I ran into the new CEO of the company that did get the deal. He shared with me the experience of inheriting a painful project where his company’s commitment meant that they had to fund 2/3 of the total cost of the project on their own dime to complete the work. It was the same project Menlo had “lost.”

The second was a project we referred to in an earlier post when we talked about “Fixed price is a lie.” Our sizing for the project indicated it was somewhere between 8,000 and 20,000 hours. Our prospect said they had another firm that could do it in 4,000 hours. We declined to bid. The project was supposed to complete in 6 months. It is now over 4 years later and it is still not complete. I’ve had many discussions with them and it turns out that they have invested thousands of hours of their own time just doing QA on the resulting software.

The question we’re left with revolves around human nature and it is simply this: why is it that when people are presented with two competing sizes, they will always chose the smaller of the two, disregarding all other factors?

Menlo’s answer has been the same throughout our history: the only way to make this work is to educate our prospects about the process we use. We find that our best clients are those that have frequently chosen the smaller size estimate in their past, suffered the consequences, and have committed to never suffering that pain again.

Comments (0)

By Rich, December 3, 2009 8:00 am

In a previous post I talked about how empowerment is one of the most overworked words in management today. Right near the top of that same list is “accountability.” I shudder every time I hear someone in management say “We need greater accountability in our team!” The reason I shudder is because it implies that accountability is a one way street, when in fact for accountability to work it must be a circle.

What do I mean by that?

I want to discuss with you accountability at Menlo around estimating. When people first learn about our weekly estimating practice, the question invariably arises, “What do you do when people don’t hit their estimates?” The answer I give is not what they expect.

I first talk about how we teach accountability around estimating to our team members, and it always occurs in the setting of a public class where Menlonians and clients are both present.

I start with my accountability as a CEO to my team. I do this by declaring to my developers that we will never punish anyone for missing an estimate.

Ever.

I then turn to our project managers and tell them they are never to punish, cajole, or intimidate any of our developers about missed estimates.

I then turn to our clients and say, “By the way, if we go over our estimates, you will pay for the additional hours logged against that story card.” You can imagine the burning question on the client’s mind is either “Why am I here?” or “What’s in it for me?”

This is where the circle must be completed to make accountability work.

I then turn back to my developers and say to them, “There’s one thing I need from you, and only one thing. As soon as you think you’re going to exceed your estimate, raise your hand and declare it to your project manager.” We have actually taught our project managers to say, “Thank you.” (No, really. They say it!) I tell them that it’s okay to ask about their revised estimate, and discuss its implications, but at no point in this conversation is anyone allowed to say, “No. You just need to meet your estimates.”

Armed with the understanding of why the new estimate is now more accurate, the project manager is then taught they must call the client and deliver the news. We don’t assume that the client wants the story card completed at any cost, so we ask them, “What would you like to do?” There are many choices here, including: 1) just keep going and we’ll pull something off the end of the iteration, 2) stop working on the card because the new cost for that story card is not in line with the value it would produce, 3) we review alternative approaches (i.e. new story cards) that may reduce the effort while producing a similar amount of value in a different way than originally planned, or 4) something else. This approach affirms one of our most common statements about agile: Agile doesn’t solve problems, it exposes them sooner so that we can deal with them while there is still time and budget to do so.

So what does the customer get out of this?

In a trusted system of estimating our developers will estimate more aggressively with no padding, and human nature says that our developers will strive to meet or beat an estimate they had a hand in creating. People do miss estimates, and when they do we deal with it in a healthy, professional way. Ultimately the client will get more work done in the same amount of time, which is what every client wants.

I teach this system wherever I go. I can recall a rather tense moment in a class I was teaching in Atlanta, where a VP of Marketing silenced a room by declaring, “This is bullsh*t. Here our people are expected to meet or beat their estimates every time.” I asked him, “And if they don’t, what happens?” He said, “Then they stay late. They come in on the weekend. They forgo holidays. They are responsible for making it work.”

I then asked him the magical question, “What do you think the effect of your system is?” I literally watched his face change from anger to understanding. He said, “Quality will suffer. Morale will drop. People will quit. Those that don’t quit have quit in their minds, but are still on the payroll.”

I caught up with members of his team years later and they said to me, he literally changed that day. He was a different manager from that day forward. I believe estimating, and how it is handled, is one of the most vexing problems of our industry. At the heart of this problem is how we as managers view accountability.

We seldom consider that accountability must begin with us for it to work.

Comments (0)

By Tracy, November 25, 2009 8:00 am

In my first post talking about the 18 steps of quality, I talked about the first 7 steps we use to ensure quality. Today I’m going to talk about the final eleven items.

8.  Iteration Kickoff
9.  Estimation

At Menlo both of these exercises happen during each weeklong iteration.  Every week the team has two opportunities to come together and discuss the big picture.  Unless everyone on the team is focused on a common goal it will be impossible to build a quality product.  Spending the time to communicate up front to make sure the team is on the same path, prevents many defects from ever making their way into the system.

10. Continuous Code Review
11. Test First/Unit Testing
12. Continuous Integration
13. Refactoring

We have a tremendously rigorous set of development practices.  These are not practices we use sometimes or when we feel like it or remember to.  These are part of the code of ethics we live by.  An application written without unit tests, continuous code review, continuous integration, and fearless refactoring is an application written to be thrown away.  Where there is rigor there is quality.

14. Green Dotting

At Menlo no one is allowed to declare themselves done with a story card.  Instead they have to ask their teammates to verify if they are done with the work.  We call this green dotting.  A simple way to increase the quality of your work is to have someone else check it before you move on to something new.

15. Show & Tell

Every week our client comes in for show and tell. This is a chance for the client to see the working product to make sure it is everything they imagined it to be.  If something isn’t quite right, it is only a week spent off course rather than months or even years.  Quality is so much more than answering the question of whether or not the application meets the specifications.  The earlier you can get someone actually using the software being built, the better.

16. Build Testing

Every iteration we make a build.  Every iteration we run a build test.  For this we use exploratory testing.  The objective is for the build testing team to put their end user hats on and use the application as a user would.  There is no list of instructions for them to follow.  On the contrary we want them to explore.  We want them to be creative and most importantly we want them to run the test differently from the week before.

17. Client Testing
18. Beta Testing

We encourage our clients to also test the application.  Since we do not typically have a domain expert on staff, we encourage our clients to designate one to testing the application whenever possible.  We also encourage them to find a small group of beta testers within their clients.  The earlier you can acquire feedback from real users, the more time you have to make the appropriate changes to the product.

Now you know our 18 steps to quality and why our phones don’t ring with support calls and why we don’t have a bug database full of thousands of bugs.  Now you know why the end users of the products we build find them to be easy to use and why so many of our clients find their products quickly gain widespread adoption.  Use our 18 steps.  Make them your own and believe me when I say, it is fun to build something packed full of quality.

Comments (1)

By Rich, October 22, 2009 8:00 am

I’m going to recount a meeting I had with a CIO in Atlanta. He was intrigued with the planning system that we employ at Menlo, but wondered how we use that same system to handle the inevitable emergencies that come up.

I like to talk about emergencies by first doing a role-play that goes something like this. The boss, Bill, stops in to talk with the programmer Aparna:

“Hey Aparna, how’s it going? Whatcha workin’ on?”

Aparna, sensing that a new priority is about to be set for her, answers, “I’m working on that really important task we talked about in Monday’s status meeting.”

“Oh, great, great. Yeah, we really need that. However, I just got off the phone with our top sales guy and he says that if we can get this one new feature quickly, he can close a really big deal. So do you think you can squeeze this in around other things you’re doing?”

Aparna’s been down this road before and has learned that the only right answer is, “You bet.”

Bill walks away satisfied that he’s being responsive to customer requests and properly motivating his team.

The next day Bill comes in and asks Aparna how this new, high-priority sales request is coming along. Aparna answers that she’s not quite ready yet. Bill also asks about the other task and again Aparna answers that that one has been impacted by this new request.

This pattern continues for the next couple of days until Bill finally walks in one day, with the sales person, agitated and upset that Aparna hasn’t gotten things done and now the sale is threatened.

Bill instructs Aparna that she needs to set everything aside, including any personal commitments she’s made, to get this thing DONE. Bill has used the appropriate tone of voice to indicate to Aparna, “This thing is on fire now.”

Aparna stays late that night, past midnight, and gets this high-priority task done. Everyone in the organization has just learned an important lesson: to get things done around here, you light them on fire. Now, everything gets lit on fire and people are coming into work wearing yellow rubber jackets, helmets, oxygen tanks, and carrying fire extinguishers.

I explained to my CIO friend that there’s a certain thrill to this level of adrenalin inside any team, but eventually this kind of fire drill becomes a standard part of the culture and thus real emergencies require a whole new level of histrionics to gain attention.

It was at this point in the conversation that his phone rang. He answered it while I was sitting there. As the phone conversation went on, he looked right at me with wide eyes and made it clear with hand gestures that the exact scenario that I had just described was playing out in this phone call.

After the call, I described for him an alternative scenario. I know many of you live this life and can’t imagine a positive alternative that can work within your organization, but I assure you I used to live this life and now I don’t.

I know it sounds too simple, but writing storycards for every task, including those that seem like emergencies, is the first step. Getting those storycards estimated by the team that does the work, and then evaluating the relative priority of each task in predictable (in our case, weekly) planning game, provides a framework for rationality. You see, most emergencies aren’t really emergencies. What the business needs is predictability. If, through process, we can begin delivering predictability, we ultimately build trust with our business sponsors and our team.  Everyone comes to realize that there is a better, more sustainable alternative to project management pyromania.

I’d love to hear from you to see if you’ve had similar success in avoiding this type of pyromania within your organization.