Agile at Newsweaver: Moving to Scrum
•Download as PPTX, PDF•
1 like•376 views
Agile is about continuous improvement, not only for the product we are building but for own process as well. In this talk, Pierre will go through the evolution of the processes used over the last few years at Newsweaver (https://www.newsweaver.com/email-overview), from a large iteration based development approach, to Scrum and more recently Kanban, DevOps and Continuous Delivery. Talk given at Agile Cork on March 15th 2016
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (12)
Similar to Agile at Newsweaver: Moving to Scrum
Similar to Agile at Newsweaver: Moving to Scrum (20)
More from Pierre Vincent
More from Pierre Vincent (10)
Recently uploaded
Recently uploaded (20)
Agile at Newsweaver: Moving to Scrum
- 1. Agile at Newsweaver Agile Cork - March 15th 2016 Twitter @PierreVincent / @NewsweaverTech Tech Blog techblog.newsweaver.com
- 3. Iterative Development In theory... In practice...
- 6. Backlog Grooming Sprint Planning Release Planning Sprint Backlog Deliverable DevRetrospectives Dev Servers Staging Servers PROD Product Backlog Daily Stand-ups Scrum Team
- 7. Benefits • Increased team focus • Less disruptive releases • Shorter feedback loop
- 8. Learnings • Be nice to your backlog • Work with Story Points • Keep an eye on bug count
- 12. Focus on Stories Commit to value, not deadlines • Demonstrable value • Small (< 2 weeks) • Limit “Work in progress”
- 13. Minimise Risk • Automate everything • Testing and Quality • Only deploy 1 change at once
- 14. DevOps You build it, you run it • Reduce handovers • Team is responsible for its context in Production
- 15. Team Structures
- 16. Cross-functional • Product Manager • Developers • UX • QA • ~ 6-8 members
- 17. Ownership • Each team owns separate Bounded Contexts • Isolate decisions
- 18. Scaling up • Daily “scrum of scrums” • Sharing knowledge • Keep Teams aligned
- 19. Some advice...
- 20. Questions? Twitter @PierreVincent / @NewsweaverTech Tech Blog techblog.newsweaver.com *We’re hiring!
Editor's Notes
- Show of hands dev? qa? managers? students? who does currently scrum? kanban? who has no idea?
- Internal Communication solution for large companies - Communicate / Measure / Adapt Help better employee engagement = better productivity Dev at Newsweaver Currently 3 teams (and growing) - only had 1 team 2 years ago 1 team on Scrum, 2 others on Kanban/CD
- Iterative Process for around 5 years problem was: the bricks were way bigger than this Issues: - QA was hard - big bang release = scary (for everybody - support, dev, sysadmins, and customers :) ) - firefighting for weeks after releases (more downtime, more pressure, more annoyed customers) - feature validation too late - building the wrong thing for too long - unknown release date - lack of focus, urgency, under utilisation of resources - lack of purpose... what do we do next? without clear product vision - easy to push deadlines
- We were considering ourselves Agile enough But pretty much only Agile by the nam Started looking into Scrum training CSM in 2012, realised that we weren’t really Agile at all Last release before moving to Scrum was almost 6 months long (700 Jira issues for 5 developers!)
- Probably very familiar to many of you Stories are prioritised in Product Backlog (through release planning and backlog grooming) Sprint planning every 4 weeks, creating Sprint Backlog Development for 4 weeks, with daily stand-up in the Team Current state of the sprint is deployed on Dev servers daily Sprint yields a deliverable, moved to Staging for final QA (3-4 days) Signed-off release candidate is deployed to Prod Sprint ends with Retrospective to look back at the process Some changes over time: Moved to 2 weeks sprints but still deploying every 4 weeks to Prod (will explain later)
- Increase in focus For Dev (we know what we are working on) For Product (priorities + smaller window = have to pick what matters most) On a team level: better communication with stand-ups On a business level: less negative impact of releases (less changes = less bugs, less disruption) more positive impact (faster feedback loop = build more relevant product) For ops: releasing more often = more work hence not releasing every 2 weeks
- Keep your backlog prioritised and clear (backlog grooming) = avoid wasting time in sprint planning Story points rather than time estimates people work at different pace Vote during sprint planning for each story (planning poker) important is to have an accurate velocity measurement Review story points afterwards (before backlog grooming) Beware of half-baked features moving priorities = leaving some features unfinished keep an eye on bug count spend time cleaning up (try to have a clean slate when starting sprint)
- Scrum worked fine for a while but noticed decreased velocity Reason: system too large and hard to change
- Loosely coupled service oriented architecture with bounded contexts (Adrian Cockroft from Netflix) Small autonomous services that work together (Sam Newman) Small = responsible for 1 single thing Loosely coupled = clearly defined interface, responsible for own data Isolated failures = 1 service failure doesn’t bring the whole system down Brings great agility: now we can deploy things independently (NEXT)
- Changes are released when ready Not committing to a deadline Not waiting either (no release train) Changes don’t wait around Deploy microservice as soon as the changes are ready Result: the story is delivered as soon as it’s finished Scrum makes less sense in CD because things get released when ready, so taking more of a Kanban approach Start finishing and stop starting Scrum is focused on time, here we’re focusing on stories and their value (NEXT)
- Focus on delivering stories a story must mean added value Minimise the risk of a story: Lean approach as small as possible with maximum value make decisions at the last responsible moment minimise waste
- Automate everything Build pipeline (continuous integration) Acceptance testing (for validation and regression) Deployment pipeline (so that devs deploy and not admins anymore) > Deploys are complex, I can explain more later if time, otherwise ask me Testing and Quality Build things fast, must build things right Very strong on TDD, >90% coverage (including on JS) Strict Sonar quality gates Minimise risks One change at once Golden rule, avoid coupling Detect issues early, isolate failure
- DevOps culture: Dev no longer stop at the commit From story inception to running in production Minimise hand-offs Dev responsible for Monitoring their code (ops shouldn’t be woken up by business bugs!) Team responsible for deployment of their stories no longer done by Ops (altho they might be responsible for maintaining the infra/platform that provides this capability) Team is familiar with running environments: Debugging infra Can prop up own environment (e.g. AWS) Understands how things work (no more “no idea about this query, Hibernate generated it”)
- Team = not only developers No separate QA team No design agency All members work towards the same goal All sitting together Minimise hand-offs
- Teams given ownership of separate bounded contexts DDD Bounded Context concept: explain isolate decisions, minimise hand-offs (again) by giving autonomy give teams freedom to solve a business problem (don't give them features to develop, but a general problem to solve) better sense of ownership
- More teams, more bounded contexts: Scaling becomes a concern cohesion of product & features between teams silos of roles (devops) can turn into silos of informations (multi teams) Scrum of scrums team leads + dev manager, cto & ops lead clear view across teams and of overarching dependencies Regular dev department updates: what is the overall goal, keep everybody aware of the direction Tools & Tech tech talks, mentoring (e.g. docker, ansible, …) Internal blogs (and external as well)
- Agile is an organisation thing 1 agile team but rest of org in waterfall = no rewards for the product agility Beware of agile-waterfall - reduce hand-offs, bring people together, cross-functional teams If you’re starting now Start with Scrum: more structure, more guidance Move to Kanban when enough maturity (too much flexibility at first can be a slippery slope) Scrum Master is key - prevent disruption, prevent stories creeping in