We don’t develop courage by being happy every day. We develop it by surviving difficult times and challenging adversity.
Barbara De Angelis
I remember the first time I worked on a team trying agile. We had dreams of big changes and productivity. What resulted after training and setting up some backlogs was more chaos than productive. We made so many mistakes that helped us when we tried it again later on. The adversity was real and some of it came from our misconceptions. Let’s review some of the major tribulations that agile can bring forth.
Scrum requires the team commit to completing software by the end of the sprint. For people coming from waterfall, this can be a challenge. When you used to get six months to produce something and now you get two weeks it is a big change. This can lead to teams being unwilling to commit to shipping software. Other things that can happen are the team may commit to way more than is possible. This can cause initial distress on a team that is already changing a lot.
Working in Teams
Before we made our first transition to agile we had one team member who was kind of a loner. He always liked to work by himself on some of the tougher assignments. Once we tried to first work more collaboratively he struggled. He was a bit territorial about the code he worked on. He didn’t want certain developers touching “his” code. We tried to work with him on this but to no avail. He ended up leaving. Overall it was a good thing as it opened up opportunities for other developers to learn new things and work more collaboratively. There was no more “my code”, just our code. That is part of the truths about agile, it is not for everyone.
I am sure at some point you have gotten feedback that you didn’t like. As a scrum master, I have gotten feedback some was positive and some negative. The negative feedback can be constructive and helpful. In this article, they remind us not to ignore feedback, especially from our customers. “Customers are your most important stakeholder. Let them help your organization craft the vision for features and functionality.” Since your organization’s job is essential to reduce and alleviate their issues it is important to consider their viewpoint. How do solicit their opinion? Make sure you continually seek customers input.
One of the great principles of scrum is the iterations or sprints. As we experiment with agile we don’t realize how much work we can get done in a short time. We do need to break our large tasks or epics down to bite-size chunks. One problem that many new teams face is the challenge of timeboxing. As they point out in this post we will hear, “Some development efforts don’t easily fit into a time-boxed sprint.” There are techniques to break down these big chunks to fit your sprint. One good one is too narrow the focus of what you are trying to change. How small of change can you get done in your two-week spring? Changes are possible you just need to try some different means.
For the project manager turned scrum master this seems to be a common issue. They miss the part about self-organizing teams and allowing the team to choose their work. The command and control paradigm doesn’t die easy. They tell the team who will work on what and when. Of course, the team doesn’t seem much different from the waterfall approach. To them, things seem the same just with more shipping dates.
Agile is a different way to deliver working software. The team can focus so much on the changes that part of agile and miss getting their work done. If this happens the management will see no benefit. The team leaders need to keep the agile novelty in check. Make sure the team is still making progress on their commitments. In time the team will learn the benefits and how to work in the new system.
Many people fall into this trap where they think technology can solve the problem. In this article, they talk about how we focus on the tools before we understand agile or scrum. I was called to help an organization once fix their issues with Jira. The problem was it wasn’t a Jira problem it was they didn’t understand the process. I tried to help them see this but, I could not convince that what the actual problem was. Don’t use technology as a hammer and every problem as a nail. Understand the basics first before you add tools.