Monday, April 27, 2009

Software Evolution [John Levy]

There are some principles of software development that were described by M. Lehman by observing large-scale development teams (such as IBM’s OS/360 development in the 1960s). When you put several of these principles together, it is not very encouraging for those of us who are concerned about software quality.

1. Early bug rate predicts late bug rate
You would think that if you fix a lot of bugs early in the project, you could expect to have a lot fewer bugs later. In fact, observation shows that projects that have (and fix) an above-average number of bugs early tend to have above-average bug rates later.

2. Software grows over time

As users demand more features and functions in their software, the size and complexity of a released software package tend to grow.

3. Bugs are introduced when bugs are fixed

No matter how careful we are, sometimes we introduce bugs while we are fixing others. As long as the ratio of bugs-introduced to bugs-fixed is low, working on bug-fixing is a productive enterprise.

When you combine these observations, things get stickier. For example, the ratio of bugs introduced to bugs fixed tends to get larger as the software package gets larger. As a result, bug-fixing gets less and less efficient as time goes on because of the growth of the software.

Also, we can imagine that putting a major push on early bug-fixing in project could drive up the introduced-to-fixed ratio, thereby keeping the first rule valid – we’ll find even more bugs later.

What’s an Agile manager to do?

First of all, pay attention to bug-find rate and system size and complexity. My guess is that having the software developers fix their own bugs before QA sees the software doesn’t fall into the domain of the first rule. In any case, it’s a good thing to have a designer/implementer see exactly what went wrong – it’s a good opportunity to correct one’s thinking. Of course, Agile principles suggest that pair-programming does exactly this at the earliest possible moment in the coding process.

Second, always strive to reduce complexity, whether by simplifying the model, partitioning the system, or adapting to existing services rather than inventing new ones.

Finally, make sure that your teams are relentlessly refactoring the code. The teams always learn better and better ways to streamline and simplify the functions they’ve already implemented, so don’t hold back on letting them express that knowledge.

If you want to read more on how software evolves over time, do a search on “Lehman software evolution” and see what’s been learned.

____________________
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on managing development, Get Out of the Way, is due out in 2009. More info at http://johnlevyconsulting.com

More...

Sunday, April 19, 2009

New Tool: So, what’s YOUR problem? [Matt Schlegel]

The first step in any problem solving process, be it an ad hoc (“sausage”) process or a systematic approach, is to recognize that you have a problem. Problems themselves are the impetus for action and for change.
When the problem is felt across multiple groups in the organization - engineering, operations, finance, customer support, marketing, etc. – I find it particularly beneficial to take the time to document the problem clearly. You will find that this is an important step for team building, too.

So many initiative teams do not take the time to document well the problems they are attempting to solve. By not doing so, the team may find that they wind up solving completely different problems. I would characterize that situation as being “off track.” On the other hand, taking the time to document the problems helps the team stay focused on solving those problems. Also, the problem descriptions will serve as a metric for success: in the end, how well did the initiative team solve the documented problems. Here is how I have developed both problem and goal statements for problem solving initiatives. This important step generally requires two meetings held on back-to-back days.

Welcome the Whiners

The first step in this problem solving process is where whiners can shine. Invite them to kick off meeting. In fact, invite all the stakeholders to the kick off meeting. When I facilitate this meeting, I encourage everyone to vent, to describe the problems they have and the troubles these problems cause. This meeting can quickly become very animated as everyone starts to chime in describing their unique view of the problem. I frantically scribble down everyone’s comments on flip charts. Meanwhile, everyone has the opportunity to understand everyone else’s perspective on the problem.

What is happening here? I have noticed several things. Firstly, everyone is allowed the opportunity to vent, and that is a cathartic process in and of itself (I suppose it is like listening to Blues music.) Secondly, the team starts to have an appreciation for each other’s perspective, building up empathy within the team. Finally, I find that the team starts to find commonality in the problem – essentially, the team creates a common enemy. In this process, a bond is formed between the members of this group, a bond formed by the excitement and anticipation that they are embarking collectively to slay that common enemy.

The Beautiful World

The flip side of the terrible world about which everyone complains is the beautiful world that they imagine possible. Once everyone has had a chance to complain about the problem, I adjourn the group and reconvene the following day. At the second meeting, I ask every stakeholder to describe that beautiful world they imagine. You will find that some people find it easier to complain about the existing world than to create a new beautiful world. Some will even continue to complain, just because it is so easy and fun to do. Certainly, if they are introducing new problems unaired the previous day, these problems need to be captured. On the other hand, if they are simply re-hashing the same issues raised the previous day, these team members need to be encouraged to describe the “Beautiful World” with the simple question, “So, how should it be?” In allowing everyone to describe their vision of the beautiful world, themes will begin to emerge. These themes will serve as the goals for the initiative team.

Now that you have descriptions of the problems that the stakeholder’s face, and the vision for the world they would like to create, you have the information you need to formulate the goals for the team and the metrics for success. Vet this information with the executive sponsor for the initiative to ensure that these goals align with the direction that the sponsor envisions. Once you are satisfied that there is alignment, you are ready to move on to the next step: building the team to slay the common enemy and create the Beautiful World.

________________________
Matt Schlegel has helped clients build many beautiful worlds, worlds in which team members are aligned to accomplish seeming miracles. Some examples include shipping American made electronics into the Japanese market; Japanese companies shipping American made products as their own; and, bringing a company into compliance with environment regulations in record time so that product shipments continued uninterrupted. Perhaps the most beautiful world he helped create was the one that eliminated commercial advertisements from TV programming using a DVR.

More...

Wednesday, April 15, 2009

Your manager makes you agile [John Levy]

Can you make someone else be agile?

It seems impossible on first glance because “agility” isn’t something you can impose on someone else. And on second glance, all the training for Agile is focused on self-managing teams.

But when I think back on managers I’ve had and I ask myself what the best ones did that helped me to succeed, there are five characteristics that stand out. The best managers influenced me and other people by exhibiting these characteristics.

1. Sensitivity – The manager listens well and has a real sense of what each person is trying to do. She watches for clues to underlying conflicts and motivations and asks questions to help me clarify what I need to move forward.

2. Insight – The manager can synthesize a big picture from lots of separate inputs. He compares what I’m saying to the comments of others and offers stories from experience to help me see what my alternatives are.

3. Understanding – The manager asks questions until she has enough information to grasp what’s missing or what could be added to improve things. She has seen lots of projects and teams and knows what it takes to succeed.

4. Clarity of goals – The manager has no doubt about what makes a successful result. He reminds me what’s to be done and what I shouldn’t do on the way.

5. Rock solid values – The manager knows and believes in the values of the company or organization and repeatedly states what they are. She also behaves in a way that is ethical and consistent with these values.

Think about how having a manager with these characteristics helps an Agile team perform to their best ability. Even though the team is empowered to manage its own day-to-day activities, having a manager around with these five characteristics can amplify effectiveness.

____________________________
John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on managing development, Get Out of the Way, is due out in 2009. More info at http://johnlevyconsulting.com

More...

Sunday, April 12, 2009

The Software Engineer as Artist [Courtney Behm]

There is a perception in the general public about engineers…solid, grounded in facts, serious, cautious. They work logically, methodically, are disciplined by their profession into taking one step at a time. I used to have that perception myself, until I started working in high tech. At first, as a marketing professional, I was looking at the engineers I worked with from the outside in, and the assumptions held reasonably well. There’s no question that they were far more practical and pragmatic than I and my fellow marketeers. But when I moved from Marketing into Program Management, and began dealing with the development process at close range, my assumptions began to change.

Hardware engineers fit my expectations more closely. They were, after all, constrained by the physical limitations of plastic and metal and wire. They were creative, for sure, but their creativity had physical boundaries that couldn’t be ignored, and the physics of matter added a stabilizing keel. I could set up a schedule with hardware engineers, and be pretty confident of our ability to meet it. But software engineers were a different box of chocolates altogether. We would make schedules, and then change schedules, and then unexpected things would happen, and it seemed that I spent most of my time one or two steps behind the volatility of their development process. I would say that my most frequent response in team meetings was “Arrrgh!”

Time passed, I spent a number of years as a consultant, and then returned to the corporate world as a Program Manager in an all-software company. OK, I said, how hard can this be? I’ve been in hardware/software companies, I know the drill, piece of cake. Not! A software company is as different an environment from a hardware/software company as I could have ever imagined. I found familiar the unexpected changes, and the volatility, and the difficulty of planning. But now it seemed more magical than frustrating, as if the absence of hardware restrictions had allowed the creativity of the mind to come into its own. And as I learned more and more about software as an entity unto itself, I realized something fundamentally important about software developers. Most of them are artists.

So what is the perception of artists? They are emotional, volatile, don’t like to be hemmed in by conventional wisdom or practices, are idiosyncratic in their behavior and dress, crave the opportunity to do something different. Conventional wisdom would tell you that artistic temperaments in high tech would only be found in Marcom or graphic design or web creation. But in fact, it is the hunger of the creative artist to break the barriers of the conventional that has fueled the emergence of software as the prime mover in the technology world. This has a number of implications for engineering leaders.

First…how do you manage the creative process to a schedule? Think about Michaelangelo on his scaffolding in the Sistine Chapel. I doubt he could have produced a project plan, and if so, it certainly wouldn’t have been done in Microsoft Project. “OK, Mike, we need you to have God ready by April 23rd, and then Adam by June 16th because the spark of creation has to happen on July 1st.” I think not. But when art becomes business, and there are customers to satisfy and external deliverables to produce, this is exactly what traditional waterfall planning methodologies ask of our software organizations. We tell them there are only so many days to be creative, and then only so many days to code and test. It is this fundamental mismatch that has given rise to disciplines such as Agile and Scrum, in an attempt to put a form around the development process that more closely mirrors how it actually works.

Second, how do you manage the artist developer? There are probably as many different ways to answer that question as there are individual developers. Yes, this is essentially true of all of us, there is no human being cookie cutter, and so we all respond differently. But it is exacerbated in the artistic world of the software engineer by the very nature of the work itself, and by the vision of the unknown miracles that software makes possible. Managers often find themselves caught between the need to meet schedules and the inability to rush the discovery process that gets them there. Sometimes the most valuable contributors are the most resistant to observing the necessities of measurable process and delivery dates. They are essential to the organization, and no one wants to make them unhappy, but at the same time a prima donna can wreak havoc on a product launch.

Clearly, software engineering leadership has its challenges and rewards. In subsequent posts, I’ll look more deeply into how we can make the artistic nature of software development work for us and for our organizations.

____________________
Courtney Behm holds a B.A. and an M.A. in Performing Arts and Communication, and an M.B.A. from the Harvard Graduate School of Business. In her corporate career, she has worked for wildly successful companies, and those struggling to stay afloat in the ocean of change. Through her consulting company, Viewpoint Solutions (www.ViewpointSolutions.com), she has helped a diverse client base, including Sun Microsystems, Adobe Systems, Wyeth Pharmaceuticals and the San Jose/Silicon Valley Chamber of Commerce, find creative solutions to classic business problems. An accomplished speaker, Courtney uses a combination of language, humor, insight and front-line experience to offer a fresh perspective on life in the fast lane. In 2006, she returned to the corporate world, and is currently Senior Project Manager at i365, A Seagate Company. She is writing a book on how to lead effectively in a time of constant change, and collaborating on a book on Personal Career Management.

More...

Wednesday, April 8, 2009

New Tool: Sausage Survivors [Matt Schlegel]

Not all problems need a systematic approach like the 8 phase methodology outlined in the previous submission. People are solving problems all the time. Some problems can be addressed in a few moments. Others take longer. Generally, the more people involved in the problem solving process – the more stakeholders there are – the more benefit would be gained by a systematic approach. Here are some examples.

Take the start up founded by a couple clever folks that have worked together for years at their previous big company. When they start developing a new product together, things just click. They know exactly what needs to happen. Then, a few folks join from another large company, some of them managers. Now it gets interesting. The development processes were similar enough so that everyone has a general idea of what needs to happen, but the words they use to describe the process, and the details of who is responsible for what are different enough so that confusion arises, gaps appear, and balls are dropped. Now, add a few junior developers to the mix. These fresh folks are looking to the leaders to understand the development process. Depending on who they listen to, they will get a very different picture of roles and responsibilities on the team. And, the balls continue to drop.

Next, take the two companies that just merged and are integrating development teams. Both development teams have their own terrific product development process. Now, they have to work together to deliver products. Which process should they use? How do they resolve the differences? And, how do they do this in a timely way that allows them to continue to meet the demands of the market?

Most people don’t take a systematic approach, and problems can be solved without one. I have heard people characterize their problem solving process as similar to “making sausage” – it is messy, and you do not want to know what goes in, but in the end it makes a delicious product. As with most endeavors, the smart application of the right tools will allow tool-wielding sausage makers to thrive and prosper.

_____________________________________________
Matt Schlegel has a German last name which belies the fact that his heritage is mostly Irish, English and Scottish. He does have a fondness for sausage which may be traced back to those Germanic roots. He also enjoys the meats of other cultures. He lived 3 years in Japan, where he indulged in sashimi, Matsuzaka-gyu, basashi, and other delicacies.

More...