Saggy Pants and Pointy hair: Motivating Teenagers and Bosses

I have a very unique situation. I have been climbing the executive ladder for years and finally reached the executive level. Recently, I moved into an individual contributor role where I try and influence an organization for change from the side of the organization, instead of from the boss position. It is a very challenging, role but at the same time very fun.  Trying to figure out  how the organization operates,  how it changes and what motivates it to change.  I also have another unique situation in that I have 10 kids. That is not binary for 2. That is the number TEN, and having a blended family with that many kids feels much like my job. Influencing the children with different ages from 5 to 23 years old, is just as challenging as helping an organization through change.  I have found some interesting comparisons:

Family	Work
One child can make an 8 hour road trip to grandma’s house completely miserable for everyone.	One person can torpedo the role out of the greatest process improvement.
What motivates my 5 year old son, does not work for my 17 year old sons.	What motivates the CEO is different from  directors, managers and individual contributors.
Not everyone can be heard at the dinner table when everyone is talking at the same time. But everyone wants to be heard.	Some of the best ideas for change can come in the ranks of the organization. At all levels.
Mom and Dad need alone time as often as they possibly can to recharge.	I got nothing here.

I would like to look specifically on what motivates. I am starting to understand what motivates my 5, 6 and 7 year olds. Treats and trips to the park. My teenagers are a bit harder, but it mostly has to do with electronics. My older kids are motivated by pure cash mostly because they need it for college or fixing their car. Organizations are somewhat similar and finding out what motivates individuals is key to effecting change. So what motivates you, your boss, or your boss’s boss?

Individual Contributors - Money is a good motivator for most individual contributors, but that is typically only the case if they feel they are not being paid enough. What I have found is a better motivator is, do they enjoy their work? Is it fun, is their voice heard, can they make a difference?  For some it might be the camaraderie of working in a great team.

First-line Managers – Many first line managers want to be directors and they want to climb that leadership ladder. So they want to make sure their team is successful according to what their director or senior manager wants. They are trying to make sure that themselves, and their teams, look good. They are building their careers. Then there are some first line managers that want to stay where they are. So they want things that are stable, quiet and secure.  When trying to effect change with first line managers you need to find out the type of managers you are dealing with.

Directors and Senior Managers – Power and influence. This is all about your team. The more successful your team is the more successful you are in the eyes of the executives. You have influence over more people, budgets and schedules. Being able to predictably deliver products or services from the organization is the key success factor of these people.

Executives – Motivators for public company executives are very different than motivators for private companies. Public companies live and die on quarterly revenue and profit.  Private company executives typically are motivated by long-term sustainable profit. How is a change in my organization going to affect my revenue and profit this quarter for public companies or longer for private companies? This of course is not always true and there are some executives with other motivation than the bottom line, but again you need to find out what motivates or de-motivates an executive to change.

Of course these are sparkling generalities and cannot be applied to every organization. The key is for you to find out what motivates people to change in your organization. Write it down. Then develop a plan to motivate your organization at all levels.

DWP

Rock Quarries and Build/Test Farms

When I was a teenager, I had a friend whose dad owned a rock quarry. They mined for aggregate that is used to make concrete, backfill for roads, and building subdivisions. It was a small operation, but for a teenage boy it was very cool. Large machines with conveyer belts, crushers, screens, and shakers. The engineer inside of me was fascinated with how it all worked. You dump in a truck full of what looked like dirt and rocks into one side of these machines and out on the other side came rocks of several different sizes, dirt and silt. The silt mixed with water made some of the best mud football games you can imagine.

The image of these big machines came to my mind when I was talking to a couple of engineers tell me about our software build, release and test system at work. The source code goes in one side and our product comes out of the other side. And in our case more than one version of the product targeted for different Operating Systems and or configurations. One of the things they were complaining about was the amount of time it took to find out if their changes broke the build or made it past all of the tests in the test farm.

Over the years the amount of tests run with each build has increased and the number of configurations has increased. This has made the turn around time hours instead of minutes as it used to be. The engineers I was talking to were complaining that they wanted instant feedback and could not wait hours to see if what they just typed in was going to bring the whole organization down or but the “magnus opus” that they believe they just created. Our build and test farm becomes overwhelmed when we are close to a release date and build results end up taking days instead of hours.

Again the big machines at the quarry came to mind again. I could see the huge screens, shakers and conveyor belts. I could picture how the first convey belt moved the dirt and rocks up to the top of this tower with conveyor belts coming off in all directions. The dirt then would be dumped into this very large screen big enough for almost everything except for large rocks about the size of large potatoes. These large rocks were sent down a conveyor belt to a crusher that then smashed these rocks into smaller rocks and then dumped that back into the top of the machine. The next set of screens would be smaller and let everything pass through except for rocks the about ¼ the size of the previous screen. In this case the conveyor belt carried these rocks to a big pile next to the tower of machines. This continued on until at the bottom of the stack silt was conveyed out to the silt pond. Did I mention mud football already?

I could see what the engineers were wanting. They wanted to know if their build had big rocks or boulders in it first. They needed a quick feedback smoketest. Well we already had that. But they also wanted the aggregate screen. They wanted product out before everything was screened through the system. So I did what most good engineers do I went to google and looked at the different levels of testing. I found a good powerpoint that shows the canoical view of levels of testing. http://www.cs.swan.ac.uk/~csmarkus/CS339/presentations/20061202_Oladimeji_Levels_of_Testing.pdf. Simply it can be desribed as.

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
• Regression Testing

As I kept looking further in my organization I found, Interesting enough, many of the groups started doing placing screens in their build/test systems themselves in an ad hoc manner with CI build systems. Jenkins and Berta seem to be the most popular. As I went around and talked to more teams and more engineers I found one group in particular that had the same vision of the rock quarry as I did but had it in Software build and test.

This group had set up a CI build system that took each check in and pushed the build through several screens of tests to see the quality of the build. They had 5 levels of testing that would occur with each build. The screens became mroe fine grained and would take longer to run at as the source and build would go down the stack. There are a number of screens that can be put in place to give the engineers a quick feedback loop that they are looking for. The key is to time bound the first level of screens. Using a mixture of the levels of testing to give the first screen nice coverage of build and give immediate feedback to the developers. Here is an example of how a nice build/test screen could be set up.

< Time	Name	Build	Test
10 minutes	Smoke Test	Incremental	High level integration, some unit testing
30 minutes	Check In Regression	Build from Smoke.	Unit Testing for CheckIn
1 hour	Integration	Full Build	Integration Test, Regression Tests
3 hours	Performance	Build from Integration	Performance Tests
6 hours	Nightly	Build from Integration	Integration Tests, System Tests, Unit Tests
36 hours	Weekly/Weekend	Build from Nightly	Full test suites. Performance

This of course is just an example of what could be. I think it is important to put a plan together on how the build progresses through the screens and in some cases the build is performance more than once on the same code base. Coordination between Validation and Development is key to making this work effectively.
Let me know what you think. Do you have any other good ideas on how to give development feedback quicker without sacrificing the quality of your product.

DWP

Drag Co-efficient of Software Development

The drag coefficient is a number that aerodynamicists use to model all of the complex dependencies of shape, inclination, and flow conditions on aircraft drag. This equation is simply a rearrangement of the drag equation where we solve for the drag coefficient in terms of the other variables. The drag coefficient Cd is equal to the drag D divided by the quantity: density r times half the velocity V squared times the reference area A. . . .

This equation gives us a way to determine a value for the drag coefficient. In a controlled environment . . . we can set the velocity, density, and area and measure the drag produced. Through division we arrive at a value for the drag coefficient. . . . [T]he choice of reference area (wing area, frontal area, surface area, . . . ) will affect the actual numerical value of the drag coefficient that is calculated. When reporting drag coefficient values, it is important to specify the reference area that is used to determine the coefficient. We can predict the drag that will be produced under a different set of velocity, density (altitude), and area conditions using the drag equation.

—From the NASA Glenn Learning Technologies Project Web site, http://www.grc.nasa.gov/WWW/K-12/airplane/dragco.html

How do you reduce the “drag coefficient” in software development? Well, the best place to start is to determine what is slowing you down. Much like an Olympic swimmer training for a race, software teams need to find ways of reducing the amount of friction pushing against their momentum—what is affecting overall cycle time—by optimizing their performance. Professional swimmers are constantly tracking performance metrics, identifying food and exercise variables that may affect their strength and endurance. They may occasionally resort to shaving their bodies, wearing compression suits, and changing their strokes as ways of minimizing their own drag coefficient. It takes dedication to get through the barriers that come with Olympic swimmers.

The same is true in Software Development Productivity. As software development professionals we need to look at our own productivity as well as our group and organizations. Just like swimmers knowing how to measure improvement is the first step. Second is knowing where to look to find improvements in productivity. Third is being self-aware enough to see what you typically don’t see.

First, metrics to measure productivity. Of course there have been several studies that measure LOC(Lines of Codes) per day, Defects/LOC, Story points, burn down charts, velocity, etc.. The list is long and can be confusing. So I am not going to add to the confusion except to say what ever you pick be consistent. Gather the metrics in the same manner each time you measure. Add additional metrics as you need to. Remember that time should be part of what you measure. Lastly, watch for trends and correlate them to changes that you make in your processes or tools.

Secondly, knowing where to look is a big deal. You can spend several weeks, months, or years looking at the wrong metrics, or focusing on something that doesn’t improve anything. My hints on this would be to look at the scope of where you are trying to optimize.

1. Personal change - There are some good resources for looking at your own personal software development process. The one that appears to be most eye opening to my is the Personal Software Process. It helps you look at how much time you spend doing certain tasks for get work done, Designing, Coding, Debugging, Building, etc... When I went through the exercises I found I was highly dependant on my compiler to find trival typos and coding bugs instead of just taking an additional 30 seconds to look first. I suggest reading through the book and taking the exercises.
2. Team Change - Areas that you can look for team productivity improvements can start with the interactions that you have with the other individuals in your team. This includes, meetings, code reviews, build times, defects, sprint backlog, velocity of task work, Build/Debug/Fix/Build turn around times. The benefit of working inside your team to look for areas of improvement is your team is relatively focused on delivering the same component/library. You all want to succeed together and the problem is typically scoped to a small number of people.
3. Organizational Change - When I talk about organizational change I am specifically targeting multiple teams integrated together to deliver products to the market. In this case most of the performance improvement has to do with team interaction, component and responsibility ownership, and communication channel effciency. So looking things like Defect assignment, Stakeholder decomposition and assignments of tasks to component groups, Number of integration build failures, Number of defects per Integration build, etc... The key here is to focus on how to improve the coordination of the work across all of the individual teams and the integration of such work.

Lastly, Is to be self aware. This is probably one of the hardest things that individuals, teams and organizations need to do to become truly effective. So let’s look at the swimming world to see if there is anything we can learn in the software world. Swimmers have used very complicated water tunnels to analyze their strokes. Although these have given some feedback, the most cost effective has been underwater video cameras. When swimmers can see how they look underwater they can make adjustments to their strokes and look at the effects those changes have on their times. Coaches can see and help swimmers but seeing it personally helps them understand what they are feeling in the water and what it looks like.

So how do we become more self aware developing software products. I don’t think setting up cameras in our cubes is going to help. But one method we might want to look at more is internal audits or assessments. If we look at this as ways to help us, instead of trying to just meet a criteria we can use the results to become more aware of our drag co-efficient. Even if we are doing a self audit like the PSP suggests. They all help us become better software engineers.

Who knows maybe we should do like the swimmers do and shave our whole bodies and wear compression suits while we code. But I dont think that will decrease the number of bugs I produce per LOC. :)

DWP

Changing your organization with the Stomach Flu

The Christmas holiday is always a time to meet with family and friends. This year was no different for me and my family. I had 2 of my daughters come home from school, one toting a fiance, (A blog for another time). Late night games with the older kids, early morning games and movies with the little kids. I wish they would get on the same schedule. The second half of our Holiday was spent at my parent’s house in Southern California. We arrived late on a Monday and my sister and her 5 kids where staying with my parents for a couple day overlap with us. Imagine all of those kids and adults in one house. Lots of fun lots of games, great conversation, and the spread of the stomach flu. Isolation was out of the question. Too many people and too little space to control it. It traveled like wild fire.

It started early Tuesday morning with one of my sister’s kids. Zero sleep for her and her husband. It quickly infected two more of her kids. Before noon on Tuesday 5 people were worshiping at the porcelain throne. Thankfully none of my kids had gotten it. We had can of Lysol  and anti-bacterial soap all over the place. We were fighting off this horrible unseen creature named viral gastro enderitus. None of my kids got sick on Tuesday and Wednesday was looking good. Until about 3pm on Wednesday when my youngest a 5 year old boy named David told me he stomach was feeling funny. With in 30 seconds we had a mess to clean up and a very sick little boy. 45 minutes later the next victim my 6 year old son. By 9 o’clock that night 3 more kids had already fallen to this nasty virus. My wife and I were the clean up crew and knew it was just a matter of time. By Friday morning when we were heading back to Northern California everyone but myself and my oldest daughter had or were still being effected by the stomach flu.

Of course the 500 mile 8 hour trip to Northern California took 11 hours because we had to stop several times. We were well equipped with throw up bags, ginger ale, and wet wipes, but we could only drive so far before we needed a break. In a very daring move my oldest who had not gotten sick taunted the virus when we stopped for lunch. She ordered the greasiest lunch she could find on the menu and said she wasn’t going to get sick. With in an hour on the road after lunch we had to pull over. It was like the virus heard her taunting and made her pay.

In the end this fast acting virus infected 30 people within a week including all of my kids, my sister and her kids and about 5 other families. So what does that have to do with anything about change in an organization? Let’s take a look.

Many of the effective changes to culture or process in an organization happens organically. It is very much like a virus. It replicates and spreads quickly and without prejudice. So let’s look at some key aspects to this virus and how it might be mimicked in organizational change.

1. It must spread quickly - When you have a change you want to make to an organization make sure that you can get it to spread quickly. Sometimes if you phase in your change it never takes hold in the organization. You may need to break up a large change into smaller chunks that are more acceptable to the org. We don’t want to kill the org we want it to be stronger after the change.

Have a plan in place. If you have multiple locations make sure that the change spreads in all locations at the same time. Otherwise you can easily get push back from one location that had not been “infected” yet. Make sure you find out who is most likely to spread the change around the most. Just like the virus attacked the youngest in my family first. You know the ones that don’t wash their hands and touch everything. You need to find the people in your org that evangelize the changes and aren’t afraid to spread it around.

2. It must overwhelm defences - Find out who has the lysol and overwhelm them with the change. Everytime you have a change there will be people that will push against it. It is human nature to keep things the same. Change is hard for people and the longer something has been the same the harder it is to change. So find out who is subverting the change and bring them on board. Let them know that the change will benefit them in the long run. If that doesn’t work then you need to surround them with peers and friends that have already been infected. And last measure and least desireable is to mandate it from above. Work with their manager to help them understand the benefits of everyone getting on board. Again last resort is to do this.

Another way of overwhelming an organization with change ties into spreading it quickly. The fast the better. Hit them fast and hard. Make sure that you have your supporting documentation, evangelists, and marketing talking points ready for the change. If you are in the middle of the change and still trying to come up with this you are too late. You need to make sure that you disseminate the information as fast and as in depth as possible. you need to overwhelm the organization. They need to see that the change is inevitable.

3. Close proximity increases the spread - I am sure if I didn’t take my family down to my parents house we would not have gotten that flu. We had to be exposed to it. We had to shake hands, eat dinner together, have fun together. This is the same in your organization. You need to get personal with your organization. They need to know that you have the best interests of the organization first. You need face time with your team and the key players of the team both your evangelists and your taunters.

If your organization is multiple geographies. Which in large organizations tends to always be the case. You need to make sure that you spend time in all of your locations and you need to get evangelists in all of your locations to help spread the change. You also need to identify the taunters and understand their concerns to help them overcome thier resistance to the change.

4. Infect the taunters - My daughter thought she had it beat. She tempted the virus and in the end the virus got her. You need to find out who in the organization will be or currently is most against the change. Identify and then use the overwhelm techniques described above. It is best to surround them with people they trust that have already accepted the change. Don’t leave this to chance. You need to work hard and see how the change is spreading and identify them quickly.

5. Make it viral not bacterial - Doctors have told me that if I have the virus it just needs to run its course, but a bacterial infection can be fought with antibiotics.  So what are the antibiotics of organization change. One of the most effective is upper management. Make sure you have upper management support for the change. Make sure that they stand up for you when the taunters come to them and complain that they don’t want to change. If upper management won’t stand or waffles on the change then the change is at jeopardy of not infecting the whole organization and you get bifurcation of the org. This then starts the multi-camp yours and mine mentality that can destroy an organization.

Another aspect of viral infections is that the host cells are used to produce more virus. You need this to happen with your change as well. You evangelists are key to this. They need to recruit more people to push the change in the organization.

Of course there are always those that will one to get their flu shot to prevent from getting the virus. Just like a virus your change needs to be able to mutate to infect the org. Good luck trying to figure that out. That is what makes you a great change agent.

Good luck infecting you organization with change. Remember if you don’t want to get the stomach flu yourself. stay away from people that have, wash your hands often and keep your hands away from you mouth. BTW, I was the only one in the house that didn’t get the virus. I think it was just dumb luck.

DWP

A Case for Software Coding Standards

I have had the unique opportunity of co-authoring three books. Each book was very unique in the way that it was published. As you would expect, by the time the third book was published, it was much easier than the first. However, you might be surprised why that was the case. Let’s take a look at what happened.
In 1999 I began co-authoring magazine articles for Rose Architect, a small magazine that talked about all things Rational Rose. This quickly grew into writing for several different trade magazines and publications. The main topic of the articles focused on software development tools and processes. After about 50 articles, my friend and co-writer, Christian Buckley and I decided we should put these together in a book. What an endeavor!
Our first decision was to self-publish the book. We found a printer, designed the cover, decided the size of the book. ( There is no standard size for technical books. They are all different sizes.) We gathered all of the articles together, categorized them and divided them into chapters. Next, we wrote introductions and conclusions for the chapters, transition paragraphs, a preface, a conclusion chapter and even rewrote some of the articles.
We had all of the content, text, graphics, bibliography, everything we needed for a book. We then spent the next 4-5 months working on the format so it was consistant and would fit on the size book that we wanted. We spent more time formatting and moving graphics, so they fit on the same page as the text, than we spent writing the content for the book. Our grand masterpiece finally went to the printer and we had the book in hand. Secrets of the Change Agent: Strategies for Software Development was born and we were the proud parents. Of course you can buy our book on Amazon. (Shameless plug)
Although the book did not make us the JK Rowlings of software engineering geeks, it did land us a book deal with a real publisher, Addison-Wesley. They wanted us to re-write our book to focus on Rational ClearCase Deployments. More specifically, how to use a system engineering approach to deploying ClearCase environments. This was the beginning of our next book: The Art of ClearCase® Deployment: The Secrets to Successful Implementation.
Now that we had a real publisher, we had to fit our writing style into their templates so their printer could automatically take the book and print it in their standard sizes, standard fonts, and font sizes. It took us sometime to learn the new template format and since much of our content was written in a different format, it had to be converted. Looking back we probably spent about 1/3 of our time formatting this book into this well defined standard from the publisher.
Within months of our book hitting stores, Addison-Wesley commissioned us to write a third book. This time on another tool from IBM-Rational. The tool was ClearQuest. There wasn’t a book out there yet on the tool and they liked the perspective we used in our other books. I had used the tool before, but was not an expert. By the end of writing the book, I would be.
We wrote the book from scratch. Nothing had been written before hand. We started with the template that Addison-Wesley gave us and started writing. Something amazed me this time. I spent no time at all worrying about formatting. I was already familiar with the writing standard and template they gave me. It was like second nature writing in that template. I focused all of my time on writing content for the book and making sure I understood the tool well enough to write about it. The book only took us six months from the first time we started writing to the time we were at the printers, three months shorter than the previous book. Our book: Implementing IBM® Rational® ClearQuest®: An End-to-End Deployment Guide is still considered the definitive guide to deploying Rational ClearQuest.
So what does this have to do with anything? I found it interesting that the final product was the same, a book. But the effort and time I spent on the actual content of the book compared to the formatting and style of the book overtime decreased and the quality of the book increased. My focus in the last book was the content. All of my creative energy was spent on the things that mattered, the content not the format, font size or color of the book.
I have found in my career when there is a well defined coding standard, development process, and tool chain, software engineers produce higher quality code in a more predictable manner. Their creative energy is focused on delivering the product not on the process of delivering the product. When teams have an ad-hoc coding standard, process and tools, the engineers tend to spend valuable time figuring out trivial things like: where to indent their code or what tool to use to share their code with their team.
Just my random thoughts.
DWP