I have been following a new blog by Tim McOwan called www.devballs.com and it focuses on delivering software using a Scrum Process.
His latest article, Guess What? Scrum Developers should be cutting code, period! has provoked some interesting comments and my comment turned out to be so long I decided it should become an article in it’s own right. The comment I was replying to was from Jason Gorman, in a nutshell it was that Business Analysts are not required developers should work directly with the customer.
While I understood what was being said I could not agree with that point of view and it seems that it would be throwing the baby out with the bath water. It sounded very Us and Them which is a bad place to be and seemed to be describing problems associated with a waterfall approach rather than scrum.
I'm a developer and have learnt some very hard and expensive lessons over the last 2 years about the holistic success of software projects, not just the technical success. This has given me a very different view and appreciation of what non-technical people bring to the overall success of a project, essentially removing that developer chip on my shoulder.
I strongly believe:
1) That BA's can have an important role but are not always essential.
2) Having a good manager is a must
3) Using Scrum properly means that everyone knows and values what everyone else is doing.
The Manager
The reason you need a good manager / scrum master is to protect your developers from the customer and enforce the Scrum rules. They ensure the bits of the project jigsaw will fit together. They should be masters of the political game, they should be setting customer expectations, organising the customer's people to be available, keeping them up-to-date, making sure that the developers don't have any impediments stopping their development, keeping an eye on the team, settle any disputes etc. They don't need to cut code they just need to pull it all together. And if they are good nobody notices how hard/well they are working. (well I notice nowadays).
The Business Analyst (BA)
It is a common experience that developers have of a BA who don't deliver great information. However they do get a first version of this information and that can be a full time job in itself. It is hard to organise meetings with the customer. How many times at a first meeting do you ask someone what they want and they just have not thought about it. How many times does one department know what they do but are not really sure what other departments do and fit in. There's another meeting to organise and another then another. Finding out who does what is really really hard and takes a long time. As a developer I don't want to do that for days or weeks at a time, I want to be cutting code.
Where there is complexity and uncertainty in the business requirements let the BA's at it so that an overall picture can emerge and prioritisation of what delivers the most business value can happen. However if it is a fairly small, well defined business requirement I don't think you would need a BA and letting the developer engage directly with the customer would work very well.
The BA also serves another role which is essentially after sales / customer care. Once the software has been written and made live the BA should go back to the customer and see how well it is working. It could be the new software has thrown up some unforeseen problems. This is all very time consuming and having a highly skilled developer doing this makes little sense. It requires a personal and working relationship between the project team and the customer again this takes time to develop. Let the BA’s do this which frees up the developers to write software.
The Developer
We like creating stuff, we like solving technical problems playing with latest technologies, new software packages, coding techniques. Letting a developer loose with the customer to get requirements could quickly turn into an indulgence of what we want to do rather than solving business problems. We will be coming up with the technical solution to a problem before the problem has been properly thought through. It is fairly easy to persuading the customer they need a more complicated solution than is required.
By giving the developers a first version of the requirements and then let us think of the solution is a much more sensible approach. Yes the requirements will consist of nonsense and contradictions but the general direction has been set and we just need to work through the detail. The BA’s and customer will be on hand to help navigate this minefield.
Scrum
Here’s the kicker, using scrum properly ensures high communication and visibility between everyone involved in the project. There should not be “developers in meeting rooms gassing about it with analysts and managers”. The analysts should be on hand to sit with you when you develop something, even better – get the customer involved. The dev’s will see what the BA’s are doing and visa-versa which should foster a sense of ‘Team’ and if someone isn’t delivering value it will become apparent pretty quickly. They should either be helped to perform or removed from the team.
Summary
So in summary, a scrum team needs these different roles and everyone brings value to the project and if they don’t it will be seen and there should be systems to deal with them. The manager protects the dev team and brings it all together, the BA’s build relationships with the business and get requirements and makes sure that the software has delivered value, the dev team get 3 week sprints to develop working software and are able to call on the BA’s / customers to clarify any nonsense and contradictions.
I read a book about 6 years ago called Coding Slave by Bob Reselman, it was a good read. One bit stuck in my mind and that was us coders are like Charlemagne’s scribes and I think this is very true:
http://www.informit.com/articles/article.aspx?p=170198
It has taken me a long time to appreciate this but now I appreciate the value others bring I am much happier in my own work.
18cd444f-474d-44ec-bf02-9b10861a99d6|0|.0