Friday, October 20, 2017

Agile Austin Lunch Session - How Microsoft VSTS went from 18 mo Releases to Three Week Sprints

Clementino de Mendonça presented to 20 Agile Austiners on the topic "Agile at Scale SIG - Agile Transformation at Microsoft TFS/VSTS team".

Microsoft uses 3 week sprints with releases to different test environments named  Ring 0 to Ring 6.
Releases every 3 months, could be more frequent, but customers don't want it more frequently.

Microsoft's internal release notes for VS are available at https://www.visualstudio.com/team-services/release-notes/

How did they go from 18 month release cycle to daily?

In the old days it took 3 months of planning to organised details for the next release.  Developers coded in two week sprints, with stand ups.
The lower levels were Agile, but the upper level planning was not.

Before and After Microsoft Transformations:
4-6 month milestones to 3 week sprints
Personal offices to Team rooms
Long planning cycles to Continual Planning and Learning
Feature Branches to everyone in master branch with tags
Secret road map to publicly shared road map on the web
100 page specs to specs in PPT
Private repos to open source publicly available
Deep hierarchy to flat hierarchy

"Culture eats strategy for breakfast", Peter Drucker

Microsoft at one time was cutting edge on Agile (Ken Schwaber studied them for the creation of Scrum), but then lost it.

Microsoft looked at Pink's book "Drive". People want Autonomy, Master, and Purpose.
Youtube video summary here,

Alignment and Autonomy balance.  Too much alignment and the autonomy falters.

MS changed Roles.  In the old days developer testers were considered lower quality.
Used to have Program Management, Dev, and Testing.  Now only PM and Engineering.  Everybody writes tests - no separate testers.

Full list of roles:  UX / User Experience / Program Management / Engineering / Service Delivery.

PM is responsible for What and Why building.  Engineering is responsible for How.

Teams are cross discipline, 10-12 people, self managing, clear goals, lasts for 12-18 months, work in physical team rooms.
The team owns the features in production and own deployment.  So if problems occur, that team fixes the problem.

Instead of doing horizontal layers: teams doing UI other team doing API, others doing business logic.
Now, one team does all of those things in a vertical slice.

Autonomy - let teams choose what they want to work on.  They must train successors.  aka.selfformingteams

800 people working on VS.  Teams stay in contact with each other using "Sprint Mails" detailing what they did, and what they plan to do next sprint.  This is instead of big meetings.


Lightweight Planning: Sprints in 3 weeks, Plan in 3 sprints, Season is 6 months, and Strategy in 12 months.

Strategy / Features / Stories / Tasks.  Strategy comes from top down.

Backlog is taken from UserVoice, community requests and voted on.

Stabilization sprint used to happen.  Devs would push bug fixes to stabilization sprint instead of fixing immediately.

Bug Cap is total number of bugs to have, it's five times number of devs.

Takeways
1. Get good a science, but don't be overly prescriptive.
2. Stop celebrating activity, start celebrating results.
3. Embrace the new normal.  Delivery continuously.
4. You can't cheat shipping.  Putting into production.
5. Build the culture you want ... and you'll get the behavior you're after.





No comments: