A Simple Matter of Software

Design principle from creator of first Wiki

“What is the simplest thing that could possibly work?”
                                                              - Ward Cunningham

Off Topic: Quote from "Here if you need me"

"I know that I live in a crass and boorish culture, a culture of shock jocks and road rage, 'reality' television and thong underwear, corruption and consumerism, mean porn and meaner theology."

"I know all this.  And still, the world I move through is rich and beautiful, and the people I work with ... are decent, discerning and good."

                                                                - Kate Braestrup

How to retain the people you want to retain

Marc Andreessen has a good post on how to retain the people you want to retain:

It's about winning.

Let me explain:

Companies that are winning -- even really big, old ones -- never have a retention problem.  Everyone wants to stay, and when someone does leave, it's really easy to get someone great to take her place.

Companies that have a retention problem usually have a winning problem . . .

. . . Great people want to work at a winner.

All the raises, perks, and HR-sponsored "company values" drafting sessions in the world won't help you retain great people if you're not winning -- not even the $6,000 heated Japanese toilets in all the restrooms, the $30,000 Olympic lap pool out back, and the free $4 bottles of organic orange juice in all the snack rooms.

I would just add two comments.

1) “Winning” is not enough, the people inside need to viscerally feel that they are winning

"Winning" but having people not "feel" that they are winning does happen more often than you would suppose.  People get caught up in all the daily challenges and issues and lose the big picture.  I have been at start-ups that are hitting it out of the park (tens of thousands of users, tens of millions in revenue, a good team of people who work together well, coming up on IPO, a solution that is certain to be in growing use for the next decade) and yet there is a percent of the population that have closed their eyes and can't see the value of what they are creating.   

In these cases, where some of the people don't understand/appreciate what they have got, I have seen good people leave to do something "new".  Only to see the hard work on their new project amount to nothing (most new software ventures fail and result in a bunch of lovingly crafted software that does not get used long term) while their old company builds success upon success.  This can be the cause of substantial regret.

2) People who don’t care about working at a winner are people who you will eventually be better off without.

Though be careful to distinguish between people who will never care about the team's success and people who are justifiably frustrated about some important aspect of their environment.   People who will never care probably shouldn't be long term members of the team.  On the other hand, for the people who could care if only some fundamental dysfunction is addressed, you should keep them around and fix the dysfunction.

                                                                               copyright 2007 Kerry Champion

Focus on opportunities, not problems

Good advice for every software venture.

"Focus on opportunities, not problems. In most companies, the first page of the monthly management report lists key problems. It's far wiser to list opportunities on the first page and leave problems for the second page. Unless there is a true catastrophe, problems are not discussed in management meetings until opportunities have been analyzed and properly dealt with."
                                                                                                        -- Peter Drucker

Agile Manifesto - Annotated

I have been thinking recently about the Agile Manifesto. 

Here it is with some annotations. 

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Right on!  This gets to the heart of the "adaptive" vs. "predictive" debate.  The post here makes a similar point phrased in terms of "evolutionists" vs. "creationists" using analogies from Richard Dawkins.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Changing requirements is a reality and you need to embrace that and learn to succeed within that reality. 

However, I have two concerns with the way this particular item is presented. 

First "welcoming change late in an iteration" can directly conflict with your ability to achieve "early and continuous delivery of valuable software".  The manifesto leaves it as an exercise for the reader to figure out how to balance those conflicting desires.  It can be done, but there is no guidance here how to do it.

Second recognizing the reality of changing requirements doesn't give you a free pass to put off detailed requirements definition.  You still want to push hard to define the requirements as early as possible and then only change them based on "new information". Thrashing a decision because of internal indecisiveness is a bad idea, adapting as you get new insights into what works best for the user is a good idea.

The good thing about short iterations is that you can "freeze" and "reopen" requirements quickly (with each iteration).  Still at some point you have to at least temporarily freeze the requirements to get the iteration out the door.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Right on! This is a direct corollary of point 1 above.  Of course some initiatives will take longer than a "couple of months", but that does not mean they can't deliver working software along the way.

Business people and developers must work together daily throughout the project.

Right on! 

Engineers working in a vacuum will produce some beautiful code, which may be irrelevant to the problem that needs to be solved.  In the case where the engineers themselves fit the target audience  (programming tools, search engines) then engineers can produce great things without the business folks.  But those cases are the exception not the rule.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

100% agree.

However, when you have multiple motivated individuals they often don't agree on how to proceed forward.  The manifesto leaves as an exercise to the reader: how do you get alignment and get past such disagreements.   

The most efficient and effective method of  conveying information to and within a development team is face-to-face conversation.

It is true that face-to-face is the most powerful way to communicate an idea and it is true that face-to-face is often underused.

However, there are plenty of times when face-to-face is not the best option for "conveying information" especially information that needs to survive for a period of time. 

Tribal knowledge is a powerful thing, but if all information only exists as tribal knowledge in peoples' heads than you will have some real issues in achieving "sustainable development" (see two items below).

Working software is the primary measure of progress.

Right on!  Such a simple but powerful concept.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

100% agree.

Continuous attention to technical excellence and good design enhances agility.

100% agree.  An interesting question here is how you go beyond "attention" to "measurement".  It is much easier to keep your attention focused when you have some measure of how well you are doing.

Simplicity--the art of maximizing the amount of work not done--is essential.

Right on! 

It is easy to state the value of simplicity, it is harder to apply it in practice.  Though Dilbert had a good example of simplicity in action that has some lessons for the software world.

The best architectures, requirements, and designs emerge from self-organizing teams.

This is true. 

However, it begs the question: what do you do when the team fails to "self-organize"?  Give up and go home?  Hopefully not.  How to catalyze "self-organization" is left as an exercise for the reader.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

100% agree.  Any complex task that is worth doing demands a certain amount of self-reflection.

By the way, one implication of this last point is that you should make your behavior suit your particular needs and experiences even if that means not exactly following agile development method as described in the various books, training classes, etc.

                                                                               copyright 2007 Kerry Champion

The difference between pleasure and satisfaction

"... a distinction between pleasure and satisfaction.  In fact, MRI brain scans have provided evidence that there is indeed a significant difference between these feelings.  Pleasure and happiness are passive emotions that happen to us as the result of outside stimuli.  Satisfaction, on the other hand, involves an active pursuit - it is the emotional reward we get after adapting to a new situation or solving a novel problem."

                                              Scientific American August/September 2007
                                              Mark Andrews

I am sometimes asked for advice on whether the questioner should join a high risk high reward software venture. 

The above distinction between pleasure and satisfaction touches on one key part of the answer.  People who strive to achieve real "satisfaction" from their professional endeavors tend to be good fits.  People who are solely looking for the "pleasures" that come from the tangible rewards of their endeavors tend to be not good fits.

The young violinist who dreams of taking a bow in Carnegie Hall is unlikely to get there.  The one who dreams of the playing itself is much more likely to have that success and eventually take that bow.

Are you agile?

I ran across an amusing checklist to measure "Agility" in the agile programming sense.

Don't agree with every single point implied by this list, though most rang true.  Here are some favorites.

======================================================================

You are not yet Agile if:

“Test-driven” still refers to your car.

Developers only develop, testers only test, and managers just manage.

Simplicity is presumed to be simple.

======================================================================

A more serious checklist to measure agility is available from the same source here.

Fat Rabbits

Snakes have very slow digestions and can eat very big meals relative to their size.

The upside of this behavior is that the can get a lot of nutrition from a single meal.  The downside is that they put themselves at risk every time they eat a mega-meal.  If a snake swallows a very fat rabbit, it will be relatively immobile and at risk from its own predators until that rabbit is digested.

Some software projects are like fat rabbits.  Teams are often tempted to take a big bite all in one go: making significant architectural changes, bundling together lots of functionality, or doing both at the same time. While that big project is underway, the team is not able to respond quickly to new information and is not able to provide a steady stream of incremental improvements.  So like a snake that swallowed a fat rabbit such a team is at risk.  They are not able to agilely respond to their current circumstances, they are stuck digesting this big chunk of work.

It is important to recognize when you have taken on a fat rabbit.  In those circumstances clearing a path and accelerating the teams progress is almost always the right thing to do. 

If you have swallowed a fat rabbit get it digested as quick as you can.

                                                                               copyright 2007 Kerry Champion