This blog will share my thoughts on Agile development and broader issues of team dynamics that go beyond Agile and software. I started this blog for several reasons. I have been coaching software development teams for some time (see Author Overview). Now I am focusing on the transition from traditional software development to Agile. In these efforts, I notice a lot of things and wanted a place to write my ideas down, share them, and start conversations. I also want a platform for my general musings on Agile development. I am partnering with other people including Bill Ives and David Socha in order to provide other perspectives (see Author Overview for their backgrounds and how we will work together). We plan to experiment with a number of different blog formats and welcome your input.
While I will reflect on the tools a bit, tool technology is not my main focus. I am more interested in the team and process issues since it is people, in the end, that have to get these tools to work. I have studied family and team dynamics and like to apply principles of complex adaptive systems. I feel that when things break down, or even better before breakdown occurs, we need to move beyond managing symptoms and treat root causes.
Let me offer an example, in most development shops noticeable time is spent prioritizing and dealing with bugs. That effort only manages the symptoms. It can be more useful in the long run to look at the operational side of development. An interesting issue is the time that elapses from when a bug, an unwanted change, enters the system and when it is detected. I have been in situations were that time was measured in minutes. Then developers could quickly learn from their mistakes, make immediate corrections, and move on. They learned and produced fewer and fewer bugs. Then we did not have to spend time prioritizing and dealing with long lists of bugs.
I will get into much more detail on many stories such as this one in the blog.
Sometimes it helps to turn things on their head. I was once asked to faciltate a release retrospective for a group of teams. I asked for six hours of their time. In these sessions in the past they would engage in examining what went wrong. The groans were loud and some team members decided to only dial in. Instead of looking at the mistakes, we talked about the times when they were most thrilled with a team’s performance. We never once discussed what went wrong, the positive energy level rose, and some of those on dial in came into the office for the remainder of the session. The team got back on a more positive track. Of course, I do not always get it right and I will share these stories also.
This blog is sponsored by Serena Software, a provider of application development and business software for companies of all shapes and sizes. I work for Serena. Some Serena’s tools and services support Agile development. We might talk about Serena on occasion, but this conversation is not about Serena, it is about the issues that everyone faces in Agile development.
Bill, David and I encourage you to browse our categories and not just look at our latest content. The categories contain the archives of our past posts. Many of these posts should remain useful as we will discuss issues in depth and not simply provide current news. Also use our search field. Often good blog content gets buried as it moves off the front page.
If you like what you find here please join the conversation through our comment fields. Our blog will allow us to learn of your comments regardless of when the original post was published. We look forward to hearing from your perspectives. We want to learn from you and we look forward to your participation.
a
Comments