douglas

Doug Shimp

My Story And My Journey Towards Scrum and Agility

By Doug Shimp

I have had an interesting Journey. From painting as a boy, working through college and graduate school, to software development, being a dad & husband and to training and coaching at 3Back, my life has brought me to this point. Here’s my story…

For me, Scrum has been a pathway to understand agility and how to make teams better. ‘Agility in all things’ is a phrase that I like. It reminds me that most of the interesting work we do requires some amount of agility and that interesting work often requires a good team.  For me, Scrum is an agile pathway to better teams that can do interesting work. I have applied scrum on projects and coached others to apply it. Coaching and training in Scrum has taken me on a wonderful journey. I have had an opportunity to work across many different industries and have been exposed to a myriad of development efforts.

Working on this book has helped me refine my understanding of Scrum. The book reveals how I apply it to problem solving for my teams. Every conversation and recommendation has been field-tested multiple times and applied to many different domains of development. Each time ideas were applied they were either polished further, removed or were found to be irrelevant in context. While the descriptions in the book are far from complete, as a ‘unified theory’ type of thing, I have found it to be very useful for my teams.

Recent History

People often ask me about my history and how I came to see things as I do through the lens of Scrum. Even though I first heard about Scrum in 1996, I like to tell my history by starting with today and working backwards.

I have been teaching, training and/or coaching teams in Scrum for the last eight years. Each year has brought me something new and provided new insights. I founded 3Back in 2004 with a focus on Scrum and the motto ‘We Make Teams Better’ (I was helped immensely in doing this by Derek Wade, one of the most brilliant people I’ve had the pleasure to work with). Each year has been an adventure in exploring new companies, working with existing ones and finding better ways to apply Scrum. People often ask me, “Is there something else besides Scrum?” or “What if X?” My answers are always, “Yes, of course, but Scrum just happens to be one of the cleanest methods I have seen. Scrum helps teams get better faster. Scrum can scale. Scrum can work in distributed environments. Scrum is proven.  Scrum will probably work for you. Your Scrum will be different.”

Before working at 3Back (Senior Consultant / Partner), I was a Director of IT, a Manager of Software Development, Methodologist and Developer (Smalltalk, C, FORTRAN, etc.). I had the pleasure of working in the financial industry and applying the concepts of Scrum. At that time, we did not apply Scrum anything like I do today. However, in hindsight, we were effective when we behaved Scrum-like. Sometimes we used heavier upfront methods that invariably brought things to a halt. This was done for lots of reasons, but the classic reason was ‘we need to get everything perfected up front’ before we move. The ‘get everything perfected up front’ approach would fail like it always did and we would go back to my favorite method of ‘Just Get Stuff Done’. My boss and mentor in this was Sal Miosi, who is my favorite boss of all time. Sal taught me the art of brevity and focus. I have rarely encountered someone like Sal. Sal had an iron hard focus on reducing things to the point that they were simple and easy to accomplish. Sal’s lessons have stuck with me.

Influences on Me

My family: my wife, my children and my friends … they ground and help me connect every day.

Sal, more than any other person that I have worked with, has an ability to focus despite chaos. Sal was the only person I have known to relentlessly write his messages and thoughts over and over until he could distill them down to a few small concise sentences.  Sal used his concise messages to focus teams and work.  Even though there might have been half a dozen directions we could go next, Sal would choose one and keep us moving. As a Product Owner, Sal’s gift was the ability to focus effort. As a ScrumMaster, Sal always encouraged behavior that took the ‘high road.’

Ken Schwaber was a big influence on me, as he encouraged me to look at emergence in a different way and brought me close to Scrum. Ken says that he believes in emergence, and now I know what he means and why it is so pivotal to his work in agility. Ken also made it possible for me to start my journey into Scrum. I cannot thank Ken enough for both of these things. Ken is brilliant and his work continues to inspire me.

Another big influence on me is Dan Rawsthorne, my co-author on this book. Dan has constantly given me lessons in adaptive thinking. I could say agile thinking but it is not so much quick or nimble as it is building a ‘model of thought’ by constantly adapting to new information and constructing and reconstructing models to fit. Dan and I have had dozens of conversations that move from one subject to the next, often our conversations have challenged me to unhinge rules I had built for myself. Dan sees things from so many different angles. From agility, to methodologies, to raw analysis and pure math, Dan has improved my thinking in every single way. This book exists because of Dan’s herculean effort to write up our accumulated conversations. And this book was possible because we had those conversations. Thank you Dan!

A longtime friend of mine is Ed Porter. Ed was the first person with a ‘pure math head’ that I ever met. He is incredibly strong at mathematical thinking. When it comes to object-oriented thinking and breaking problems down, Ed is the first person that comes to mind. He took the time and made the effort to help me master objects in Smalltalk. Ten or more weeks of relentlessly working, reading, coding, and applying it finally got me to say ‘ohhhhh’, the rest of our time is historyJ It seems to me, there are a few folks who are born wired to think with objects and the rest of us must learn to think that way.

I also learned a lot from Chemistry, believe it or not. The two major lessons chemistry taught me was to stay flexible and humble because, the universe is so complex.

  • The first lesson from chemistry is small molecule spectroscopy.  Doing work in small molecule spectroscopy as a summer intern showed me that the amount of data that could be generated from the smallest molecules can overwhelm the computational power of the planet. There is more data than we know what to do with so we must learn to ask the right questions first. Just because you have a pile of data doesn’t mean you know anything – it could be the wrong data.
  • The second area of chemistry that greatly influenced my thinking process was protein crystallography, which I worked on in graduate school. Proteins are large, sloppy molecules that are always breathing and moving through time. They never stop! To understand a protein you have to realize that nothing about them is static, actually nothing at all is really static. Everything is moving through time and changing. What a mess … Cool!

Painting

The first time I really learned how to estimate was from painting. I started painting when I was 14. I used to time myself in everything and write down notes. My first indoor painting job (in Wisconsin where I grew up, indoor work was ideal during the winter months) was a big lesson in estimating. I bid the job for painting the inside of a house. I offered to move everything in each room of the house, offered to use the best paint, and went to work. The end result was that I made about 8 cents an hour, well below the $3 an hour minimum wage at the time. My estimating really sucked on that one… ;-)

However, I did learn one important lesson, and that lesson was to finish what you start, and do a good job. My estimating may have been poor, but my work was good. My client on that first job referred me to dozens of her friends, and my estimating rapidly improved. Over time the business grew and my brother and I joined forces. Our company grew to 40 people working in the field, with union workers, industrial/commercial jobs and large projects – house painting became a thing of the past.

Here is what I learned about estimating from painting:

  1. You will never know exactly how long it will take until you are done;
  2. Actual costs of a job can help estimate a similar new job;
  3. Throughput on a big job becomes the best indicator of whether you will make any money; and, most importantly
  4. Estimating is relative.

You can size your job in anything: windows, T-shirts sizes, door frames, time, whatever… For smaller jobs these numbers become stable and reliable very easily. For large jobs, like painting the pipes in a coal power plant, it becomes tremendously difficult no matter what numbers you have, so all you can do is take a guess, begin somewhere, and start relying on monitoring throughput to refine your estimate.

Besides estimation, another thing I learned from painting was the ‘Definition of Done’. Anyone who has spent any amount of time working with their hands will have the ‘Definition of Done’ hard wired into their head. All tradesmen know ‘If you don’t know what Done looks like you will never finish.’ Knowing what ‘Done’ looks like is so important that it forms a recognizable pattern of thinking. Knowing ‘Done’ must be constantly enforced and reinforced. There are some simple questions you can ask to understand ‘Done’ when working on a Story or painting a wall, and they can be summarized by: “If it were ‘Done’, what would it look like to you?” When a good understanding of ‘Done’ is missing, projects both big and small fail or go sideways.

The lessons of estimating and done are crucial to agility, and I initially learned them through painting.

Self-Organizing Teams

There are two starter lessons on self-organizing teams that I picked while exploring. The first is that rapid fire micro direction of another person’s actions is often not possible and is not sustainable. And the second is rapid fire micro direction of the team’s action interferes with their communication patterns and destabilizes internal synergy. In both cases it aggravates the people involved and limits the intellectual power available for work.

Both of the above patterns lead me to the power of self-organizing teams. These patterns were reinforced with observations from painting, software development, management, training and coaching teams. I struggle to say more than that since this area is so subtle and tricky to describe.  Instead I will give a list of bullets to summarize a few of my lessons.

  • When working with teams you have to start with modeling the behavior pattern you want.
  • Set clear elevating goals. What is the overall job? What do we need to achieve?
  • Don’t micro direct unless you are a mentor. As a mentor, help on&off as they struggle to learn.
  • Struggling for mastery is central to learning.
  • Don’t be afraid to learn. Kindergarten skills over technical skills.
  • Good teams are learning all the time.
  • For scrum teams there are objectives, the Product Owner’s intent, their plan and reality.
  • Nurture your passion in what you do.  Help your teams nurture their passion.
  • Small rapid fire micro direction of each person doing work is hurtful.
  • How you deliver a ‘message’ matters especially with people!
  • Great teams are built by doing work together.
  • We are wired to connect. Help us do that and we can do amazing things together.
  • Make a habit out of reflecting early and often. ‘How is that working out for you?’

You would never tell an experienced plumber how to use the wrench, unless you wanted to wear that wrench on the way to the emergency room. Why would you tell an experienced developer how to code? The best way to get a job done is make space and allow people to learn. Great teams figure out hard problems and optimize themselves to get the job done.

Conclusion

At this point I will stop writing. There are dozens more lessons that I could write up and dozens more people that helped me grasp those lessons. My last lesson is ‘no head works alone’. I no longer worry about where I get an idea from or if I am smart enough. My ideas come from everywhere and every person that I have had the privilege of interacting with. Each interaction is an opportunity to learn and improve. Being on a Scrum team is a deeply personal social experience. Scrum has allowed me to accelerate my learning curve – it can do the same for you.