Managing the Creative Process [Courtney Behm]

So…you have a product that is core to the success of your organization, and you’ve just realized that, though the titles of your team say Software ENGINEER or DEVELOPER, it should really be ARTIST. Add to that the challenge of software itself, a product that is often indistinguishable from magic, and you have a dilemma. How do you maintain the level of creativity you need to be cutting edge and still deliver on time?

Let’s talk about the planning process. Consider, for a moment, Microsoft Project. I know, I know…a fearsome thought. So many people have an antibody reaction to using Project; I’ve worked at companies who have refused to use it, relying instead on Excel spreadsheets and lots and lots of manual updates to manage complex development programs. Microsoft Project isn’t perfect, no question about it, but it’s not really that bad. Its biggest problem is that it isn’t flexible enough to track the work of artist developers. It’s an artifact of the waterfall methodology, symbolized by the horizontal Gantt charts with their slick interdependencies that adapt every time a date is changed. It assumes that the project is one monolithic whole with interconnected moving parts. You start with A and move to B and then to C, and before long, you intersect with D. Waterfall methodologies focus on maintaining these relationships to keep the project on track. For some applications, it works wonderfully – IT infrastructure projects, vendor evaluation, customer betas and product launches, to name but a few -- but waterfall, and therefore Project, isn’t the best tool to support the more fluid vision of the software developer.

In reaction to the restrictions posed by waterfall, we now have “Agile” programming, with its various manifestations…the one I’m most familiar with is Scrum. Agile is pretty much exactly what its name indicates. It’s a way of approaching software development that allows us to bob and weave, to take advantage of discovery, to place enough rigor around the process to know what is going on, but to keep options open. Agile says that the best results arise from small, iterative development chunks. You come together as a group, you meet every day, and you chart your progress with tools that can be easily adjusted as you discover more and more about what your product really needs. And within a short time, you have a usable, working piece of functionality. It changes the game.

But Agile programming seldom takes place in a vacuum. Inevitably, there are customers and deliverables, and we need to sell product to make money. So elements of waterfall creep in under the cover of darkness. How can we support the creativity of our software developers and still march to the corporate drumbeat of deadlines, release schedules and launches?

Eventually, common sense trumps methodology, and a hybrid scheme emerges…not as crisp and apparently predictable as waterfall, and not quite as free and creative as Agile. This is a compromise with which no one is completely happy, but which honors both the need for flexibility and the need for predictability. However, it isn’t easy. Knowing when to let the creative energy flow and when to rein it in is a dance that doesn’t come naturally to most of us. We are called to come out of our comfort zone and live in two worlds at once. And this management challenge has a tendency to change emphasis depending on the breadth of our responsibility to the organization. The closer we are to the development process itself, the more comfortable we will be with an Agile approach. The closer we are to the Boardroom, the more we will want things to be certain.

But to be successful in this volatile, ever-changing world of software, we have to listen to the development process as if it could talk, and let it tell us what it needs. When we consider it as a living organism, the combined DNA of marketing and engineering creativity, the offspring of a company that depends on it for survival, we can see more easily where the touch points are, where we can apply structure, when it’s time to let the ideas flow, when to say, “That feature won’t make the release” and when to say, “This feature is worth waiting for.” It may mean letting go of some old assumptions about how things work, but the final result will be the best of both worlds.

____________________
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...

New Tool: Exploring the Idea Space [Matt Schlegel]

In my previous blog I described how one goes about rounding out the team for your problem solving initiative. Now, we dedicate the team to dreaming up as many ideas as possible to solve the problem and achieve the goals. I call this the Idea Brainstorm.

What is an Idea?

An idea is any thought. It may be a big, complex thought. It may be a simple thought. It may have come up before. It may be a newly minted thought. It may be “good.” It may be “bad.” It may be funny, or serious, or even impossible. No matter – all thoughts and all ideas are welcome. The idea brainstorm is a chance for the group to flex its creative muscle. Encourage the team not just to explore boundaries but jump over them and run as far away as possible. My dear friend and mentor, Kimberly Wiefling, encouraged me to start each brainstorm with a warm up exercise. I will never forget when she had us brainstorm the similarities between a refrigerator and a cat. This is still my favorite warm-up theme. My favorite answer to date is that they are both endothermic, a property of both biological and physical systems (Thanks, Mike Plasterer!). Every time I conduct this warm-up, I enjoy hearing new ideas, which reminds me of the importance of including team members of varying backgrounds and experience.

After the warm-up, I have the team brainstorm ideas to solve each objective and its related problems. I try to have the team consider both the objective and the problem since each view may generate different ideas. I ensure that each problem/objective is allotted time for brainstorming. If there are 10 problems and 50 minutes, I will monitor to ensure that the team start the transition to the next brainstorm topic after 5 minutes. Intentionally, this session quickly becomes a high energy meeting with many ideas being bandied about. I will stand at the flip chart scribbling down each idea as it is aired – no filter. For instance, if multiple people say the same idea, I will write it down multiple times.

Some people will be natural contributors in this environment. Some will not. The Naturals will chime in without much prodding. Those that are quiet have important contributions that must also be aired. After the initial idea frenzy, I will go around the room and ensure that each person has had an opportunity to contribute a thought or two. I also remind people that some ideas may spring up after the meeting. In that case, I encourage the team to send me the ideas by email. The point is to get as many different ideas into the mix as possible.

Sugar!!!

In order to keep the energy high, I bring tasty, sugar laden treats for the team to enjoy. These treats provide the fuel to keep the team powered for the entire session. While I generally do not strictly prioritize the problems and the order in which each is brainstormed, I do try to leave the less difficult problems for later in the meeting, just in case the team starts to run out of steam. Of course, sugar can only take you so far, and the longest I would advise conducting this type of brainstorming session is 90 minutes.

First Reaction

A word of caution – what is the first thing that happens when you hear a new idea? You have an emotional reaction. That idea is great! Or, that idea sucks! It is inevitable that each person will have a reaction to each idea. I explain this phenomenon to the team and acknowledge that they will have these reactions. In the case of a negative reaction, I encourage the person with that reaction to think before they blurt, to think about why they are having that reaction, and then to think about how they might solve the problem in a manner more suitable to them. In other words, I encourage them to re-channel the negative energy from the reaction into a positive idea that they can share with the group. I assure them that we will have a chance to analyze the negative reaction at a later meeting, but not at this session. In this way, the team maintains a high energy level and a positive tone for the duration of the brainstorming session.

Idea Space

At the end of this session, you will have a rich set of ideas to work with. You will have allowed all the team members to contribute and to appreciate the contributions from each other. I have found at the end of this meeting, the team morale has increased. There is a sense of hope. The team sees possibilities for solving the problems and paths to reach the goals. In the next phase, the team will scrutinize each path and assess its viability relative to the others in what I call the Analysis phase.

_______________________________
Matt Schlegel’s fondness for the “Refrigerator and Cat” warm-up exercise comes from a deep-seated love/hate relationship with cats starting with his first pet cat “Fufu” and her fondness for gasoline to a more recent run-in with neighborhood cats and their propensity for fertilizing his front lawn. To address the “fertilizer” problem, Matt developed an alarm, uncleverly dubbed “Cataway,” that would direct ultrasonic sound into the “blast zone” when a cat would enter. Results: no more “fertilizer” on the lawn.

More...

Will complexity overwhelm us? [ John Levy ]

Should we worry about software being too complex?

I’ve been teaching a course to elders about how computers work – both hardware and software. The challenge in such a course is to make the content both true and accessible while keeping the presentation interesting.

Hardware is in some ways easy to teach. Once a student grasps that all computers involve the interaction of a processor with memory (both for instructions and for data), there is only the matter of input/output left to deal with. Well, OK, there’s bootstrapping and operating systems and a lot of other stuff in there, but knowing about the processor and memory is the only crucial step to understanding how it runs.

But what about software? First I explain that nobody writes in machine code; very few write in assembly language; and even procedural languages like C and Pascal are being abandoned for object-oriented languages. So I have to get across, first, that people who create software are thinking abstractly in terms of algorithms and procedures. Then the next level of abstraction is objects and messages. And finally, the tools of the trade include editors, compilers, linkers, loaders and program (and object) libraries being used in Integrated Development Environments (IDEs).

And I haven’t even touched on testing and QA yet. How is a layperson going to come to appreciate the difficulty of producing a properly-functioning program? Yet everyone knows war stories of how failing software caused lots of damage. Is our knowledge of testing methods inadequate, or are we just being poorly managed?

Gerald Weinberg, in his recent book, Perfect Software and other illusions about testing (Dorset House, 2008), does a brilliant job of explaining to non-experts why testing doesn’t – and can’t – produce the eponymous perfect software. I highly recommend reading Chapter 14 of his book, which starts off with a study of failed and successful projects at IBM. All of the projects had “bad luck” strike during the projects. His conclusion is that success was a function of good management, not avoidance of bad luck.

Fifty years of Moore’s Law has given us computing power in our pockets that is greater than the room-filling machines of the 1960s. And we have whole networks of tiny microcontrollers inhabiting our homes and our cars. How are we going to deal with the prevalence of bugs in these devices?

No one says the code has to be perfect. But it has to be structured in a way that keeps it from failing catastrophically. And it has to be adequately tested even as it gets larger and more complex. Are we up to the challenge?

I firmly believe that Agile software development frameworks give us the best path to developing decent software. But they are not enough. We have to manage ourselves and our organizations in ways that permit healthy development behavior. This is what Agile Management is about: giving up certain counter-productive behaviors and establishing new management patterns that encourage constant improvement in the face of increasing complexity.

_________________________
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 is at http://johnlevyconsulting.com

More...

A PM with a Different Approach [Philippe Habib]

In the 20 plus years of writing software, I have acted as a project manager (PM), as well as having worked for a good number of PMs. A recent experience really made me re-evaluate what makes for a good project manager.

Most of the project managers I have worked with acted as the tie-breaker, or opinion of last resort when it came time to decide on features or schedule. They’d come up with a schedule, often guided by when the client wanted it done, and a list of features that the client desired, and keep tabs of progress during weekly meetings as time went on. Everyone on the development team always had a great relationship with them. Note: I mean client in the largest sense; either Marketing or an actual customer.

This all changed when I worked with a PM who had a very different approach. He started off with a list of features that the client requested, and asked each engineer to commit to the time required for every feature. Then, he turned that into a schedule and got the client’s approval.

Starting at that point, engineers were held to the schedules to which they had committed. A schedule slip was not treated as an inevitable part of the development process, but as a real problem that needed to be addressed and remedied. Engineers were asked to find ways to recover lost time without abandoning other commitments made to the client. This PM wasn’t a good buddy who drank coffee and ate doughnuts with us for an hour a week at project meetings. He was a tough taskmaster who pressed us to deliver what we had committed to.

During these same meetings, we’d often hear the client give feedback on the progress as they saw it, and maybe ask for feature changes or additions. This PM defended the original schedule just as doggedly in those instances. New features or changes would mean, at the very least, some time spent evaluating the impact on schedules and deliverables. Maybe it would mean more time, or dropping other features, or maybe even less time, but nothing got committed to without a thorough evaluation.

At the cost of losing a good buddy during project meetings, we gained a clear view of expectations and some strong protection from the feature creep that kills schedules, and make projects drag on, and rob everyone of the feeling of completion and a job well done. Besides, we could always be friends outside of the project meetings.

______________________
Philippe Habib consults on embedded device design and firmware. Prior to consulting he has worked for Oracle, IBM (lotus/cc:Mail), Apple, and several startups. More information can be found at www.phenomasoft.com.

More...

New Tool: Building your problem-solving team [Matt Schlegel]

My previous blog entry discussed the first step in a problem solving quest: the formulation of a problem and goal statement for the initiative. The next step is to pull together the team you will need to achieve those goals and solve those problems.

First, break all the rules

Marcus Buckingham, in his book “First, Break All the Rules,” describes the metaphor of people having super-highways or bumpy country lanes for executing a given task. His point is that not everyone is good at everything and assigning folks with super-highways to a task will get you there much faster than will the person with the country lane. I have found that this is true of problem solving as well. Some folks are great at describing the problem. Some folks are great at coming up with creative ideas. Some folks are great at analyzing the ideas. Some folks are great at building a plan to execute the idea. Some folks are great at selling the plan. And, some folks are great at driving the plan through to completion. And, while you can find people who can do more than one of these areas well, it is difficult to find one person who can do them all well. You will want to keep the strengths and weaknesses of your team members in mind as you construct your team.

Beyond the Stakeholders

In defining the problem, you have already pulled together a team of stakeholders. In addition to these folks, you will want to think about who else may need to be involved in the initiative. Were there other groups identified during the problem description meeting that contribute in some way to the problem? If so, you would want to consider including them. Is there certain expertise required to solve the problem? If so, enlist the help of an expert. Will there be an impact on the workflow of any group or groups in solving the problem? If so, make sure those groups are represented. How about systems and IT infrastructure? If yes, ensure an IT representative is part of your group. Simply put, ensure that the people who need to be involved in both designing the solution and living with the solution are represented on your team.

Roles and Responsibilities

Take the time to ensure that every member on your team understands his/her role in the initiative. Prior to meeting with the entire team, I tell all the participants that they will be expected to describe how they will contribute to the team. At the meeting, I document what each member says, and this document becomes the Roles and Responsibilities document for the team. Challenge the team to think about what other resources they think they will need to solve the problem. Also, challenge those with a clear vision of their role on the team as to whether they need to participate in the initiative at all. At the end, you should have a clear description of each team member’s role and how they plan to contribute to solving the problem.

Housekeeping

If you have added new members to the team since the original “Problem” meeting, then you will need to loop back with the new members and ensure that the problems from their perspective are aired and recorded. Once any new problems are captured, you will want to check to make sure that the goals will address the new problems. This is an important sidetrack to ensure that new team members feel vested in the process.

Check in with the Sponsor

Once you have identified your team members and each of their respective roles and responsibilities, you will want to check in with the sponsor. Brief the sponsor on the team you have assembled. Also, get feedback to make sure you have your super-highways in the best places. With your team in place you are ready to move on to the next step. In my next blog entry I describe the creative idea brainstorm.

________________________________
Matt Schlegel learns a great deal about teams by watching his children participate in team sports. He finds it fascinating to watch how children identify with their budding super-highways. He also finds it fascinating to watch how great coaches inspire kids with a positive attitude that carries over into their support for each other.

More...