Johnny Knapsack's story in the 15 Second Principal by Al Secunda is insightful.
| Johnny Knapsack grew up in a small Midwestern town. He was a tall, lanky lad with long, skinny legs. He got his nickname because every day he'd walk to and from school carrying a load of textbooks in his knapsack. One day, on his way home from school, an upperclassman named Chuck challenged him to a race. Before he could refuse, the race was on. Johnny had no expectations of winning, however, because Chuck was the fastest man on the high school basketball team. You can imagine Johnny's amazement when he beat Chuck to the soda shop. Word soon spread about his accomplishment, and from that day forward, life was never quite the same for Johnny. Every day after school, someone else would challenge him, and every day, without fail, Johnny would win. |
The story goes on to describe how Johnny keeps running with the same heavy knapsack on his back and winning every single race till he reaches one of the most important race of his life - the Olympics trails, where he loses by fraction of a second.
When advised by American coaches that he could have easily made up the split second difference and won the match had he not carried the heavy knapsack on his back, Johnny replies:
| "Everyone kept telling me to take it off," Johnny replied. "But I always kept winning. I was just following my father's advice - never change a winning game and always change a losing one." |
The coaches response to Johnny's reply is soul-stirring and applies to a lot of us; not just in our lives but in the way we run our projects as well:
| "The coach responded, "Johnny, you are so fast and gifted that you have been winning in spite of the knapsack, not because of it. Your self imposed handicap finally caught up with you in this national event." |
In multiple organizations, client offices and development shops around the world I see programmers carrying knapsacks of their perceptions on how successful projects aught to run, on their backs.
Every now and then it is not un-common for me to come across a business analyst who believes that a twenty page login use-case just has to be written or a test lead who believes that a twenty page login test case has to exist, or a developer who refuses to code without a detailed lengthy low level functional specification document, irrespective of how simple the system is.
When I started moving my teams to Agile in some of my older projects and client offices, I would see a few developers panic with the idea of not having Dead-lines and Gant-charts. Some who had never shipped, because they changed job faster than typical Big Design Up-front Projects are usually delivered, were concerned with the whole idea of shipping every month.
A young enterprising tester complained that as a project manager I should estimate for him and give him deadlines instead of having him estimate for his own tasks. Another developer kept complaining that we didn't have detailed project wide documentation and if someone left, the project would be in a bad shape.
We continued to have folks fully involved in estimating for their tasks and people (including the developer who was most worried about people leaving) did leave smack in the middle of the project but the project ended with a very successful implementation and a very happy client, way before the expected end date. By the expected project end date we ended up delivering way more features than promised because agility had lightened the heavy knapsack we were carrying. Some of us, had seen the light.
Even now, as you read this, countless development shops around the world are focused on have enterprise wide project processes, practices and methodologies which every team in the organization is forced to follow.
With software development, the whole idea of carrying knapsacks on your back as you run is lethal and yet very common. We are handed over the knapsack on our first race, usually by our first organization.
Johnny's story however, has a happy ending:
| "When Johnny arrived home, he kept thinking about what the coach had said. He decided to experiment by running the next race with one less book on his back. To his amazement, he won the race in record time. In each subsequent race, he kept lightening his load by taking an additional book out. Finally, he was running and winning with an empty knapsack and then without the knapsack at all. He had learned his lesson." |
Just like Johnny some of us are lucky enough to see the light and lighten our knapsacks as we move forward. For others though, every race after that is essentially a replay of the first one where they carry the same heavy knapsack of their processes and methodologies on their backs.
Whether you are following CMM, RUP or Agile, always keep asking yourself: Are your processes and practices adding genuine value or are they just added items in the knapsack you are carrying on your back? If they are just added items which are slowing you down, consider lightening your knapsack before you lose your most important race.
I leave you, dear reader, with questions worth harping on - Are your projects really successful? Are they successful because of your processes or in spite of your processes? Are you just following what traditional project managers and your older organizations taught you, just like Johnny followed his father's advice?
Comments are closed.