A Tree Named Performance

What does reactive mean to you? And by reactive I mean in the situation or person sense and not in the chemical sense :)

I found this great definition for reactive over at the Business Dictionary. Being reactive means:

"Behavior that is not internally motivated but manifests in response to a situation or the actions of others."

So is being reactive a good thing, a bad thing, or something in the middle?

In some cases it is indeed a good thing. Reacting to changing and fluid situations to put the right people and processes in place to solve a problem is a good thing.

Unfortunately being reactive tends to create a feedback cycle if you are not really careful. You get so wrapped up in being reactive, and responding to the needs, wants, and desires of those around you that you stop being proactive because you run out of time in the day.

You start losing sight of the forest as all you see are these trees blocking your way, and sooner or later you hit one of those trees. You hit it hard, and it really hurts, your head starts to swell and you see a bunch of stars, birds, and moons rotating around your head. A perfect storm that rips up all the trees and spins them faster and faster around, creating a massive feedback cycle that becomes harder and harder to break. You are spending all your time dodging trees.

You see, when a team is in reactive mode, and they are juggling requests as they come in from multiple sources, things get missed. Priorities get messed up, you lose sight of the big picture, and worse, your definition of done changes.

You no longer put the fire out, wait for any flare-ups from fires still burning in the root system, and then finishing off with some nice landscaping to restore the beauty of the forest. No no no, when in reactive mode you just stamp out the fire with your feet and move onto the next one as the hair is singeing on your arm.

So how do you break this cycle?

By making behavior internally motivated, not externally.

They are lots of ways to make behavior become internally motivated:

• Make sure you create an atmosphere where your team will take a high degree of pride in the work they do (I don't want my teammate to find a bug in my code)
• Enable your team to take ownership in your product (I have a vested interest in the success, I suggest features and improvements)
• Identify and immediately correct issues before they become a problem (bad behaviors, bad processes)
• Invest in paying down the technical debt (No more, hey this piece of code already does it that way so what's the big deal)
• Make sure "done" is actually done
• etc

Most of the above is related to strong leadership and management and deserve posts all on their own. One quick and relatively "pain free way" is can be taken straight from the Agile cookbooks, change the definition of done. For example, make sure done means that:

• All features have been tested by the developer
• The acceptance tests have been successfully executed
• No regressions in the automated builds
• You have checked for memory leaks
• You have done some performance testing to make sure you understand the characteristics, and are getting the most bang for your buck
• etc

A proper definition of done is crucial to being proactive and not reactive. Sure you still might hit performance issues, bugs, or missing features, but you are now forewarned and forearmed with the information to narrow down any issues, and you can answer something other then “I will have to look into it”, or worse, "I am not surprised".

When working with your teams, make sure that everyone agrees to a complete definition of done, and that everyone buys into the definition.

The future of Car Infotainment

QNX is up for an award at the Adobe Max conference under the "Mobile" category. You don't get much more mobile then a car. Unless your battery is dead that is, then it is not so mobile until you get a boost.

The QNX CAR application platform in an all encompassing reference platform for building next generation infotainment systems and digital instrument clusters.

Vote for QNX Car at Adobe Max's site today! You can also see other cool applications of Flash technology from the other finalists too.

Kudos to me!

Yay me! My blog was added as a top project management blog to The Daily Reviewer.


"Congratulations! Your readers have submitted and voted for your blog at The Daily Reviewer. We compiled an exclusive list of the Top 100 project-management Blogs, and we are glad to let you know that your blog was included! You can see it at http://thedailyreviewer.com/top/project-management"

The Daily Reviewer is an an online aggregator of content similar to Alltop, which, incidental I am also on. The Daily Reviewer seems smaller, much newer, and more advertising driven then Alltop.

Looking at their terms, it seems I will have to be more active blogging as they are looking for bloggers to post at least once a week. This is a little more frequent then my blogging patterns have been over the past few months.

Should be a good motivation to get started again :)

Rotating Scrummasters - A good practice?

In many Scrum teams a practice has emerged to have the Scrummaster role played by a different team member each sprint. The ideas behind this are many and varied:

1. Rotating the Scrummaster allows more people to learn Scrum in-depth
2. Each team member adds new ideas to how to run the Scrum project
3. Builds skill redundancy for the team. If the Scrummaster gets sick, or quits someone can take over without too much lost velocity
4. Helps empower the team, everyone gets to participate at all levels
   
5. Helps prevent people just reporting status to the Scrummaster
6. etc

But is this really a good idea?

Most of these benefits can be achieved with other means, and some are caused by the Scrummaster doing a poor job at leading the team. For example with number two, that can be accomplished by having a really great and open team atmosphere, or even good, dynamic introspections. You don't need to be "in charge" to bring forward ideas.

Depending on the context I think it could beneficial to rotate the Scrummaster role around. However, not every single Sprint. It makes more sense to allow at least three Sprints to elapse prior to rotating out the Scrummaster. It will take at least three Sprints for that person to get comfortable in their role and get their mind into the Scrummaster space.

Don't force every single person on the team to take on the Scrummaster role! Not every single person has the personality to do the job well and there is no point in setting someone up for failure.

Even if you don't rotate the Scrummaster role around, it is very important for that Scrummaster to train his replacement. People should always be able training one of their peers to do their job. In the military this is institutionalized for very good reasons, but many companies don't factor in the "bus factor" in their contingency plans. This can seriously harm a company or a release cycle.

What do you think? Should the Scrummaster role be rotated? If so what best practices do you have? Or should the Scrummaster role be assumed by one person so that they can master it?

10 Things a Janitor Can Teach You About Leadership

Col. James Moschgat wrote an article about the ten leadership lessons he learned from his janitor at the United States Air Force Academy, an unassuming Medal of Honor winner from the Second World War.

There are some excellent lessons here:

1. Be Cautious of Labels - Labels don't define people, actions do.
2. Everyone Deserves Respect - Golden rule stuff.
   
3. Courtesy Makes a Difference - Goes with the above rule, respect begets respect.
   
4. Take Time to Know Your People - Strengths, weaknesses, motivations, etc.
   
5. Anyone Can Be a Hero - Save the day, save the project.
   
6. Leaders Should Be Humble - Don't be like "modern" leaders like self-aggrandizing sports heros and the like.
   
7. Life Won’t Always Hand You What You Think You Deserve - You need to work hard to get it.
   
8. Don’t pursue glory; pursue excellence - Be great at what you do, even if it isn't "sexy", but love your job at the same time, life's too short for anything else.
   
9. Pursue Excellence - See above.
   
10. Life is a Leadership Laboratory - Examples of great leadership are all around, you just have to look.

Number eight and nine are pretty much the same, I would have pulled the following point into a numbered lesson "No job is beneath a leader". This lesson is one that I can really relate to.

In one particular example, about a year ago, one of the teams I was leading was working on a Java web project that was running a little late. OK, a lot late. The whole team had pulled together to put the final touches on the acceptance build. It was 10pm at night we had to get the build out the door before the end of the day. QC was many timezones away (India) and not yet in the office. We had 3 browsers to test, and only two hours to do this.

The solution was to import that QC test plans into Google docs, then have the entire team run through the test plans collaboratively in real-time. Executing test plans isn't part of a developers normal job, sure they run their own tests, but they not responsible for running sanity tests on builds that are on there way to the customers. But we didn't think twice, we all pulled our socks up and got the job done. Developers, Project Leaders, and Project Managers all worked together to get the testing done.

This allowed us to get the sanity testing done on all the supported browsers done in a fraction of the time it would have taken a single QC person to do it. When the QC started their day a few hours later, they spent their day running their more detailed test scripts against our drop to see if we had missed anything, but the Project Leader and I had confidence that what we were sending the customer didn't have any big functionality or rendering bugs.

When I look back at this example, I see three leadership principles demonstrated:

• Lead by example
• No job is beneath a leader
• Rewarding the team for their sacrifice (reward followers)

Lead by example
In this instance I was able to lead by example by implementing functionality and fixing bugs quickly. By submitting good patches, and performing good code reviews. By working nights and weekends for those four weeks or so, I could show that I too was making sacrifices to my personal time, I tried to ensure that I arrived with the team and left with the team during that time. I wasn’t just dictating that overtime was to be done, I was actually doing overtime. After the project, several of the team members came up to me and thanked me for my contribution, and said that it helped motivate them to work extra hard and get the project done.

No job is beneath a leader
It wasn't in my job description to write code, review patches, or run test scripts, but I did it anyway because it helped the team accomplish the mission. If someone had to go out and pick up supper from the office, I did it. What was really great was that everyone did whatever had to be done. This was a great attitude to see on a team.

Rewarding the team for their sacrifice
I made sure to thank the members of the team personally nearly every night when they signed out for the day. At the end of the project I made sure they were compensated for their time, and provided little thank you gifts to everyone. Doing a few little things to thank them for their time and effort can mean a lot.

When projects run late, teams can easily get de-motivated, leading by example, doing whatever it takes to finish the project even if it’s “beneath” your position, and showing appreciation for the team’s sacrifices are three ways that can help show the team that you are with them and that you support them.

Remember that leadership is about influencing people, hence it is more of a service then a command. You need to influence your team to go the extra mile by being a good leader that your team will look up to, and be inspired from. These three principles honestly applied can help you become that leader.

Great Principles to Live By

Patricia Sellers posted an article up on her blog a few days ago about David Ogilvy, called by some "The Father of Advertising". In the article she shares the business advice David once told her. All of these are great, most of them strike to heart of humanity and leadership. Here are ones that relate most to me:

1. Remember that Abraham Lincoln spoke of life, liberty and the pursuit of happiness. He left out the pursuit of profit.
2. Remember the old Scottish motto: “Be happy while you’re living, for you are a long time dead.”
3. If you have to reduce your company’s payroll, don’t fire your people until you have cut your compensation and the compensation of your big-shots.
4. Define your corporate culture and your principles of management in writing. Don’t delegate this to a committee. Search all the parks in all your cities. You’ll find no statues of committees.
5. Stop cutting the quality of your products in search of bigger margins. The consumer always notices — and punishes you.
6. Bear in mind that the consumer is not a moron. She is your wife. Do not insult her intelligence.

I have six of the seven posted. I am not in advertising so I don't relate to that one specifically, the rest however are all great. They seem very relevant in today's tough market, with companies downsizing or looking to penny pinch. At the end of the day, good leaders will inspire others to to success.

Which ones do speak to you the most? Which ones would you add?

Good Technical Debt vs Bad Technical Debt

Early today I was reading a short blog post over at Scrumology on an age old argument about the fine balance of technical debt and releasing early.

Accumulate too much technical debt and your product's development will slow to a crawl attempting to service all the debt you have burdened yourself with. If you spend too much time keeping yourself debt free, you will miss your opportunity as your product's all important time to market is too slow.

So where do you draw the line?

I think we can draw a lot of parallels with financial world. As the article and its links point out, there is good debt and bad debt. Good debt is debt that builds value (business loan) or the opportunity to build value (student loan) and/or builds happiness (mortgage). Bad debt is debt accumulated to gain things that rapidly decrease in value; they worth less than the debt took on. Think clothes, or that new big screen HDTV.

For technical debt to be good debt you need to gain more then it will cost to retire it.

If you can close a big deal by adding a feature to your product within a really short time line, then it makes sense to do so. You after all have bills to pay, you can get feedback from your customers, and your team will get to celebrate a success and build momentum off of a big win. This can really help morale. (Of course adding features to win deals from specific customers is its own bag of worms, but let's just assume for the sake of argument that this feature is an awesome feature that you were planning on releasing in your next major release, but the customer couldn't wait that long.)

Another example of where technical debt is good debt is in cases where the product/solution is a one off, spending too much time and effort on a clean design is simply wasted effort and not needed. The code will rarely be modified. In these cases you only add to the cost of the product.

And in those cases where the products are not one offs, there is a concept of "luxury design" in my opinion. Especially when considering architectures that need to "scale" or other such "not needed yet" nonsense.

If you are creating a new product to release you don't need to worry too much about "scaling" upfront. Having scaling issues is a "good thing". It means you are successful. It means you have the resources and the business case to go ahead and put the right architecture in place so you can scale to the next level. But putting that in too early and you could miss your market window. You have missed your chance to build value and wealth, and to gain customers.

There are of course cases where you cannot accumulate that debt because the cost is simply too high. For example, adding a new feature to a successful ecommerce website where if the customer experience drops due to performance or bugs you get big a drop in revenues. Here you have the data to prove it that the debt is bad. There is a direct and immediate cost.

Of course with gobs of money and time, you can have the best of both worlds. With a proper user-centered design approach to product creation, your user experience team will be doing user research, and running user tests with mockups and wireframes while your team off building components and backend pieces. It's too bad that this is not more commonplace, users around the world would rejoice.

There is an old adage that nothing in life is certain but death and taxes, and in product development I will advance a new adage for consideration. "Nothing in product development is certain but technical debt and too early release cycles".

What do you think? Should technical debt be kept to an absolute minimum, or is a more pragmatic approach needed?

Cyclomatic Complexity Debunked?

I have always taken for granted that code with a higher cyclomatic complexity number (CCN) is more bug ridden then code with a lower CCN. This has been taught/assumed for many years. and apparently the old adage about assumptions (ass-u-me) holds to be true again.

I was doing some quick research to find a free tool I could use to measure the CCN of my project as part of its continuous integration environment. This is a best practice of many agile practitioners, and good software engineering to boot. According to this article however, it isn't as useful as it was assumed to be.

What the survey did not show, however, is that code complexity does not correlate directly to defect probability. Enerjy measured complexity via the cyclomatic complexity number (CCN), which is also known as McCabe. It counts the number of paths through a given chunk of code. Even though CCN has limitations (for example, every case statement is treated as equal to a new if-statement), it’s relied on as a solid gauge. What Enerjy found was that routines with CCNs of 1 through 25 did not follow the expected result that greater CCN correlates to greater probability of defects. Rather, it found that for CCNs of 1 through 11, the higher the CCN the lower the bug probability. It was not until CCN reached 25 that defect probability rose sufficiently to be equal that of routines with a CCN of 1.

There is no correlation between CCN and bug counts for code that has a CCN of 1-25! For software engineering wonks, and process improvement gurus this must come as a bit of a shock. So I ask the readers, is the measurement of CCN a sacred cow that should be slaughtered with the rest of those asinine bovine as we move to a more agile and lean software development process? Or is it still a useful tool that should be kept, just interpret the results pragmatically?