Agile Improvement Projects

Business needs for improvement projects are changing. Organizations expect faster results from their investments; they want their improvement projects to adapt to and follow changing business needs and be more engrained with the organizational way of working. The agile way of working, used more and more in software development, contains several mechanism that support these business needs. So the question is: Could an improvement project be performed in an agile way, and what would be the benefits?

Why use Agile for Improvement projects?

There are a couple of reasons to work agile in improvement project. It helps the business to adopt improvement projects to the changing needs, thus getting business value. Which includes making the value visible, and discussions on the value can be expected from the improvement project. Agile also helps to engrain improvement in the way of working of an organization. Many organizations have or are adopting agile development methods, and use techniques like retrospectives to continuously improve on a team level; it feels natural to adopt similar mechanisms for organizational improvement projects. Finally, since there are always limitations in lead-time and money (available hours of the team and of the organization that need to adopt the changes), you have to work efficient. Agile helps improvement teams to deliver quickly, and deliver maximum value with a limited budget. So altogether there are sufficient reasons, from a business point of view to adopt an agile way of working for improvement projects.

Delivering Training in an Agile way

I worked with a customer that wanted to measure and control the quality of their software products. We agreed to work on-site with the teams and management for a week, to train and coach them. In stead of making a plan for the full week, we only planned the first two days with a kick-off presentation, workshops, and daily evaluation and planning at the end of each day. This would make us flexible towards the needs of the various teams, which would become clear during the week. I made a short list of available trainings and workshops, and my customer picked the ones for the first two days. I also gathered and organized my presentation and training materials, to have them on-site during the week.

In agile terms: As a 1 man Team and Scrum Master I created a backlog and my Product Owner (customer) prioritized the User Stories (trainings, workshops, presentations) and picked the ones for the first two sprints (day 1 and 2). We decided to have a stand-up every morning to check the planning for the day, and to have a daily retrospective and planning game at the end of each day to evaluate the day and fix the planning for the next day. It would be a training week with 5 sprints of 1 day.

After the first day on-site, we did an evaluation (Retrospective!) and decided that we needed some small changes on day 2 (Planning Game!). We also made a draft planning for day 3, which included a new course to be developed (using partly existing materials). This way of working (Sprints!) was used throughout the week.

Additionally, on the 3^rd and 5^th day we had a short evaluation/planning session with the whole MT. On the 3^rd day, the MT asked me if I could do a presentation of how an organization could look that would use a full blown quantified quality management system. This was a pleasant surprise for me, as I didn’t expect that they would be willing and ready to take this step. I adapted a presentation that I’ve given as a keynote on a conference, and added specific slides on what we had done already in the past days. It was a great success; it helped the attendees to visualize how their “road to quality” could look. The employees asked lot’s of questions, and there were several good discussions between the managers and the employees, about the reasons to manage the quality of their products, and what the management can do to facilitate this. Neither the customer nor I would have expected this when we started the training. By working with agile daily sprints, and continuously adapting the training we were able to make it more valuable!

You might be wondering if anything went wrong, or if there were things to improve? Of course! Since every day ended with a planning game, I always had some “homework” in the evening. Incidentally this posed a challenge to have training materials ready for the next day, but I always managed to do it. On the 1^st and 2^nd day we had some training sessions which took more time then planned. Actions taken were to become more focused in the training sessions, and also allocate some more time for the sessions, or slack in between training sessions, to meet the schedule. With these improvements, we managed to met the schedule for the remaining days.

Summing up, Agile practices helped to deliver this training week and make it more valuable. The daily retrospective and planning game took only 15 minutes at the end of each day, and helped us to adjust the training to the changing needs. Every morning before the training started we had a short stand-up of 5 minutes to check if everything was ready. We didn’t really have a demo, but since my customer attended almost all trainings and workshops you could consider the full training day to be a demo. Where my customer could not attend, I briefed him on what happened when he rejoined the training. In the final evaluation on day 5, our conclusion was that delivering the training in this agile way had been very effective and efficient.

Process Improvement, the Agile way

The agile approach has been also been used in two process improvement projects, the first project for improving process management activities within a business unit of a multinational company, and the second to do selective and quick process improvements, in an R&D center to continuously improve the performance and results.

The projects used Scrum as method to coordinate and collaborate. The manager responsible for processes within the business unit was the Product Owner, who made user stories that described the services and products that had to be delivered by the Team. Given that this was an improvement project, the products produced were presentations, slide sets, and documents containing policies and text for the intranet or newsletters, and tasks that had to be done, like arranging discussions, workshops and meetings, and taking and communicating decisions.

The team consisted of professionals involved in operational development at the R&D centres. They were very experienced in process management, but most of them never worked in an agile team before. Based upon my agile experience, I became the agile coach, helping my fellow team members on how to fill in the different Scrum roles. I also organised retrospectives at the end of each iteration, and supported team members to implement the improvements that were suggested in the retrospectives into iterations.

We had a backlog with user stories from our product owner, and a first planning game at one of the R&D sites, where all team members gathered with the scrum master (our former project leader) and the product owner to discuss and define a first sprint, and agreed upon the user stories, and how we would do our “stand up” meetings, use a wiki to collaborate, and do the demo for our customers and the retrospective to learn and improve as a team. We decided to work in sprints of 3 weeks. The demo’s would be given to the product owner, and we would invited relevant members for our organizations to attend and give us feedback.

The wiki was our task board, and communication tool both within the team, and from the team (including the product owner) towards the organization. The project plan was a wiki page, which included the goal of the project, the way of working (our process), and contact information of all team members and stakeholders. Also the backlog was on the wiki. This created visibility for the improvement project; both in the communication within the team and from the team to the stakeholders. Planning games were done by telephone conference, where the scrum master continuously updated the wiki during the meeting. The user stories and engineering tasks were added, prioritized, and checked by the team which at the end of planning committed themselves to deliver the required functionality. The demo consisted of a phone conference with presentation. Team members and the stakeholders either joined in from their workstation, or (if multiple people were at 1 development site) arranged for a conference room with a beamer and hands-free telephone connection.

It took a couple of iterations to tune our “definition of done”. Having a presentation or document made was not enough, so we decided that a task could only be done if the products had been reviewed and commented upon by at least one other team member, and the product was updated based upon the review comments. Of course all documents and presentations had to use official templates and comply to the corporate standards, but this was something all team members were already familiar with.

Looking back there were several benefits from the agile approach as we used it in our global process management project. The main benefits that we saw were:

• Being able to deliver the right product with high quality, using frequent feedback
• Understanding the strengths & weaknesses of our processes, and the business value
• Alignment and streamlining of processes between several R&D centres
• Efficient ways for professionals to work together in a dispersed team

We were able to produce many documents, newsletter, slides sets and supporting material that the local R&D centres could use to align and improve their development processes. Though we have no hard figures, our impression is that it took us less time then usual to make them. An even bigger benefit was that the quality of the products delivered by the project was very high, and there was a strong commitment for the changes proposed by the project, due to the frequent planning game and demo meeting where we aligned with our customer and the stakeholders. Several R&D centres started to use the material while it was still under development to do their local process improvements. This helped them to start quickly, and come to results faster, and it also helped our process improvement project since we got feedback from the local improvement initiatives and were able to update our products along the way. All together the commitment for the process improvement initiative was high, both at a business unit level and at the local R&D centres.

In the retrospectives that we did after every 3 week iteration we discussed how the team member had experienced the agile way of working. It took some time initially to develop an understanding of the roles, and how to combine the team role with the local responsibilities of the team members. This because the team member had two roles in the team. First they represented their local R&D centre and acted as a linking pin to local process support teams, and the local management. Second they brought in their experiences and skills with process management. The aim of the team was to enable team members to contribute as much as possible from their experience to the result, increasing the effectiveness of the team as a whole. This resulted in team members picking up different tasks, depending on where they saw the biggest possible contribution. If we saw that higher priority tasks were not picked up, we discussed this in our stand-up, ensuring that they would be done in time before the iteration finished. This task approach could be conflicting with the representation role that team member had, e.g. in situation where certain process documents were to be made by a team member which would not be of use for his own organization. Where there were potential conflicts, we discussed them in our stand-up meeting, and we always managed to come to a solution. That could either be that another team member would pick up the task, or that the team member would make a first version which would then be extended by other team members based upon their experience. Though being dispersed, we managed to work together in pair where this benefitted the team. All team members were very positive about the agile approach, which enabled them to contribute to the end result. Also they valued the support of the other team members, which helped them to learn from each other, and to further develop their process and change management skills. 

Conclusions

This blog described how we have applied our experience with agile into training and process improvement projects. Scrum was used a as method to iteratively deliver a training, and products and services for process improvement. Retrospectives, stand-ups, and a wiki and telephone conferences were the main tools to manage the work and deliver results. Using agile, the training week delivered more value for the customer. The agile approach has shortened the lead time in process improvement, gave a better understanding of what our customer needed, and increased the commitment for the changes that were needed in the organization. The team members and customers appreciated this way of working since it helped them to continuously contribute value, and to develop their knowledge and skills.

More information

Several articles are available that cover the agile topics mentioned in this blog:

• Golden Rules for Agile Process Improvement
• What Drives Quality: Senior Management
• Getting Business Value out of Agile Retrospectives
• Measuring and Controlling Product Quality
• Using Scrum for Process Improvement

About the Author:Ben Linders has a broad international experience, specializing in quality, process improvement and organizational development.  Team worker, driven, supportive, and pragmatic. Committed to quality business results on time, continuous improvement & development of professionals.

Agile, Scrum, Lean, Six Sigma, Retrospectives, Lean Startup, Kanban, CMMI, People-CMM, Root Cause Analysis, Open Space, RUP, EVO, Props, Prince-2, ISO 9001, EFQM.

Email:              info@benlinders.com

Twitter:           @BenLinders

Website:          http://www.benlinders.com/