Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

23 February 2017

The Hare & The Tortoise

The fable of the Hare & the tortoise has been used to draw lessons in competing and co-operating.

The fable also applies to software organizations.

The Hare Company.

  • No prototypes are being worked on. (Hare Sleeping)
  • No experiments being done to Cross The Chasm. (Hare Sleeping.)
  • Wishful thinking about own capability. (Hare Dreaming.)
  • RFP is received. (Hare wakes up.)
  • Estimate based on myth.
  • Mad scramble to bung in a business proposal. (Hare racing.)
  • Loses Contract. (Tortoise wins. Hare team gets more dysfunctional.)
The Tortoise Company.
  • Prototypes concepts that are likely to win in the marketplace. (Steady progress.)
  • Experiment. Be ready. (Steady Progress.)
  • Fast feedback loops. (Course correction. Prepare to undertake "Op Overlord")
  • Has true picture of own Capability. Uses CMM as a "dashboard" instrument.
  • Estimate based on track record.
  • RFP is answered based on known facts. Risk minimized.
  • Wins without breaking a sweat.
  • Proceeds with Agile implementation of project.
Surprisingly, It is the Tortoise that is Agile!

22 February 2017

20 February 2017

Humility & Courage

Humility is not lack of confidence. Bravado is not courage.

I believe that Humility & Courage are essential traits for doing quality software work. The reality of software development teaches that. Refusal to learn this lesson is a root cause for poor software quality and dysfunctional teams.

Humility.
Humility means being aware that one could be wrong; that one's understanding has gaps. Humility leads us to always question our assumptions; to always put them to the test.

Defensive coding is humility. Assert statements check one's mental model of the state of execution of the code. It is accepting that one could be wrong.

Recognizing the primacy of unit tests that can be easily and frequently run, and provide appropriate coverage metrics, is humility. Adding tests that increase coverage metrics is humility.

Humility is a prerequisite for learning.

Courage.
Visually challenged persons are not be able to walk briskly. But they learn to progress by testing their way with the help of a cane. That is courage.

As software professionals we should realize that we are "visually challenged". Courage is "tapping" our way forward. The "tapping of the cane" are experiments that we must conduct to improve our understanding. These experiments have to be small steps.

Resolutely "tapping" our way to our objective is Courage.

Agile.
An Agile process is about Humility & Courage.

21 January 2014

Bolt or Jackie?

I was in conversation with someone who said he had experience of agile methodology at one of the companies he had worked at.

I asked him to describe agile development. The first statement that he made was, "It is for fast development."

Not quite correct. Agility is not the same as speed. Usain Bolt is the fastest human. I doubt if he is anywhere near the most agile. Arguably the most agile would be Jackie Chan. Though Mr. Chan would undoubtedly be quick, I doubt if he is a world class sprinter. I doubt if Mr. Bolt would qualify for the Jamaican acrobatics team.

Agility is the ability to respond to surprises. It needs muscular coordination, quick reflexes, flexibility, excellent sense of balance, and sixth sense.

A software process that focuses on speed wants to anticipate all surprises. It is about risk minimization. It invests in up-front detailed design and the associated processes to ensure that the plan is followed. It needs a clearly marked standard track to sprint down.

A software process that focuses on agility acknowledges that the only thing that can be said in advance about surprises is that they will occur. It is not about speed of development but speed of response to surprises. Speed of response to surprises needs leadership with a mindset that is willing to accept surprises - not sweep them under the carpet. It needs leadership with a mindset willing to invest time in keeping the code malleable at all times.

When I asked my interlocutor to name some of the agile practices, the only one he mentioned was morning ten minute stand-up meetings. Questioned as to how it was determined if the day's commitment was achieved, or not, there was no answer. (Expected Answer: unit tests that pass.)