Thursday, June 29, 2006

Managing efficiently a team

I am not a team manager.
However I have experienced different management styles as a team member, and I am convinced that hiring an excellent manager is crucial for the success of any project.
How to recognize such talent in others? And in ourselves?

There is a best seller book called "The One Minute Manager" that is worth reading, even if you are not in a manager position: it offers paths to improve your personal managing skills when organizing, solving problems and getting a team work done on the project.
In the few following lines, I will try to give you a summary of this book, that I really did appreciate.

We commonly divide managers in two groups: the "democratic" managers (centered on people), and the "autocratic" managers (centered on results). I personally prefer the democratic kind (like most team members I guess) because they really care about your feelings and want to make your job exciting and empowering. The problem is, those purely democratic managers are usually not considered efficient by their own hierarchy, as they would rather miss the milestones in order to preserve a good relationship with their teams.

Where is the balance?
World-class managers are well organized and have realized that "people who feel good about themselves produce good results". They define the word "Productivity" as quantity AND quality. The latter is fundamental and often missed by poor managers in their day-to-day activities.
For example, one rule of thumb could be not to make decisions for others: people tend to be accountable for their work when they have decided by themselves how to realize an objective. The bottom line could then then to be crystal clear in the definition of short-term objectives, stated in weekly meetings.

Here are three keys for efficient management, stated in the book:

  • One-minute goal settings
    => Organize short meetings (2-3 hours) every weeks to review and analyse last week issues, and to plan the objectives for the upcoming week.
    => Write at most one page statement for every goal: this helps to focus on narrow matters and avoid confusion.
    => Ask team members to explain their problems in observable, measurable terms (no place for wasteful grumbles!)

  • One-minute praise
    => Daily records of progress (can help people reach their full potential)
    => Be consistent (praise if things are done right even if many problems arise elsewhere)

  • One-minute reprimand
    => Specify exactly what has gone wrong
    => Do not attack the person but point out the wrong behavior (avoid defensiveness)
    => Be consistent (reprimand are done wrong, even if everything is OK everywhere else)


  • These could constitute effective hints for detecting good managers, but also for hiring XP team members, as we need the team to be mature, auto-organised and efficient.

    I am convinced there are other qualities that a good manager should have, like being a good information transmitter from team members to hierarchy and vice-versa, having a good ability to listen... Do you think of others?

    Sunday, June 25, 2006

    Computer programmer : the cornerstone of high-tech software industry

    As they get their first job as a programmer, I noticed that most people want very soon to manage their own team or become "software architect", though they do not have yet the slightest experience on the job.

    Why that situation - a system analysis:
    ---------------------------------------

    I suspect the main reason is that "computer programming" is not at all considered as a job to be proud of: in the classical view, it is often synonym to a lower working class of the high-tech industry, editing trivial code chunks for a large system that has been designed by an elitist architecture team.

    The main drawback of this situation is that skilled experienced programmers almost always get demotivated and stop doing what they do best, to choose between two main career paths:
    - specify what others should do through large documentations
    - manage programmer teams as appointed leaders

    The resulting situation is that nearly 80% of the programming population is composed of beginners, mediocre programmers or uncontrollable geeks.
    Alarmed by this constatation, the top executives naturally credit them with poor credibility and empower other layers in the organization for thinking in their place, like design architecture teams, Quality Assurance teams and middle management.

    As a consequence, in the shared mental model of most organisations, these layers soon own all the "noble" jobs that every sensible computer programmer should seek to succeed in his career, whereas the programming folk is dangerous and should be highly controlled by responsible thinkers.


    A cancer for software edition
    -----------------------------

    This reinforcing process generally goes unnoticed and lowers the capability of an organisation to produce high quality software.

    It especially results in a complex machinery where every single need goes through several translations handled by as many different teams before getting to the programmers. Traditionnally we observe a minimum of 4 steps:
    1- decomposed in several pieces of functional requirements by a Product Line Management team,
    2- analysed by the architecture team to produce the detailed technical design requirements
    3- developed by programmers, following the constraints of a heavy QA process
    4- tested by a dedicated team, at the very end of the development stage

    Apart from the considerable waste of energy of such a process, I think the number one issue appears in the lack of the programmer team involvement on the 2 first stages: the programmers are the ones in charge of the code production, and thus own the real expertise of the inner details (potentials as well as risks) ; furthermore,a clear vision of the needs in the actual implementation stage would enhance the rate of success, by focusing on the real added-value.
    This kind of organisation strongly favors a discrepancy between the concerns of the team and the concerns of the rest of organisation.

    XP: a new breath of air
    -----------------------

    XP gives back to the programmer its central role in the software production.
    The bet is to create a new kind of reinforcing feedback process to motivate the talented programmers keeping an active role in programming teams as they get more experienced.
    In a mature XP team, everyday issues constitute as many opportunities for personal improvement, and the potential of each member is used to the best for the project accordingly to his (her) insterests.

    Tuesday, June 20, 2006

    Time for a new start

    This post will be short.
    The purpose of this blog is to post my thoughts in a day to day basis about my own experience of software development.
    I have chosen the name "extremepill" because I discovered 4 years ago an awesome methodology whose name is eXtreme Programming (XP), that I now tend to consider as a true philosophy of life, a way of being in the world, and in particular a real Pill for the future of the software industry.
    I want to thank my first coach Regis Medina who introduced me to this new world.

    Please do not hesitate to add comments if you feel there is a need ; I will be very please to share views!