Sliding Doors - A Tale of 2 Agile Teams

In the 1998 movie, Sliding Doors , Gwyneth Paltrow experiences two very different storylines in parallel because of one small difference. In one version, she leaves work early, catches the tube and arrives home to find her boyfriend in bed with another women; in the alternative version, she is slightly delayed, just misses the tube, and doesn’t catch him. The movie plays both versions side by side, switching scene by scene between them.

This blog is based on a real life project, where we were asked to help automate some manual business processes. As we began exploring the problem space, it turned out that another team had also been asked to do the same, but were taking a different approach from us. While we were thinking about business and user goals, they had decomposed the problem functionally.

This story describes how these two approaches differ, particularly with the outcome, tries to explain why goal decomposition is better, yet despite this, is still relatively rare to see.

The Blue Team 

I am the Scrummaster for the Blue Team – we are an agile team and our customer has come to us with a problem: Every quarter, she has to compile a dashboard of information for the Board and some external stakeholders. The process she uses is time-consuming, involves emailing spreadsheets around several people, and produces raw data that is hard to analyse. The people producing the data don’t all do it the same way, and she does lots of spreadsheet wrangling to get it consistent. It’s a real pain, won’t scale, and she has asked us if we can help. 

The Green Team 

I am part of the Green Team – we are an agile team and our customer has come to us with a problem: Every quarter, she has to compile a dashboard of information for the Board and some external stakeholders. The process she uses is time-consuming, involves emailing spreadsheets around several people, and produces raw data that is hard to analyse. The people producing the data don’t all do it the same way, and she does lots of spreadsheet wrangling to get it consistent. It’s a real pain, won’t scale, and she has asked us if we can help.

The Blue Team 

We have had some meetings and are pretty sure we understand the problem; but we’re a Agile team, so we will be keeping in touch with the customer. We are only funded for 8 weeks, but we should be able to create a good prototype in that time, which can be used to justify more funding if they want. The goal for the project is pretty simple: “Prototype A System for Capturing and Analysing Customer Metrics“. The data being captured is a bit complex, so we will need a Data Scientist and an Information Architect. We will build a software prototype, so have a couple of Developers and there will obviously be a Project Manager to keep things on track. We will use Scrum and 2 week Sprints. We are ready to start!

The Green Team 

We have had a few meetings to help us understand the problem, and have secured funding for 8 weeks work. The main person who uses this data is Sarah. She produces the final reports, but she also generates the data for one of the more complex departments. We have asked her to be Product Owner, and she has agree to be available for the whole project. The project Goal is pretty clear: “Make Sarah’s Life Easier for the Quarterly Metrics Collection & Reporting“. We like using Scrum, and will try to identify a Minimum Viable Product (MVP) that Sarah can actually use to help her. This will also help us get the requirements right. We probably won’t have the MVP for a couple of Sprints, but Sarah says that’s OK. The data model looks like it might be tricky, so we will make sure our development team has some data science experience – we can bring in an expert later if we need to. 

The Blue Team 

We have just started the project. In our Sprint 0, we have identified three main areas of wrk that we will work on in parallel. They are our Epics:

• Define the Data Model: the data model is quite complex, especially as lots of different people create the data, so we need to understand that properly; 
• Build a new Data Capture System: this will be a web based GUI for users to capture the metrics for the central team to analyse;
• Build a Prototype MI System: this will prototype how the data should be stored, managed and manipulated. It will show that the data model can be implemented. 

We will plan to do this in 4 Sprints of 2 weeks each.

The Green Team 

We have just started the project, and in our Sprint 0, we thought about what is realistically achievable in the time we have. If it goes well, the project funding will probably be continued, but that’s not certain, so we shouldn’t assume it will. Our goal is to help Sarah, so this is our approach:

• Sarah has to produce a set of reports during the project, so it would be great to give her something that will help her, even if it’s just for a subset of her users.
• The data model looks complex, and even the users don’t seem to be able to agree on it. We will expect it to change, so won’t be surprised if it does.
• We won’t be able to replace the whole system, so we know that the existing process will still be in place at the end of our funding. 

Despite only having 8 weeks, we still think we can build a useful MVP for Sarah. We’ve agreed with her that the MVP will let one team use a new GUI to capture the data, and that the system will generate a spreadsheet file that Sarah can include in her existing process. Although it doesn’t sound like much. Sarah tells us that she won’t need to double check their data, and it will save her quite a lot of time. The team think that we can actually deliver more in the time we have, but this is a great starting point. 

The Blue Team: Sprint 1

The team is off to great start! The GUI will be a sandboxed prototype, hosted in the lab, that we will use to define the UX look and feel. In the first Sprint, we delivered a bare bones version so the users can feed back on essentials like layout, colours, usability, etc. Meanwhile, the data modelling team have begun user workshops to understand the data. Once they have some models, we can build them into the GUI.

The Green Team: Sprint 1 – Get Consistent Data from Team X 

The team starts! The first focus is a first version of a GUI that the Team X can try. This will allow Sarah and the team to work out what data she needs. They can decide what should be free-flow, what’s mandatory, etc. We aim to come up with some common ways to describe and capture the data. At the Sprint Demo the users like the GUI (compared to the Spreadsheet), but one of the drop down lists has too many entries and is hard to use. Meanwhile, Sarah has taken the data rules the team came up with and will ask the other teams to apply the same rules to their spreadsheets. This makes life a little easier for her, but she’s really looking forward to the next increment.

The Blue Team: Sprint 2

The data modelling team is doing well, and has 4 more workshops booked this sprint. The model is good, but not stable enough to be implemented yet. The GUI is looking good too. The team has come up with User Stories for most of the users, and manage to build a version that’s about half complete for the users to see this Sprint. The demo goes really well. It’s much prettier then the spreadsheet form, and has some lovely features like tool-tips and pre-populated default values. There are some issues, though. One of the drop down lists is far too busy, and the users struggled to get to the right values.

The Green Team: Sprint 2 – Replace the Team X Spreadsheet 

Some of the team are improving the GUI abd adding the remaining fields that Team X need when they report their data to Sarah. The others are developing a component to generate file format that’s compatible with the spreadsheet files the other teams will produce. They need it to be the same so that Sarah can treat the Team X file the same as the other teams.

By the end of the Sprint, the team can demo a version. The GUI is functional rather than beautiful (it still has the drop-down list), but it works, and the file is correct. The team can use it at the demo, and although they can suggest lots of improvements, they confirm it’s easier than wrestling with spreadsheets the ‘old way’. Sarah is thrilled with the progress. Team X generate quite a lot of data, so the prospect of not needing to correct it for consistency is really appealing!

The Blue Team: Sprint 3

It’s a good job we are using Scrum, because the feedback at the Demo has changed what we thought we would be doing in this Sprint! It’s really important we get the usability right, so will be focussing on some smart searching as a priority. The data model is coming together, so we can begin implementing that in this Sprint. In particular, they have decided which fields are mandatory. The demo is to Team X, as they are high priority users, and they think the GUI is awesome! They can’t wait to be able to use it. 

The Green Team: Sprint 3 – Roll out to the rest of the Region 

The backlog prioritisation session is interesting! There are so many possibilities. We could store the data (rather than just transform it); we could roll out to more teams; we could improve usability; and Sarah would love a feature to join the spreadsheets into one.

Unfortunately, we can’t do it all, so Sarah decides the priority is for the rest of the teams in the region to be able to use the GUI, and she will sacrifice usability and more functionality for that. But, her second priority goal is ‘Make the GUI Pretty”…

So, the team focussed on the additional fields, changes to data checking, changing some fields from mandatory to optional; and vice versa. Near the end of the Sprint one of the developers was able to integrate a new search component that replaces that awful drop-down (which had got even worse with the other team’s requirements!). The demo goes so well that Sarah wants the teams to use it for real during next months data capture! 

The Blue Team: Sprint 4

It’s the final sprint, and the data modelling team hold their final workshops! Some of the fields they thought were mandatory aren’t for everyone, so we had to change the model a bit but we are pretty sure it’s complete now and ready to be implemented if the project is extended. 

Meanwhile, the developers have done a great job. The GUI is finished and looks amazing! The UX look and feel is complete and the style guide written so that the team that builds the production version can make their version look that same. 

The User Demo went well and the users were all able to enter dummy data and the feedback was universally good – they all said that it would be much easier to use than their spreadsheets. They had a few suggestions, but nothing major. The product owner is also really happy. She confirmed that the data being collected was much higher quality, and will minimise the effort she currently spends correcting and standardising the raw data. 

The Green Team: Sprint 4 – Improve Usability and Data Quality

There a loads of things the team (and Sarah!) would love to do, but since funding is about to run out, it’s more important to get the current functionality right. Some of the other teams in the region are a bit reluctant to change, so Sarah prioritises usability enhancements to help convince them. There are some data quality checks that Sarah needs.

Towards the end of the Sprint, the team autogenerates some documentation and Sarah gets some more teams to test it. Luckily, they are able to use it without any changes!

The final demo is a big success. The users love the new system and are full of ideas on how it can improve. We capture these briefly, but reluctantly tell them that the funding is over for now. The system is hosted stable infrastructure, and the funding included hosting costs for 12 months, but no further support. 

The Blue Team

From our perspective, this has been a great project! The users can see the potential benefits of an automated system, and we have a documented data model that describes all the information the business needs. The developers have shown what’s possible in a short time, and the GUI looks amazing.

There is still a lot to do before we can ditch the spreadsheets, of course, but the Product Owner is really pleased with what we have done, and is optimistic about getting more funding. She had to use the old process this quarter, but hopefully there will just be a couple more cycles of spreadsheets before they can be consigned to history! 

The Green Team

From our perspective, this has been a great project. Some of users can benefit from a much improved system for capturing metrics. Although Sarah still has to wrangle spreadsheets, her job is a lot easier than it was before. The developers are proud of what they have done, although a bit sad that they didn’t have more time to make the GUI look better. 

The benefits of the new system are clear to Sarah, and she is optimistic that she will be able to secure funding to take the project forward. There are so many possibilities! Her biggest problem will probably be choosing what to prioritise first!

The End

So, that’s the end of the story. Do you recognise yourself or your project in either team? Which team would you rather be part of? Or have work for you?

 The Blue team is a great place to work if you like understanding problems thoroughly, doing things properly and hate leaving a job half done. We won’t release half baked products that don’t ‘delight’ customers, and we still share progress frequently, and change direction as a result.

The down side is that once we start, it’s hard to stop until we get to the end; and our customers might get frustrated by seeing progress being made but not being able to use it yet!

In the Green team, we think differently. We don’t create solutions, we solve problems. We agreed a goal early on that was directly connected to the business need, and didn’t describe the solution. This meant we could explore different solutions without compromising the goal (we actually suggested user training could have brought a quicker result, but the client didn’t want that!).

Our focus on identifying small goals that contributed towards the bigger goal did mean that the technical solutions were less impressive than the Blue team, and that can cause frustration sometimes - nobody likes knowing they could have done better. But within the constraints we delivered the most customer value that we could.

And when we left, the customer had some tangible value for their money. There is direct business benefit.

The Green team understands Goal decomposition. They satisfied the customer through early and continuous delivery of working software that actually had value, and they allowed their architectures and models to emerge.

Even though both teams used Scrum, iterated, delivered increments of working software and demonstrated high levels of customer collaboration, only the Green team were truly agile.