Project lessons learned in Agile implementation

Agile is by no means new in the world of Information Technology, but many public sector organizations are just starting to jump on the bandwagon. Treinen has been involved in at least 15 Agile projects public sector clients in our 20 years of doing business. We provide Agile project management, requirements tracking, and software testing, as well as Scrum Masters and Scrum coaching. We know what it takes to implement Agile, or a hybrid model, in the public sector with its many constraints. This comes from our shared experiences as a firm in implementing Agile, and the lessons learned along the way. We would like to share some of these lessons learned with you.

Treinen’s Agile project teams have been composed of project managers, business analysts, developers, and testers, as well as Scrum Masters and Scrum coaches.  The Product Owner and Sponsor roles in our experience have always been fulfilled by the client. Agile is often chosen due to the high risk of changing rules as programs change or are being created, frequent legislative mandates, and short timeframes.

Most of our engagements have used the Scrum framework to implement the Agile methodology. The best way to evaluate a Scrum team is to perform a retrospective – so we have divided up our lessons learned from several projects into four quadrants as we do in sprint retrospectives. We will start with the challenges, then move to the accomplishments.

What we could improve on next time

This category applies to what we did, but could have done better:

1.       Continue with Scrum activities. Daily stand ups, sprint planning, reviews and retrospectives are key to a cohesive team working toward the same objectives.   We have dropped daily stand ups and aggressive management of the backlog simply because our application of Agile was more hybrid, and we were moving from development of a new product to intensive testing before go-live. However, we still had work items to prioritize and people’s workloads to manage, and dropping these activities led to confusion and wasted time. It also prevented good change control.

2.       Get customer feedback earlier. While we did show off the product early to customers, and did give them early access with user acceptance and beta testing, we should have started even earlier. Even basic terminology differences led to confusion and frustration because customers were not trying to accomplish specific goals until later.

3.       Involve the Maintenance & Operations (M&O) team sooner. The agencies’ maintenance and operations teams were originally scheduled to take over the systems from the contractors who built the system six months after go-live. This was not accomplished and the contracted team had to stay on longer for knowledge transfer. We wish we had added the M&O team to our Scrum team and activities from the start to ensure an earlier and smoother transition.

4.       Better user stories with use cases and design specifications. While our user stories contained basic capabilities that were needed, and sometimes wireframes, there was often lack of clarity around the before and after each user story. Having use cases would have helped the team detail alternate flows as well as preconditions and postconditions for each user story. Decision matrices might also have helped with understanding the various paths a user could take through the system. In addition, having clarity around the design and layout of buttons, use of different controls, and flow through screens would have prevented a lot of churn after go-live with the primary user bases.

What we should have stopped

It is never easy to admit behaviors and practices, no matter how well-intentioned, that lead to greater challenges. Here’s what we should have addressed.

1.       Interpersonal disagreements. The team was passionate about the work before them, and felt the pressure of the immoveable time constraint, both of which led to challenging interpersonal dynamics. More team building activities and increased communication would have likely improved team cohesiveness and overall satisfaction.

2.       Weak change control. While Agile ascribes to anticipating and welcoming change, that change wasn’t appropriately prioritized in a couple of implementations. Some new work was brought in before basic feature requirements were met. This led to overcommitment of resources and burnt-out team members.

3.       Making changes without communicating or documenting the changes in any way. This is unfortunately common on Agile projects. The speed at which changes were being made required strong communication amongst all members of the team. Unfortunately, some changes were discussed verbally and not discovered by the rest of the team until defects were logged. In addition, when transitioning to new team members and our M&O team, there was confusion in some scenarios about what the system should do.

What worked well

Here’s the good part – what we did that led to greater success for the Agile projects on which we served.

1.       Use of a central repository, like Team Foundation Server, to track user stories/requirements, test cases, defects and releases. This succeeded because the teams were committed to using this every day and keeping their work updated in the repository.

2.       Executive sponsorship. This is critical to every project, but especially Agile projects. We have consistently had sponsors and product owners who were heavily involved in a daily basis in making quick decisions so the team received frequent feedback to keep moving forward and build upon the last iteration. We have been fortunate to have product owners and executives who actively supported the team with removing barriers and providing adequate resources to get the work done.

3.       Committed team. Every person on the team was committed to ensuring customers had an effective application for enrolling in their benefits. We have also been fortunate a few times with development teams that had worked together before, so there was little time needed for their ramp-up in working effectively.

4.       Agile coaching for organization executives and the team. This led to increased buy-in from executives as well as relatively quick decision making to continue releasing working software and meeting the schedule constraints.

5.       Strong communication with other program teams. With new programs or business strong communication is crucial to ensuring the IT side matches what is changing on the business side. Understanding how changes in policy drove changes in applications and architecture, and how the organization communicated with customers, helped our teams make adjustments earlier, saving time and money.

6.       Close collaboration with front-line staff. As we built the applications, we worked closely with the business teams who worked directly with the customers. This helped us understand what they needed, and how the system could work to deliver those needs. We provided “Train the Trainer” sessions that helped front-line staff better train and support customers with how to use the systems. We also worked together on webinars, user acceptance beta testing efforts to increase customer understanding and adoption of the applications.

Accomplishments

There is so much to celebrate from these projects and the outcomes for customers.

1.       In both projects, the applications were built, fully tested and brought online within schedule for our clients and their customers. These were major achievements given the tight time constraints, the number of capabilities needed within the applications, the interfacing with other systems, the new technologies used, and the amount of traffic that comes through the sites.

2.       Most importantly, the outcomes for customers were significant. Both applications resulted in increased customer participation in the agency programs, faster response time, and increased clarity for where the customer was in the business process and what to expect next.. This is what our work is all about – improving public services for our clients and their customers.

All IT projects have challenges, and these projects were no exception. But the successes overcame the challenges, and the lessons learned are being used to ensure greater success in the future for all of our clients.