Making Your Agile Transition and Org Progress Visible


Published on

Slides from my talk at LSSC 11 on making your Agile transition and Organization Progress Visible.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Today I’m going to talk about making your organizational progress and agile transition visible. I’ll go through a medium sized companies journey through an agile transition and show how our coaching team made data across the organization visible, what worked, what didn’t and then show some lessons I learned along the way. - talk about the value of visibility. I’ve always like the phrase ‘nowhere to run, nowhere to hide’ - in traditional orgs, data that flows through organization gets cleaned as it makes it’s way up the chain, the visibility created by adopting agile practices is designed to surface information about what’s really going on. - talk about how visibility, from my experience, is limited to team-level information which isn’t as helpful to managers and executives who need different data visible to make decisions
  • - typical visibility is around team-level or project-level areas - helps the team make decisions - designed to expose what’s really going on to management - talk about how simple is perfect to start with, add more data as you need it coaches see this data and it exposes deeper organizational problems, management see this data and they want to make the team work harder
  • talk about toronto agile open space, person mentioned they have net promotor scores for multiple products - team-level data doesn’t necessarily help with tactical decisions - need to find data to answer a variety of ‘why’ and ‘what’ questions that can help determine the right priorities for teams
  • - talk about how managers/execs are able to make better strategic decisions when they have real data - use Q4 example, seeing that sales was far out-pacing getting clients live gave the ceo/cto better data to decide where to focus more time and money - close with how data must flow up and down these levels to keep the org aligned
  • set some context, paint a picture of the org structure, size etc. talk about overlapping code, how each ‘group’ handled new dev + maintenance
  • - after 3 months into the transition I was talking to the CTO and mentioned that there sure was a whole lotta shit all over the walls, but he still had no idea what was going on. - talk about the relevancy of data for someone at his level - not efficient for him to walk around to every team to see what’s going on across multiple teams/projects mention the Gemba Walk session....if you went to it
  • - hey, we do a lot of patches, what’s up with that? talk about what other data and challenges we discovered
  • talk about the phases: phase 1: get the data - ‘how did this happen on your watch?’ - doom and gloom - deer in the headlights phase 2: do something about the data - don’t want to save the world - personal safety, panic, frustration
  • talk about how the visibility led to a different strategy for product made visibile the bottleneck is getting clients out the door, led to ‘why’ questions
  • Making Your Agile Transition and Org Progress Visible

    1. 1. Making Your Organization Progress and Agile Transition Visible
    2. 2. Operational (Team/Project Level) SPRINT BURNDOWN RELEASE BURNDOWN IMPEDIMENT LOG - Ndepend trial expired - integration environment unstable - running low on sticky notes! TESTING DASHBOARD ☺ order entry form coverage billing module ☹
    3. 3. Tactical (Portfolio Level) Operational (Team/Project Level)
    4. 4. Information flows through the organization to support each level of planning Strategic (Org Goals) Tactical (Portfolio Level) Operational (Team/Project Level)
    5. 5. Group A (3 Teams) Group C (4 Teams) Group B (2 Teams) Supporting Teams (OPS, Internal Infrastructure) - ~100 people in MedCo Engineering - big band Agile transition - team of 3 coaches - cross-functional teams created
    6. 6. what the @#$% is going on?
    7. 7. Yummy!
    8. 8. not started training/kickoff embedded coach on their own agile transition visibility group A group B - purely subjective - reviewed at standup - sparked conversations about how to help teams - helped prioritize types of training Team 1 (kickoff next week) JL Team 2 (training today!) JL Team 1 MS Team 2 MS
    9. 9. agile transition visibility
    10. 11. the release wall Jan Feb Mar Group 1 Group 2 Group 3 Version/ notes Major Release Minor Release Patch Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes 2.5 - notes 2.6 - notes 2.7 - notes Version/ notes Version/ notes 2.7 - notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes Version/ notes 2.5 - notes 2.5.1 - notes 2.7 - notes today
    11. 13. What Other Data Did We Get? <ul><li>average 85% of time spent on failure demand (one group was 99% on failure demand) </li></ul><ul><li>9 months from time a customer call was resolved (via value stream map for most common issues) </li></ul><ul><li>technical debt (10,000 LOC JSP’s, 6000 line methods) </li></ul><ul><li>1.5 weeks per month spent on manual regression covering approx 30 - 50% of the system (time was based on data, % based on thumb in the air) </li></ul><ul><li>0% unit test coverage </li></ul><ul><li>complex branching policies (each team had their own branch) </li></ul>
    12. 14. What Happened Next? <ul><li>Quarterly A3 process for engineering initiatives to address technical debt </li></ul><ul><li>root cause process with 99% failure demand team </li></ul><ul><li>narrower focus for coaching requirements (training, team embedding) </li></ul><ul><li>started thinking about different product strategy </li></ul>
    13. 15. What Was the Outcome? <ul><li>99% failure demand team was reduced to 95% after 3 months </li></ul><ul><li>moved to mainline branching strategy </li></ul><ul><li>implemented automated nightly build process </li></ul><ul><li>accomplished 20% of A3 plan, continued with quarterly improvement process </li></ul>
    14. 16. It Ain’t All Rainbows and Sunshine
    15. 17. Visible at Q4 Set Expectations and Create Personal Safety Show the Value of Making Data Visible Have the Teams Own It Find the Valuable Data
    16. 18. Urgent! V4.0 V3.5 3.5 backlog 4.0 backlog
    17. 20. understanding our “smart number” wasn’t smart enough re-think of organizational strategy company open space to come up with a better plan first step towards breaking down silos Getting Visible Led to:
    18. 23. “ Q4 is a fast growing software company. Over the last 12 months we have seen a significant spike in sales and bringing on new customers. With this increase in sales also came a number of production problems in getting those clients live. It was not clear if we had problems in our process or not enough people. By visualizing all of the data related to sales and implementations we have been able to identify the problem areas more quickly and change our organization strategy and product direction.” - Q4’s CEO, Darrell Heaps
    19. 24. Thank You! Jason Little @jasonlittle [email_address] Exa mples and Other Mat erial : http://www.agilec
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.