Delivering Working Software
Delivering working software in short iterations again and again at a sustainable pace is very challenging in your first one or two projects because it’s unfamiliar territory for you and your team members or your business users. Let me tell you a story. Several years ago, one of my project teams chose to deliver in short iterations. We took on more than we could deliver to demonstrate our good intentions. We accommodated changes generously any time and every time. I hear you saying, “That’s crazy! That’s not agile!” Our product owner had a bad case of “feature-itis.” We wanted to prove ourselves by making our PO happy. We feared saying no. We never paused to reflect. We never followed through to get feedback from business users. You can guess what happened next.
Of course, our team members experienced a lot of stress and burned out. It was a clear sign of an unsustainable pace . Cutting the long story short, our approach did not consider learning and the ability to “inspect and adapt.” We had to pause and reflect. We planned for a one-day team meeting offsite to visualize the future of our project. We had to do a major course correction or an overhaul to improve our approach. That is when we realized the power of perpetual team learning, team retrospectives, and learning from customer feedback.
Agile teams have to be disciplined in order to deliver in short iterations and ensure positive reinforcement as they move forward. This is possible when iteration activities happen meticulously. For example, iteration planning—which includes understanding user stories, estimation, creating a work breakdown structure, identifying dependencies, making a commitment according to the team’s capacity, and many other activities—lays a good foundation for the rest of the iteration. Also, the effectiveness of iteration end activities, such as review, demo, and retrospective, enable continual improvement in upcoming iterations.
Learn, Apply, and Improve
These days I start my coaching sessions with the simple question posed earlier: “How do we learn?” I don’t just ask this question. I ask the team members to ask themselves. I encourage team members to spend some time in self-inquiry and find answers. This is done in a group setting. When I initiate this exercise, the participants open up slowly, share their answers, and start conversing. That helps them realize how they learn as individuals and understand the commonalities to maximize team learning. I think this is where agility starts.
You have to go through this “learn-apply-improve” cycle in your team. You learn from two primary sources: team retrospective and feedback from the business user. Collective decisions and action items based on what you learned help your team improve, and that results in positive reinforcement. This is because you went through the learning experience and made a collective decision about what to do next. No one else external to your team came in and told you what to do. Isn’t it such a simple thing to begin with?