Mythical Man-Month Chapters 1-5

I started reading The Mythical Man-Month by Fredrick Brooks– a near 40 year old book about software development teams and timelines. The underlying idea is that you cannot just throw workers at a project and expect results. I heard about this book a while ago, but I couldn’t ever track it down at a library, nor could I find someone who would let me borrow it and to be honest, I didn’t want to pay for it. Just recently I found someone who would loan it to me. The book is old, and there are some parts in it that help show its age, but the underlying concepts are there and go into more thought than I’ve ever had about them.

While I’m only a few chapters in, as a developer, it has been quite depressing for me. There’s a section where it talks about the productivity of developers, and brought their salary into play. The developer who makes twice as much as the other is not twice as productive. The developer at twice the salary may be ten times as productive!

It is an interesting time for me to go through this book. I’ve been at my current workplace for just over a year, and I’ve been with my project since its beginning. I’ve seen developers come and go on the project. Team leads, and project managers moved around. At one point, we had 11 workers on the project full time, and in less than a week the team will have six. The number fluctuates, and the team looks very different than when we first started.

For the most part, the team has worked well together. I believe that is because of each individual’s ego is inline. Mythical Man-Month compares development teams to surgical teams. Each person in a surgical team has a specific task. One person may be deciding how to split away something, another person may be splitting that into smaller more manageable tasks. Another could be actually doing those tasks. Then there are the individuals who are helping support those actually building, such as secretaries, and managers who will be gathering information from your client. This works because everyone knows their role, and follows it.

So why did the beginning of Mythical Man-Month depress me? Because I’m seeing the concepts in the book come into play and be accurate. Developers are optimists, and they’re horrible at estimating. The money wasted on bringing new people on board only to see them go has costs go through the roof without positive impacts on the team. Furthermore, I am now thinking about if I am as good of a team member as I had thought, my place on the team, and what I’ve been doing to improve it.

It also depresses me a bit because of the approach to software design, and how ends up in the end user’s hands. For example, our product owner will request some report. The team will gather information on said report, by asking questions, doing some database research and basic proposals. Everyone will agree that this report is important and it needs to be generated a certain way. While in the middle of actually building it, suddenly the requirements will change. For me that is extremely depressing. I feel that it shows a lack of planning and respect for the developers’ time. Mythical Man-Month touches on a related topic when it goes into talking about focus and effort. A feature that may be used once a quarter can take a long time to build. What if those efforts went into something used every day? I’ve seen problems like this throughout my career, and it makes me stop and wonder about where my energy should be placed.

Scrum: A Breathtakingly Brief and Agile Introduction

by Chris Sims & Hilary Louise Johnson

I’ve been on a handful of scrum teams. I understand scrum and I like scrum. I’m not going to go into the strengths of scrum, or the negative points (unless painfully obvious in the book) of scrum. I’ve done other agile types of development, but scrum seems to be the strongest for the corporate world in my opinion.  With that said, I’ve never been on any team that fully follows scrum. There’s always subtle variations to it that the team needs. The basic ideas are the same though.

The book is short, and you can read it in a half hour. I think it is a great introduction to scrum, and some of the basic goals from all points of view. I would recommend this to anyone who has not been doing scrum, or wants to know more about it. If you’ve done it on a couple of teams, there will be nothing new for you.

The book starts out talking about the types of team members. There are three – the Product Owner, Scrum Master and Team Member. The one I found interesting and I think needs to be addressed is the Team Member. Team Members need to be cross functional in my opinion. The book talks about specialization but later retracts it a bit.

• “People who do the work are the highest authorities on how it should be done.” This to me brings to light one of the biggest downfalls of scrum, and that is poor architecture is often a result of scrum. When a developer has a misunderstanding of the ultimate goal, or different point of view, this can lead to poor decisions with architecture. You also must remember that not all developers are strong in the architecture area
• Doing my job vs. Doing the Job – The ultimate statement of being cross functional. It doesn’t mean you have to be an expert in all areas of technology of the product, but you need to be able to do it.

This goes back to my cross functional team members. I believe that scrum is under the fundamental understanding that nearly everything is able to be completed by any team member. Sure there may be a few things that are an exception, and not everyone will be on the same level, but everyone needs to act on the best interest of the team.

The book brings up burn down charts. Burn down charts are awful any time the scope changes. For example, if my product owner comes to me and adds 6 hours of work to the sprint, and I complete 8 hours of work the same day, according to the burn down, it looks like I only did two hours of work. Additionally, you show me a release burn down where there isn’t a story added. When a story is removed (say it is no longer necessary) it looks as if the team did a great job! I much prefer the idea of a burn up chart.

Meetings vs. Ceremonies – I forgot about the “ceremonies” title. At first, a major selling point of scrum and agile was less meetings. I was sick of having meetings every other day to discuss status on work. Those meetings were an hour or longer. With scrum you have more frequent, but shorter meetings. Probably a wash in reality.

Sprint Planning – I’ve never done scrum with a full time product owner. Having a dedicated resource to be a product owner is expensive. As a result, I’m reminded that I’ve never done sprint planning as efficiently as it could go. The book divides sprint planning into two parts that I don’t necessarily agree with, but I understand what they were going for.

• Part 1 (What will we do.) – The product owner decides what stories will be considered for the sprint. To me, this is pointless. The point of the prioritized backlog is the indicator of what should be done. This step only exists because product owners do not keep the backlog up to date.
• Part 2 (How we will do it.) – The team breaks up these stories and tasks them out. The product owner is available for questions on how to do this. I’ve never had a product owner regularly available during sprint planning. As a result, I believe developers need to groom the stories early to help understand the stories. This will not occur during any “sprint ceremony”, but needs to be a regular occurrence. This will also help understand the end goal of the system. The problem with my preference is that it does take a lot of time.

These are based on my experiences and opinions of scrum. Like I said earlier, every scrum team has their own obstacles that won’t work in the textbook definition of scrum. Scrum is about small teams. And if you don’t have a small cross functional team that can be trusted, you’re in for trouble down the road.