I recall that during an agency meeting conducted to plan the kick-off for a new project, I recommended that the project be done using an agile approach. Although some in the meeting were interested, the key project sponsors were not willing to risk departing from an established and familiar project planning methodology that was in place. It is often true that state government administration offices develop, recommend, and in some cases enforce the use of methodologies that have evolved from mainstream approaches to suit the needs of government. In this case my sponsors felt that the risks of departing from the methodology outweighed the benefits.
So while I wasn’t able to go full-steam ahead with agile, I was able to implement some of the basic elements of agile methodologies and, in doing so, took a step in the right direction. Here are some of the things I brought into the organization.
1. Weekly Status Reports: Not normally a part of agile development, status reports were contractually required for each consultant for this state government agency. The first simple step I took was to get the agency’s approval to change the format of my team’s reports. This was a step for which the team members were grateful because it simplified their report preparation. I asked that they provide the three key items: what they hoped to accomplish for the week, what they actually accomplished during the week, and what they encountered that affected the work or has the potential to affect their work in the near future. Some may recognize these as the items normally discussed in daily standup meetings for scrum-based teams. This was intended to change the team members’ mindset to think in terms of the near-term goal. Past reports regularly included a narrative about methods used to solve challenges while the newer format focused on accomplishments and barriers.
2. Information Boards: This government client’s development teams have always worked based on “tickets” (features, bugs, information requests, etc.) maintained in a simple tracking system. Tickets have titles, descriptions, assignees, etc. Using data extracts, Excel formatting, and an old-fashioned paper cutter, I was able to create physical cards, one for each relevant ticket. Those cards were attached using pushpins to a blank wall of an unused cubicle, and suddenly, without adopting full-blown agile, we had a scrum board. At a glance, team members and management could see what was being done and what was to be done next.
3. Daily Meetings: My teams had been used to occasional meetings aimed at clarifying requirements or determining a development approach. During a period of high activity where we were implementing a large number of features, I asked the team to meet with me on a daily basis for fifteen minutes to help me understand the current status and to let me know if they needed anything from other teams or agency departments. Nobody was particularly excited at first, but after a short time team members recognized the value in spending only a little time discussing the project progress. This meeting was conducted in the cubicle that held the information board mentioned above, so part of the meeting also included the ceremony of moving things across the board to indicate each ticket’s current state. Since that first use of the daily meeting, I have expanded the approach to all other development teams, whether they are simply maintaining systems or are doing significant development.
4. Progressively Elaborate: Using an established approach from more traditional and accepted methodologies, we defined something analogous to a minimum viable product (MVP). Our version of the MVP was the initial cut of the application with sufficient features to support a significant facet of the agency’s needs. This was the initial code release that went to user testing for feedback related to things such as page flows, look and feel, and navigation. It was our first ‘sprint.’ Additional sprint planning occurred using feedback from the prototype and from our own rolling-wave planning sessions, focusing on details for the near sprints and concepts for the later sprints.
5. Product Owner: It was my goal to include a representative from the agency to be a fully involved part of the team, even recommending that person be relocated to an empty work area in the development team’s area. We never really achieved that level of participation from the sponsor team, but we did have a very active and involved business participant as part of the team. That person was often shadowed for a good portion of their day by our business analyst, so like it or not, they were participating in the elaboration of requirements. The empty work area eventually became an area where UAT could be conducted within easy reach of the developers. Office politics and a sense of desk ownership prevented us from having a fully engaged product owner, but we did have a level of participation from the agency that we had not been able to achieve in past efforts.
So how did we measure up compared to the principles of the Agile Manifesto? Through a more involved business participant and by having daily meetings, I feel we met the goal of favoring Individuals and interactions over processes and tools. Using prototypes and an iterative approach, coupled with abbreviated status reporting, I feel we made gains in favoring Working software over comprehensive documentation. Using our versions of the scrum board and product owner, we approached favoring Customer collaboration over contract negotiation. And again, our iterative approached helped us move towards favoring Responding to change over following a plan.
Clearly, we did not meet my initial goals of doing the project through a full agile approach, but the project’s success encouraged me to work with the agency to continue testing the waters.