AdamM

Trying to move to an Agile organization is an interesting endeavor. On one hand trying to be Agile without management or executive buy-in almost always fizzles before it reaches critical mass. On the other hand trying to force Agile down from above tends to result in teams going through the motions until management abandons the attempt and returns to status quo while awaiting the next trend. To succeed in an Agile transformation everyone needs to be on board and willing to change.

If you are trying to push Agile up in your organization there are right and wrong ways to do it. Starting out an Agile transformation by telling your manager that the team needs to be self-managed will likely give a negative initial opinion to them. You basically told them you want to cut them from the team. Instead think of what supports the organization. Sell Agile as a way to provide better value faster. Notice I didn’t say more value. It needs to be clear that generally the team will deliver the same “amount” of stuff. The difference is that an Agile team will generally deliver more relevant stuff than a non-Agile team. Over time this might have the feel of more stuff. It might even, in a high-performing Agile team setting, be more stuff. It will likely not be significantly more though, so leave that out of the sales pitch.

Likewise dictating Agile to teams is not always an easy proposition. Think of how it is sold. Most organizations that decide they are going Agile today will send their PM’s to Scrum training, institute a bunch of meetings, and expect “better” results. One problem occurring is that they aren’t really open to change. Management wants the team to change their processes, but will not let the team drive that change to what works best for them. The team is expected to do all the changing in this transaction. The failure points should be clear when management steps back. Agile pushes teams to self manage; let them figure out the right process. Give them the goal, sell them the vision, and let them deliver. In return, be open to feedback from the process. Support the team in their attempts to deliver, even if it means change. That doesn’t mean bend to their will, but have open discussions and show willingness to change when it makes sense.

Most Agile methodologies and frameworks will expose problems with the current way of working. Some problems will be at the team level, some will be at the management level. Both parties need to be willing to acknowledge the problems and work through them for the Agile transformation to succeed. Agile transformations are going to be hard. Any change is generally hard, and truly embracing Agile will likely drive significant change. Bringing the entire organization on board will ease the transition, leaving half of it off will stifle it.

Kanban is a change method I have not had the opportunity to employ here. I wish I could though. The apparent simplicity appeals to me. That’s not to say that Kanban is going to make life simple. Deciding to use Kanban in your project should not be taken lightly. If you thought Scrum exposed issues in your process just wait.

Most of us have heard of Kanban. We’ve likely even heard that it comes from lean manufacturing efforts at Toyota. I’ve written about it briefly before here and here. Our own burn-down chart has a level of resemblance to a Kanban board. A different team here is trying to use it as a primary work process. Even with all that I think we miss the point here, and maybe you do too.

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?