Cup acconf 2017 v1 1pptx
•Download as PPTX, PDF•
0 likes•39 views
How we are bringing Agile to a 400 year old organisation Author: Clare Tunstall & Vicky Drummond
Recommended
Recommended
More Related Content
Similar to Cup acconf 2017 v1 1pptx
Similar to Cup acconf 2017 v1 1pptx (20)
Recently uploaded
Recently uploaded (20)
Cup acconf 2017 v1 1pptx
- 1. “The world is seeing the most radical transformation in the distribution of knowledge and information for 500 years. The values we have sustained as the world’s oldest publisher will continue with us on our journey into an exciting future.” Sir David Bell, chair of the University of Cambridge Syndicate
- 2. How we are bringing Agile to a 400 year old organisation Clare Tunstall & Vicky Drummond Twitter: @ClareTunstall @VickyDrummond
- 4. Our history
- 7. Digital expertise has become central Digital and blended as a % of sales 14% 17% 23% 23% 26% 32% 36% 40% Cambridge Core, our platforms bringing academic content onto one platform Nominated for user experience awards The Cambridge Learning Management System supports our leading products including Testbank, Empower and Touchstone HOTmaths, our leading Maths digital learning product
- 8. Our Purpose Our vision is a world of learning and research inspired by Cambridge Where – We enable people to achieve success by providing the best learning and research solutions – We support our customers through continually improved content, experiences and care – We use our profit for purpose, contributing to society by furthering the mission of our University We exist to unlock people’s potential with the best learning and research solutions
- 9. Where we were – our content platforms
- 10. Where were we – the numbers Lead time 6 months Cycle time 2 weeks Release frequency 2 or 3 per year Deployment duration 2 weeks Availability: 99.53/99.56 * Release failure: 9%/7%* * CJO/CBO 2014
- 11. Where we were …culture & thinking • Completeness • Perfectionism • Business knows best • Silo mentality • Want it all want it now • Low-viz offshore teams • Lack of ownership
- 12. “The world is seeing the most radical transformation in the distribution of knowledge and information for 500 years. The values we have sustained as the world’s oldest publisher will continue with us on our journey into an exciting future.” Sir David Bell, chair of the University of Cambridge Syndicate
- 13. The opportunity to change: AOP – the academic re-architecture project • Re-architect CBO and CJO to bring them together into one combined content platform • Use research to understand our customers better and to inform the new structure and design • Employ Agile methodologies to fulfil the in-house build • Create a dedicated programme team to deliver
- 14. AOP objectives 1. Combined book & journal platform 2. Customer centric 3. Industry leading & innovative 4. Clear brand strategy 5. Flexible, responsive, robust, scalable
- 15. Hello Agile! Image copied from a Slideshare presentation by Johnny Ordóñez
- 16. What did we change? • We put the customer first • We started truly collaborating • We improved our focus • We adopted a continuous improvement ethos
- 17. Customer first – research • Major global research comprising: • 50-question survey with over 9,200 respondents (researchers, authors, society partners, librarians) • 50 face-to-face interviews with customers from all over the world • 10 internal stakeholder interviews • 3 internal workshops
- 19. Customer first – the feedback process
- 20. Customer first – testing
- 22. We improved our focus – MVP/MLP “Creating an MLP means involving one’s customers from the start in the concepting and design of the product.” Credit: http://www.moonshot-io.com
- 23. We improved our focus - Tradeoff Matrix Fixed Flexible Accept Scope X Schedule X Quality X Resources X Adaptation of Jim Highsmith’s Tradeoff Matrix – Agile Project Management
- 24. We improved our focus - prioritisation CC Image “Square peg round hole 21” courtesy of Yoel Ben-AvrahamCC Image “Square peg round hole 21” courtesy of Yoel Ben-Avraham
- 25. We improved our focus - prioritisation
- 26. We improved our focus – the basics • Timeboxing • Just in time planning • User stories • Team charters & agreements, policies, guidelines – Definition of Done… – Definition of Ready… – …but should we share them?
- 27. Continuous Improvement – Continuous Delivery
- 28. Continuous Improvement – Dispersed Teams Credit: Creative Commons CC ‘Hiding’ by Kristina AleandersonCC ‘This is not communication’ by mollybob We must “acknowledge and intentionally accept the productivity impact, co-ordination problems and lack of teamness” that working in dispersed teams presents. (Larman and Vodde)
- 29. Continuous Improvement – A Learning Culture
- 30. Where we are now – Cambridge Core
- 31. “It looks really good… We’re very impressed” Nutrition Society I'd like to congratulate you on the Cambridge Core platform - it looks great. The site is very easy to navigate and looks crisp and contemporary. Crossref Highly efficient in finding sources based on solid search criteria. Researcher Using your journals site this morning made me weep with joy. It's such an accessible, easy to use interface. tell your developers they are sexy geniuses. Researcher Where we are now – some nice words… Two different tech vendors (Ingenta and HighWire) I had meetings with at LBF mentioned that they’ve been asked ‘to build them something like Core’.
- 33. Where we are now - culture & thinking Completeness Perfectionism Business knows best Want it all, want it now Silo mentality Low-viz offshore teams Lack of ownership Iterative Good enough Customer knows best Prioritisation & MVP We’re in this together All part of the team Responsibility
- 34. Where we are – the numbers Lead time 6 months 2 days Cycle time 2 weeks 2 days Release frequency 2 or 3 per year weekly Deployment duration 2 weeks 2 days Availability: 99.53/99.56 * 99.98 Release failure: 9%/7%* 2% * CJO/CBO 2014
- 35. “The world is seeing the most radical transformation in the distribution of knowledge and information for 500 years. The values we have sustained as the world’s oldest publisher will continue with us on our journey into an exciting future.” Sir David Bell, chair of the University of Cambridge Syndicate
- 36. Any questions? Reading Suggestions Agile Coaching, Rachel Davies & Liz Sedley Agile Project Management, Jim Highsmith Building Successful Communities of Practice, Emily Webber Lean from the Trenches, Henrik Kniberg Agile Retrospectives, Esther Derby & Diana Larsen Scaling Lean & Agile Development, Craig Larman & Bas Vodde Practises for Scaling Lean & Agile Development, Larman & Vodde Contacts Clare Tunstall, Agile Coach, Academic Technologies email: ctunstall@cambridge.org Twitter: @ClareTunstall Vicky Drummond, Head of Customer Experience, Cambridge Core, Academic Publishing email: vdrummond@cambridge.org Twitter: @VickyDrummond
- 38. Our history
Editor's Notes
- Show this as people are sitting and settling down CLARE - INTERACTION Before going to first slide, learn about the audience. Hands up if your organisation is older than a year, keep them up if 5 years, 10 years etc. /25/50/100/200/300…. We win?
- About us… I’m Clare, Agile coach. 20 years software experience. I’ve been at CUP for 8 years. Been agile for 5. 1st Scrum Master. Internal coach and change agent (also office fruit pusher – fruit bowls to keep teams healthy & feel valued) Proud of my reputation for making things happen and fixing problems, but also taking care of people. Absolutely no going back. Interests: mum to two boys 8 & 12, choir, relearning pottery. I’m Vicky….
- CLARE About our organisation Cambridge University Press is an integral part of the University of Cambridge, host to this conference We’ve published the work of Milton, Newton, Austen, Byron, Darwin, Einstein, Bertrand Russell, Jane Goodall, Steven Hawking and many others, about discoveries that changed the world – X-ray, DNA, split atom, evolution, jet engine. And we’ve published the work of more than 60 Nobel Laureates We cater for 4 distinct and separate markets – Academic, English Language Teaching, Education (schools) and Bibles Vicky and I work in Academic Publishing – our talk is only about this part – not the rest, although there are pockets of agile appearing there too.
- CLARE We are the oldest publishing company in the world We were amongst the first to put our journals online – and that website didn’t change until recently. Notably, only 1/20th of our lifetime has been in digital In the relatively short time period of the last two decades we have introduced our first electronic books on CD-ROM, our first website, ecommerce, online journals and books, print on demand, e-books, a learning management system, and responsive website, to name a few changes.
- CLARE Before the introduction of digital, the technology of printing didn’t change much for 500 years! With printing when mistakes are made they are costly both financially and for our reputation. A classic example is the 1631 edition of the King James Bible – known as The Wicked Bible. The word “not” was accidentally omitted from the commandments thus instructing “thou shalt commit adultery”. Not surprisingly most of these books were destroyed and only a handful of copies survive!
- CLARE Despite our perceived reputation as being archaic, throughout our history we have pioneered new technology to improve the quality of our print production and content. This has also meant that we have always been an organisation that has excelled by creating a culture of completeness and perfectionism. In this fast moving world of digital products we have found that this approach is not appropriate. Printing books is an industrial, repeatable and therefore predictable process, but building digital products is not. Digital gives us an opportunity to change things on the fly. But until recently we were still using a waterfall process to cover all project types. We are learning that Agile methodologies are appropriate.
- CLARE The appetite for what we are doing is increasing in the wider organisation; our Agile product teams are looked to as leaders, as Digital and blended products now account for 40% of our sales – and the problems we are solving are common throughout our organisation. We’ve not been able to make this change quickly. We are maturing over the period of a few years. This talk provides a snapshot in time, starting quite early on in that journey.
- VICKY to introduce Core, CJO CBO We are going to be talking about Cambridge Core - a brand new digital platform for Cambridge University Press's academic content. As such it is key to the delivery of our mission:
- VICKY We have over 370 journals, containing about 1.6m articles in Cambridge Journals Online And around 30,000 books, with more than 260,000 chapters on Cambridge Books Online So in all around 19m pages of content on both platforms – laid end-to-end these pages would stretch from Cambridge to New York These platforms have served us well but in recent years we’ve had feedback from customers that it would make sense to have all our content in one place
- CLARE (READ THIS IN FULL) CJO was 17 years old (not a bad innings!), falling over, and buried in tech debt. CBO was relatively young but struggling. CJO was released 3 x annually and CBO just twice annually (plus point releases to handle fixes and those requests that couldn’t wait 6 months (but limited to 15 tickets per release, most of which were bug fixes only 1 or 2 ‘small improvements’ or ‘features’). Lead time was 6 months - Requirements were submitted 6 months in advance of release, and often the biz wouldn’t see the feature until 6 months later and, unsurprisingly, it wasn’t always get what they thought they had asked for. Cycle time - A one line code change (or even text change in many cases) would probably take at least 2 weeks Deployment to production was 2 weeks+ (infrastructure didn’t trust the team not to break it so this meant a 2 week code freeze whilst they undertook their own regression testing) Availability – doesn’t look too shocking – but that’s because we were only measuring the home page – actually had a lot more down time in other areas of the site. Rollbacks – quite high. Releases were limited, and the majority of tickets were for bug fixes. WE WERE SPENDING MOST OF OUR TIME KEEPING THE LIGHTS ON. Interaction: Does this scenario look familiar to anyone in the audience? Any thoughts or comments?
- VICKY – biz perspective Our organisational culture was holding us back: Completeness & Perfectionism – Culture of launching a complete and perfect product. Takes too long and by time ready it’s outdated Business knows best – some customer centricity but predominantly assumption led and guided by competitors and demands of publishing partners CLARE – tech perspective We also sometimes struggled with the academic environment, and tendency to debate and discuss rather than decisiveness. Long Jira tickets with unresolved debates between stakeholders. Conflicting requirements in separate requests. Silo mentality - Separate QA and infra. BA wrote requirements on behalf of biz, devs were not consulted. Lack of aligned vision & thinking led to misunderstanding, sub optimal software, and ultimately, blame Low-viz teams – working with offshore development teams in Manila, gave us many problems that we ignored. They were not consulted, they were passive recipients of solutionised requirements. Lack of clear expectations or joined up product leadership led to poor quality & lots of waste – making them easy scapegoats. All in all, the business was dissatisfied with technology and vice versa!
- CLARE The result was that we were serving neither our internal or external customers with the level of service that the quality of our product – our content – deserved. Combine the problems we were struggling with and the seismic shift that David Bell describes here, it was clear that it was going to take more than “values” for us to stay in the game - something had to change in the creation, management and delivery of our products. We had to update our practices, take back some control of and be more responsible for our processes, and we needed the business to provide clearer direction. Agile fitted.
- VICKY
- VICKY How did we get to here from where we were? In short, a customer-driven approach, together with Agile delivery methodologies, has been transformative to our business
- CLARE We have not been able to make this change quickly . We knew it wasn’t going to be easy, but we drove the bottom up transition ourselves in technology. Low risk POC / experiment self contained Started small, an experiment on low risk corporate site, without the biz, a small team, incremental improvement, started addressing some of our big problems almost immediately. Scrum events -> high viz of Manila team Timeboxing & Sprints -> visibility, reduce task switching, improved focus Invited a QA member to join the team – earlier feedback loops. First taste of a more cross functional team. 2. Cambridge.org – our sales and marketing site - was next – Vicky invited to be our first PO for the academic part of our S&M site Asking the biz was hard, but legitimised by the fact that Agile used widely & successfully elsewhere. Vicky soon realised that PO is a full time job and recruited a dedicated PO We evolved the role – biz taking on more of the responsibilitie of PO as they saw the benefits The change was massive - shorter feedback loops, greater communication, time investment needed soon led to permanent role, and adoption across our sales and marketing website (3 teams, 3 SMs, 3 POs) Because of WMP POC we were ready to try agile with something bigger Note that WMP Agile has continued to improve since then, and is major part of our community. 3. We started taking off when we get Board agreement to use Agile for a much bigger programme, which we will talk about. But would remain organic, bottom up transition. 4. We gained height with Education & familiarisation Time spent educating people about Agile – training, CoP – l&l, talking to our board members and senior management, getting POs trained, crib sheets, visiting Manila kicking off their CoP Terminology was alienating but necessary to differentiate – board lunch Cathy! 5. Teams created & start developing Component teams – skill sets at the time UK different to Manila (more senior/experienced, younger less experienced in Manila) and we built an onshore team for collaboration/responsiveness with biz. Also, a very broad range of skills in our tech stack. Front end team only was Agile at first – I was SM. SMs transitioned from del mgr role, got certified then worked with me. How ACCONF has helped I’ve been to each ACCONF since 2013, and bring more people with me each year. Autotrader talk at ACCONF 2014 (This was a lightbulb moment for Nik and I – about adoption being a long process of continuous improvement, and it being OK to be pragmatic and choose your battles – not aiming to become agile overnight.
- CLARE We changed loads to move away from the old culture and way of doing things – it’s difficult to distil down! We tried loads of stuff and encountered heaps of challenges, a few of which we will share with you here, but here are the 4 most important things we did Read the 4 out loud
- VICKY Wealth of data to get under the skin of our customer’s motivations, behaviours, expectations and the context of their visit to academic content platforms
- VICKY Improved collaboration enabled us to Improve our focus - result of all research led to personas - describe the customer research work and how the personas were developed. How this hard evidence has stopped the Hippo dead in the water! - Analytics Impossible to build a platform to accommodate the idiosyncrasies of everybody using it. Way I behave online could differ from…HSS/STM BUT Personas are an abstraction of what is common – and allow us to pick out the most common user journeys. They can also make key user groups “come alive” in the project team. What’s important to Lin at this point? What is Rachel likely to want to do here? Humanised them New tool. Major piece of internal work to explain the research and put the personas in context.. Information around the office. Weaving into conversation. Etc. Validated/challenged decisions Powerful weapon in our arsenal
- VICKY
- VICKY We shared the research results and the user journeys accompanying the personas internally … and then used both heavily to start the design process, using our design agency Make it Clear This was a very iterative approach, checking designs against the user journeys and with real users from each persona at stages before design sign off. We also tested terminology Once we moved into development, then we’ve worked hard to check in with our user groups as we build. The graphic here shows some of the key points we’ve done this [could go into a bit more detail each and about how agile has allowed us to do this here if we have time?] Rachel testing to ensure we had covered all the essentials
- CLARE - USE POINTER? The business and technology start truly collaborating …we took down the metaphorical fence that was dividing us. The background is pink and fluffy here because this is the soft stuff – the human element is the secret sauce – building relationships, providing a common language and creating opportunities to talk. That’s where I came in. Some people found that hard (and still do – it’s not for everyone). We had to take people out of their comfort zone, much as this slide feels out of place in this deck. USW: At the start of the project I organised a User Story Workshop inviting stakeholders and the early development team to work together. We worked together to define user journeys and the top level requirements By inviting some real users along (researchers and librarians) we were able to validate – even threw the features they said they simply wouldn’t use or didn’t need, saving both development and maintenance costs for those features Set up: Now we were ready to start, we cut ourselves off from the rest of biz- we were left alone to get on with it, but still collaborated with them, just in a more structured way. We quickly developed our own culture, distinctly different from the rest of the organisation Product Ownership: PO Vicky as chief spanned the gap between technology and biz – represented a single vision, decision maker, took a lot of slack that technology was absorbing before Our product managers and Bas were given Product owner training - Scrum Alliance certification is a good foundation to start from. We had 7 dedicated POs on the programme, led by Vicky, they became more decisive, and had explicit responsibilities including ensuring that the customer was always represented. But new role presented challenges: Hand over to Vicky! Ask about resistenace VICKY resistance, power struggles, fear of change, some lack of willingness to change, some feeling left behind, threatened. Shield/sponge CLARE: people wanting to replicate the old product exactly . Our POs are very much part of the teams and support the developers and QA, working though things together. User Stories: Connect with personas We had struggled with ambiguous, conflicting, or over-prescriptive requirements. Well-written stories enabled the right balance of clear direction vs discussion, although we had mixed levels of success with this…old habits were harder to break for some more than others, and the open ended questions, indecisiveness, tendency to solutionise was still problematic in areas. We had to make some team changes. Trust: Collaboration requires trust and the ability to understand and admit when you are wrong. We have worked hard on building trust by enriching our interactions with each other, this is especially challenging when you work in dispersed team. We use tools and techniques such as retrospectives, fist of five, dot voting, turn taking, to ensure all voices are heard and that everyone can be seen. We create team charters and values so we know what to expect of each other. We visit each other whenever possible, and arrange team outings to make the most of our time together. Day to day, we create opportunities to learn more about each other, adding a few minutes on to a meeting to exchange small talk or to play a quick game if that doesn’t come so easily. None of this was happening before. At the start I worked in a team where they didn’t know each others names, now they not only know their names, but they might also know their favourite sport, film or food. Now we know and trust each other more, blame culture has largely been replaced by ‘fessing up, gentle ribbing on Slack, and a Broke the Build trophy. All colleagues in Manila and Cambridge alike are seen and heard. Staff retention is high. People have worked together for a long time and know and trust each other. The team is dedicated and committed. Slack & Bonusly Can’t talk about collaboration without mentioning slack, and we are also trialling Bonusly across the programme as a reward and recognition programme – one of the behaviours it is trying to encourage is collaboration. Collaboration has been built into personal goals across the entire business, and luckily for us agile matches perfectly! What is next? A workshop with some of the members of the business who felt left behind to work out how to extend the reach of our collaboration. Better collaboration across teams – more slack channels to handle shared dependencies etc.
- VICKY User Story Workshop MVP - a Minimum Viable Product. Highlighted that demand outstrips capacity agreed to work towards a ringfenced set of items of the highest value first. To agree this, the epics at each step of the journey were prioritised, then a horizontal line was drawn to define the minimum. Without this keen focus we would probably still be in development today! VICKY this section: Challenge 1: struggling with MVP, a huge complex product that millions of people were using already. Perhaps talk about what we lost? some people disenfranchised - where we would have said yes before, we were now saying no. Challenge 2: we had previously developed bespoke functionality specific to individual journals. This was to change, in the interest of both the reader and in terms of what we had to build and support - we could create universal customer experiences and reuse code. This meant unpicking some contractural obligations. Challenge 3: balancing the effort on all these features with quality. We used and adapted Jim Highsmith’s Trade-off-matrix so that we had a clear message from the board <insert message here>! Challenge 4: protecting ourselves from noise - We cut ourselves off from the rest of biz- we were left alone to get on with it, but also collaborated
- CLARE – READ IN FULL With MVP we created an expectation, but things change. Jim Highsmith’s Trade Off Matrix was designed to create, communicate and maintain a balance between the three constraints of scope, schedule and cost. This is a reaction against the waterfall fantasy that knowledge work projects deliver the full scope, on time on budget. The columns display the relative importance of each dimension. Each column can have only one check mark. We adapted it slightly, splitting his ‘Cost’ into Quality and Resources. This was proposed by the project leaders and negotiated and agreed by senior stakeholders, giving clear direction about success and tolerance to all. The level of flexibility in each dimension enabled decision makers to follow the correct and agreed course. VICKY - implications 1. Management agreed that the priority was to deliver to a deadline – August / September is when librarians make their purchasing decisions etc. So schedule was fixed. 2. They agreed that scope would be flexible, and that as we approached launch scope would continually review and reprioritise the feature set, that we wouldn’t ‘over-perfect’ functionality to maximise the amount we could deliver, and that we may leave some functionality on the legacy system. 3. Quality, - important – see Product Vision – but we accepted we would launch with some imperfections, and we would launch minimal feature and some tech ical debt, 4. Lastly resource – it was agreed that the project could exceed the budget. That overtime may be needed to be paid. That travel between UK & Philippines increases efficiency and costs would therefore increase, and that resource may need to be pulled in from BAU.
- CLARE Having an MVP and a group of Product Owners enabled Prioritisation. This is relatively easy in single teams, BUT a huge challenge for us has been prioritisation across component teams, and managing dependencies Started with back end team developing APIs as they anticipated would be needed in advance of the front end development starting mostly (and therefore the detailed requirements) because we needed a critical mass of functionality. They were able to do this by applying a general knowledge of overall requirements based on the previous system. When the front end team started developing the features, and consuming the APIs, needless to say they found they weren’t providing exactly the business logic or data that was needed. Problems: So code developed before we tried joining up didn’t match up, then as new requirements came on board, the back end team became a bottleneck as they had to rework to fit. (I am told that some orgs e.g. facebook may insist on the development being adjusted to the API but that was the approach we took) Also Front end priorities were not aligned with the back end, so there was a lot of delay and blocked tickets. Plus back end team were in Manila, front end in Cambridge. Solution: early attempts at dependency mapping – a wall where all POs were encouraged to share & synchronise their plans. POs met weekly(?) to share their stories, to ensure all requirements joined up, and reduce waste and rework. This didn’t take off, so Vicky was asked to taken on a cross team view. On next slide…
- CLARE We then started programme “Big Planning” with the Solution Architects, some developers, Product Owners and Scrum Masters meeting every month to plan the month ahead. Each colour is a different team. Most dependencies are sequenced and most stories are aligned. We are also gradually introducing more cross-functional teams: some admin developers are now embedded in the front end team, so that when a front end feature is developed, the back office functionality to support happens with it – a vertical slice. The membership team is no similarly moving into the front end Product Owners now straddle both admin and frontend This combination works well – we will continue to improve the dependency mapping and do more around cross-functional feature teams. We live with the dependencies and there is not much push to move beyond this. Pragmatism, choose improvements. Part of the long journey. We are also gradually introducing more cross-functional teams: some admin are embedded the front team so that when a feature is developed the back office functionality to support happens with it – a vertical slice. The membership team is no similarly moving the front end Product Owners
- CLARE Seems obvious but we also did the basics….some other practices that significantly improved our focus
- CLARE The third big change was the concept of Continuous Improvement = this was a strong guiding light. We started with one of the teams being agile, and evolved from there. Challenge – each team unique & different level of maturity, or strengths and weaknesses. Wanting their own way. Keep agile manifesto in mind – if we dismiss too much ‘good practice’ we lose agility – scrumbut. Keep hold of principles, no dogmatism, with perhaps one exception…Continuous Delivery and Engineering What they don’t teach you in scrum school – the rigorous engineering approach & practices required to ensure that software can be released at any time. One of the biggest challenges for me, as I don’t have an engineering background. I built a maturity model as a conversation starter. It is based on InfoQ and DZone articles I’d read. I would sit with each team every 3-6 months and use the model talk through the practices they needed to consider, in a timely and proven order. If we couldn’t work it out, I would connect them to people who could help. The team would receive a new award each time they had progressed a level. The physical award provides: a vision of what we are trying to achieve a roadmap for the next steps recognition for a team’s achievements a signpost to members of other teams who may need your help or advice This work, combined with getting a pipeline has resulted in automation and delegation of a lot of the push to live process Challenges: adoption of some engineering practices has been slow as we didn’t have the skills and had to learn as we went – unit testing, automated testing, getting a pipeline What is next? More consistent use of engineering practices & clearer expectations. More unit testing.
- CLARE 3. Working with dispersed teams DROP THIS ONE IF WE ARE RUNNING LATE – JUST REFER TO QUOTE Time – golden time extension – lack of shared hours. No more than 2 time zones Tech comms - a lot of work on improving our comms over time. Before it was all phone calls only, no visibility (and little engagement, using only representatives), moved to Skype, Odro (gradual degradation) , added booster mics to ensure everyone can be heard, and wide angle webcameras to ensure everyone could be seen (no hiding!) and now we have a Surface Hub which takes care of much of that! Could do with one for every team in both locations! Email has been replaced by persistent chat in Slack – but can be picked up asynchronously. INSERT PHOTO OF SURFCE HUB STAND UP
- CLARE 4. A learning culture People wouldn’t take time to make improvements, perceived to be too busy to make the time. This has gradually changed. Retrospectives (and occasional cross programme retrospectives) Agile CoP in Cambridge and Manila: Lean Coffee (challenge getting people other than SMs interested – AUDIENCE does anyone else have this problem? ), Lunch and Learns, brown bag sessions, Agile Practioner Guild., We are always changing how we work, trying new things. Skills gap is real. Before we expected juniors to just be able do it, and complained when they didn’t. Now we use some basic pair programming, and team agreements, policies and standards to clarify our expectations and get juniors up to speed. What’s next? More T-shaped people, using skills matrixes (learned from RedGate at ACCONF– show here) to identify gaps and learning opportunities.
- VICKY Shortlisted for three awards Next slide – wait for video to load, hit return on laptop
- VICKY
- https://www.youtube.com/watch?v=A_upW2fb5hc&list=PLTK8KRW19hUVucVRHbIx73oLKUro8HXt0 VICKY
- VICKY We have the concept of “Good enough” – we have more capacity to deliver new features & innovate Responsible product ownership means that an appropriate amount of effort is given to developing the right features – no more perfectionism, gold plating, or delivering pet projects that our customers didn’t need. The business acknowledges that the Customer Knows best – and we have satisfied customers, feeding back comments such as “Core is groundbreaking” Vicky more please CLARE PHOTO OF SHOWCASE to pink fluffy lside Instead of attending a 3 hr long fortnighty meeting going through lists of things to be done, the business now attends a fortnightly showcase to be updated on all the changes we have made! This includes customer services, sales and marketing and editorial, and it’s recorded for anyone who is interested. The teams still spend at least 3 hours a fortnight in meetings, but they are talking about immediate work – the conversations add directly to the value. VICKY MVP – there is still frustration that we can’t deliver it all, but knowing that we are delivering the highest value stuff, and that someone is accountable for that, makes the pressure to deliver real rather than confected, and therefore more compelling VICKY I RAN OUT OF TIME HERE, THIS NEEDS MORE WORK THAN PREVIOUS SLIDES Insteadof separate silos All part of the team – virtual teams aiming to feel as though they are in the same room. All are included not just a rep. Have been working towards cross-functional teams, we’ve experimented with: - scrum of scrum style stand-ups where reps from each team share their progress, difficulties, etc. (didn’t work out) Bringing in a back end team member to front end team to deliver vertical slices of functionality, but that has been difficult (why?) – feature specific channels on Slack to attend to cross-team issues (working well). Swapping of people in and out of QA team. Plannign roadmap pictures now – Vicky to talk through
- CLARE You can see we have made significant performance and responsiveness improvements Lead time – an urgent and prioritised requirement can go from the point of raising the request to live in production in 2 days to 2 weeks (depending on the team). BUT we do struggle with a large backlog – lots of great ideas - and so some of our less urgent or valuable work waits a long time Cycle time – a one line code change can take 36hrs to 1 week, (typically 48 hours) depending on when it falls in the week. The 36 hours is dictated by our dispersed QA team working hours – it must be released during their working hours. BUT Core has CMS so a one line text change is immediate in most places. Also, although we are doing dev ops, it is still a limited team that can push the button, but we are moving away from that soon as we have tools under the bonnet. Release frequency – why does Ian say deployment multiple times per week and Paul weekly? Deployment duration – still needs to be handed over to QA in Manila Average # deployments per week for Core 11.5 (28 is highest) Ian says “I don’t have to think about deployments anymore, whereas before it was all I thought about! True, my team may still push the button, but we’re moving away from that soon, now that we have a god set of tools under the bonnet.”
- VICKY And so our journey into the exciting digital future begins…
- If no questions, ask them about themselves… Where are they on their journeys? Are they working in very well-established organisations? How did they go about introducing agile? What worked for them, what didn't? Did they face similar resistance? How did they overcome it? etc
- OLD We are the oldest publishing company in the world We were amongst the first to put our journals online – and that website didn’t change until recently. Notably, only 1/20th of our lifetime has been in digital In the relatively short time period of the last two decades we have introduced our first electronic books on CD-ROM, our first website, ecommerce, online journals and books, print on demand, e-books, a learning management system, and responsive website, to name a few changes.