Archive for the ‘Project Management’ Category

Book review: Management 3.0

A lot of management or process books discuss what has worked in the past for the author with the implication that it will work for you, too. Not Management 3.0 by Jurgen Appelo. His main theme is that software development is hard, complex, and chaotic. There are too many variables with too many unknowns. Not only would what worked for him probably not work for you, but what used to work for you may not work anymore.

Because of this chaotic environment, your best bet is train and empower your team so that their judgement can find the best path. It is hopeless to try to micro-manage them. This book is the author’s attempt to train and empower you. He does not tell you what to do; he gives research and information for you to figure out the best combination for your particular situation. He discusses his research into the various aspects of software management – ideal team size, how to motivate, proper amount of empowerment, etc – so that you can use what you think is useful.

While the subtitle is ‘Leading Agile Developers, Developing Agile Leaders,’ this is not a process book. He discusses Agile, uses it as examples, and continuously discusses how the manager can achieve Agile principles. However, the book is about managing and the ideas should be just as useful in a Waterfall office.


Ode to the Change Request

I’m trying to figure out why anyone would call software defective that perfectly executes the requirements. What I think is that people associate defect fixes as being free and quick while change requests are charged and require lots of paperwork. Thus they want to classify everything a defect.

The reason that defect fixes (and here I am using my definition of ‘defect’ as being that which does not meet requirements) are usually quick is that we already have requirements and the code is already written. We know what to do and it is already mostly done, we just have to fix it.

A change request is not usually quick because

a)      we don’t know what to do. We are not the ones talking to the customer. Besides, we have to cover all exceptional cases. Also, most change requests are inconsistent with the rest of the application and basically wrong. We need to discuss it. I’ve found that in the cases where the situation is intuitively obvious and no discussions are needed, somehow QA comes up with a different understanding and we go around in circles over whose understanding is more intuitively obvious. Besides, we need documentation for traceability. This documentation does not need to be an epic novel, just enough to list the requirements.

b)      The code is not written. New features require new code which takes longer than fixing existing code.

None of this magically goes away by calling the issue a defect. If there are not written requirements concerning the issue (for whatever reason) then we need written requirements made. Simple as that. If there used to be written requirements but no one can find them, then new requirements covering this issue need to be made.

If we don’t want to charge the customer, then let’s not charge them. We don’t have to charge for CR’s. In fact, the overhead of justifying every hour far outweighs the revenue received for the minor CR’s. I don’t understand why we nickel and dime our big customers anyway. We should be doing this stuff as a matter of routine as part of the maintenance agreement.

Let’s imagine a scenario where the customer thinks the functionality should change for a particular scenario that was not covered in the original requirements.

We could a) call it a defect, or b) call it a change request.

Imagine a) call it a defect. We admit our software does not do what it is supposed to do. Our programmers are sloppy. Our QA apparently is incompetent. We apologize and humbly ask for forgiveness. The customer wonders if there are less idiotic vendors to deal with.

Now, imagine b) call it a change request. We explain to the customer that while this scenario was not considered, it is very common in software that once a new feature is released that new situations are discovered and that we would be very glad to discuss it with them. While discussing it with them, we point out how related areas might need to change and some risks involved. We also make some suggestions so that they know all their alternatives. An agreement is made on how the new scenario should behave and documented so that there are no misunderstandings. A service pack is released a month later to address the new scenario. Of course, all of this was at no cost to the customer as part of our comprehensive service. The customer is glad to have partners who understand their business so well and know that there is no one in the world that could possibly replace us.

Change requests are our chance to shine. It is our chance to get face time with the customer and be their partners in planning their business. It is our chance to show the value we add and to actually add value. Let’s not miss the opportunity.


Most people think being a good teammate is to help out others on the team. That is just half of it.

No one in sports thinks a ball hog – someone who once given the ball tries everything in their power to score themself and never passes to anyone else – is a good teammate. Yes, helping others is good but you must also be willing to ask for help yourself. If you do not utilize the skills and knowledge on your team, then what is the point of you being on the team? Just so that they can benefit from your brilliance?

 Even when you do not necessarily need help, it is always good to get a second opinion or bounce an idea or two. By using your team, it becomes a better team.

Let’s Actually Deliver!

The whole purpose of software development is to deliver working software, so I am continually amazed how many people in the process do not want to deliver.

  • QA complains about every little bug
  • UAT complains about every little bug
  • Customer complains about needing training

Apparently anything less than perfect software is not acceptable by these folks.

Sorry, guys. Perfect is going to take awhile. In the meantime, why don’t you take this release which is miles better than the previous?

Perfect is the enemy of the good. Often the cost-benefit of perfect shows that it is not worth it. Spending days of programmer time to save some admins a couple of seconds is value destroying.

Even if you spent the time to get to perfect, you will find that the definition of perfect has changed. Look at Microsoft Word – 15 years in development comprising hundreds, if not thousands, of programmer-years and still not perfect. Of course, the current version would have been seen as spectacular 15 years ago, but today people still find things to complain about. 

Duke Nukem Forever fell into this trap – trying to be the perfect game when the definition of the perfect game constantly moved.

The criteria should be, is this release a step forward or a step back? If it is forward progress, then deliver!

Maintain Pressure

Intensity is the price of excellence. 
– Warren Buffett

In The Snowball, Buffett makes this statement many times. And author Alice Schroeder makes clear that price is paid two ways – by Buffett devoting almost every waking moment of the past 60 years to making money and by those who have to work with him. Buffett is compared to the sun – nice and warm from a distance but you don’t want to get too close.

While we don’t want to be at Buffett level, excellence requires intensity. And intensity can only be maintained in an pressurized environment. Even if someone has inner-drive, it is no good if no one else will work with that person. It is a blow to the ego to have mistakes pointed out and to have seemingly clever solutions rejected. Without pressure to tilt the playing field, excellence will be outnumbered and attacked by the lazy, egotistical, and jealous.

Without pressure, the cream does not rise to the top.

Power without responsibility causes corruption because without responsibility there is no pressure.

Sure, there must be time to relax and recharge. But don’t coast.

Giant Sucking Noise

Has this every happened at your company?

A problem is identified. The person doing the analysis only does a little before announcing their wonderful solution.

It seems problem solving is fun and creative. The person coming up with the solution feels so clever.

However, when full analysis is not done, it leaves a vacuum. And that giant sucking noise we hear is that solution based on half-assed analysis. It sucks because it does not fully solve anything.

But problem solving is funner when the analysis is incomplete – actual constraints and issues puts boundaries on the clever solutions. And analysis is so much work – not nearly as fun a being a clever problem solver.

A complete analysis usually practically points directly to a solution. The issue is vivid, the need real. But when we are led to the answer, where is the satisfaction of clever problem solving?

It is overwhelmed with the satisfaction of a good solution.

DevDelivery’s Second Rule of Development Process

Any process where key steps depend on humans executing perfectly is guaranteed to fail.

Humans make mistakes – it is what makes them human. Anything that has to be done right should be either

  • Automated
  • Reviewed
  • Structured so that mistakes are obvious and quickly found

If one of these are not built into your process, don’t blame the person who made the mistake that caused the deployment to fail – blame your process that did not catch/prevent that mistake.

DevDelivery’s First Rule of Development Process

Any process that depends on psychic mind reading for communication is guaranteed to fail.

Not may fail – will fail.

This may seem obvious, but communication has to be built into the process and not depend on it happening accidently. I’m constantly amazed how many decisions are made in hallways or actual meetings but never relayed to anyone not present at the time.

Project management is about three things – communication, communication, and communication.