I spent a day last week in London attending the first Scrum Day conference held in London. What follows is a light summary of what was discussed and some personal analysis.
The key highlights for me of the event were a key forward thinking and pragmatic case study discussion of Capital One's agile transformation, presented by CIO Rob Harding, and an enlightening discussion on uses of Scrum techniques in alternative industries by Ade Shokoya.
There were a variety of individual presentations on 4 different tracks and some core elements.
The conference was opened by Gunther Verheyen from Scrum.org who presented a good talk on measuring value over performance. Focussing on collaboration over performance at team level leads to improved performance and prevents 'gaming' the metrics system, which then focusses on the delivered product rather than the team. He briefly showed various elements from ebmgt.org including some traditional value measures and their agility index. There was a lot of common sense here, though I felt that, while Scrum.org had branded a lot of this up, there was little new here. This is ground covered by the Nokia Test and Geoff Watts very successfully before in his excellent book 'Scrum Mastery'
My first optional talk was Ralph Jocham, who provided a really good case study on scaling the Scrum implementation used for the Swiss Post app development work. This development was for a suite of interconnected applications for a complete logistics solution. They hired different suppliers through a bidding process on time & materials to provide Scrum teams and hired an office to put them all in to enable co-located working. Each team had a different app focus with a PO, SM etc. Ralph acted as a head Scrum Master, facilitating between teams and acting as a buffer between the teams and the more linear organisation they were working for. Interactions between teams were handled by having regular 'Alignments' (meetings) between the key disciplines of PO, SM, Architects and QA.
My second optional talk was with Cesario Ramos who spoke about 'Scale your Product, Not your Scrum' - Essentially this was a LeSS presentation, detailing the process of scaling by becoming more feature driven and not component orientated. He introduced the concept of having a merged retrospective, in addition to the team retrospective which makes a lot of sense when dealing with large scale product development. He also stressed the importance of encouraging people to 'Just Talk' and that 'More formalisation decreases communication' (which really resonated with me but was in stark contrast with what was to follow. He closed by presenting a map for feature team adoption - I found a copy on the LeSS site here.
Rob Harding, CIO of Capital One was next to take the main stage. He spoke at length about the transformation of Capital One into a Scrum based organisation. He really stressed the importance of the need for harnessing the power of the company culture to enable a successful transformation and how high level transformation is crucial to maximising the potential of change. This also resonated with me in my belief in adapting what exists rather than revolutionary change where possible. The key element to his change which stuck with me was shifting from an organisation that worked with projects linked to budgets to an organisation that worked on products delivered according to capacity.
My final optional talk (after the Keynote) was with Ade Shokoya. Ade gave an excellent (albeit far too compressed) talk on how Scrum has been used in different industries outside of software development. This is something I'm really passionate about and that I believe is a massive growth area for agile as a whole. Ade showed how new technologies such as 3D printing are enabling rapid turnaround in manufacturing and enabling them to be more agile. He also went through other industries that have used these techniques, from clothing (Zara) to education (eduScrum). I could have done with another hour on this.
Keynote with Ken Schwaber & Dave West
Ken Schwaber, co-creator of Scrum, co-presented this with Dave West, the product owner for Scrum.org. This started out with an introduction on Scrum.org's mission statement, which has been changed from 'Improve the profession of Software Development' to 'Improve the profession of Software Delivery'. They went on to describe the common organisational scenario that occurs where Scrum happens within a traditional framework, which they referred to as Water-Scrum-Fall.
Ken & Dave then went on to present recent innovations from Scrum.org, including the Agility Index that Gunther had shown earlier, 'The Nexus', a formalised, simple, strategy, for scaling Scrum. On review after the conference, it makes sense in the most part for very big projects. Details can be found on the Scrum.org website. It's worth a read if you want some ideas on scaling very large projects.
Ken introduced the Scrum Development Kit. More info of which is on Ken's blog. The idea with this is to provide a more end to end definition of done and provide teams with the tools to help them get there. The final reveal was a very high level description of 'Scrum Studio' a recommendation from Scrum.org to rather than transform the existing organisation, to build a new one beside it instead.
After a break for another talk, the main speakers including Ken & Dave reconvened for a Panel discussion. In this it was revealed that Scrum.org are to add yet another level of certification (PSM III) on top of their existing certifications. What really struck me was that someone in the audience asked Ken about Scrum in other industries. He refused to comment as he only saw Scrum as a tool for software development. This was in stark contrast to other talks during the day and left me, as a pragmatist, feeling quite negative about the future of Scrum.
For some organisations, Water-Scrum-Fall, is as good as it gets without significant changes in business operation and is, arguably, a good step in the right direction. This is not to say that you get the full benefits of Scrum - you don't, but for some businesses the full end-to-end process cannot be fully transformed. I do a lot of work with agencies and many clients prescribe a certain level of commitment and fixed scope. Enabling the business delivery elements to work in a Scrum style allows the agency to satisfy the needs of clients with different contractual requirements and operate in a cohesive manner. I will be presenting articles on how to get the best from an unavoidable Water-Scrum-Fall scenario in an upcoming post.
Much of what was discussed suits large scale development, ideally internally. When working with agencies (or anyone providing products for multiple clients) the strategy of transforming the upper part of the organisation first (to avoid Water-Scrum-Fall) doesn't work - you need to be able to handle multiple ways of delivering in order to satisfy client needs. As Scrum-WaterFall-Scrum is pretty much impossible then Water-Scrum-Fall is a good starting point for some clients. As the agile maturity of the organisation improves the organisation can begin to educate it's clients to transform relationships to pure Scrum. To support this, a Continuous Improvement Office is essential.
Each of the core Scrum organisations (Scrum.org, Scrum Alliance, Scrum Inc.) all seem to have their own branded variation on how to scale Scrum. They all seem largely similar. What Ken & Dave presented as 'The Nexus' isn't really anything new or a game changer. It's largely what Scrum consultants have been working with variations of for years.
Although the problem behind the Scrum Development Kit makes sense the solution of a recommended toolset seems a bit weird to me as there are so many variables that go into defining a definition of done. To me the whole point, and a measure of agile maturity, is how good you can get your definition of done to. I'm not sure I can get behind this, it feels like Scrum.org are telling people that they just aren't good enough unless they do everything just the way that things are prescribed to them. I hope that I am wrong - When more is revealed I will undoubtedly write about it again. An acceptance that you can always be better is a given in agile circles.
I liked what I saw of Scrum Studio although, once more, this seems like a rebranded rehash of ideas that are not new. I remember reading about something similar, used as a transformation tool in Mike Kohn's 'Succeeding with Agile' where he referred to it as an 'Enterprise Transition Community'. I have recommended the establishment in several organisations of a 'Continuous Improvement Office' which essentially takes on the roles of the ETC ongoing and merges in some elements traditionally done by a PMO (Project Management Office) - Details were sketchy though so I'm hoping there's more goodness in here.
I am a pragmatic agilist. I am proud of that fact and I strongly believe that businesses best solutions are found by combining elements together from different agile philosophies. I felt let down by the dogma of the keynote speech in the way that Scrum seems to be growing where it's greatest benefit has always been it's simplicity. It felt like the whole keynote was a massive sales pitch for Scrum.org and their own brand of certifications. This left me with a load of questions which I will be looking to address in posts over the coming months...
- Is Scrum (in it's formalised state) dead?
- With so many 'right' ways, if there is a 'right' way, what is it?
- Do we need a framework to be the best that we can be?
In answer to a lot of these I would like to re-quote Cesario Ramos - 'More formalisation decreases communication'
Feel free to join the discussion below.