Evolving Your Agile Way of Working (WoW)

 

Choosing your way of working (WoW) isn’t just a one-time event, instead it is an ongoing effort.  Figure 1 shows the workflow for choosing and then evolving your WoW.  In our previous blog, Choosing Your Initial Way of Working (WoW), we worked through the left-hand side of Figure 1.  In this blog we explore how a team evolves their WoW via a series of experiments, hopefully ones that are guided by the Disciplined Agile (DA) toolkit.

Figure 1. The workflow for choosing and evolving your WoW.

As you can see in Figure 1, evolving your WoW is a two-step process at a high-level.  First, you identify that you have a potential issue with your current WoW and second you experiment with one or more potential improvements that you believe will address the issue that you’ve identified.  And of course you repeat this strategy whenever needed.

Identify Potential Process Issue

There are various ways that a team can identify a potential process issue:

1. Retrospectives. Retrospectives are a strategy for a team to reflect upon what is working well for them and what isn’t working so well. Some teams, particularly agile ones, will choose to hold a retrospective at the end of each iteration/sprint whereas lean teams tend to hold them on an as needed basis.  Regardless, one of the outputs of such a working session is a list of one or more potential issues the team wants to address.
2. Someone recognizes there’s an issue. Sometimes it’s as simple as someone saying “Hey, I think that X is a problem. Is there anything we can do about it?”
3. Someone from outside the team points it out. It can also be as simple as someone from outside of the team – one of your stakeholders, a colleague on another team, a leader within your organization, or others – identifying a potential issue.

The point is that there are multiple ways that potential issues are identified.  So what are you going to do about them?

Experiment with Potential Improvement(s)

For any process issues that you believe you can address, the next step is to experiment with one or more potential solutions. Experiment?  What?!?!?!?!  That’s right, experiment. Any given practice works well in some situations but not in others.  Just because a technique worked well for another team, maybe even one that you’ve worked on in the past, that doesn’t mean that it will work well for your team in the context of the situation that you currently face. There is no such thing as a best practice, regardless of the endless marketing you may have heard telling you otherwise.

What you need to do as a team is to identify ways that you can potentially address an issue, narrow down your options, and see how well a given technique works for you by trying it out in practice.  In other words, you need to run an experiment.  Figure 2 depicts a continuous improvement loop, also known as a “kaizen loop,” where you choose a technique to experiment with, you try it for a sufficient amount of time to determine whether it works for you, and then you decide what aspects of the technique (if any) you should keep and which you should abandon.  And if you’re enterprise aware your team will share your learnings with others.  Guided continuous improvement takes this one step further by employing the DA toolkit to help identify potential new WoW for you to experiment with that is more likely to work for you, thereby increasing your team’s rate of improvement.  Better decisions lead to better outcomes.

Figure 2. Guided continuous improvement.

An Example

Let’s consider an example.  We’ve been working together as a team for several months, have released the initial version of our solution into production, and have been working on our next release for about a month.  Our Team Lead has informed us that we’ve coming to the end of the funding for the team.  When we formed the team we received funding for a 6-month project, following our company’s fixed cost approach to funding solution delivery teams.  Our team expanded in size so that we could become a complete, whole team, and a side effect of that is that after a bit more than 4 months we’ve run out of money.  This is a problem that the team needs to address.

Terry, our Team Lead, gathers the team to work through the issue.  The first thing we do is discuss whether this is an issue that we can even influence.  The Team Lead believes that we can because our organization’s leadership is very happy with our work and can see the value in the product that we’re working on.  Because they have been receiving advice from an Executive Agile Coach they are beginning to realize that the way that they fund teams needs to evolve. Terry believes that our team is in a position to suggest, and then experiment with, a new approach to funding.

As a team we discuss what we need to do, realizing that there are really two issues commingled here: First, we’re funding a project, not the actual team.  Second, we’re taking a fixed-price approach. Carlos, our Agile Coach, suggests that we review the options captured by the Secure Funding process goal, the goal diagram for which is shown in Figure 3. It indicates that both project-based funding and fixed-price funding are the least effective options for agile teams, and more importantly it also indicates that there are better options available to us.  We look up the trade-offs associated with the options in our copies of Choose Your WoW! and after a bit of heated discussion agree that we should suggest to our management team that we adopt a stage-gate funding strategy for a product (long-lived) team.  Several of us wanted to push for a time-and-materials (T&M) approach, but we felt that would be a future improvement that we could experiment with once we’re successful with stage-gate funding.

Figure 3. The Secure Funding process goal diagram.

Terry, with the support of Polly (our Product Owner), manages to convince our senior managers to experiment with a new approach to financing.  Terry and Polly were able to describe the trade-offs associated with both the existing approach to funding and their suggested new approach. Interestingly, their suggestion was whole-heartedly supported by Florinda our finance officer.  She’s been concerned for several years about the way that IT projects have been funded, and is eager to move from a cost-based funding model towards one focused on investing our company’s money wisely. Our team was given the go-ahead to try the new funding strategy.

Sure enough, we run the experiment with stage-gate funding of a product team and it works well.  Our “stages” were three months in length, and after two rounds of such funding we successfully experimented with a T&M approach as we’d originally hoped.