I recently played the ballpoint game for the first time and was impressed…

• … how clearly it demonstrates the different phases of a team going through the ’storming, norming and performing’-phases for everyone - even for management spectators.
• … how the iteration-rhythm helps to keep focus and increase the team performance to a very high and predictable level.
• … how easy it felt to deliver good results once the team started to perform after the 2nd and 3rd iteration.
• … how much fun it can be, to be part of and work in a cool software develoment team.

You can find various explanations on how the ballpoint game is organized and played.

Here is a nice video that illustrates what happens through the iterations: http://www.youtube.com/watch?v=d4-El7gJuZE

Thanks to Stefan and René for the inspiration!

I have just finished the book ‘Managing Humans: Biting and Humorous Tales of a Software Engineering Manager’ by Michael Lopp and I would like to recap the idea behind the 2 identified types of ploblem solvers on a development team. These are their characteristics:

• Incrementalist: They are driven by constantly making small forward increments. They are aware of available resources and the landscape in which they operate at any time. Since they know that there is no final solution, they are good brainstormers to come up with quick solutions. They love discussions and drive progress.

• Completionist: They need time to figure out the plan to analyse and solve a problem before they start moving in a direction. They apply a strategic vision to integrate their solution into the greater picture.  If a Completionist is quiet, is does not mean he has nothing to say. It is just unlikely for him to talk about something without a fully formed plan. After having thought all through, the Completionist knows exactly what to do.  It is the architect type of guy striving for a perfect longtime solution.

In the end both types like to get stuff done. The difference is just how they get there and that is exactly the point around which both regularly argue with one another.

If you think about your team and who shows tendencies towards one of the two types, how can this insight make your team communication and problem solving habits more effective? As a team lead you definitely need both types and it is your responsibility to engage both in a healthy discussion.

I am a fan of good receipes and checklists and just discovered the podcast “The Managing Software Development (MSD) Show” by James Edgell, which I highly recommend for all folks being responsible for IT-people and in the end for what they produce.

The value of your software development resources (people) consists of two things: their technical knowledge and their behaviour. The first can be developed by training and gained experience, the second is harder to change. And since everything is about bahaviour in people management, we also focus on it in terms of performance measurement.

James recommends the following:

• Identify important abstract behaviours (see following list).
• Measure the performance of every desired behaviour for each of your directs at regularly scheduled checkpoints. Scoring is from 1-5, where 1 is least demonstrated and 5 is most demonstrated. Add score corrections for plusses and minusses that are not covered by the behaviours in the list, e.g. for a rare talent or special industry knowledge no one else has.
• Set annual goals to improve on some of them. Goals should be ’smart’ (s=specific, m=measurable, a=attainable, t=timebound).
• Sum up the scores and order them by score. You now have a handy helper to make decisions regarding: bonus payment, promotion, layoffs.
  Divide the list in 4 sections from top to bottom:
  • 10% - your excellent people.
  • 20% - exceed expectations.
  • 60% - meet expectations.
  • 10% - need to improve.

Here are the behaviours:

• Strategic planning: Consideration of future needs, vision of the future.
• Maintained industry awareness: Latest trends, not only technical, understands customer business, evolution and lifecycles.
• Innovation: Brings in new ideas, continuous brainstorming, brings vitality to the organization.
• Builds and sustains relationships: Inside the team, the department, also builds those relationships actively outside the department and organization.
• Communicates effectively: Oral, written documentation and email, accurate to-the-point information or distraction.
• Leads and develops a team: Gets things done and drives the team, also motivates to do unpopular tasks.
• Enthusiasm: Does his things with high energy and enthusiasm.
• Assertiveness: Challenges the organization and the team to get the best possible outcome, does not settle with what is already there.
• Decisiveness: Stands by team decisions, solves conflicts quickly, does not undermine made decisions once they have been made.
• Clear and focussed thinking: Concentrates on what is relevant to make progress working on issues, is result oriented.
• Planning and organizing: How efective they organize their tasks and the team’s tasks.
• Productivity: Are they always on time, do they produce work of good quality, are they busy to get things done effectively.
• Customer focus: Mentality towards the customer.
• Integrity: Honesty, ethical thinking, are they trying to do the right things.

Thanks James, please give us more of that!

Sometimes you come accross something and pause thinking ‘I have experienced exactly that’. So it happend when I read Scott Ambler’s post ‘Bureaucracy Isn’t Discipline’.

Here are the main points and in my view ammunition for philosophical discussions:

• Successful agile practices demand great discipline and require significant skill and experience to actually get stuff done.
• Just following repeatable processes rather than focusing on repeatable results are ‘process smells’ and seen as anti-pattern.
• Delivering repeatable results in agile environments is critical to success in IT projects.
• Mistaking bureaucracy for discipline is a reflection of cultural damage that has occurred over the years to large organizations.
• This bureaucracy is seen as inhibitor to software process improvement efforts and particularly to agile methodologies.
• A cultural shift towards agile will make many ‘bureaucrats’ uncomfortable.

I think, the approach to use a defined set of formal processes (bureaucracy) comes from the management people who hope to reduce risk and thus ensure repeatable production results. On the other side there are the natural constants of the IT environment with its complexity, constant evolution on all layers, life-cycles etc.

In my opinion, a possible solution could be found between these two extreme views if…

• hierarchies are kept flat or are at least perceived as being flat.
• communication-paths are reduced to the least required number and everybody knows what exactly his job is and what skillset this requires.
• an open, friendly, frictionless and goal-oriented culture gets established and maintained (preferably top-down).
• the system allows the players to focus on and finish their tasks and have a feeling of accomplishment.

Here are the thoughts taken from a lecture of Judy Estrin (CEO of JLABS, LLC) on innovation recorded in October 2008 at Stanford University:

Core Values of Innovation:

• Curiosity and ability to frame open questions. Instead of ‘Do you need this feature?’ you could ask ‘What are you currently working on?’ or ‘What are your problems?’.
• Self-assessment, ability to question yourself about the direction you are heading and make adjustments along the way.
• Risk-taking and willingness to fail. Try something and accept potential failure in order to take lessons from it. If failure is a problem, nobody will try anything.
• Openess to share knowledge and thoughts. Be open to surprises.
• Patience to let things grow. Mutual trust among the team members.

Judy underlines, that it is important to address all of these points and find/grow the right balance in your environment.

Other interesting Points from the lecture:

• Maximize the potential for innovation in your team by hiring cognitive diverse people.
• Importance of attitude in people you hire.
• Support an encouraging culture in your team.
• People are naturally innovative (kids). This gets beaten out and is unlearnt by the system (school, university, incentive systems).
• Innovation is not necessarily a new product.
• Companies are making themselves efficient by measuring many business aspects. This limits them to incremental innovation, which is always based on prior work. Groundbreaking (disruptive) innovations are created in different environments.

Listen to the 60min lecture: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2052

The five stages of innovation:

1. People deny that the innovation is required.
2. People deny that the innovation is effective.
3. People deny that the innovation is important.
4. People deny that the innovation will justify the effort required to adopt it.
5. People accept and adopt the innovation, enjoy its benefits, attribute it to people other than the innovator, and deny the existence of stages 1 to 4.

Taken from http://sydfish.wordpress.com/2008/03/17/the-five-stages-of-innovation/

Inspired by a talk of Joseph Pelrine

http://www.infoq.com/presentations/Agile-Adoption-Joseph-Pelrine

about why agile methods sometimes fail in organizations, I became aware of the following point:

The cycle to successful progress in agile teams is NOT Inspect > Adapt but rather Apply > Inspect > Apadpt.

Agile teams operate in complex environments (systems). Often there are no direct connections between causes and effects observable about things that are going on during project sprints. The only chance is to address issues in retrospect with a bit more distance and the picture how things evolved in the underlying system. You can not do a useful insprection and then do adaptions without really having tried (=applied) things out in your system’s environment.

Some other points from Joseph Pelrine’s session on why agile sometimes fails:

• Not understanding the Apply > Inspect > Adapt cycle.
• If you are doing agile by the book (only Inspect > Adapt), you are not doing agile.
• Agile techniques are scary to many people. They can not deal with what comes up and tend to get crushed.
• People not willing or able to step outside of their comfort-zones.
• Problems in communication and conflicts.
• Use of the wrong tools in wrong places just for the sake of using them.

Inspired by the post by Jeremy Meyer “Why it’s better to be lazy” I discovered an interesting conceptual view on how military staff was classified by General von Moltke’s Value Matrix:

“There are only four types of officer. First, there are the lazy, stupid ones. Leave them alone, they do no harm…Second, there are the hard- working, intelligent ones. They make excellent staff officers, ensuring that every detail is properly considered. Third, there are the hard- working, stupid ones. These people are a menace and must be fired at once. They create irrelevant work for everybody. Finally, there are the intelligent, lazy ones. They are suited for the highest office.

General Erich Von Manstein (1887-1973) on the German Officer Corps”

If we transfer this into our world, it would look something like this:

• Smart + Lazy: Innovative type that does not rush into things. He figures out the easiest way to accomplish a goal. Has a strategic mind and long-term view. Is a good leader.
• Smart + Active: Follows opportunities as they arise in realtime. A manager type. His intelligence is sometimes diluted being confused by too many parallel things and lack of discipline to focus. Gets lots of stuff done. Not a great leader.
• Stupid + Lazy: Follows orders. Does not show too much own initiative. Operative administration type. Often inherits value created by the Smart-Actives. Does no harm on teams. Performs in a consistent predictable manner.
• Stupid + Active: Dangerous type. Does not follow orders, makes mistakes and pursues his own agenda. Default behaviour is to act in absence of skill. Causes all kinds of trouble.

I’m sure, while reading, you already thought about some of your colleagues to be a good fit into one of the 4 categories ;).

Inspired by an article at InfoQ (http://www.infoq.com/articles/better-best-practices) I discovered an interesting model, which explores the nature of learning in an interesting way: The Dreyfus Model for Skills Acquisition.

In essence it describes how people acquire skills over time, what supports them best in their progress and how they behave with their growing knowledge. Five levels are described:

• Novice - Needs to be told exactly what to do. Has very little understanding of the context to base decisions on. Wants frequent quick wins, needs regular feedback and reassuring messages. Learns best by abstract and context-free rules.
• Advanced beginner - Is familiar with the basic steps but still needs guidelines to follow. This is the stage at which a learner is most dangerous - he knows enough to think he knows a lot. Uses more sphisticated rules than a beginner. Treats all aspects with equal importance.
• Competent - The learner begins to understand his tasks and starts seeing longer term consequences. He can figure out a sequence of tasks in order to accomplish a goal. Learns best when given hierarchical goal-based targets accompanied by some rules. *
• Proficient - An ability to analyse a situation and seperate what is most important develops. The learner is experienced enough that solutions start to just appear and are seen in the wider context. The person can rely on his judgements. He follows higher-leveled maxims. Decision-making feels less labourous. Searches inspiration, loves challenges and is open to constant learning.
• Expert - Works mainly on intuition and is rarely wrong. Involves critical reflection on his intuitions, rather than goal-based planning. Loves to meet and exchange thoughts with other experts. Best practices are seen as a necessary evil. Does not rely on rules and maxims. Has a vision of what is possible.

* Most people don’t get beyond the competent level at most skills. Progression from Novice to Competent is linear. The model points out that one can become competent at something just by doing enough repetitions, but learners who want to reach beyond this point need to develop and maintain an active will to become proficient. It takes many years of dedicated effort to become an expert in a particular field.

Here you will find an application of the Dreyfus Model to software development with Ruby on Rails: http://pragmaticstudio.com/dreyfus

This is a nice collection of podcasts and videos of today’s entrepreneurial leaders talking about various success factors:

http://edcorner.stanford.edu/podcasts.html

Podcast-RSS: http://www.stanford.edu/group/edcorner/uploads/podcast/EducatorsCorner.xml

Guy Kawasaki on important stages towards successful innovation.

http://itc.conversationsnetwork.org/shows/detail1867.html

Killer Innovations is a source of tools, tricks and lessons about creativity and innovation. The goal of the podcast is to show the listeners that being creative and innovative is a skill that can be learned.

Goto: http://techtrend.com/blog/

Current show: Finding and Keeping Innovation Champions

Great essay about hackers and the way they work and like to work:

Audio: http://itc.conversationsnetwork.org/shows/detail188.html

Transcript: http://www.paulgraham.com/gh.html

Other essays of Paul Graham: http://www.paulgraham.com/articles.html

An interesting blog-post on “Software Development Team Diversity“

Big collection of articles worth reading about management of software projects found on “AYE (Amplifying Your Effectiveness) Conference - Articles about software and IT Development”:

Goto: http://www.ayeconference.com/articles.html

I have often wondered why it is so difficult for non-developers (management, sales people, customers, inexperienced developers etc.) to understand the mechanics of software development, its life-cycle and the related elements like for example the importance of

• code-base quality,
• refactoring,
• versioning,
• unit testing,
• agile development practices,
• requirements management,
• project-wide standards,
• creating a productive, open and creative atmosphere around development,
• permanent curiosity for new tech-stuff and the freedom to play with it,
• and many more…

Some individuals of those groups don’t even at least try to find out more about it. Obviously they have not realized yet that when building complex websites, maintaining and extending them for many years they are already developing software - and that this is different from building a toaster once and selling it. So, I decided to post some related articles, books, podcasts etc. whenever I get across them which convey the nature of software development in understandable words.

I hope this selection motivates people to read/listen an maybe even understand one day and thus reduces unnecessary friction.

Here are the first links:

• Article: “Keep it DRY, Shy, and Tell the Other Guy”
• Book: “Practices of an Agile Programmer”
• Blogpost: “Moving to Subversion”

Post about how to hire good programmers.

Goto: http://www.artima.com/wbc/interprog.html

Goto: http://www.manager-tools.com