I have recently started a new job and needed to go through my stack of software books looking for ones that might be helpful. I ran across a book I read many years ago that has probably helped me more that any other book with project management. This book is not a software book though. It is Influence, The Psychology of Persuasion by Robert B. Cialdini, PH.D. This book helped me realize that developing software has more to do with people than computers.
I found one chapter in the book particularly helpful, Chapter 2, Commitment and Consistency: Hobgoblins of the Mind. The main gist of the chapter is that people try to be consistent with their actions; therefore by getting commitment from a person you can guide them to a desired action. One example of this is the free SWAG many companies give away. If Apple can get you wear their new cool shirt they are giving away, you will start seeing yourself as an apple person. When it comes time to by a digital music player you will be more likely to buy an ipod as an automatic response to being consistent. Generally speaking the more public the commitment the stronger the consistency response will be. That is why they say if you want to lose weight or quit smoking you will have a better chance by making your intentions public.
At the time I read the book I just started as a Project Lead. One of the first things I ran across in my new position was the issue of poor requirements. These came in several variants. One was the vague requirement that could fit almost any problem. Another was the software solution disguised as a requirement. All this was mixed with requirements that where just plain wrong. Considering myself a pragmatic person I decided that we would revisit each requirement just before we where ready to implement it. To my surprise this approach did not work. As far as the project manager was concerned, the requirements where done and did not need further discussion, no matter how small the change would be.
I later realized that commitment and consistency was the source of the problem we where having. The project manager spent a great deal of time writing the requirements document. It was a mark of the project managers work and who she was. Asking her to break her idea of consistency went against human behavior, and was bound to fail. The problem was not the project manager or the requirements but the process that required a great deal of commitment to information that stood a good chance of being wrong. The trick is to match the level of commitment to the task.
Extreme Programming offered a nice solution to this particular issue, the stories on a note card. This solution is nice as it offered a nice balance between commitment and change. The requirements document from my previous project interjected too much commitment. The note cards do not require as much work and is not as permanent or public as to cause over commitment to a requirement.
On the other hand, some things need a larger degree of commitment. For example time lines usually need to be kept. This is a good place for some kind of public formal agreement. I have worked on many projects where the management team sets the time lines and gives them on the team. This is a sub-optimal situation at best. A much better approach is to create a high level of commitment to the time line with the team.
Scrum has very good solution to this. The time line for a sprint is fixed and public knowledge. The contents of the sprint is decided by the team doing the work and made public. This gives the team the firm commitment that is needed to make the time line work.
I now find that I consider the level of commitment for any team task I am about to oversee. If I am having a problem getting the team to change course, I know I need to tone down the commitment on that part of the project. Conversely, if the team is having an issue keeping on course, I need to increase the level of commitment.
Wow, what an insightful way to look at things, that does make an interesting kind of sense. I also really love this argument in favor of doing user stories that don’t have too much detail (as well as leaving the farther out stories in the “epic” format).
I wonder though what the implications of this are for emergent design…?
Hey Jim did you mean ‘course’ instead of ‘coarse’ in the last paragraph. Interesting post though.
Thanks for the praise Abby. I have been giving a lot of thought on how to apply these concepts to coding. I think the main problem we as Software Engineers have with some agile techniques like emergent design, is an over commitment to the code we write. Some ways that this commitment can be lessen would be to emphasize unit tests as more important than the code. This makes sense as the purpose of the code is to solve a problem, not to be elegant. To do this we could quit doing code reviews and just review the unit tests. I am not sure what I personally feel about this. My whole career has been about writing better code. But I do think it is worth exploring.
I am a Software Engineering Student, and now I know just what I need to work in teams … a pistol … after killing few people, others will sure show commitment to me.