There is a brilliant article here written by Yammer’s VP of Engineering Kris Gale. The article is covers a talk that he did at Hack+Startup on why the traditional engineering organisation structure is dead.
The truth is that in many ways he is absolutely right. The rise of Agile, Lean, DevOps and Continuous Delivery all show that the landscape has moved wildly within the last few years and the structure of engineering organisations needs to adapt to this.
Kris points to a new engineering organisation which follows the following rules:
- Small teams (2 to 10 people) doing small projects (2 to 10 projects)
- All projects have a definite end date
- Team members only assigned to one project at a time
- Prevent specialisation
- No code ownership
- Bug fixing is done by everyone
In his talk that went along with the article, he mentioned that he was deliberately contrarian and wanted to make people think and he’s succeeded and I agree with almost everything he says. Traditional engineering organisations need to follow this approach when it is right. The issue is that it is not always right.
It’s unarguable that Continuous Delivery has gone from being just a CTO friendly buzzword to a central requirement for a high performance delivery team. It’s no longer cutting edge to merely check in your code to source control and have Jenkins or other continuous integration box run the unit tests. You have to be able to get that code out into a live environment as fast as possible and that means Continuous Delivery. The ability to deliver code into production at will has a direct effect on your bottom line but to do this effectively you need two things, 1) understand the important areas of functionality that the customers really use and 2) be able to test these areas as quickly and easily as possible. The first is a business issue but the second boils down to automating your testing.
The trouble is that most of the industry holds on to a quality assurance process that is directly at odds with this. The reasons are mostly historical but companies have had varying levels of success in the drive to automate QA. The level varies on how highly the company values this ability. So what levels of QA do we commonly see?
In an Agile project trying to get useful functional requirements from your business can be a painful task. Unless they are experience Agile practitioners, it’s like asking a home-owner to design a house. The requirements they give you will be completely different than what an architect would give you and is pretty likely to be not completely thought out; bits will be missed out, specific guidance on how particular bits should be done will be lacking so something that passes all the acceptance criteria will have to be torn down and done again.
Now I know that Agile allows you to revisit areas and refactor them but wouldn’t it be nice to get the business to give you a set of specs that looks at things from multiple perspectives. That way you would be more likely to get a coherent set of requirements with only a few missing bits that are easy to work to.
The next time I need to get requirements I’m going to use the carrot and stick approach. I’m going to get a whiteboard, draw a line down the middle, write “WORST” on the left half and “BEST” on the right. When business have to come up with requirements I want them to come up with the most painful process that would actually work and write that down in the WORST side. I want them to think about the most inept way they can get something done. Once they got that down, only then do they get to describe their ideal solution in the BEST side. This way they are forced to think about the worst case scenarios, the inefficiencies, the bloody-minded stupidities the faffing about that always surround inefficient solutions and deliberately steer away from them.
Of course this is nothing new, it’s just a matter of negative and positive requirements (“must do X, must not do Y”), but it seems a nice understandable way to encourage business folk who don’t have much experience with Agile to interact with development.
A week after launch and we have successfully achieved the goals we set for our client and completed the triage period.
Running an Agile project of 40 people is no mean feat, especially considering that a large Agile team is considered to be 10 people. Sure we hit some hiccups along the way but we also dealt with some issues that affect all large enterprises changing to Agile development. Some were dealt with by tried-and-tested methods and some were dealt with by solutions that we came up with ourselves. I’m in the process of writing up the project as a case study that deals with all the pro’s and con’s of running Agile at this scale for a single project and I’ll be sure to post the outcome of the paper.