I recently returned from Atlanta, US and A (as Borat would say), where I was helping set up a new Agile development team.
Actually, they are a little bit more than a dev team - they are one of these product teams I'm so keen on. The teams owns the full lifecycle of change; development, testing, support, deployment etc all in one team. The idea is that they start to make decisions as a team rather than individual silos and that they have empathy for the impact of their changes on others. For example, if a change is poorly tested that is going to affect the velocity of the sprint due to rework. Or if they develop a change that is difficult to deploy then the team are going to feel that pain.
I think of it as
gradle to grave responsibility. Your job doesn't stop at checkin. Its only just begun.
Only once software has hit production does it realise any business benefit.
It's not the first time I've set up a team like this but I get the feeling that its going to be a fantastic success.
We are still in sprint zero so how can I make such a bold statement? Largely its a gut feel but because I've done this a number of times I know what "good"
feels like.
That's a bit of cop out though and not very interesting for anyone kind enough to read this blog.
Let's drill into a bit further and have a look why the ingredients of success are there:
Budget/investment in tooling
We are putting together a kick-ass CD pipeline with Bamboo, Jira, HipChat and Bitbucket all very neatly integrated. Add into the mix Puppet, Urbancode Deploy and a load of other tooling and they have everything they need for a very fast pipeline.
What's more, there is budget for some consultancy if we get stuck or need some training.
Right people in the right team structure
We've been able to cherry pick some of the best people that already work for us and go to market for the rest. This means we can really closely get in the skillets we need "off the shelf" rather than having to train & influence a set of existing individuals.
When you employ people that already live Continuous Delivery, BDD, Git etc then your job is considerably easier.
We've really concentrated on the soft skills of the guys & gals that make up the team too. Attitude for me is 99% of the job and technical skills 1%. People with the right attitude will learn the tech. The culture of the team is absolutely important.
Some banking type told me this week that culture is just fluffy and that its just about tooling and automation. I bet you £10m that this team will be more successful than his.
Its
all about culture. Tooling and automation comes out of that culture.
Agile training
Teaching a development team the Scrum process is actually pretty simple. What is often neglected though (I'm guilty of this one) is what it means to the business stakeholders outside of the core dev team. In my experience, business users often want to assert some requirements and then walk away. They also want the full product and the idea of Minimal Viable Product is a hard pill for them to swallow.
In an Enterprise you also get a million and one different stakeholders all fighting for their piece of the pie. Having to prioritise the backlog is difficult when you have different stakeholders from different parts of the business and with a different management hierarchy. You end up with stakeholders trying to reserve story points in a sprint and other work arounds. This is a bad place to be in.
However, we've (the royal we) have spent considerable effort and time spending time with the business stakeholders training them in Scrum. How does prioritisation work? What are the sprint ceremonies? Why should the Agile team be self managing etc etc
The fact that we spending the first month or two on technical setup (CI processes etc)and not on business change gives me confidence that the stakeholders "get it".
Aligned goals (minimal number of stakeholders)
Agile is easier the fewer people that are involved trying to pull the team in different directions. We are lucky that we have a very senior stakeholder that is able to arbitrate and protect the team for the prioritisation noise and that has a clear direction of what they want to achieve.
Self organising
Agile teams need to be protected from outside interference so that they can concentrate on the task at hand.
Too often have I seen other interfere with the running of an agile team and decisions made on their behalf.
Go away! Leave them alone! The Agile team best knows how to organise themselves for optimum performance.
I see really good signs that the team aren't being micro-managed and are protected from the scary, outside world with a good Product Owner.
As long as the results are there, the stakeholder don't seem to care too much about
how those results are achieved. That seems simple but too often people hang on too tightly thinking that it will give them control and will help ensure success. Its actually the opposite; don't strangle the team, let them breathe and hey will get you where you want to go.
Again this is aided but not having too many cooks (stakeholders).
