Taking An Agile Project To The Next Level

For the past three months, I have been working closely with one project to improve their production management processes. They were already working with a basic implementation of Agile project management with Scrum, but they reached a stage in the project where they needed to take what they were doing to the next level. The client had their own Agile implementation and the two processes needed to be integrated to create something that would work end-to-end. Initially, I spent a lot of time understanding the needs and process of my internal and external clients and focusing the process improvement effort.  As we implemented the needed changes, there were many other things we learned along the way.

Have someone 100% dedicated to the process improvement project.  This was the first time I was acting as a consultant external to the project. Usually, I am the project leader working on the project as well as championing process improvements. While I was providing extra capacity for the project team to do the process improvement work, I was only able to dedicate approximately 50% of my time. The other half of my time was divided between all the other productions I support, along with my normal day-to-day work with the teams that report to me. I am happy with what we accomplished, but it would have been better if I had been 100% dedicated to that project. I would have been able to have more micro-interactions with the team along the way, rather than calling 60 to 90 minutes team meetings when absolutely necessary at less than convenient times. For a short periods of time, I was able to do my work while sitting in the middle of where the team was doing their normal day-to-day work, which was invaluable for me to see in action what was and was not working with the old process. Had I been working on this project full-time and co-located with the team, the team would have been more involved throughout the process.

Make sure everyone who needs to be involved is there. While the timing to do this worked well in the project’s schedule, it was also while key members of the team left for summer vacation. Every time a key person went on vacation, progress in that area slowed down. When they returned, they needed to be brought up to speed again and their input came late. If I had the choice, I would do a process improvement project either before or after the summer vacation season. Unfortunately for this project, it would not have been possible since the new process had to be put in place before this current round of product development.

Test the process and the tools before you deploy.  Central to the process improvement effort was creating a new project in Jira with a simpler workflow and using the Agile tools in Green Hopper.  Some were surprised that I insisted that we thoroughly test out the new workflows, most of which I did myself.  If you roll out new tools as part of a process improvement initiative, they will not be adopted by the team if they do not work as expected.  While testing things out, I had the opportunity to think about some of the details of the workflow in practice, which I was able to adjust before rolling out the tools.  In addition, even though the team was familiar with Jira, I presented a basic orientation to the new workflow to the entire team before we switched over.  We caught a few other minor bugs and every member of the team had the opportunity to ask questions and provide some feedback before making the workflows final.

At some point, you just need to take a shot at trying the new process.

Sometimes you have to just do it.  As previously noted, the first phase took about three months until everything was put in place.  About halfway through the project, when some of the issues of the old process got particularly painful, I suggested that we start switching over to the new process without all the new tools in place.  Agile and Scrum are about customer focus, maintaining a prioritized backlog, regular communication practices and focusing development on the highest priorities first.  All of this can be done without any fancy tools.  For teams that are new to Agile and Scrum, I strongly recommend learning the principles and practices without any electronic tools beyond a simple spreadsheet.  For this particular project, a lot of the existing process issues were purely social and could have been addressed anywhere along the way.  Unfortunately, there was a strong preference to wait until a previously scheduled event.  I still think we could have started addressing the social practices earlier and evolved them as the other processes developed.

It’s all about coaching in context.  Over the years we have trained a lot of people on Scrum.  While training is necessary to educate people on the principles and practices, it does not really become clearly relevant until it is applied in the context of a real project.  For this specific project, more than half the team had training and/or experience with Scrum.  Still, most of the questions and discussions were about solving challenges in the context of the project.  Whenever a team is learning a new process or evolving an existing process, having someone with experience coach the team is valuable.  The coach should not solve the problems for the team, but instead make thoughtful recommendations that help the team solve the problems themselves.

All in all, I am happy with what we accomplished.  As the team stabilizes on the new process, we will be using retrospectives to continuously iterate and evolve what was put in place.  That is true Agile development!

Related Posts:

• Focus The Effort
• Understanding The Customer
• How To Create Customer Satisfaction