My favorite excerpt from Netflix Freedom and responsibility slides is “Context, not Control”.
Marketplaces are extremely powerful at co-ordinating scarce resources. It’s possible to use it to co-ordinate software development teams. Lets see how.
There needs to be competition between buyers and sellers. Development teams sell their services, and business units buy their services.
You need multiple buyers. For example: the Content team, the Commercial team, and the Search team.
Each month the Big Boss can give each team credits. It can be a different amount of credits for each team, depending on the priorities of the overall business. (Or depending on results of product experiments).
For example, in month 1 the big boss might give: Content team 10 credits, Commercial team 20 credits, Search team 15 credits.
You also need multiple sellers, that is development teams. I think it’s best if the teams don’t specialise and that you rotate one person per team per iteration.
At the start of each iteration the buyers (business units) try and persuade dev teams (sellers) to do their work in return for credits. The credits are effectively a measure of how valuable the work is.
Typically, the dev team with the lower “price” will win the work. The dev teams compete for credits – it’s a measure of how much value the team adds to the business.
As with most metrics, it should only be taken seriously over the long-term. Otherwise, investment in quality code and automation will be half-baked.
If you rotate teams then the credits should be divided equally between the members of the team. It becomes a measure of how effective each developer is.
The distribution of credits each month should be based on the potential of each business unit to drive the business forward. This encourages an MVP/experiments approach.
Having business units spend credits on dev work highlights the scarcity of dev resource. It should promote involvement and collaboration from the business.
This week i had agile training. It stressed the importance of dedicated product owners. The trainer told us that the bare minimum is 50% of the product owners time.
Where i work it’s common to have a nominal product owner who can only spare 5-10% of their time. This effectively means that 80-90% of requirements are “made up” by the dev team.
Put another way, it takes 5-10 times longer for the company to get the product it wants.
It means the dev team are wasting 80-90% of their time.
The quickest fix is to start making members of the dev team into product owners to address the balance.
When teams and systems start to grow, the obvious choice is to assign ownership of different components to different people: “Component Leads”.
The trouble with this is: what happens when the lead is on holiday? Or ill? Or leaves? It’s time for handover. The typical reaction when someone recieves a handover is: We should have done this sooner. Much sooner. In fact, it should have been a collaborative effort from the start.
Developers generally aren’t so keen on working on “other people’s” code. “Why was it done like that?”. “We should have done it like this”. “It doesnt work on my machine”. “WTF?”.
The team should be responsible for delivering value, not the individual. More collaboration, less silos. It fosters learning, spreads knowledge, and increases resilience.
Suprisingly, a collaborative approach plays well with measuring individual performance but thats the subject of a previous post…
Specialisation has been ingrained in organisations since the industrial revolution. It may be a good fit for factory work, but not for software teams.
The games company Valve constantly seek to recuit the most awesome talent. How quickly this happens determines the companies rate of growth. Awesome talent adds value to the business. For detail on how, check out their awesome handbook. (Distilled in this Forbe’s article).
It would be interesting to see how the Valve approach scales beyond a few hundred people. Although, let’s face it, traditional hierarchies don’t scale particularly well.
Could continuous hiring be the the new continuous deployment? It seems to offer many advantages to just-in-time hiring. And it’s certainly refreshing to have an alternative view of growth. Targets driven by profit and shareholders don’t feel right to me. Maybe the financial crisis has taught us something after all.
Dev teams are like football: the paparazi, the glamorus wags. But also the (not so glamorus) stats.
Football has stats such as the proportion of games won when a particular player plays. Great… so whats it got to do with development?
Well, large dev teams often split into two. And if people slowly rotate (e.g. if two people swap teams every sprint) then we can get some awesome stats: the number of successful sprints for everyone on the teams!
The more randomised the rotation the more meaningful the stats. And rotation promotes knowlege sharing. Some businesses favour rotation even if they don’t chase metrics.
It’s the Moneyball approach (which revolutionised baseball) but better. It does for teams what A/B testing does for products.
Meaningful stats are good for targets and bonuses. (Some companies shun using sprint objectives for bonuses). A caveat though, developers typically do it for the love of it more than for targets or bonuses.
Rotation meets random. Don’t underestimate it!
I’m sure there are lots of team maturity models out there. This one is about the level of self-organisation. It’s a simplifiction (like all models).
How does your team score?
(1). Team members need to have specific tasks assigned to them e.g. build widget X for the TV section of the website.
(2). The team as a whole can be given a specific objective e.g. redesign the tv section for the website. Team members can assign themselves tasks. (This is made much easier by visibility of priorities and work in progress).
(3). The team as a whole can be given a results based objective e.g. increase traffic to the TV section of the website by 10%. Note: This objective has quality baked in – it’s hard to game. It’s also simpler to specify – try defining “done” for (1) and (2)! It gives more room for initiative.
(4). The team can work to meet a balanced set of objectives eg 50% customer loyalty, 30% profit, 20% innovation/collaboration.
(5). The team can balance their own objectives e.g. the best way to achieve a sustainable business is to delight customers (with viral baked in) but we need to break even and invest in innovation so we dont get outflanked by competitors.
Of course, a dev team won’t make product decisions in a vacuum – it will draw on the wisdom of the business. The important distinction is that it’s pull rather than push. The team can decide what to do rather then being told what to do.
What Matters Now is Gary Hamel′s impassioned plea to rethink the fundamental assumptions we have about management, the meaning of work, and organizational life. He asks, “What are the fundamental, make–or–break issues that will determine whether your organization thrives or dives in the years ahead?” The answer is found in five paramount issues: values, innovation, adaptability, passion, and ideology.
Innovation: Innovation is the only defense against margin–crushing competition, and the only way to outgrow a dismal economy. In too many companies, innovation is still a buzzword, rather than the responsibility of every single individual. This must change.
Adaptability: In a world of accelerating change, every company must build an evolutionary advantage. The forces of inertia must be vanquished. The ultimate prize: an organization that is as nimble as change itself.
Passion: In business as in life, the difference between “insipid” and “inspired” is passion. With mediocrity fast becoming a competitive liability, success depends on finding new ways to rouse the human spirit at work.
Ideology: Today, businesses need more than better practices; they need better principles. Bureaucracy and control have had their day. It′s time for a new ideology based on freedom and self–determination.
Values: With trust in large organizations at an all time low, there is an urgent need to rebuild the ethical foundations of capitalism. What′s required is nothing less than a moral renaissance in business.
Everyone seems to be talking about data. User data. Understanding users. Good, it’s important.
The catch is that users don’t care about giving you data.
Some companies equate data with user registration but users don’t like registration (even via social login). It’s easy to forget that there are other approaches to user data – especially if it’s not clear exactly what the purpose of the data is… market research? … aiding client pitches? … internal metrics? … cross-media promotions?
Different approaches may be better suited to different needs.
There is another catch. Obtaining representative data is hard.
Some media companies think that age/postcode gathered from competition entries is useful. It’s not. It doesn’t tell you (for example) if your users are young. It just tells you if you had a competition that appealed to young people. More generally, competitions are skewed towards time-rich, cash-poor users.
And of course, building and maintaining a registration system isn’t trivial. There are security and browser issues. Automated testing (how do you create/delete test accounts?). Asynchronous flows (such as confirmation emails).
It has to work with within other flows such as posting a comment. There are edge cases.
There are the alternate flows: unsubscribe, forgotten password. Do you need an “edit profile” page?
What about mobile? What about an API? And how do you actually do something useful with the data? If you use Janrain Capture, for example, you have to develop a custom system to export data as CSV.
The real cost of registration is the complexity it adds. Complexity reduces agility.
Despite all this, some companies place registration way ahead of delivering a top-rate product for end-users.
Some companies don’t bother to try simple solutions before embarking on a grand data cathedral.
One option is a prominent but unobtrusive one-click poll. The result can be stored in a cookie and tracked in Omniture. It is more representative than most other options. Like any approach, it’s not perfect. But it’s a good start.
Other options include
What’s your approach? Leave a comment below.
