Rob Bowley shares lessons learned while doing Agile: Scrum is not that bad, Don’t call it Agile, Doing the right thing vs doing it right, Identify the change agents, Hire good people, etc.
Rob Bowley is Head of Development at 7digital Ltd, a digital media delivery company (primarily music) based in London. Rob played a pivotal role in the introduction of Agile at 7digital starting over 3 years ago and was also heavily involved in introducing Agile at his previous position at BBC Worldwide. He is Co-Programme Chair for spaconference.org. Tweeter: @robbowley. Blog: blog.robbowley.net
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
Good presentation but missing some answers...
Firstly though, things I agree with. I agree that Scrum gets a bad rap (I would argue certification is not necessary, but even if it was, so what?). I absolutely agree with the statements that developers require more discipline to do agile than more heavyweight processes, which by their very nature are process oriented and will save the developer if they miss something (this is often due to the redundancy of the processes, such as having a spec that states what the code will do AND tests which cover what the code does mean the lack of one will be covered by the existence of the other, reducing risk if coverage is not there - I don't agree that it is OK not to write tests all the time. This is an inherent fallacy and agree with Rob's assessment).
I also agree with the statement that business sponsors are important and that the importance of doing things right should come first (as it happens, I am not convinced that all system thinking dictates that you should do the right thing the wrong way first) as this allows the 'process' to be worked and software delivered using processes which are solidified over time. This is a form of maturity model and some have argued you can go through both sides at the same time and work to meet in the top right quadrant. These are truly best practises, as they have stood the test of time through heavyweight processes and continue to do so through other, courser grained methods such as TOGAF.
Where I disagree are introducing the statements such as "Don't call it agile, it is industry best practise" because this is inherently a false statement, unless you state it in the context of an organisation where 'pure' agility can take (such as organisations with low number of employees, high collocation, developer centric and the like). For those with experience of larger organisations with non-collocated teams, where there is no architectural input, agile will fail and fail badly (See the paper by Boehm and Turner about their observations published on the agile alliance websites for a study of what contexts heavier methods work better than agile ones), causing no confidence in the methods at all and given how radical it is for some companies, there will be no second chances.
As a result, working towards an agile workforce will need smaller teams (nice small steps in delivering the development capability), eventually working through lean architects (who will be aware of the bigger picture and take advantage of effects such as Conway's law) which gives that 'risk mitigation' to the majority of organisations that sit somewhere in the middle. Time and time again people assume agile will scale and solve all the problems but it doesn't do so on its own and I have yet to see one where there isn't some element of architecture (ideally lean), product management and the like that hasn't come into play in the majority of organisations that are not pure tech companies.