On August 10th, 2020, a straight-wind derecho storm wrought devastation through the Midwest, destroying millions of acres of forest and farmland, and leaving millions without power. We decided to make the most of the situation by constructing a log cabin from the roughly 30 downed mature ash trees in our neighborhood. We started without any detailed plans, timelines, or designs of the final product, using a high-level vision and continual inspection/adaption to guide our progress. The result was far better than we ever imagined! We successfully applied agile values, principles, and practices to the effort, resulting in a product I expect our family to enjoy for many years.
At the same time, I was engaged in two challenging initiatives at work and experienced how these agile principles (setting a vision, trusting teams to deliver, and continual learning and improvement) drove similarly amazing results.
1. INTRODUCTION
Building a custom log cabin from downed ash trees is much like building new software or implementing a new technology:
- In the beginning, the construction process and delivery pace are uncertain.
- Several factors can result in pivots in approach.
- Rapid learning occurs throughout the process.
This experience report explores experimentation with two core principles, applied to the log cabin construction and two software delivery efforts delivered in parallel:
- Establish a clear vision and empower teams to deliver the vision.
- Continually experiment, inspect, and adapt.
I was amazed at how these core principles drove similar success across all three initiatives.
2. Starting with The vision and empowering teams to deliver
In his book, Start with Why, Simon Sinek describes his recipe to inspire others: communicate a clear vision with a strong sense of purpose. This section explores the pairing of “starting with why” with the agile principle of building projects around motivated individuals and giving them support and trust.
2.1 Log Cabin Project
The “why” of the log cabin project started from a question of what to do with 30 downed trees in the middle of the neighbor’s yard. Half-jokingly, I made the comment that “we could build a log cabin out of all these trees.” My wife and I thought for a moment and agreed that was exactly what we should do. We spent the next two weeks dragging the branches to large piles in the street and hauling the sections of tree trunk to a corner of our yard near the forest. Only once we had piles of freshly cut logs did we start thinking about the design for the cabin. We researched log cabin examples to determine an approach for connecting the logs but did not have enough information about each unique log to do any detailed planning, measurements, or designs. Instead, we laid out a vision and a few key success criteria for the project.
Log Cabin Vision
Create a cool space for the family to enjoy with a feeling of being in nature.
Key Success Criteria
- Must be weather-proof.
- Must have windows.
- Must sleep at least two comfortably.
- Adults must be able to stand up inside.
With a clearly defined vision, purpose, and definition of success, we started work. The door and windows took shape according to the size and availability of materials. We started on the roof after depleting logs long enough to continue building the base. To meet the adult standing and sleep space success criteria, we built the roof with a steep pitch and large overhangs on all sides. We discovered the derecho also provided an abundant supply of shingles, which we fashioned from cedar fence blown down during the storm.
We continued to make improvements beyond the initial success criteria that aligned with the vision: a deck overlooking the nearby creek, LED lights, screened windows, a space heater for fall-winter-spring, and an air conditioner for the summer.
We achieved the vision and success criteria without any initial notion of what the result would look like. See the below pictures showing the resulting product in use.
We often make analogous comparisons between house construction and software delivery, but I now question this line of thinking. A typical construction project begins with detailed blueprints, describing every detail of the projected result. The dimensions, weight, and properties of every building material are known and the processes for assembling the materials are well established. Neither holds true when delivering software, making it problematic to compare. I do not feel delivering software is analogous to building a house, but it is a lot like building a custom log cabin. When it comes to software delivery (and log cabins), a clear vision and the ability to adapt are much more important than having a detailed plan.
2.2 Agency Dashboard
My government client lacked data analytics capability, creating frustration for leaders striving to build public trust and confidence externally and improve service delivery effectiveness internally. To mitigate this gap, leadership requested dashboard reports from each business area. I was asked to help facilitate the delivery of a list of reports gathered by the business areas in support of this request.
We faced several challenges in our plight to deliver the dashboards:
- A delivery team/structure did not exist—capacity was required from staff currently already overallocated on other efforts.
- The requested scope was new and unknown to delivery staff.
- The organization did not have prior experience deploying dashboard capabilities using the planned technology.
- Each business division provided requirements without a cohesive vision or strategy.
- The requested delivery timeframe was insufficient to complete even a small percentage of the defined requirements.
- Culturally, business leadership viewed their role to provide detailed requirements, and IT teams were expected to deliver the requirements as provided.
We were given a deadline of a month to deliver roughly 30 new dashboard reports across 8 different business units. Like the log cabin example of focusing on the vision, we asked for clarification of the “why” behind the request:
- What were the goals we were hoping to achieve with the dashboards?
- Who was the primary audience for the dashboards?
After two weeks of working with leadership to clarify the dashboard vision, we landed on separate vision statements for two different dashboards: an external public-facing dashboard and an internal dashboard.
External Dashboard Vision
Share accurate data with the public to increase comfort and confidence in the quality of services being provided.
Success Criteria
- Clear and understandable to someone without internal-specific knowledge.
- Easy to locate from publicly available websites.
- Data is consistent between dashboards and aligned with other publicly posted data.
Internal Dashboard Vision
Monitor the performance of each division to identify improvement opportunities and initiate action plans to improve delivery results.
Success Criteria
- Easy to understand performance measures, desired target outcomes, and whether results are meeting expectations.
- Easily accessible by staff.
- Data is timely and up to date.
- Data quality issues are identified.
With vision clarity, we realized our report requirements list lacked a critical element that was important to the vision. We spent the next week assembling a team around that first element and kicking off the project with a leadership commitment to support the team with whatever they needed to deliver it. A week later, the team presented a summary dashboard to the leadership team (deployed to a test website), exceeding all expectations and solidifying executive support for the project to continue forward well beyond the project due date.
I have spent most of my career immersed in command-and-control environments in which knowledge was expected to be passed down from the managers to the teams performing the work. I had never experienced the true power of a team of diverse-minded individuals collaborating on a common vision until seeing this team in action. In one week, without any direction beyond the vision and acceptance criteria, a team of individuals with partial capacity and no prior history working together delivered data visualizations from a new business area using new technology onto a website requiring coordination with an external vendor. This result is impressive by any measure but is even more amazing considering it was achieved in an environment known for bureaucratic red tape and politics.
This experience has changed how I provide direction to teams. Previously, I quickly jumped to “helping” teams by solutioning and problem solving for them because I felt I had the best answers. After all, I have been implementing systems for 20 years and have so much experience to share:). I realized the best way to get results is to focus on ensuring everyone understands why we are doing the work and for whom…and providing any support requested.
Four months later, we launched the initial version of the dashboard to the public, including data from seven different business areas.
2.3 Technology Refresh
The organization operates several custom applications, but rarely with an investment level sufficient to keep pace with the rate of business and technology changes. One of the critical business applications was written in ASP and was no longer supported on newer browser versions. The “why” in this example was more straightforward: update the technology to avoid critical business failure. I was asked to support the team re-writing the application logic from ASP to ASP.net
We also faced several challenges as we prepared to re-write the system:
- Business and technical knowledge of the system was limited; staff most familiar with the application had departed or retired.
- A new sub-contractor development team with no prior business or system knowledge was hired to deliver the re-write.
- As a result of the large amount of technical debt, changes had not been made to the system in a long time and processes were not established to deliver new/updated code.
- The work was funded by enhanced funding, adding reporting requirements and oversight from an external stakeholder whose processes remain anchored in a waterfall mindset.
Launched primarily as a mitigation to a critical system failure risk, the vision of the refresh project was the upgrade of technology with minimal functional changes. Success was simply defined as upgrading the technology with the least amount of effort and disruption as possible.
We applied a strong focus on empowering the delivery team to make decisions about how to best deliver the work. An example of this principle was our approach to establishing a delivery cadence/process. Most IT organizations default to launching teams using a prescriptive Scrum delivery method. This was our initial starting point as we kicked off the effort. After the first two weeks, it became clear Scrum was not going to work without material changes in the team’s interactions and practices. In the first retrospective, the team asked to try a flow-based approach, switching to a Kanban method of tracking/executing. We made the switch and started to see improvements in team effectiveness immediately.
As a result of this experience, my view on Scrum has changed significantly. I, like most people I encounter, believed Scrum was the road teams must follow on a path to agility. I no longer feel this assumption is valid. Looking back on prior experiences, I realized every attempt to deliver work using the Scrum framework completely fell short of achieving the goals of an agile process, and in many cases counteracted the very principles Scrum is intended to support.
Through this delivery effort, I realized listening to the team, meeting the team where they are, and doing what is a best fit for the team in alignment with the vision is the real key to success. My revised theory on Scrum: Scrum is a good fit for advanced delivery teams, working within an organization with a strong culture supporting agile values and principles. It is best to let teams decide if and when Scrum is right for them.
After many changes, which will be discussed in the next section, the team delivered a phenomenally successful release to the delight of a user base accustomed to work arounds and limited technical support. In addition to refreshing the technology, the team implemented dozens of functional enhancements and positioned themselves as the leading example for future-state delivery, utilizing build automation and regression testing not yet embraced by the rest of the organization. In the years preceding the production release, a handful of system updates had been implemented. Following the release, the team continued a release cadence, adjusting seamlessly from a project delivery process to a product support process to continue delivering system enhancements and fixes in response to user priorities every week.
3. Continual Experimentation, Inspection, and Adaptation
Continual inspection and adaption is a commonly referenced agile principle. This section covers how the principle was applied to each of my concurrent delivery efforts.
3.1 Log Cabin Project
I never imagined I would find myself building a log cabin. I did not have the tools or knowledge around the two most time-consuming activities involved in the initial steps of log cabin construction:
- Stripping the bark off each log.
- Notching the joints to allow two logs to overlap at the corners.
I expect the log cabin industry uses expensive machinery to perform these functions. I searched for tools available for the smaller scale builder to discover “axe” is the primary tool of choice for completing both tasks.
The recommended approach for stripping bark off trees: striking the tree with the back end of the axe over and over until the bark peels away, then scraping off the strands of remaining bark with the sharp axe blade. This process took about an hour for each 8-foot log. We tried a few experiments to improve the process:
- Scaling – the neighborhood kids were interested in helping, so I went to Walmart and bought several axes (which made for an interesting conversation at the checkout). Kids turned out to be helpful but worked at a pace much slower than an experienced adult. I am not certain if the time required to provide instruction and make sure they did not accidentally kill each other with axes was worth the production value of their work. Either way, I think the kids enjoyed being part of the process and now they have crucial log cabin-building skills:)
- New tools – I continued to search for better ways to strip bark and found two alternatives to the axe: A drawknife (a flat blade with handles on each side) and a floor stripping tool I used to remove the glued-down tiles when remodeling our basement. I found I was able to strip bark much quicker with the floor stripping tool, but with more exertion and lower quality. After experimenting with several options, I found the optimal method was to use the floor stripper to peel vertical strips off the log, then use the two-handled blade to clean up anything that was missed.
Cutting the notches out of each log presented a similar challenge, as I was unable to find available tools designed with this purpose in mind. At first, I used a chainsaw to outline the notch, then an axe to chip out the wood. I decided to invest in a battery powered Dewalt circular saw, which improved the process considerably. With the saw, I could adjust the height of the blade to quickly saw multiple cuts through the notch at a consistent depth, and then break off the remaining wood chips with the axe. The saw cut approach dramatically reduced the amount of time required to hack at the notch with an axe and increased the quality and precision of the notches. When I think back to the time of early settlers, I am amazed they were able to build quality log cabins without the aid of modern tools.
Reinforcing my above epiphany about Scrum, I did not follow any Scrum practices during the log cabin construction effort, but it is one of the most agile projects I have experienced.
At the time of this writing, the log cabin remains incomplete. I still have the chinking mud to apply between the logs, which I expect to involve several more cycles of experimentation, learning, and adapting to land on an optimal process for completing the task. In the meantime, the MVP vision and success criteria have been met and we are fully enjoying the result. Below is a photo of the current state of the log cabin project:
3.2 Agency Dashboard
Like the continual improvement process used when building the log cabin, we structured the Agency Dashboard execution process to optimize for experimentation. The team started each new dashboard report using high-level acceptance criteria to deliver a first working version then focused on eliciting and incorporating the feedback from business users. We learned early on that working from a tangible example produced much higher value input than discussing hypothetical scenarios.
Leveraging the learning from attempting Scrum on the technology refresh effort, we began a slightly different launch approach for each team: we changed the Scrum terminology but followed many of the core practices/ideas. Instead of a product owner we had a business owner. Instead of sprints we held weekly planning sessions and set weekly target goals. Instead of standups, we had checkpoint meetings. Instead of sprint demos, we scheduled leadership reviews. Like the refresh project, team feedback was continually incorporated to optimize what worked best for the individuals doing the work to deliver the vision most effectively.
Additionally, the agency dashboard teams were not traditionally structured teams. Every team member had a separate full-time job except for the primary Power BI developer, who supported all dashboard development activities. After experimenting with several options for balancing staff allocation across efforts, we landed on an approach that placed these decisions into the hands of each team’s business owner. The business owner proposed the target goals each week. If the team was unable to commit to a goal due to conflicting work, the business owner could decide to either seek de-prioritization of other work or push the dashboard goals to the following week.
After the initial production delivery, the agency dashboard project transitioned into a product, receiving approval for ongoing funding and support to continue the delivery of new dashboards and maintain existing dashboards, becoming a pioneer cross-functional product support effort at the organization. The teams continue to onboard new business areas and deliver new value.
3.3 Technology Refresh
The log cabin project provided simple examples of experimentation, inspection, and adaption leading to increased efficiency. The higher complexity of the technology refresh took this concept to a whole new level. The delivery team experimented with and changed every aspect of their delivery process between the project kickoff and the production release. Below are a few examples:
- Delivery approach—As mentioned above, the team started with Scrum, immediately transitioned to a flow-based approach, then continued to tweak smaller pieces of the process such as sizing approach and board configuration. Each modification to the approach improved efficiency and the team’s buy-in to the process. The team continued to maximize work not done and shift focus to the most critical areas as a result. The team organically gravitated to Scrum practices with each incremental change and by the time of the first release was following most of the Scrum guide without any intentional effort to “do” Scrum.
- Required documentation—The team began with an expectation of requirements documents, which transitioned to acceptance criteria within user stories and collaboration using MS Teams posts/chat and wikis. The team was selected to pilot the organization-wide MS Teams rollout and was the first team to adopt the use of a collaboration tool at the organization.
- Stand-up facilitation and engagement—At the beginning, I facilitated all standing meetings, but observed this resulted in team members communicating to me rather than the rest of the team. In a retrospective, we agreed to rotate the facilitation of daily standups. Team members became more engaged and started communicating with each other…and made my involvement less and less necessary.
- Defect tracking—The approach for logging and tracking defects is a common source of contention on any team with separate development and testing roles. The refresh team was no exception. The initial stance from the team was to log defects for each issue identified. This changed to a single defect for each story. Finally, defects during development were replaced entirely by close coordination and collaboration on the user story in focus.
- Delivery schedule—To meet federal enhanced funding requirements, we submitted a full project schedule and staffing plan for initial project approval, which was out of date the moment it was submitted. We reviewed and updated the high-level schedule after every team retrospective. The updated projections and changes in planned phases were communicated to our funding stakeholders transparently along with the team’s rationale for the updates. This process allowed the team to control the schedule and enabled clear communication between the team and project stakeholders.
- Team composition —In a few cases, the team members selected for the team or the responsibilities assigned to a team member were not a good fit. Allowing the team an open forum of communication elevated such discrepancies to the attention of the leadership team who could take action to improve alignment when needed. Several staffing adjustments were made throughout the project to keep engagement from the right individuals with the right mindset.
The refreshed system was deployed to production in January without business disruption. In addition to maintaining the refreshed application, the team has started the process of eliminating technical debt and improving several other custom systems maintained by the organization.
4. What We Learned
This experience report explored the application of two core agile principles across three quite different projects:
- Establish a clear vision and empower teams to deliver the vision.
- Continually experiment, inspect, and adapt.
The table below summarizes the challenges, starting assumptions, and key learning / results from each effort.
5. Acknowledgements
I want to thank my wife, Jocelyn and kids Ethan and Ella for the help and support building the log cabin and putting up with my agile theory discussions.
I am sincerely grateful to all the dedicated public servants who worked to improve the lives of citizens through the agency dashboard and technology refresh projects
I also want to thank Shelley Horak, Abhay Jain, and Rober Sfeir for taking the time to review and provide excellent feedback to improve this experience report.
