stockimages – freedigitalphotos.net
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. Continue reading
SweetCrisis – freedigitalphotos.net
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?
Boians Cho Joo Young – FreeDigitalPhotos.net
There. I said it. Agile is not the be all, end all solution for your project woes. It’s not the ultimate answer to the question of building software. On-time, within budget, highest quality; these are no more promised in a project done via Agile methods than one done more classically.
One thing that really needs to be understood here is what is meant by “Agile.” I have seen people use the word Agile to refer specifically to Scrum more times than I can count. (Pro-tip: this is wrong, just wrong.) Many use Agile in reference to a family of tools. Agile is also used to denote a family of practices and procedures. This isn’t wrong per se, but it doesn’t tell the whole story. Continue reading
Stuart Miles – FreeDigitalPhotos.net
Every attempt at transition can have issues. Some issues are fairly common regardless of who attempts the transition. No matter who tries to cross the Sahara there will be a lack of water available during the trip. These common issues are often called red flags.
Every desert crossing attempt is unique. The people and methods involved vary. Some may be making the trip over the course of week, others in just a few hours. In each of these circumstances the best way to address the lack of available water is very different.
In Agile transitions there are also red flags. Just as with crossing the desert each Agile implementation is different. As such there is not a proper way to address every issue every time. The more similar organisations are the more similar the solutions may be, but even that is not a given. Today we are looking at the Agile red flag of a combined Product Owner & Scrum Master. Continue reading