Panera Bread chose Disciplined Agile Delivery (DAD) as the framework for adopting a disciplined approach to their agile adoption. This paper describes the approach that they used to learn DAD and apply it on their first pilot project.
1. Introduction
Panera Bread is a very successful and rapidly growing bakery-cafe chain with over 1700 cafes in 44 US States and in Canada. Panera’s IT group consists of about 250 people supporting a mixture of custom built applications integrated with off the shelf packages. In early 2013 the President made it clear that he was concerned about IT’s ability to keep up with the pace of change of the business. Panera decided that they needed to transform the enterprise to apply agile delivery in a disciplined fashion. In this paper we describe how within one year the company made great progress towards transitioning from a traditional model to an agile approach that is very aligned with the company’s established business agility. In the context of their first pilot agile project we show a specific example of how DAD’s goal-driven approach was used to make better process decisions for Panera’s unique context of the organization and their projects. Finally we describe how the PMO customized their governance for their new agile culture. A key learning of this experience was the value of investing in a deep relationship with the internal customer. The result was a greatly increased level of trust due to the degree of collaboration and its related transparency to all aspects of the delivery of the solutions.
2. Background: What is DAD?
Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver sophisticated solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders. Worse yet people don’t always know where to look for advice or even know what issues they need to consider.
To address these challenges the Disciplined Agile Delivery (DAD) process decision framework (Ambler and Lines, 2012) provides a more cohesive approach to agile solution delivery than individual agile methods such as Scrum or Extreme Programming (XP), making it easier for teams to make better process decisions when adapting agile for the context that they find themselves in.
DAD is a people first, learning-oriented hybrid Agile approach to IT solution delivery. That means DAD doesn’t tell you what you need to do when. Rather, DAD walks you through your process options, and their tradeoffs, which enables you to build a process that suites your needs within the bounds of the framework. It also means that you are allowed to incorporate valuable features of all the Agile approaches including: Scrum, Lean, Kanban, XP, etc.
While Scrum provides a decent framework for the construction phase of a project, DAD recognizes that there are many activities required to deliver a success solution other than just building the software. The DAD lifecycle explicitly calls out the following phases:
- Inception, where you organize the team, environment and high-level strategy for the effort;
- Construction, where the team incrementally and collaboratively builds the consumable solution;
- Transition, where the solution is released into production.
To complete each phase the team must fulfill a set of process goals. DAD has a comprehensive set of predefined goals that can be augmented and tailored to meet the needs of individual projects. Each goal has a set of defining factors each of which has a set of options that the teams can select. The factors vary by goal. The options for each factor often range from ignore to formal acceptance. The DAD process framework supports several different lifecycle models. The starting model includes a Scrum like construction phase with the addition of inception and transition phases as well as appropriate governance soft milestones. More mature teams may want to graduate to a more advance lifecycle such as Kanban for construction or even to a continuous delivery approach.
3. Panera’s Transformation – The Approach
Panera’s agile champion, Mike Nettles was familiar with the value proposition of the DAD framework and contacted the creators at Scott Ambler + Associates (SA+A) to see how it could be applied at Panera. The following describes how SA+A worked with Panera to address the challenge presented by the President of IT needing to become more responsive to business change.
3.1 Assess the Organization
Context counts. Mark Lines and Scott Ambler spent three days working with management and the project teams to review the existing processes at Panera. They then produced a roadmap for transforming the organization from a traditional solution delivery approach to the Disciplined Agile model.
3.2 Train the Executive Team
A transformation from traditional approaches to agile will fail if there is not adequate support at an organization’s executive level. Mark Lines and Scott Ambler conducted a one-day workshop with senior executives to ensure that everyone understood the new model of intense and ongoing engagement that would be required between the business and IT in order to be successful.
3.3 Train the Delivery Teams
The next step was to train the delivery teams on the approach just prior to launching two pilot DAD projects. SA+A conducted a 3-day DAD workshop customized for Panera to include labs based on one of Panera’s in-flight projects. One such lab entailed whiteboarding the vision statement for one of their new projects. This is one of the deliverables of DAD’s Inception phase, which can be used to obtain stakeholder agreement that the project makes sense and the team is ready to begin construction.
3.4 Train the Business
A prerequisite for successful adoption is engagement and buy-in from the business. One of the authors conducted Product Owner training for a large group of business stakeholders. Panera’s use of DAD champions from both business and IT proved to be critical in maintaining the positive adoption momentum that had been established.
3.5 Pilot Project
The project that was selected to be the pilot project was called Back of House (BoH). This scope of this project included sales forecasting, labor scheduling and inventory counting for each café. The solution helped Panera forecast the sales based on past sales and other variables such as expected weather. The store could then optimize their scheduling of resourcing for their cafes. The work to be done included a mixture of custom development with package implementation and customization. This project was a good fit as a pilot project for a number of reasons. The project was non-trivial, providing real value to the business. People might have been skeptical of the results if the project were not seen as business critical. The project team consisted of a mix of on and off shore team members which allowed us to tackle the issue of whether or not geographically distributed agile projects are feasible.
Having selected the pilot project the next step was to select a DAD lifecycle. The Scrum-based DAD Basic/Agile lifecycle seemed to be the appropriate selection which consists of three phases as depicted in Figure 1.
Figure 1. The Disciplined Agile Delivery Basic/Agile Lifecycle
3.5.1 Inception phase – Getting the pilot project started
According to studies, the average agile project spends about one month doing planning work before starting the first iteration. (Ambysoft, 2013). DAD explicitly recognizes this fact although it encourages this planning to be reduced to as short a time as possible. The BoH team did their Inception planning in a two-week iteration. The team performed just enough work to achieve the DAD Inception goals, which are:
- Form initial team
- Develop common vision
- Align with enterprise direction
- Explore initial scope
- Identify initial technical strategy
- Develop initial release plan
- Secure funding
- Form work environment
- Identify risks
Let’s describe some of the decisions made and actions taken related to these Inception goals:
- Form Initial Team: The project delivery team was comprised of a team of five team members in St. Louis and 4 team members from a vendor in Brazil. A senior IT executive, although initially an agile skeptic agreed to take on the role of Team Lead (what Scrum calls a Scrum Master). The rest of the onshore delivery team consisted of an Architecture Owner who also was a developer, two more developers and a tester. While these were their primary roles, all team members were cross-functional in that they were willing and able to help each other do their tasks if required. After some convincing, someone from the business unit agreed to work full-time with the team. While initially she didn’t spend much time collocated with the delivery team, over time she spent more and more time working side by side with the team as she recognized the benefits of doing so.
- Develop initial release plan: Estimation of the work item list (what Scrum calls a backlog) and extrapolating the work effort based on an assumed team velocity led the team to project that the project would need 8 iterations of construction to complete the work. The time frame of the release from Inception through to Transitioning the product to the stakeholders was depicted by a high-level Gantt chart as seen in Figure 2. As shown in the diagram the team finished a 2-week Inception planning phase on September 9th before executing 6 iterations of Construction ending May 28th. They then had a 2-week Transition phase ending Jun 14th to finish testing and deliver the solution to the stakeholders.
Figure 2. Release Plan for the Back of House project
- Identify initial technical strategy: The team worked with the Architecture Owner to quickly model a multi-phase evolution to a target architecture. This architecture would evolve over series of project releases to be more robust in support of the high-availability non-functional requirements. This was then diagrammed in a tool, printed on large sheets of paper and posted in the work area.
- Form work environment: The onshore team chose to collocate in a common work area, backs to each other, with a work table in the middle of the work area that they could turn to for ad hoc collaborations. The Product Owner sat with the onshore team, usually at the table in the middle of the team. The offshore team worked at their usual desks in the same general area. We will shortly describe how the on and off shore teams coordinated their work.
3.5.2 Inception Milestone Review
This work completed during the Inception phase was summarized into an eight slide presentation that was given to management as the DAD Inception milestone review. The purpose of this meeting was to obtain stakeholder consensus that the project made sense and the team was ready to move into the Construction phase.
3.5.3 Construction phase iteration – An Example of Using DAD’s Goal-driven Approach
An important part of how Panera successfully adapted agile for their pilot project was applying the DAD process decision framework. The DAD framework depicts 22 process goals as shown in Figure 3 common to any project and provides strategies for achieving each goal and their tradeoffs.
Figure 3. The Process Goals of Disciplined Agile Delivery (DAD)
Rather than attempting to describe all aspects of this project, we will focus here on showing how decisions were made related to one specific ongoing DAD goal, namely Coordinate Activities. Figure 4 depicts this goal diagram used to help Panera make process decisions regarding various strategies for coordination and which made sense for them.
Figure 4. Coordinate Activities DAD Goal Diagram.
This diagram depicts the goal of Coordinate Activities, the factors that need to be addressed, and the various options. Where an option is bolded and italicized it indicates that the option is a good starting point for new agile teams. If an arrow appears beside the list of options it indicates that the list is ordered with the most desirable options at the top of the list. Let’s review some of the explicit choices that Panera made regarding coordination for their BoH pilot project:
- Share Information – Since the majority of the team was collocated in a common work area they relied mostly on conversations. Each iteration review and demonstration was conducted as informal reviews albeit as a meeting in a room outside their work area with other invited stakeholders. The team periodically engaged in non-solo development by pairing with other team members. Sometimes this was two developers pairing, while other time it might be developer and a tester or any combination of team members.
- Coordinate Within Team – The team held daily coordination meetings (what Scrum calls a Scrum) every morning at 10:00 to plan the day’s work. They chose to visualize their work on a JIRA task board which was displayed on a large monitor in the work area during these meetings. They also reviewed their burndown charts daily in JIRA.
- Coordinate Between Locations – Part of the team was in Brazil. The BoH team chose to adopt collaborative tools by using JIRA and Microsoft Lync for instant messaging. During the coordination meetings the offshore teams were visible via a webcam so that both teams could virtually meet. Additionally a screen with the JIRA task board was virtually shared so that all team members could provide their updates during the daily coordination meeting. Recently they have chosen the strategy to gather physically at critical times whereby the team from St. Louis visited the team in Brazil.
These are just a few examples of some of the decisions made for this particular DAD goal in consideration of the alternatives shown in this diagram. Many other context-based decisions were made for the other DAD goals.
3.5.4 An Incremental Approach to Adopting DAD Practices
As shown in Figure 3 above DAD describes five goals for the Construction phase. To fulfill these goals DAD describes a hybrid of agile practices from mainstream agile methods such as Scrum, Extreme Programming (XP), Agile Modeling, the Unified Process and many more. These recommended practices for each iteration of construction are shown in Figure 5. It certainly is not advisable for new agile teams to attempt to adopt all of these practices on their first projects. For the BoH project the team adopted the underlined practices shown in the figure.
Figure 5. DAD Construction Phase Practices. Underlined practices indicate those that were used for Panera’s pilot project.
The practices that this pilot project team chose to implement were essentially all of the Scrum-based practices, some basic practices from Extreme Programming (XP) such as periodic pairing, as well as some Agile Modeling practices such as continuous documentation.
3.6 Agile Governance
Coincidental with running the first pilot projects at Panera management established some new agile metrics to track the health and progress of the projects. They designs a set of dashboards in their JIRA tool to display summary information for their key projects. Additionally, Panera adopted the DAD milestones as depict in Figure 1. Lightweight milestones reviews were conducted as part of the Iteration reviews and demonstration to gauge the progress of the projects towards completion. Panera found that Proven Architecture milestone to be quite useful as a tool to mitigate technical risk early in their projects.
3.7 The Transformation is a Work in Progress
Any agile transformation is a multi-year effort and Panera is just a year into their adoption. The adoption will continue to roll out across the organization horizontally across approximately 10 teams and vertically as each team adopts more agile practices as and when then are ready.
Here are some of the initiatives, some of which started in the pilot that are underway for Panera’s continued agile transformation:
- Purpose-built agile space. In iteration 4 the BoH team moved to a new fit-for-purpose agile space. It provided desks that were more spread out, with an area large enough for six people to work back to back and more space in the middle.
- Information radiators. A large monitor was installed on the wall to display project information such as the planning board, task board, burndown charts and status of builds.
- Adopting more construction practices. Over time the team wishes to adopt more of the construction practices shown in Figure 5. The team is working on improving its continuous integration practice and plans to adopt the practices of test-driven development and continuous deployment.
- Building on the agile governance with product roadmaps, multiple backlog management, and improved metrics.
- Improvement of their DAD technical practices such as continuous integration to allow for more frequent builds, releases, and automated regression testing.
4. What We Learned
Every transformation offers new opportunities for learning. Here are a few lessons for this initiative:
- Improved working relationship between IT and business stakeholders. One of the greatest benefits thus far in Panera’s agile adoption is the improved relationship with the business. They are now far more engaged with IT throughout their projects to ensure that what IT delivers truly meets the needs of the business.
- Separate executive session avoids group bias. It was beneficial to have an agile workshop with senior executives so that they could ask questions that management cares about without getting overly technical. We have found that if these workshops have multiple levels of hierarchy present that some people are afraid to ask questions for fear of looking stupid in front of their managers.
- Set expectations for your iteration demonstrations. One of the authors (Mark) made a rookie mistake in an early demonstration for the pilot project of not setting expectations appropriately. A VP from the business who was not familiar with agile was invited to attend and was expecting much more that what could be demonstrated only a few weeks into the project. He had been used to seeing demonstrations of completed products. So he was underwhelmed by what he saw. The lesson learned was to set expectations, and set the context of the demonstration.
4.1 How DAD Helped with the Transformation
The added guidance that DAD provides to supplement mainstream agile methods helped in the following ways:
- A Phased approach to delivering the pilot project. Spending two weeks at the beginning of the project for the Inception phase creating a vision and preparing for the Construction phase set the appropriate expectations for what to expect from the pilot in terms of what will be delivered by whom and when. It also provided the team with some time to establish their work environment, tooling and other logistics.
- A goal-driven approach to adapt the agile approach for the context of the pilot project. Referencing DAD’s goals, the factors to consider in order to achieve the goals, and choosing from the selection of options helped the project team to make good process goals without having to figure it out by trial and error. In this paper, we showed with just one example of DAD’s goal diagrams how referencing the guidance of factors and options can improve decision making for your teams.
- DAD provides a selection of agile practices from leading agile methods to choose from in one place. It is difficult to understand all the available agile practices that together can maximize the effectiveness of an agile team. DAD provides a blend of the commonly accepted good practices from a variety of leading agile methods in one place. The Panera pilot project made a conscious decision which practices that they would adopt from DAD and which ones they would defer adopting until future releases.
- Adoption of an Agile PMO enabled appropriate albeit lightweight governance for Panera’s agile projects. In Ambler and Lines’ book on DAD they make it clear that an agile transformation is difficult to be successful and sustain long term without adapting an organization’s governance for agile projects. Although not complete, Panera has already implemented many facets of an Agile PMO.
5. Acknowledgements
I would like to thank Hakan Erdogmus for reviewing and providing some value input into this paper.
REFERENCES
- Lines and S. Ambler, Disciplined Agile Delivery, IBM Press, 2012
- Ambler, An Introduction to DAD, at http://disciplinedagiledelivery.wordpress.com/introduction-to-dad/, 2013
- Ambler, http://www.ambysoft.com/surveys/projectInitiation2013.html, Ambysoft, 2013
