Agile Development at Sky Network Services John Sweet Development Manager - SNS

1. Agile Development at Sky Network Services John Sweet Development Manager - SNS

2. Agile Development at SNS • I will cover • A brief overview of Agile development • The development and test methodology we use • The team make up • A description of the application • How we introduced Agile • How things work today

3. The Netstream Product • In late 2005 Sky took over Easynet and renamed it Sky Network Services (SNS) • A Broadband Provisioning System existed (to manage new and existing customers) but it was old technology, not scalable, not linked to other Sky systems • The decision was taken to rewrite it from scratch using Agile methodologies • The work started in January 2006 with the first version going live in July 2006. • We now have over 2 million broadband customers (increasing by about 20,000 per week), over 1.6 million Sky Talk customers. • Later this year we will deliver Iteration 100 (our 50th full release into the live environment in a little under 4 years).

4. The New Provisioning System • Broadband (and Telephony) Provisioning System • Written in Java with an Oracle database • Interfaces with BT and other Sky systems via XML messaging • Interfaces to exchange hardware via SNMP • Mostly middleware – very few web screens (so we don’t have to worry about web front end testing) • Load on the system is relatively light (in today’s terms) so throughput and performance not really an issue • Supports Sky sales channels so is business critical • We use lots of open-source technologies (Spring, Hibernate, ActiveMQ, Wicket)

5. Team Shape • 32 software developers spread across 5 teams • 12 testers, 2 allocated to each team plus 2 working on the ‘end to end’ test platform • 8 business analysts – they float between the teams being focused on projects – they take the customer role • 6 database analysts / designers • Iteration manager or Scrum Master • IT Director – who is 100% committed to all aspects of Agile development – this is key to the success • Team of project managers who manage different project priorities determining (with the BAs) which stories go into which iterations • Various other managers including me

6. Our Agile Process • We follow the Agile project management and co-ordination process SCRUM. • And the development process XP (Extreme Programming)

7. Scrum Project Management • Scrum is a process skeleton that includes a set of practices and predefined roles. • Main roles • ScrumMaster (Iteration Manager) - maintains / tracks progress • Product Owner - represents stakeholders (we use BAs) • Delivery Team which includes the developers and testers • Practises • During each sprint (10 day iteration for us) the team creates an increment of shippable (usable) software • The requirements delivered in a sprint come from the product backlog - prioritized set of requirements of work to be done. • Items in the sprint are determined during the sprint planning meeting where the Product Owner selects the highest priority items from the product backlog. The team then determines how much of this they can commit to complete during the next sprint. • Daily stand up meetings to review progress and plan work for the day; also used to resolve blockers to progress.

8. Extreme Programming • Extreme Programming has 12 practices, grouped into four areas, • derived from the best practices of software engineering: • Fine scale feedback • Pair programming • Planning game • Test driven development • Whole team involvement • Continuous process • Continuous integration (automated testing) • Refactoring or design improvement • Small releases (or iterations – ours are every 2 weeks) • Shared understanding • Coding standards • Collective code ownership • Simple design • System metaphor • Programmer (and tester) welfare • Sustainable pace

9. Project Planning • Projects are broken down well ahead of delivery. • Requirements are then captured as ‘stories’ – each story is a piece of work for one or more teams. Stories are held in the (Confluence) Jira tool • Stories are then planed into the next Sprint (10 day iteration) a week in advance of it starting • Cards are printed off for each story for each team to put on their story boards • Where more detailed requirements need to be documented, this is held on our Wiki • We try to be as flexible as possible with stories ahead of the iteration starting • BUT as inflexible as possible once it starts – otherwise delivery team effort will be wasted

10. Story Delivery • On the first day of the iteration (Sprint), the planning meeting takes place – big get together for BAs, developers and testers • Story cards are put up on the board, blue stickers are the first stage (indicates testers and BAs have agreed the automated tests that need to be written to prove the story has been correctly implemented) • Daily stand-up at the start of the day (shown) to review progress and plan work for the current day

11. Testing – The Important Bit (to this audience) • Virtually all testing is automated. This is key to our Agile development. The testers in the department spend most of their time writing automated tests – NOT doing manual testing. • 3 layers of testing • Class level tests – written in an automated framework called Junit – these are written by developers before they write the code as part of Test Driven Development • Module Level Tests – these are written by the testers. We use a tool called Concordion (similar to the Fit or Finesse tools) – developers write Java frameworks then testers write XML test scripts • End to End tests – again written by testers, the framework we created ourselves (using Ruby on Rails). We call this system Buffy We ‘stub out’ selectively external systems (like BT) • All tests are written, run and required to pass before the iteration completes.

12. Automated Tests Build Monitors • As soon as code changes are checked into Subversion, the Team City tool builds them and runs automated tests. Build monitors give the development team immediate visibility of whether code changes they have made have ‘broken’ the automated tests. • Quick – Junit class level tests written by developers • Full – Concordian module level tests written by testers • Buffy – End to End test suite – again written by testers

13. Halo Story Board The basic layout (of swim lanes from left to right) for status of stories is fixed. But the self-organising teams have the freedom to record whatever they like everywhere else • Left – cards ready to play • Centre – stories being developed • Right – completed stories (blue / red / green stickers = test status)

14. Typical Team Story Board • Penfold Team Story board – Note (end of iteration) • Top left velocity tracking for the iteration (estimate, actual and running total) • Towards right – completed stories (with stickers) • Bottom left – bugs /to fix / other tasks to be run when we have time

15. Agile – How we got started • Key Facilitators • IT Director who was 100% committed to the benefits of Agile delivery • A completely new application so no legacy code (without automated tests) to deal with • Budgets were generous so we could bring in experienced Agile coaches (like Thoughtworks consultants) to help us get the processes started and embedded • A small existing team that went through a large expansion meant we could bring in lots of people who believed in Agile who trained up the old team • The nature of the application (with clear interfaces and known requirements) suited Agile development • Used retrospectives to learn and improve as we went along

16. Challenges • Automated testing means testers need different skills to traditional manual testers • Automated test set is constantly getting larger so takes longer to run • 3 layers of testing – we need to make sure we don’t test everything 3 times • Quality is determined by the team so we need very good, highly motivate people • Recruiting new people is hard because there are not many people with experience in the market – we do lots of training / coaching • We are giving people very saleable skills in the marketplace so retention is something we have to be very careful of • Process is lean (a good thing) but produces very few metrics so productivity gains are hard to measure • Development focused on iterations is very effective BUT it takes a short term view – producing a coherent long term design can be difficult

17. Benefits • Credibility – When we tell the business what we can do (and what we can’t do) they believe us • We are in control of our own destiny – if there is too much to do scope does get pushed out (or we get more resource) • We have a high level of success – projects are delivered on time with good quality • We do have bugs but they are few and mostly unusual edge cases. Our quality is generally very high (without lots of formal reviews) • People love working for us - sustainable velocity, self organisation, latest development practises, saleable skills – the team are highly motivated • We are seen as a beacon of success across Sky • We are lean – very little superfluous documentation

18. Agile Development at SNS • I have covered • A brief overview of Agile development • Our adaption / adoption of Agile • The team make up and the application • Where we are today • I am happy to take questions in the break • I am also happy to arrange for people to come into our office In Brick Lane to show them first hand how things work at SNS

19. Any Questions?