Agile

I follow a lot of blogs related to Agile. I also follow many people on Twitter and watch a few LinkedIn groups. It all results in a lot of information available for me to digest. It also gives me a chance to watch some trends pertaining to what people are talking about. I will be the first to admit that I need to increase my net to get solid industry wide trends. (I am always looking for more blogs and people to add to my following lists.)

One trend I have seen a little of over the last few months is the idea of Agile Project Management and Traditional Project Management working more closely together.

I have stated in the past that I feel there is room for co-existence. While many “Agile Purists” push the idea that there is a black and white distinction between Traditional and Agile methods I feel it is more of a continuum. Chuck Cobb over at Managed Agile Development has really been pushing this lately. His concept is that we really need to redefine it such that there is no distinction between Traditional Project Management and Agile Project Management, and I totally agree.

Stop me if you’ve heard this one. The next big project is in trouble. A high performance Project Manager is brought in to bring it to fruition. They come in guns blazing. Change this process. Remove that documentation. Do these tasks. They know what needs to be done and by golly they are making sure it gets done, and now! If you aren’t part of their solution you are part of the problem. They will dictate what gets done, when it gets done, and how it gets done. The project finishes. Over budget and late, but it was failing when the new PM came on-board. It matches what was originally asked for to a T. It is considered another big success for the PM. Within a week the customer has a list of what doesn’t work and needs to be changed.

What about this one. The next big project is in trouble. An Agile Coach is brought in to bring it to fruition. They first observe what is happening. They talk with the team about delivering minimum viable functionality as quickly as possible. They talk with the Product Owner about what really comprises minimum viable functionality. They further work with both parties to break it down to least amount of functionality that can show what is being made. They bring that back to the team. They ask the team to meet a goal of the first piece of it in a short time-frame. They let the team decide what tasks are required to meet that goal. They show what is being made and solicit feedback. They connect with management about the process and how to allow it more freedom to succeed. The project finishes. On time and budget, but with a very different product than originally asked for. It is considered a big success for the team. Within a week the customer has a list of extra functionality they would like.

This weekend my wife and I took the kids to a park. Actually we took them to two, and there’s nothing all that unusual about this.

Our son has been really into bugs lately. Our daughter has been into whatever her older brother is into most of her life. At one point of this particular park trip our son had managed to get a small green Aphid like bug on his hand, It might have been some kind of treehopper or planthopper, or an aphid. I really don’t know. The kids called them “gillies.” The point, apparently, is that it was green.

See, my daughter wanted her gillie. She was getting quite upset that she didn’t have one in fact. I noticed she had a bug not unlike the one her brother did. She hadn’t noticed because it was on her arm near her elbow facing away from her. Being the helpful problem solving type that I am I tried to get her to notice it so she would calm down. When I finally did get her to turn her arm and look she started to shake her arm while screaming “get it off!” Moments after brushing it off she was proudly showing off the green one in her hand. What happened? I didn’t understand the requirement. I thought the user story was “I want a gillie!” Turns out the user story was “I want a green gillie!”

Often we spend so much time trying to deliver value we lose sight of who we are delivering value for. In an Agile environment the short cycle times are not there just to push out small bits of value as fast as we can. This should be solved by customer collaboration. When we collaborate we can verify our understanding of user stories. “User moves piece” becomes “User selects preferred move from list.”

That’s not enough though. Customer collaboration without responding to change is a failed implementation. Without adjusting based on the feedback we get we may as well not be collaborating.

Are you regularly collaborating with your customers? Are you changing based on what you discover?