Jeff McKenna's Agile Development Blog

Junkies and Zombies: Patterns of Project Behavior

Yesterday I finished reading Adrenaline Junkies and Template Zombies - Understanding Patterns of Project Behavior by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Suzanne Robertson. Whew... with a list of authors like that it must be good or at least long.

It is good and it is not long. It is a very readable compendium of 86 patterns with a couple of ‘interludes’ to break things up. The patterns are in a short, fairly informal format of some two to six or seven pages. Each describes a way we operate or operate in organizations. There is some gentle discussion of details. And an even more gentle treatment of those patterns that are judged less than ideal.

The book supports achieving a goal of mine for all teams and individuals on those teams: Becoming more conscious of the work that we do and more conscious of the relationships that we are in as we do that work. The patterns are presented as a way to think and reflect on how we work together. Some are more technical, some are more relational, and some are individual.

The names give many of them away: Face Time – about talking together; It’s Always the Goddamned Interfaces – exploring the congruence of teams and components that they build; Sanctity of the Half-Baked Idea – notices that if only ‘good’ ideas are allowed the great ideas are more difficult to find.

I recommend this book. Enjoy it one small bite at a time.

P.S. As I was reading the book I found myself wanting to score myself and score my current job situation. How was I doing? How were we doing? What was our Zombie Score? Perhaps the authors can provide a simple spreadsheet and do some analysis. If the Zombie score of an organization is good, are they more successful?

My Eight Current Agile Blogs

When I put together this blog I wanted to make reference to other bloggers. I noticed that there are a lot of Agile blogs. What I chose to do is to pick people I knew or blogs that I found particularly interesting. There are many, many others. Have fun browsing!

Tobias Meyer writes the blog, Agile Thoughts. He is one of the most interesting trainers that I know. He is very opinionated. I know him personally and really enjoy being around him. I have learned a lot from him. Tobias is always very thoughtful and I really respect his opinion. He is particularly interested in the games we play to help people learn.

Mike Cohn writes the blog, Succeeding with Agile. Mike is a classic and was on the Board of Directors of the Scrum Alliance for a long time. He has written some of the best books on Agile. He is very strong in what he believes Scrum should be. I have trained with him. I enjoy being with Mike a lot and he is very knowledgeable. He has thought out a lot of things and is not afraid to make controversial statements.

Ken Schwaber writes the blog, Edge of Chaos: Edge of Chaos, Agile Development Blog. He is the man who put Scrum on the map. He went to conferences starting in the mid-90s and talked about Scrum and learned more about it. Ken co-wrote the first book defining Scrum and is the “father” of Scrum in a sense of getting the word out. He put together some of the first training programs. Ken is still active. I see him about twice a year at the Scrum gatherings.

John Scumniotales writes the blog, Agile Product Development. He was on the very first Scrum project, which I also had the pleasure of being on. John was, in essence, the very first Scrum Master. He is now a VP of Engineering at Serena Software. He is taking Agile up through the enterprise. He has been very concerned with how to bring Agile practices as you move up the management chain. We have disagreed at times but he has thoughtful articles about his experience, more on the management or executive side of Scrum. I read his blog fairly often.

Jeff Sutherland writes the blog, Scrum Log. He was the intellectual founder of Scrum. He did all the research with the Japanese. He was the CTO of the first Scrum project that John Scumniotales and I were on. Jeff is a very interesting fellow with two MDs. He was a fighter pilot in the Korean War. John is full of energy and goes around the world training people in Scrum. He is constantly pushing the boundaries of Scrum. You should read his articles about red and blue Scrum. He has said that if the project team does not have a velocity in place after two or three meetings you should disband the team and start over again. I think of what he does as tough love or “tough Scrum.” Jeff is a great guy who always listens carefully to what you have to say.

David Anderson writes the Agile Management Blog. David is from the Lean thinking approach and I find him very interesting to read. He has a lot of good ideas. He is very much into measurement and its effects on projects. Lately he has been chatting more about Enterprise Agile and more focus on Lean.

Corey Ladas writes the blog, Lean Software Engineering. I do not know him but I find his work in Lean very interesting as we bring the Lean practices more directly in front of the Agile process. Clearly Agile and Lean are closely tied together. Corey makes this very explicit.

The Agile Advice blog is subtitled Working with Agile Methods (Scrum, XP, Lean). I do not know this writer but it is a blog I saw that I liked. I thought it was interesting and wanted to include it.

The Importance of Quality Engineering Practices in Agile Development

As I have working with a number of Agile development efforts I have noticed the importance of quality engineering practices in Agile adoptions.

Agile work management is about orienting people to make the right work at the right time. I sometimes think of it as the TIVOing of software development. We are timeshifting work. You wait and do things at the right time. Ward Cunningham, the inventor of the wiki, talks about only doing what you know. Don’t do what you don’t know. This is a critical quality in how we experience development in Agile.

A clear prerequisite to being able to do this is quality engineering practices. We have discovered that many organizations do not have a clear understanding of this. Now quality is a fairly broad term. It can be interpreted in many ways. People say, well, of course you need quality engineering. And I have a specific take on what I mean: a quality of correctness. It is correct.

It is little things like the code works and it continues to work. It does not have bugs in it. The code actually fulfills the purposes for which it is intended.

It is finished. Sometimes the code never seems to get done. There are always some bugs associated with it or the documentation did not quite get done.

And we have experience with this. It can be achieved. The project I mentioned in the post, Achieving Immediate and Continuous Bug Fixes in Agile Development, is an example. Because we wrote with sufficient unit tests, because we had good automated integration tests, because of a 100 regression test way of thinking, and because of continuous integration that ran these tests, when we finished a piece of code it was done and there were very few bugs, never more than 5 at one time for the entire project.

Now this does not mean that we had all the features you might ever think about. In my mind that is the trap we fall into. We say: ‘Oh, that feature should do X and Y should be done in a different way.’ That is not what I mean by done or quality. Quality means that the system does what you want it to do at that moment in time. We take small steps and make sure that each step is done in a quality manner.

Later, you might add some different features or change features to respond to market pressures, better ideas, customer input or other conditions. However, when the new stuff is put in, these additions also have the quality of correctness.

This requires good engineering practices. It is interesting to consider this because what happens is that the teams that achieve this way of thinking/acting with their code are very productive. They feel better. It is fun to be around them. They are always thinking about new things because they do not have to think about the old things any more.

The social side is that they are more willing to try new things. It means that there is more innovation in the products. They know that if something is done it will be quality or they will just take it out.

I see Agile being like the train running down a well laid set of tracks, constantly moving forward on a solid foundation. When the foundation is kept strong (the attitude and practice of quality) the train can easily move. As you go forward everything is working and you are just advancing. More alignment is naturally achieved.

In fact we use the term release train to refer to a particular way of deploying software on a regular basis. It is this feeling. You are on an engine that is running and you drop new requirements in as you go forward and working functionality comes out the other end.

This causes some other issues. At times, developers never feel they are done. So we need to address this human need for accomplishment and build in pauses, vision setting, and reflection to address this human need. You need to have the team take time to stop and look at their accomplishments.

This means that way down deep inside the team has good tools and a good sense of what testing is. The developers know what good design is and how to recognize it. They know how to change the design if the requirements change. Extreme programming really pointed the way to achieve this quality. If you do not do this then Agile becomes just another process that sort of works. The old ways come back: schedules slip, bugs proliferate, morale declines.

I wanted to discuss quality engineering because it is important for people to understand that Agile is not just about making short iterations. An attitude of quality is important. It is an old software adage to get the best people you can. Here we are suggesting that the best people as those who know quality engineering.