At some point someone made a promise. Now the team is in a bad position and struggling hard to meet the deadlines of the original plan.
I’ve been in that position more than once, and as a Scrum Master I have used the same strategy:
- Working with the customer to lower expectations and make the plan more aligned with reality.
- Find more time for the team to do its work.
The second part would make me cancel everything not immediately helping the team accomplishing its short-term goals. The retrospective meetings were always the first thing that went out the window, and I felt like I was helping the team by doing it.
That was before the first rule of holes was brought to my attention (by Henrik Kniberg).
The first rule of holes: When you’re in one stop digging.
That wonderful quote by Molly Ivins really got me thinking. To bring a derailed train back on track, the solution is not to make the engines run faster. Instead we need to make a careful evaluation of the situation, and find solutions that will help us achieve the end goal of getting the passengers and cargo reach its destination on time.
In software development terms, when the going gets tough, we need our retrospectives the most.
Another way I’ve violated the first rule of holes is the thing I wrote about in my previous post. Although I know that automated tests is one of the best ways to increase productivity, I came up with all sorts of excuses why “it wasn’t for us”. So, I’ve let my teams dig deeper holes and making a bad situation worse.
Yet another common violation is the building up of technical debt. We’re so busy digging for new features that we forget that we have to be able to ascend from the pit. We need to stop digging and clean the small messes before they become drainers of effort.
What holes have you created or ended up in? What did you do about it? I’d love to hear your stories.
Cheers!
I’m back from my summer vacation. I try to take a long holiday every year and stay away from computers, be with my family, visit interesting places and, of course, read books. Summer is the time of year when I take my reading habits away from the toilet out to the hammock. Time is still scarce but this year I managed to finish five books, mostly in a horizontal position.
As you may know I keep personal logs for almost everything, including notes on the books I’ve read. Now I decided to take that habit and make it public, something I’ve been meaning to do for a very long time. For that reason I’ve set up a new sub domain, reviews.hans-eric.com, where I’ll publish such notes. It won’t be fully fledged reviews, but short posts that primarily reflects how I found the book (or the movie, or whatever.)
Here are four of the books I read during my holiday:
If you’re interested in following what books I read (and what movies I watch,) subscribe to my reviews feed.
Cheers!
As a programmer you are the ultimate software development tool, and like any tool you need regular care to stay effective. If you don’t invest enough in self-improvement you’ll end up useless, with a blunt sword. I’ve seen many programmers wielding blunt swords, unable to fight their ways out of old habits and paradigms. Don’t let that happen to you. Sharpen your sword regularly.
First and foremost you should take good care of your body. Health is the most important property, and it’s achieved with exercise, nutritious food, and enough sleep; The hallmarks of software developers. 😉
The second most important sharpening activity is constant learning. If we stop learning we become frozen in the slice of time we call life. So try to learn something new every day.
For me, the best way to acquire new knowledge is by reading books. Since I spend so much time in front of the computer screen, a book is a welcome break. I can bring it and read it wherever I want, including the bed and the toilet.
Acquiring knowledge is one thing, making it stick is another. If you want to keep your knowledge for a long time, you should practice. The most effective practice is to teach others what you know. Gather your workmates and hold a lecture, or write about it on your weblog.
If your company allows it, or if you’re lucky enough to have spare-time, make a hobby project. Try to implement something based on your new knowledge. Rereading is the worst kind of practice, but something I resort to sometimes.
My most used whetstones are reading, writing and running a million hobby projects. What are yours? Which ones would you like to have? It doesn’t matter how you do it, as long as you keep your sword sharp.
Previous posts in the Tools of The Effective Developer series:
- Tools of The Effective Developer: Personal Logs
- Tools of The Effective Developer: Personal Planning
- Tools of The Effective Developer: Programming By Intention
- Tools of The Effective Developer: Customer View
- Tools of The Effective Developer: Fail Fast!
- Tools of The Effective Developer: Make It Work – First!
One of my favorite quotes comes from Ron Jeffries on his blog Hot Needle of Inquiry:
“the river is moving, and if we don’t keep rowing, we are going to drift back downstream”
The quote reminds me of the importance of self-improvement. If we stop learning we are nothing but dead material in the stream of life. Ron seems to have stopped updating his blog, which is sad because it was one of my favorites.
Today I read a really interesting post on Debasish Ghosh’s blog. He shows how you can get object-orientation in a functional language using closures. I knew it could be done, but I hadn’t seen it in code before. Neat, but I received the real learning opportunity from one of the comments, in which Gabriel C. states “LOVED the Koan”.
I didn’t have a clue of what a Koan was, but Wikipedia came to my rescue:
“A koan is a story, dialog, question, or statement in the history and lore of Chan (Zen) Buddhism, generally containing aspects that are inaccessible to rational understanding, yet that may be accessible to Intuition.”
Thank you Debasish and Gabriel, you made me exercise rowing today too.
I just finished reading The Google Story, by David A. Vise
. I can’t say it’s a great book. Some parts are terribly boring, stuffed with uninteresting facts and examples. But there were chapters that made me long for my next visit to the toilet. Here is the list of things that caught my attention:
- Larry and Sergey built their product first and raised money later. It’s so much easier to sell your idea if you can back it up with a real and functioning implementation.
- The two founders didn’t start with their eyes on the money. In fact, they had no idea how to monetize their search engine in the beginning. Instead they were focusing on providing the best search experience they could. The focus on usefulness is what laid the foundation to their success. People noticed, trust was built.
- A Google employee (a Googler) are free to spend one fifth of his time at work on a private project of his own pick. One day each week, free to spend on anything that interest you. You’re not just free to do it; you are supposed to do it. It’s your job.
To me that sounds just like employee heaven, but the employee is not the only winner. Some of these private projects grow and end up in valuable products for the company. Just look at the wide range of services that Google provides, many of them started out as private projects.
- Google takes care of it’s employees. Free healthy food and day care for my children would make my life so much easier. That’s another win – win deal between you and your company.
If I ever get to build my own start-up, I will use Google as my template.
Cheers!
I am a very busy man. I have a full time job as a project manager and software developer. In my spare time I am an freelance journalist, writing articles for a Swedish computer magazine. On top of that I am a caring father of two lovely children. Needless to say, spare time is scarce.
Both my job and my writing, as well as my wellbeing, require constant learning. The most convenient way for me to accomplish this is by reading. I love reading books. Tech-, popular science and fiction books – I devour them all.
The only problem is when to do it. I am always busy, either with work or with my family. But the optimizer in me has found a solution: I read while in the toilet. Tech-books are especially well suited for toilet-reading. They are usually well structured and have relatively short chapters. I tend to keep at least a couple of them lying within range.
Of course, I sometimes take unnecessary long time doing my needs, and sometimes my wife complains about it. But you know what they’re saying: a man’s gotta do what a man’s gotta do.
