Writing Crystallizes The Thought

Agile Teams often hold the belief that we should not write anything down because that’s waste. From a human perspective though we need to write things down because that’s the mechanism that allows us, or maybe even forces us, to think things through.

Even the Romans knew that “verba volant, scripta manent,” meaning “the spoken words fly away, written words remain.” So maybe the real question is not “Should we write anything down?” but rather “How much should we write down?” The face-to-face interaction should be followed up with the creation of an artifact that captures what the conversation clarified. This will serve as the basis for further decisions or conversations, or maybe assists in the reexamination of this decision when more data becomes available. Interspersing face-to-face conversations with written thoughts firms up ideas and speeds up the road to shared understanding and clarity.

Usually at this point somebody will jump in to say that all that writing is taking time and that writing a 100-page requirement or design document is a waste. Yes, 100 pages might be a waste most of the time. I think that the artifact produced should be a piece of focused and processed information. If it is 100 pages then it should be indeed a very complex issue, or somebody hasn’t done enough thinking about this. But I’ll leave this topic for another day.

This belief in writing things down was confirmed a few weeks ago as I talked to a new co-worker, Steve Feldman, who writes the Seven Seconds blog. He mentioned that he routinely asks his dev teams to blog about their work. The part of the work that is general in nature can be blogged on their outside blogs, while the company and product specific work should be blogged on the inside blogs. The act of writing things down externalizes the person’s thinking and opens up the ideas for a conversation with the rest of the team.

The blog entry with one’s thoughts will generate further conversation, both online and face-to-face. Each conversation should bring the team closer to identifying and solving the problem that they have set out solve.

Brief Introduction to Personal Planning

As a knowledge worker, you live in a world where a continuous stream of commitments are made and accepted ’round the clock. To succeed in this world, you must learn to make commitments and keep commitments. Since commitments that rest on a plan are more likely to be kept, you must learn to make plans quickly for your work and then carry out those plans effectively.

Maybe you have encountered the following situations: your client has to remind you that you haven’t provided the white paper that you promised over two weeks ago; you seem to be the last person to finish your work for the release and the rest of your team starts to notice it; or your presentation for the team meeting is not done until late into the evening the night before the presentation. If you have been part of the business world for a while then you know that commitments will be made–one way or another–so not making commitments is not a viable option.

The situations mentioned earlier often happen because you make commitments without thinking through and planning out that commitment. Sometimes you make commitments under pressure, direct or indirect, that influences you in ways that later come back to haunt. Or it could also be that you, like many people, probably feel that planning is arduous and unrewarding. It doesn’t have to be that way. With a little practice you can learn to make plans for yourself quickly enough to productively participate in the commitment making process. Armed with a bit of self-knowledge and a few handy practices you will be on your way to make planning fun and make commitments that you can keep.

Effective planning demands of you–and knowledge workers in general–to think through the information do you owe to the people that you work with. Specifically:

  1. To whom do you owe information?
  2. In what form do you owe that information?
  3. Under what timeframe do you owe that information?

You must make a plan to deliver that information successfully to the people that need it from you. This information represents your commitment and it might be in the form of written pages, diagrams, presentations, software code, or any other piece of work product. This is what you make, this is the output of your work. As a knowledge worker, your widgets are processed information: you take in one kind of information, think through it, analyze it, synthesize it, and produce a different kind of information ready for the next person to consume.

For you to do your job well, you must plan the processing of information into work products that your consumers need. Successful planning involves performing the following activities:

1. Identify Tasks. Identify and list out each piece of finished work that you are expected to complete. If the piece of work is bigger than what you can picture in front of you, then you have to figure out how to take it apart. You proceed on taking it apart until you can picture each new part in front of you. This easily can be the hardest part of the planning work in particular, and knowledge work in general.

2. Order Tasks. Arrange the work in the order in which you need to get it completed. The beauty of doing a plan for yourself is that there are no complicated dependencies. You simply list the work items in the order in which they can be done. If at any time you find that you got the order wrong, just reorder the list.

3. Estimate Size. For each piece of work that you identified, figure out the size of that work. The size can take many forms: How many problems do you have to solve? How many features and sub-features do you have to build? How many customers do you have to call? How many pages do you have to write? How many slides do you have to create? Remember that you will have to keep dividing things up until the pieces of work become small enough that you can wrap your mind around them.

4. Estimate Productivity. For each kind of work that you have identified, decide on a productivity metric that you can apply to doing that work. Search your past experience for anything similar. If you have never had a similar experience, then envision what would it take to do this and use your best judgement to establish a productivity measure for the work standing in front of you. Here you might consider the following: the number of pages that you can write per hour, the number of drawings that you can produce per hour, the number of defects that you can fix per hour, the number of problems that you can identify per hour, and so on.

If you estimate that you cannot get one item done per hour, then use the reverse measure and identify how many hours does it take to create one, for example how many hours would it take to draw a diagram.

5. Calculate Durations. For each piece of work apply the productivity measure to the size of the work that you estimated in the previous step, and compute how long will it take complete that part of work. This should be simple math: if you identified that your white paper is going be 6 pages, and you expect to write the paper at a rate of 2 pages per hour, then you are estimating that completing the white paper will take 3 hours.

This is where you might also want to think of some other tasks pertaining to the part of the work that may have eluded you originally: Should you have somebody review the paper? What happens if they find something in the paper which will require of you to rewrite the introduction? If you feel that these are likely scenarios, then include tasks for these in your plan.

6. Estimate Available Time. Look at your calendar and consider how much time you have available to complete this work. This involves thinking through all other commitments that you have already made, since those will also take up your time. Make sure to account for any small and large things that take up your time: preparing for a board meeting and preparing for a surprise birthday party for your friend could be equally time consuming and thus leaving you precious little time left to spend on the new commitment that you are about to make.

7. Calculate Schedule. Fill in your available time found in step 5 with the tasks durations that you computed in step 4. This will give you a schedule that can serve as the basis of your commitment.

8. Track and Improve. Once you start working on the tasks, track your time spent, record every new task that you discover, and track your time on those, too. Track with a purpose. Your tracking must validate the basic assumptions that you have made during planning: Have you identified the list of tasks correctly? Have you estimated their size correctly? Have you estimated your productivity correctly? Have you estimated your available hours correctly? When your answer is ‘No,’ then immediately ask: Why not? What caused the discrepancy? Can you figure out the cause of the difference? Can you find a way to correct for this next time?

As you answer some of these questions, you will find that your planning is going to become more accurate over the course of a few planning cycles. The more you have a chance to make a plan, track the plan, and analyze your results, the better you will get at this. This is not magic, not mysticism, it is only simple logic.

If at any time you find something wrong with the plan, you correct it on the spot. Record what you did and why you did it. Your list of corrections also serves to improve your planning.

Practicing the above planning activities may not make you a project planner who can plan the design and implementation of the next air traffic control system that requires coordination across multiple companies and hundreds or thousands of people, but it will make you a competent planner who can plan one’s own work.

In conclusion, to successfully make and meet commitments, you must learn how to plan your own work, understand your performance at doing the kind of work that you need to make commitments about, and continually observe how well are you doing. Your goal is to keep improving both your work and the planning of that work. Becoming proficient at planning and executing your work will enable you to become a much valued member of any team.

Enjoy the journey!


  • Watts Humphrey formulated these ideas relative to software development in his book A Discipline for Software Engineering.
  • Peter Drucker talked about concepts related to knowledge workers in many of his writings.


Resources for a New Manager

The life of a new manager is full of challenges. You, like many people before you, might’ve gotten into this role without any management training. This article aims to assist you in building your own management curriculum to help you on your new journey.

The job of a manager is very different from the job of an individual contributor. As a manager, you are responsible for your entire team’s work, not only your own. You are accountable for the performance of your organization. You have to enable your team to produce more jointly then what they would be capable of producing alone.

According to Peter Drucker, the guru of modern management, the five elements of management are:

  1. Set objectives
  2. Organize
  3. Motivate and communicate
  4. Measure
  5. Develop people

All of the elements above are important. Unfortunately, many managers get themselves so busy that they forget about developing their team and themselves. As a manager, you get your work done through other people. And this means that you’ll be meeting with people, both formally and informally most of your time. Here are some of the meetings that you’ll need to have to succeed:

  1. Weekly one-on-one meetings with each one of your direct reports. An important part of this meeting is developing the people who report to you.
  2. Weekly project review meeting for all projects that are your responsibility.
  3. Weekly staff meeting with all your direct reports. The purpose of this meeting is to ensure that your entire team is on the same page with the issues that affect your organization.
  4. Monthly department staff meeting (if you have multiple managers reporting to you). During this meeting you have a chance to communicate with the entire organization those topics that pertain to all of them.

The following are resources that you can benefit from as you are developing yourself and your team.


The following podcasts are excellent learning resources:

Manager Tools: Mark Horstman and Michael Auzenne have been producing this podcast since 2005. They provide ready-to-use, practical, and detailed advice on topics ranging from “How to do a handshake” to “How to do your one-on-ones.”

Career Tools: Also by Mark & Mike of Manager Tools. Detailed, practical advice on managing your career one day at a time.

HBR Ideacast: published by the Harvard Business School, provides commentary and advice on a variety of business topics.

Management Books

There are many books targeting the new manager, so picking one is not so easy. Here are some to help you get started:

First, Break all the Rules, by Marcus Buckingham and Curt Coffman. The authors report the findings of a multi-year Gallup survey. Their book represents the conclusions drawn from interviews with eighty thousand managers representing one million employees. Their teams sifted through the data to find which criteria separate the best from the rest. Their advice helps you focus your first actions, and provides a roadmap of what to concentrate on as a manager.

The 7 Habits of Highly Effective People, by Stephen Covey. Free Press. 2004. The undisputed front-runner work  with lessons for developing yourself and your team. Covey’s words of wisdom are just as true today as they were over 20 years ago when he wrote them.

The Essential Drucker, by Peter Drucker. Harper Paperbacks. 2008. This is a good summary of Drucker’s work. He is the “guru of gurus” when it comes to management. He is able to clearly articulate topics that others struggle mightily with. You learn from him about just about any management topics that you will come across during your career. Feel free to pick up any other book by him, including one of the thickest ones, called: Management.

For more books look on my reading list.


Magazines may be old media, however the following have good web editions as well. The Harvard Business Review keeps you up-to-date with both academic and hands-on practitioner articles. The Strategy-Business magazine adds to the mix consultant written articles with sound advice. The Economist magazine keeps you up-to-date on world business and politics.


There is an abundance of material available to help you become a great manager. Commit yourself to using them. You may have a lot to learn, however it will be a lot of fun. It is only appropriate to end with Drucker’s advice to all of us: you accumulate knowledge with one reason in mind, to use it to help your team get better results:

The ultimate test of management is performance. Achievement rather than knowledge remains, of necessity, both aim and proof.

Peter Drucker

Software Development Strategy

strat-e-gy: a plan of action or policy designed to achieve a major or overall aim.

The New Oxford American Dictionary

The dictionary definition points us in the right direction. The software development strategy is your highest level plan for achieving your software project’s objectives. According to Watts Humphrey, the strategy is “the order in which product functions features or requirements are defined, designed, implemented, and tested.”

What does this mean? This means that the plan of action part of your strategy lays out what you build first, what you build next, and so on. It also lays out how are you going to validate the strategy. The strategy also lays out the policies for risk mitigation and decision making. Sections of the strategy may exists both along the developer – customer continuum and also along the system abstraction levels continuum. For details about these continuums see: Multilevel Planning and Component-Based Development.

The System Architect is responsible for the overall strategy. The strategy has to be sound enough that designers and implementors working on parts of the system receive from it the necessary guidance to aid their technical decisions. A well conceived strategy pushes the decision making down to the lowest possible level, closest to where the problems are encountered, while at the same time provides for the oversight necessary to build a coherent system.

Accompanying the development strategy is the testing strategy. The testing strategy focuses on the various testing activities, including the system validation and verification activities. It is constructed similarly and serves the same purpose as the development strategy, only for testing. The owner of the testing strategy may be the System Test Architect, if there is one, otherwise this is also owned by the System Architect.

Why do you need a strategy? Without a strategy it is difficult, if not impossible, to execute an iterative, incremental development process. The strategy ties the iterations into a coherent whole, and allows the team to move confidently toward the goal. Your first attempt at creating a strategy may feel awkward, but with practice you’ll get better at it. Why don’t you get started today?

Essential Software Design Documents

When it comes to documenting software designs, there are many practices ranging from a quick whiteboard sketch to fully specified UML models with OCL to tens of pages of written text. Here is what I found that worked best based on most projects that I have been part of:

  1. Static Structure Diagram: this is a class, module, or package diagram. This diagram (though often it is more than one), shows the relationship between parts of the system at a given level of abstraction. The relationships shown include: containment, references, parameters, inheritance, and so on. Record on the diagram indirect and implied dependencies with a note.
  2. Initialization Sequence Diagram: shows how the system is brought up from being on the disk into the operative memory and “ready to transact business” state. This diagram is part of the dynamic model of the system. It shows the order of messages sent or method invocations. Often also shows resources allocated to get up and running.
  3. Shutdown Sequence Diagram: shows how to put back the system or component into the proverbial “bit bucket.” Must complement the initialization sequence diagram and demonstrate that the system is not loosing resources during its operation.
  4. Sequence Diagrams, Activity, and/or State Diagrams for the key “business” of the system or software part. All other activities took place just to get ready to do the business of the system. Now it is time to get the business done. The key sequence diagrams show what the system does, how it provides the value that it is expected to deliver.
  5. Brief Design Commentary to explain the “why” behind key structural and behavioral elements and decisions. This is usually one Wiki page that ties all other documents together into a coherent whole.

Each of these can be created at “every zoom level” in the system. This means that if you are developing a component-based system, then you would have this set of design documents for the system, subsystems, modules, and components. Within each you represent the unique concerns of each software part.

Read Applying UML and Patterns, 3rd. Ed., by Craig Larman for an in-depth course on how to do object-oriented analysis and design on an iterative software development project. As you do design more, review your results, learn from your mistakes, and over time you’ll get better at it.


  1. UML basics: An introduction to the Unified Modeling Language, from IBM developerWorks, 2003.
  2. Allen Holub’s UML Quick Reference. 2007.
  3. Book excerpt from OOAD with Applications, by Grady Booch.
  4. UML Modeling in Color, from Wikipedia.