Archive for March, 2013

The Entrepreneurial Developer

Friday, March 29th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

The Entrepreneurial Developer

 

When I first started programming, more than 20 years ago, I was hired by a guy to teach him how to program. After 2 weeks he looked at me and said, “You know, I see what you do, and I know I could do what you do. I just don’t want to, how about I hire you to do the programming that I want done?”

 

Over the course of the next two years I became the effective CIO for Athena Software. Athena Software was an award winning shrink wrap company that produced handicapping software for American football and basketball. It’s ironic that I’ve never been a big sports fan.

 

During that time, I was the business analyst, the architect, the database administrator, the programmer, the tester, the release manager and the support team.

 

It was obvious that programming was just one piece of the puzzle. An important piece, but not the be all end all of making a profitable company.

 

Later, when I got out into “the real world” I was surprised to find out that my skill set was not “normal.” Normal turned out to be testers who could’t code, developers who couldn’t test, and database schemas that were … lets call it, sub-optimal.

 

Since that time, I’ve come to describe myself as an entrepreneurial developer and I’ve found many others who share that mindset.

 

Entrepreneurial team members are an asset to your company because they focus on the entire value stream and have a primary interest in making the company more money. Entrepreneurial team members can be difficult. They’re opinionated, they tend not to tow the party line, and tend to ask uncomfortable questions. Worse, not only can they be a pain in the neck, if you’re not careful, they will be the first ones hired away if you don’t pay them enough, or if the work environment becomes unfriendly.

 

For all that, you want to have them on your team because they are self driven, they get stuff done and they have ideas for bringing more money into your company.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

“On Time and On Budget” Doesn’t Matter

Thursday, March 28th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

“On Time and On Budget” Doesn’t Matter

 

In most cases, a software project’s success is based on how well that project meets it schedule and it’s budget.

 

All that does is tell you how good your guessing engine is at prediction.

 

It’s also easy to measure, and I’m guessing this is the reason it’s used.

 

 

So what is a better measure?

 

 

How about looking at your business case?

 

Let’s pretend you have a project that has a schedule of 12 months and a budget of 1.2 million dollars.

 

Now lets say that you get 2 months into this project and your team tells you that it’s going to be closer to 18 months and closer to 3 million dollars to accomplish.

 

 

 

What do you do? Is the project a failure?

 

Who cares?

 

Check your business case.

 

If the business case says the project is worth 2 million dollars, then cancel it. You just saved your company a million dollars.

 

If, on the other hand, the business case says that the project is going to bring in 5 million dollars a year for the next 10 years, keep spending.

 

Was the project on time and on budget?

 

Who cares.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Are you Being agile, or Doing agile?

Wednesday, March 27th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Are you Being agile, or Doing agile?

 

Agility is being able to cross a stream by jumping from rock to rock.

 

If I teach you the steps to cross a particular stream, it doesn’t make you agile. The steps probably won’t transfer to the next stream.

 

Agile coaches often have the following “Who’s on first” conversation.

 

 

Agile Coach: “I’m here to help you be more agile.”

Customer: “We’re glad to have you, we’re having difficulties doing this agile thing.”

Agile Coach: “That’s great, but I need to stress that I’m here to help you ‘be’ more agile.”

Customer: “Exactly, so tell us how to do it.”

 

 

There seems to be a belief that a methodology is a set of practices. This belief is so ingrained that the Scrum folks bristle when you call it the “Scrum Methodology.” They stamp their feet and saying, “It’s a framework, not a methodology.”

 

It makes sense, the Wikipedia entry on methodology has this charming nugget.

In recent years, some have argued the word methodology has become a “pretentious substitute for the word method”.

 

In agile coaching, we are often told, “Just tell us which steps to take to cross this stream, and then we’ll cross all streams with the same steps.”

 

Agility is a capability, not a method.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Without this one thing, plans are worthless

Tuesday, March 26th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Without this one thing, plans are worthless

 

Fanaticism is defined as redoubling your efforts after your aim has been lost.

 

You can see this in companies that worship their plans.  Plans that are worthless because of one missing element.

Their project’s mission.

The mission (usually called business case) is the why behind the what.

 

Too many times I’ve seen plans hand down from on high with no indication of the why behind the plans.

A few years ago, I asked a senior manager at a large company if I could see the business case for the project team I was working with. His response was telling. “Why would we let our developers see the business case?”

 

Sometimes this makes sense, like when Company A is trying to fake out Company B by announcing that they are starting work on a product or a service that Company A has no intention of taking to market.

If Company A can get Company B to waste resources by building a product or service that no one wants, Company B won’t be in position to respond to company A’s real product.

 

But lets say a company is not bluffing and are really planning to use the software or service they are having built.

The team implementing the product or service may know of a better way of of accomplishing the mission than the industry “experts” who made the plans.

Ask yourself, “What is the mission behind our current work?”

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Are your requirements are too expensive?

Monday, March 25th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Are your requirements are too expensive?

 

If you are working in a software shop, or if your company is producing software, the odds are high that your company is spending too much money on requirements.

This is natural because we live in a plan driven culture. The expectation is that we figure out everything that needs to go into the product before we start. This will allow us to take our completed documentation and hand it over the wall to a development group that will produce what we requested.

Chances are, your company is wasting money, because when writing requirements, we are at the lowest point in our knowledge of our customer real needs.

Remember:

Our customers will not know what they want, until we show them what they asked for.

 

This is why reducing cycle time is so important.

The shorter the cycle time, the sooner you can build what your customers wants to pay for, as opposed to what they asked for.

This is not to say that planning isn’t important, it is, but it’s important to only do the right amount of planning.

 

Ask your developers (in private) these questions.

Have you ever gotten requirements that were too detailed in certain places, but not detailed enough in others?

Have you ever gotten requirements that you didn’t have any questions about?

Have you ever gotten requirements that you didn’t have a hand in making?

Have you ever been told what to do, without being given an explanation as to why you were doing it?

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Is your Continuous Integration tool doing to much?

Friday, March 22nd, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Is your Continuous Integration tool doing to much?

 

Yesterday I said that a CI tool should only do 3 things, Poll, Initiate and Update.

 

Period. No more, no less.

 

I can hear you saying, “But my CI tool will do my checkouts, my compiles, run my tests and a bunch of other stuff too.”

 

You’re right, it can, and you don’t want it doing that for one big reason. You only want your build done one way.

 

Your build server, your developers, and your testers should all use the same build process. Unless you want your team to have your CI server installed on all their machines (and there are some decent reasons for doing just that) then they all need to be able to run the same single one line of code to do their local build, and run their unit tests.

 

When the build machine does the build and runs the unit tests, you want it to use the very same single line of code.

 

If the build is being created in different ways by different people or processes, sooner or later you are going to get bit by the differences.

 

Ask yourself, are all my developers, and my automated build process using the exact same steps to create the build?

Or conversely, have you ever had to figure out why the build on the build box was different that the developer build?

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Continuous Integration for Managers – Poll, Initiate, Update

Thursday, March 21st, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Continuous Integration for Managers – Poll, Initiate, Update

 

I’m not going to get into how important Continuous Integration is to your Agile Development process. We’re going to take that as a given.

 

The point of this slice is to give you a 30,000 foot view of CI so that you have a better idea of what is actually going on.

 

Your overall CI system is composed of 4 basic parts.

 

1) The CI Server

2) The Version Control System

3) The Build System

4) The CI Dashboard

 

The CI server sits in the middle of the other 3 parts and acts like an orchestra conductor.

 

The CI server does 3 and only 3 things.

 

1) Poll the version control system for changes

2) If a change exists, initiate the build

3) On completion of the build, update the CI dashboard with a simple Pass or Fail.

 

There, you’re done.

 

Don’t get me wrong, that second step can get amazingly sophisticated and there is a temptation to let the CI system get it’s hands dirty in doing the build. This is because CI systems compete on how well their product can handle the creation of the build.

 

Tomorrow I’ll get into why you want to avoid letting your CI server do more than poll, initiate, and update.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

Wouldn’t it be cool if your compiler caught that?

Wednesday, March 20th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

Wouldn’t it be cool if your compiler caught that?

 

Twenty years ago Microsoft published Steve Maguire’s first book, “Writing Solid Code.”

Some of the examples are dated, but the philosophy behind the book is still rock solid.

Today we’re only going to touch on the first chapter, called “The Hypothetical Compiler” in which Maguire talks about what a huge time and mental savings the compiler provides over the way code was built prior to the existence of the compiler.

He then went on to say how great it would be to have a “compiler” that would find your logic and integration bugs.

I didn’t know it then, but what he was talking about was the combination of what would become Test Driven Design (TDD), and Continuous Integration (CI).

Think about it. If you drop a semicolon in your code, you expect your compiler to catch it. You don’t fret about it, the compiler pops up the errors and the warnings, you fix them and move on. It takes all of about 20 seconds.

This is the power of TDD and CI. You are effectively writing compiler extensions. Any time you run into a bug, your write a test for it and you can never accidentally insert that bug back into your code.

Of course this requires some discipline (keep build times under 5 minutes, keep the code decoupled, etc. etc), but the power and freedom that comes from that discipline is hard to describe if you haven’t experienced it first hand.

 

What difference would it make if your custom compiler could find your bugs for you?
Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation. If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community. If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

How to reduce your cycle time to zero.

Tuesday, March 19th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

How to reduce your cycle time to zero.

 

Yesterday I promised to talk about how companies can have a cycle time of zero … or less.

As a quick reminder, cycle time is the number of days between product approval, and first revenues from said product.

The deceptively simple to a cycle time of zero is “sell it before you build it.”

Companies have been doing this successfully for over 100 years, in a field called direct response marketing.

I’m going to assume that when you were a kid, you read the advertisements in the back of comic books or magazines.  How many times did you see the phrase, “Please allow 6 – 8 weeks for delivery” ?

You may not have known this, but it’s code for, “If enough people order this product, we will build it.”

So how does that apply to you?

Before you get too far, understand that there is an implied commitment here. “We have the ability of creating this product in 4 – 5 weeks, provided enough people want it.”

The whole key here is to use revenues to prove the validity of your concept. Then use on-going revenues to fund the exploratory process of building the product your customers want.

Your mission is to always be working on products that are in demand and the black. Remember, teams working on profitable products don’t get downsized.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation.  If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community.  If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.

How fast is your business’s cycle time?

Monday, March 18th, 2013

Welcome to Agile Slices; a series of quick pragmatic articles of about 200 words, intended to help you, your team and your business, harness the power of agility.

 

How fast is your business’s cycle time?

 

Here’s a quick diagnostic tool for your company:

From the time funding is authorized on a new product, how many days does it take to get your first dollar of revenue?

This number is your cycle time. It’s similar to how fast a car can get from zero to sixty.

 

Before starting, there are going to be people reading this slice thinking, “Cycle time doesn’t apply to me because [really good reason here]”

Please, if this is you, before you leave this page, ask yourself, “How could this apply to me and my team?  What value could we get from this concept?”

 

 

[Those of you who are still with us, thanks for staying.]

 

If you don’t know your cycle time, you’re not alone.

If you do know your cycle time, you are far in front of your competition.

In most companies cycle time is in the hundreds of days. In a sad number, it’s over a thousand days. In a tragic number of cases, cycle time is infinite.

 

An infinite cycle time translates to: “The project was funded, staffed, started, and then canceled before ever making a dollar.”

 

What if I told you that there are companies that have a cycle time of zero?

What does that mean?

Tomorrow we’ll talk about how companies can have a cycle time of zero … or less.

 

 

In the mean time, start asking yourself:

What is my company’s current cycle time?

What is my department’s current cycle time?

What is my team’s current cycle time?

 

If you don’t know, guess, if you do know, ask yourself if there is any way to shorten your cycle time.

 

Stay On Mission.

 

If you have already used this slice, please add your voice to the conversation.  If it sounds silly, please take some actions to test a particular idea’s validity, and then share your results, good or bad, with the community.  If something strikes you as golden, then I’m glad I was able to provide value to your life, please let us know what difference it has made for you or your company.