During a recent engagement, at the IT head-office of a modern, large corporate organisation, agile was set as the ‘go-to approach’ for most of their new initiatives, this after experimenting with a couple of successful ‘projects’.
An interesting conversation followed:
Me: “Projects did you say? Did you not mean, setting up a couple of agile teams that work as a small, end-to-end, somewhat self-functioning group of people producing value per iteration did you say?”, Client “No, we start a project, and then we set a clear vision and a roadmap that has clear deliverables and vision for what they deliver, precisely by when. Then we make a puzzle per team so that the things fit well; we are very quick that way…”, Me: “Hold on, deliverables clear? Does that mean that you agree what is to be precisely delivered by when?”, “Exactly!” the client replied.
So, I learned that the patient did not see its disease yet. The teams were functioning as silo’s; there were many risky handovers, bug fixing sprints took place, and much hidden technical debt only came to show at the end of a ‘project’.
Time for action…
My plan of attack was quickly drawn up: first, start slowly, educate people on scrum and the simplicity of the framework. Get the component teams to have some quick-wins, while slowly restructuring by borrowing people out of their silo’s and putting them in the ‘team’, and always explaining WHY we are changing these small things, (so that they work together as feature teams), later I set up guilds of specialists, kept the reporting lines to their guilds (their old ‘teams’) and then guilds distributed people to feature teams. We kept our focus on delivering things with as much value as possible.
{{cta(‘047ac8f2-ff1a-4a65-894c-2234d7c1ebf8’)}}
A week later I encountered another agile team at the same client (let’s call them Team B). They were also working with Scrum and trying to deliver value by every sprint, but they couldn’t. According to the business people, there was no value at all by the end of a sprint; they were surprised, they had built what was in the description of the user stories. But didn’t understand that another silo-team was supposed to be integrated with their team to do so.
They had already done ‘their part’ of the work and handed the half-built product over to team B. API’s that needed a lot of crash-testing (trial and error). Many problems followed, stress, people working longer days to ‘make up for their failures’, bad practice. So, again a lot of work to do, and here one might say it’s easy to reveal the bad setup of the project (covering two teams, not working with one another), but that would hurt people a lot. So, tactical smaller changes were made.
First, the user stories were rewritten to cover the end-to-end value bringing features instead of only a graphical part (front-end) or a data part (back-end) while the two teams were put together in the same room (collocation) and joined the same daily stand-up from that day onwards. After a couple of weeks down the road, and some bad and valuable work being produced and demoed, on the surface all looked fine, but underwater, the two teams remained informally separated. The one team was asking to have technical user stories, specifically for their ‘team’, so that they didn’t have to bother the other team with questions, etc. “NO!” the scrum master said on my advice and kept his foot down.
Quickly we introduced and improved planning poker for the end-to-end user stories, slowly but surely the two teams worked together to deliver value, and after three sprints of misery they didn’t overcommit and started to deliver a small bit of working software!
The business, however, was angry, the ‘project’ didn’t go as fast as promised, they spent a lot of money, they said. And why did the team’s product owner say ‘no’ here and there? We compared the last big programs to this one, and I quickly found out that the last three programs delivered their products late, with many bugs, and little to no value, because the market had changed over the 8-month period from start of delivery, making the perception of our agile team way better.
So, bad news bubbling up early in time was new to them, with the average velocity of the team and a good backlog of things, we could create a rough forecast (agile forecasting) in a nice graph that showed them what to expect (if the ever-changing backlog wouldn’t change). Business people love agile forecasting because it’s clearly evidence based (velocity in the past and velocity to the future!) and it shows the variance / volatility of a team.
Here we went from one learning into another; the organisation was convinced to give a ‘carte blanche’ budget for the value that the team was going to produce in the next year with value sprint-by-sprint and zero major issues in their production environment.
