September 7, 2009 by mensming.

One of the things I love is being able to see presentations from conferences I was unable to attend. A coworker passed on a link to this video (55 minutes) from the Business of Software conference. In the talk, Jason Fried of 37Signals, makes of Ruby on Rails and Basecamp, speaks on many aspects of running a software company and keeping teams working effectively.

Here are some of the slide titles, topics and items Jason discussed:

• Planning is vastly overrated - no roadmaps, specifications, projections. Get rid of distractions. Functional specification does not reflect reality and leads to an illusion of agreement.
• Decisions are temporary - optimize for now
• Red flag words - need, can’t, easy, everybody, nobody. These are the words that cause projects to be late
• Interruption is the enemy of productivity - the closer the team is physically, the less you get done. Interruption is not collaboration. A fragmented day is not a productive day.
• Underdoing - target non-consumption
• Find the right size - imagine the software as a physical item
• Follow the chefs - what is your cookbook?
• Always be questioning - Why are we doing this? What problem are we solving? Is this actually useful? Are we adding value? Will this change behavior? Is there an easier way?
• Give up on hard problems - there is an abundance of easy problems
• You’re an editor - Curate your product. Say no to more things than you say yes.
• Work Less
• Q&A - Starts 28 minutes into the video

An enjoyable video, especially the first half before the Q&A session.

Posted in software engineering, professional development, process improvement, project management, requirements, conferences | No Comments »

January 28, 2008 by mensming.

Feature Driven Development (FDD) is one of the agile methods I think does not get enough attention. In particular, the principles of FDD - as they impact project management -are very useful in agile and non-agile environments. The book that I used to learn about FDD is A Practical Guide to Feature-Driven Development by by Stephen R. Palmer and John M. Felsing. This book has a good description of FDD but is weighed down with a specific modeling approach.

Recently, Software Engineering Radio had an interview with Jeff DeLuca, one of the creators of feature driven development. I found it to be a good introduction to the topic. However, for a practitioner of FDD there will be nothing new here.

Posted in software engineering, project management | No Comments »

March 29, 2007 by mensming.

As I have mentioned before, I attended a breakfast talk by Steve McConnell (http://www.construx.com) entitled “Legacy of Agile Software Development”. During the talk, Steve skipped over the section of the slides labeled “Agile Practices That Tend to be Problematic”. I grabbed the slides after the presentation to see what he had to say.

Note: Steve is not necessarily saying these are bad — just that the teams his company has evaluated, these practices have not provided the value that they promise.

• System Metaphor - Least understood practice
• On-Site Customer - Difficult to achieve
• Collective Code Ownership - Uneven code quality and sometimes results in lack of ownership.
• Pair Programming - Sweet spot between junior and senior programmer
• Refactoring - Good practice whose name is used to cover up bad behavior

Posted in software engineering, project management | No Comments »

March 23, 2007 by mensming.

Last week, I attended an ASQ dinner meeting where the speaker was Izzy Gesell (http://www.izzyg.com/). The title of the talk was “Tools for Transformation”. I think I would have named the talk “Lessons from Improv”. Izzy is a former improvisation artists and he applies the lessons and techniques from improvisation to the business world.

Izzy’s talk was dynamic and interactive. I took away 3 items which can be applied to a software (or any other) team:

1. Acceptance - Accept what is given and move forward
2. Focus - Concentrate on the essential
3. Trust - In the process and the people

The idea behind acceptance is instead of complaining or trying to change the unchangeable, it is more productive to take what is given and move it to the next level. This does not necessarily imply agreement. Concentrating on the essential - Focus - I believe is a key attribute of all the successful teams I have been a part of. In the case where the team was not performing well, a lack of focus was definitely a component. And finally trust. Once again, the best teams operate in a an environment of trust.

Posted in process improvement, project management | No Comments »

March 9, 2007 by mensming.

Years ago, I was stuggling to meet all of the committments I had made. When discussing this with my manager, he suggested keeping a log of what I did each day for a couple of weeks to identify items that I could eliminate or postpone (or now that I manage others - delegate). The exercise was useful and got me through the commitments. I then promptly forgot about it. Some time later, I was in a similar situation and started to keep the log. This time, I made it into a habit. Since then, I have kept a simple work log at my last 3 companies.

It is a simple format:

Date      * Description of what I did
Date      * Description of what I did
Date      * Description of what I did

No more than a line for each item. (The details can always be found in my engineering notebooks, wiki entries, source code control comments, bug reports, etc.) At the end of each week, I archive that week’s log and start a new one. I review the prior weeks log when I file my weekly status report. At longer intervals, I will review larger blocks of time.

The work log has helped me numerous times. It is especially useful when I need to answer questions like “when did we do A, B and C?”

I am currently in the process of moving out of my current position. One of the first things I did was review my work logs for the last 12 months and identify

What types of items should my replacement do?

What should be delegated to existing team members?

What items do I need to discuss with my boss about who should take on these duties?

Without these logs, I am sure I would let something slip through the cracks. This is definitely a habit that has been useful and that I will continue.

Posted in project management | No Comments »

March 6, 2007 by mensming.

Over the years, I have seen many forms of status reports used by my team and the teams I have worked on. (I am distinguising these reports from those used for project status. Often, there may be corporate standards or contractual requirements associated with them.) I have settled on the following format which works well in a variety of submittal formats (email, word document, wiki, etc.):

Notes

Highlights

Lowlights

Plans

The notes section is optional. It is used as a reminder of upcoming items or circumstances that the manager should be aware. I have used it to record upcoming vacations, travel plans, customer visits, release dates, milestones, etc. This section often spans multiple reporting periods. The highlights section enumerates those items that went well during the reporting period. These are just bulleted lists - not a lot of text. The lowlights section are those things that did not go as planned. Once again, it is just a list of bullet points. The plans section lists what the individual intends to accomplish in the next reporting period. If this information is captured elsewhere, say in a project plan, then just reference it.

I use these reports in two ways. The first is in my regularly scheduled one-on-one meetings. I review the status report beforehand. (I am opposed to receiving both written and verbal status.) I make notes of those items I need more information on - these are usually the lowlights. I encourage my staff to include items in their reports that they want to discuss with me. The second way I use these are during performance reviews. This is especially useful in countering the “recency effect” - only remembering what has happened in the last 1-2 months. Unfortunately, it is usually the details of the good things I forget, so I review the highlights sections in detail for the last year. I only look for trends in the historical lowlights.

I have used this format consistently over the last 3 years. As an organization, we have tried collecting different information or collecting it in different ways but I keep coming back to this format.

Posted in project management | No Comments »

March 1, 2007 by mensming.

I finally got around to reading The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. While an excellent book for programmers, I believe that it is equally useful for testers (both doing automation and doing manual testing), project managers and technical writers.

In particular, I think many of the traits described in the first section of the book are as valuable (or maybe even more valuable) for non-programmers. The following tips leaped out at me as traits that should be shared by all team members:

Tip 1.	Care About Your Craft
Tip 2.	Think! About Your Work
Tip 3.	Provide Options, Don’t Make Lame Excuses
Tip 4.	Don’t Live with Broken Windows
Tip 5.	Be a Catalyst for Change
Tip 8.	Invest Regularly in Your Knowledge Portfolio
Tip 9.	Critically Analyze What You Read and Hear
Tip 10.	It’s Both What You Say and the Way You Say It
Tip 11.	DRY - Don’t Repeat Yourself
Tip 27.	Don’t Assume It - Prove It
Tip 46.	Test Your Estimates
Tip 56.	Start When You’re Ready

Some of these tips require explanation. Please see the book for details. It is my belief that if every team member acts in these ways - regardless of position or seniority - then the team will be much better for it.

Posted in system testing, project management, web testing | No Comments »

February 12, 2007 by mensming.

I have been looking at standardizing some document templates for various software artifacts. As I review these things, there are several items that annoy me. As I think about it, I think the difference comes to how the documents are viewed (and in particular whether they are handled in hard copy vs. looking at them online).

Typical documents I see look like this:

Title Page

Revision History

Table of Contents

Bunch of standardized boilerplate text mixed with the content I am interested in

Many times, I need to page through 3-5 pages before I get to the information I am interested in.

Title Page: In a printed document, this may or may not be a nice touch. However, generally, it does not add significant value over just a title, author and update date at the top of the first page of text. Whether to include a title page or not in the printed document is a question of your audience. In an electronic document, this is text and whitespace that must be skipped over to get to the “meat” of the document.

Table of Contents: If I see another 3 page document with a table of contents, I think I will scream… My general rule for printed documents is that a table of contents is useful once the “meat” of the document is over 10 pages. In an electronic document (where I have full text search), I want the table of contents to be hyper linked enabled so I can use it as a navigation tool.

Boilerplate Text or Background Info: In a printed document, it is a matter of preference. In general, I prefer background information on a project to be kept in a separate document that is referred to in the main document. However, this may make using the printed document unwieldy if the reader needs to shuffle between multiple documents. In an electronic document, I want the background information to be a link to the definitive source. It is easy for me to skip over and if it changes, there is only one location that needs to be updated.

Boilerplate text is often seen in document templates. These are usually instructions for how to use the template or perhaps generic text that describes corporate policies or procedures. This text may be useful to a new employee or someone who is using the document for the first time. However, after that initial experience, this is text that most people will skip over and generally ends up wasting space. If instructions are needed or a reference to a procedure needs to be included, make it a reference (or link) to another document.

Revision History: Some documents include a detailed table of every change made by every person ever in the history of the document. While this is valuable information, I consider this document meta-data rather than content of the document itself. I would prefer to see this data stored in the version control or content management system rather in the body of the document. That being said, it is nice to have some version identifier in the document (perhaps in the header or footer) to distinguish between versions.

Posted in project management | No Comments »

January 10, 2007 by mensming.

Today I attended a webinar sponsored by ASPE Technology (a training firm) by Bob Galen entitled “Planning & Tracking a Software Project at the ‘Right’ Level”. The beginning of the presentation was absolutely outstanding. It discussed the various symptoms of not enough planning and tracking or too much planning and tracking.

The slidedeck used in the webinar is not available on the web (at least not yet). However, a very similar slide deck from an earlier presentation can be found on Bob’s site here. Take a look at slides 5 - 15 in particular.

The theme of the presentation - that the “Right” level depends on your context - is driven home by the factors around too low or too high of planning. I found it useful to ask myself if these factors can be found in my current projects.

Update 01/13/2007: The presentation used during the webinar can be found here.

Posted in project management | No Comments »