A few days ago Joshua Chappell tweeted this:
Theres always talk of scaling-up #agile; is anyone writing about scaling it down? Need to help small shops of 1-4 Devs in sister companies.— Joshua Chappell (@joshchapp) February 27, 2014
As I have a fairly strong opinion on scaling agile (don’t, scale autonomy instead) I thought this would be a great excuse to describe my ideal team situation. So here it is:
Give people a problem, not a task
The absolute most important thing in the list.
A lot of people, in and outside the agile community, are obsessed with getting tasks to and through development teams as efficiently as possible. These tasks are usually stored in a big list maintained by some important guy up the food chain. The best you can hope for when you give someone a task is that they finish it as quickly as possible.
If you give people a problem instead, you will instantly unleash their creativity in solving the problem. This autonomy to solve a problem also happens to be the best way to motivate people and get them engaged.
Make sure all required talents are on the team
Writing successful software applications is hardly ever constrained by the typing of the code. Yet we focus a lot of our attention on software developers and keeping them busy. If we are giving a team a problem though we need a lot more skills. People who can really understand the problem, communicate with users and stakeholders, interpret data, and design a customer experience are just the tip of the iceberg.
Give the team the resources they need
This goes much further than making sure they have a second monitor on their desk. Do they have the test environments they need? Do they have access to users/customers? How quickly can executive decisions be made? Do they need to get permission for everything they do? Are they allowed to run experiments?
One of the most frustrating things you can do is give people the responsibility to solve a problem, but not give them the tools, access and other resources they need.
Let the team experiment
The reason to do a project is you want to do something new. So the worst thing you can do is to assume you know everything at the start. You don’t.
So give a team the chance to learn. A low-risk option to do that is by talking to stakeholders, users and customers. But sooner or later you need to experiment with prototypes and later also in production. How do these customers behave compared to this other lot?
Just stop assuming your customers are going to run away screaming at every change, or that your users will resemble a deer in highlights when the order of the buttons is changed. All of the big sites out there are constantly changing this and their users are doing just fine.
You do not have to experiment on all of your customers all the time. But every Internet company out there is running tens if not hundreds of experiments in parallel. And they are learning about their (and your) customers much quicker than you are. So you need to figure out a way to deal with this.
For a great introduction on how to learn read The Lean Startup by Eric Ries.
2 week iterations are a crutch
I know the Agile Manifesto says a few weeks to a few months with a preference to the shorter time-scales, but that was written in 2001; a life-time ago. All the tools are out there, most even free, to allow you to release daily, or even faster. There are no more (valid) excuses to release monthly, or quarterly. In the end every line of code you write, without having tested the myriad of assumptions underlying it, is most likely waste.
So you need to run your experiments continuously, not every couple of weeks.
And while you probably have a lot of technical challenges to overcome to release more often, it is more likely that you have organizational silos around Problem Definition (The business), Solution Development (Software development teams) and Change Management (IT operations). Your software developers are rewarded for introducing lots of change and your operations people get called out of bed at 3 in the morning when things go wrong. Still wondering why they don’t get along very well?
Also when trying to release more often than once a week I often see the cracks appear in Scrum. So take a look at something like Kanban and continuous flow to guide your day to day work. Don’t give up on doing retrospectives though.
To read more about how to get your Devs and your Ops to work together, read about DevOps in The Phoenix Project. Marcus Hammarberg and Joakim Sundén (from Spotify, who really get all this) wrote Kanban in Action. And when you want to read how to completely turn all your development practices on their head to go a million times faster, bug Dan North to finally finish his book. In the meantime go to one of his Accelerated Agile courses.