Disciplined Agile for Non-Software Work

I am increasingly asked the question, “Can an agile way of working be used to deliver value not related to software?” In my experience and the Disciplined Agile toolkit’s guidance, the answer is a resounding YES!

As the world is gaining more and more awareness of Disciplined Agile (“DA”), there is a wonderful awakening to what real business agility is and what is potentially required to achieve it.

When I am asked the question above, it stems from an interest to understand how those doing non-software work can also adopt lean and agile principles and practices vs. trying to provide reasons why it would not be applicable. Unfortunately, many misinformed “expert consultants” and instructors disseminate this type of rhetoric (shame on them, they should know better) and the unknowing or inexperienced team members.

I am always thrilled to answer the question with that resounding YES and provide context from real initiatives that used an agile way of working. The remainder of this blog will focus on one of these real-life adoptions.

Zsofia was a point of contact in the procurement department at a large organization that I had the pleasure of coaching on DA’s global adoption. The adoption initially touched her as part of her vendor management oversight role. One of the first teams that we were transitioning to an agile way of working would have a mix of employees and contractors. It was here that Zsofia was to observe and participate in supporting a team developing software using agile.

Due to her role, she was included in the foundational training courses that were part of the learning path. The team was using the agile lifecycle, and Zsofia primarily observed some of the recurring events. Initially, iteration reviews, but she also attended as an observer during iteration planning and a few daily coordination (standup) meetings as time passed. She saw how this new way of working was different, how challenging it was for the team to adopt it, and how collectively the team members and stakeholders were getting how this was improving what they would deliver.

Like many corporate functions that need to change their way of working to support agile adoption by product teams developing software, I had recurring one-on-one coaching sessions with Zsofia. After some time had passed and her understanding of how agile is different from their traditional process, she asked me if she could use agile to complete a project she had identified and was approved to lead.

One of the next initiatives that would adopt agile was re-platforming a large legacy product onto technology new to the organization. This would require multiple teams (potentially) and a new vendor as none of the current ones had existing expertise with the target technology stack.

Zsofia saw this as a strategic opportunity to revise the knowledge assets that her area was responsible for, including the Request for Information (RFI), Request for Proposal (RFP), Proposal Evaluation Matrix, Contract, etc. Based on her interaction with a team that adopted agile, she identified many changes that were going to be needed by Procurement in the future – they could not just force-fit a few tweaks into the existing documents that supported a traditional process. To be fit for purpose, they required a significant amount of change.

The Senior Leadership Team approved the decision to adopt the agile lifecycle to deliver the new vendor management assets, and we were off.

Similar to a software project using the agile lifecycle, we started with the Inception phase. Here we took the Minimum Business Increment used to justify the project, decomposed it into features, and then stories that would be needed. We developed a release plan centered on understanding the flow of work and how Zsofia as the Product Owner would need to consider the various other corporate areas SMEs such as legal, finance, HR (people management), etc.

Like features in a software product, each of the documents that would become a template for initiatives using an agile WoW in the future, such as the RFP, were Zsofia’s features. The minimum functionality required to provide value initially was a set of templates. Still, the context in each template could be reduced for initial utilization on the re-platforming initiative. Once the initial functionality was “released” into usage, additional areas in the templates would be developed, and feedback from the usage put into practice. Not so different from what we “should” see occurring on value delivery through software projects.

Figure 1 below is from the software development product team formed as an initial adopter of agile that Zsofia supported. This is the minimum business increment (MBI) decomposed into features and identified stories for one feature.

Figure 2 below is the MBI that Zsofia identified and decomposed. Very similar to what she observed with the software development team, features were identified to fulfill the MBI, the documents needed in the vendor management process to select and onboard a new vendor. The equivalent of user stories for Zsofia was the key sections in each template.

Nearing the end of the inception phase, Zsofia and her team identified all of the stories required for each template to have the minimum context to be released into their production environment, using in practice with candidate vendors. As the Product Owner, Zsofia prioritized the backlog of stories based on the value a section would provide, the risk of getting the content of that section completed, and when SMEs from the other areas could commit capacity needed. Very similar to a software project.

 As you should be able to glean, you can deliver value for non-software work using Disciplined Agile!