Change for the sake of change is not a good way to run a company. Truly it’s not even a good way to run a team within a company. Constant unnecessary change will drain a teams energy. It will prevent Agile teams from becoming high-performing.
By that same token never changing is an even bigger failure. The real trick is to do the right amount of change at the right time for the right reasons. This is what we deal with as we try to become more Agile. Every situation is different and I am not going to pretend to have all those answers. What I do know is that there are some general guidelines to help us create an approach to implementing Agile based on how ready the organization may be for change.
One of the worst things to have happen at work is for everything to be OK. Last week I read a post over at Managed Agile Development. It got me thinking about the push towards Agile that we are making. We have met with resistance, and some of it is most definitely because things here are OK.
Our development process doesn’t have a huge pain point. Sure, we have some irritation here and there, but nothing really hurts. With nothing causing a large amount friction there’s resistance to change. Continue reading
When looking for information on Agile, software development is the most common industry represented. Within those results more often than not Scrum is used as the implementation. Many articles that try to talk about Agile in a generic sense use terminology from Scrum. A common side effect of this is that many people associate Agile and Scrum on a 1 to 1 level. This is a problem.
Earlier I introduced the concept of Planning Poker for estimation. (Part One. Part Two.) This has continued to be a very good tool for our team, and specifically our project manager. While most notably used for estimation, that is only part of the benefit that is received by using a process similar to Planning Poker. To our team the interaction between the team and the product owner coupled with the team wide understanding of upcoming user stories are bigger benefits.
When I first introduced this new form of estimation to the group I made a mistake. I did explain the concept of story points to the group and even had cards made to represent them. The cards all had graphics backing the central number to help frame them as relative effort. Boxes play heavily into the product we develop, so I had single boxes, groups of boxes, and pallets of boxes for the story points. I also created a separate set of cards for estimating tasks and bugs. They were to be done in hours, so they had cards with numbers and no background. The mistake is that the story points were set up with the same set of values as the hours.