Why don't small companies do big a agile?


Published on

Why don't small companies do big-A-Agile? Are they agile by default? Is Agile just a way for a large company to behave more like a small one? In this retrospective on agile adoption in companies large and small we'll look at what drives adoption, how effective it is at meeting those goals and whether software craftsmanship could teach us more.

Published in: Technology
1 Comment
  • I'd love to hear the talk behind those slides =)
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Java developer Agile enthusiast Aspiring software craftsman Co-founder of LSCC Twitter Why don't small companies do Agile?
  • Start with some definitions Tried doing by numbers About names not roles ” We need Mike to help with this” ” That's a job for Rachel” In large co ” We need QA to help with this” ” That's a job for the operations team” Not to say ppl don’t know each other Identifying by role/team creates short hand – but creates barrier
  • We mean agility Responsiveness; ability to react Bottom up – enthusiastic developers introduce specific practices
  • Agile goes mainstream Big-A-Agile is how we try to get there
  • Take away the theatre and buzzwords – agility is pretty simple Iterate!
  • XP practices fit this perfectly Scrum & kanban provide structure on top – forecasting, planning & process improvement
  • BA vs talking direct to customer Requirements review; architecture standards committee; design sign-off Not been in business long Large business, older, more time to build legacy Interesting metric: LOC/developer 50k 10ppl = 5k/dev 1m 20ppl = 50k/dev Large companies, more code & more code per-developer More to remember Harder to change Software factory
  • With less inventory, even starting on wrong foot easier to retro-fit tests Dev owns junit tests; BA owns acceptance tests; who owns browser tests? QA or dev? What if they're written in junit?
  • Small company trying to find product market fit – can’t wait
  • So small companies naturally do something approximately agile; what stops a large company replicating that?
  • Byzantine process – dedicated job to navigate Failure of an alternative, nervous management return to process safety net “ We’re doing agile, but...” Requirements review, design sign off This isn’t “scrum, but” – its “waterfall, but we’re pretending its agile”
  • Separate QA, build, operations team More people, more meetings, more waste
  • Everybody ”does their job”, instead of delighting the customer ” I fixed the bug, it's up to QA to test it” ” I raised the defect, I'm waiting for dev to fix it” ” The build's ready, operations need to deploy it” ” It's the maintenance team's job to fix bugs” Thrashing - reviewing possibilities / changing direction
  • Development is documenting requirements Start from vague ideas; most precise form is code Project idea has a lot of appeal – but software is weird stuff People feel threatened by agile
  • So why do large companies do big A Agile... Or the stupid...
  • Coming from waterfall background, or half arsed agile
  • What would a diabolical agile roll out look like? How would Dilbert's PHB do it?
  • Project mindset Have team size, fixed scope, fixed date Backlog full of mandatory stories Extra credit: new to company
  • Alpha geek & passive-aggressive cynic Solve all design problems – can't estimate without understand what we're building Everything is a 5 anyway Might feel like planning theatre, but its important to be able to hold developers accountable for their commitment
  • Sprint end – stories not done carry over Process set in stone, can't change it But of course, this isn't agile – it's a checklist of behaviours
  • Now agile is mainstream First line of the agile manifesto Ironically...
  • If big-A-agile isn’t the answer for large companies, perhaps software craftsmanship provides a better view?
  • Software craftsmanship typically focuses on the individual developer How can I improve? How can I learn? How can I mentor others? I’d like to go off in a slightly different direction – if I built a team of craftsmen, what would that look like
  • Responsible for, and capable of , delivering a working increment More dependencies, more project management Developers want to understand the business Let them work with the customer, not for the customer
  • Bob Martin talks about 1 master, 3 journeymen, 9 apprentices Fred Brooks “If a 200 man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back programming”
  • If team responsible for customer to production; all process is internal to team Conforming to standard should be choice of team – because it’s beneficial to the team Some mandatory – rest owned by team
  • Most developers need to work harder on improving quality; very few over-engineer Rush design, multiple code rewrites Skip unit testing, bugs found late – expensive to fix. Not my fault – unlucky Bugs thrive in crap code; debugging crap code takes time -> just fix the code! Scrum/kanban etc give ways of tracking velocity/cycle time to make projections based on past experience If schedule is slipping, cut features not corners
  • So how does craftsmanship help?
  • Developers understand the business; customer trusts the development team -> what to build next. Small, autonomous team; with right experience; producing clean code -> implement smallest thing One team (devops); minimal, self-improving process; working in partnerhsip with the customer -> get feedback quickly On top of the XP practices, craftsmanship is about the relationships, the team structure and a focus on quality
  • XP is about the day-to-day practices What developers do
  • Scrum is about the iteration-by-iteration practices What project managers do
  • Software craftsmanship is about developers “raising the bar” But it’s also about building the right team and genuinely empowering them to craft great software This is in management ’s domain Craftsmanship has these four key goals to enable agile delivery: autonomy, experience, process & quality – let me summarise my thoughts about this into what I think the software craftsmanship manifesto should have said
  • We don’t want dependencies, scheduling and project management – we want autonomy We don’t want armies of untrained developers – we want to hire great developers with a balance of experience and help them all progress We don’t want long process definition documents – we want permission to use the right process for the job Finally, we have to stop writing crap thinking its quicker. If we do the job right, speed will come naturally.
  • Why don't small companies do big a agile?

    1. 1. Why don't small companies do Agile? <ul>David Green </ul><ul>@activelylazy </ul><ul>londonswcraft.com </ul>
    2. 2. Small Company <ul><li>Small company </li><ul><li>” Everyone knows everyone”
    3. 3. People identified by name </li></ul><li>Large company </li><ul><li>People identified by role/team </li></ul></ul>
    4. 4. Little a agile <ul><li>Something you are </li><ul><li>Ability to respond quickly </li></ul><li>Some teams are naturally agile </li><ul><li>Find their own process
    5. 5. Bottom up agile </li></ul></ul>
    6. 6. Big A Agile <ul><li>Something you do
    7. 7. Management imposed – top down agile
    8. 8. By introducing specific process </li><ul><li>I.e Scrum </li></ul><li>Goal is to be more agile </li><ul><li>to increase agility </li></ul></ul>
    9. 9. Agility <ul>Responding quickly to a change 1. Determine next required change 2. Implement small product increment 3. Get feedback from customer </ul>
    10. 10. Agility <ul>Responding quickly to a change 1. Determine next required change <ul>On-site customer, prioritised backlog </ul>2. Implement small product increment <ul>User stories, short iterations, TDD </ul>3. Get feedback from customer <ul>CI, small releases, continuous deployment </ul></ul>
    11. 11. What makes a small company little a agile?
    12. 12. Small Company has... <ul><li>Less process / bureaucracy </li><ul><li>Quicker to describe required change
    13. 13. Fewer signoffs before implementing change </li></ul><li>Less inventory </li><ul><li>Less code to change
    14. 14. Less likely to have legacy code </li></ul><li>One team mentality </li></ul>
    15. 15. Small Company does... <ul><li>Unit/acceptance testing </li><ul><li>Easier to retrofit tests
    16. 16. No arguments over ownership </li></ul><li>Continuous integration </li><ul><li>Excellent free CI tools
    17. 17. If any test coverage, devs likely to setup unasked </li></ul></ul>
    18. 18. Small Company does... <ul><li>Shared ownership </li><ul><li>Whole team own whole codebase
    19. 19. One team mentality </li></ul><li>Small releases </li><ul><li>Can't wait months/years for new product
    20. 20. Need to recognise revenue
    21. 21. Demoable product to drive sales
    22. 22. Learn & iterate </li></ul></ul>
    23. 23. What stops a company being agile?
    24. 24. Constraints <ul><li>Process </li><ul><li>Response to each mistake is more process
    25. 25. Accumulate over time
    26. 26. Difficult to unwind </li><ul><li>“ That’s the way things are done around here”
    27. 27. Any alternative must work first time </li></ul><li>Checklists, sign-offs, reviews
    28. 28. Explicitly waterfall process </li></ul></ul>
    29. 29. Constraints <ul><li>Functional silos </li><ul><li>Economies of scale / simplify management
    30. 30. Releasing an increment involves multiple teams
    31. 31. The result? </li><ul><li>Resource contention </li></ul><li>The response? </li><ul><li>Scheduling, priorities, reviews </li></ul><li>Needs sufficient bandwidth & reliable SLA </li></ul></ul>
    32. 32. Constraints <ul><li>Lack of ownership </li><ul><li>It's always somebody else's problem
    33. 33. Lack of care – someone else can clean it up </li></ul><li>Competing demands </li><ul><li>Multiple customers -> multiple views of priority
    34. 34. Different priorities: new features, support, technical
    35. 35. Team ends up ”thrashing” </li></ul></ul>
    36. 36. Constraints <ul><li>Lack of flexibility </li><ul><li>” Fixed scope”, fixed deadline
    37. 37. Project mentality </li></ul><li>Command and control </li><ul><li>Agile removes the illusion of control </li></ul><li>Politics </li></ul>
    38. 38. What drives Agile Adoption? <ul><li>Desire to... </li><ul><li>Decrease time to market
    39. 39. Increase predictability
    40. 40. Increase productivity
    41. 41. Build the right product </li></ul><li>Or the stupid, because I... </li><ul><li>Heard about it from an analyst / at a conference </li></ul></ul>
    42. 42. What drives Agile Adoption? <ul><li>If small companies are more naturally agile:
    43. 43. ” A large company adopts agile to behave
    44. 44. more like a small company”
    45. 45. A company only needs formal Agile Adoption if it isn't naturally agile </li></ul>
    46. 46. <ul>We have heard about new ways of developing software by paying consultants and reading Gartner reports. Through this we have been told to value: Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact Working software over comprehensive documentation as long as that software is comprehensively documented Customer collaboration over contract negotiation within the boundaries of strict contracts, of course, and subject to rigorous change control Responding to change over following a plan provided a detailed plan is in place to respond to the change, and it is followed precisely That is, while the items on the left sound nice in theory, we’re an enterprise company, and there’s no way we’re letting go of the items on the right. halfarsedagilemanifesto.org </ul>
    47. 47. What does “Doing Agile” look like?
    48. 48. Agile Roll Out <ul><li>Pick project
    49. 49. Write requirements as User Stories </li><ul><li>Create “project backlog”
    50. 50. Prioritise </li></ul><li>Form team </li><ul><li>No history to base judgements on
    51. 51. No story point standard </li></ul></ul>
    52. 52. Agile Roll Out <ul><li>Run user story workshops </li><ul><li>Team takes time to form
    53. 53. Let team solve design problems up front
    54. 54. By the 3 rd day, everyone has lost interest </li></ul><li>Run first sprint planning session </li><ul><li>Team commit to first sprint scope
    55. 55. Best if expected velocity “reverse engineered”
    56. 56. “ Planning theatre” </li></ul></ul>
    57. 57. Agile Roll Out <ul><li>Nominate a Scrum Master </li><ul><li>Or “Project Manager” as they used to be called </li></ul><li>Have daily stand ups </li><ul><li>What I did yesterday... </li></ul><li>Update burn down chart daily </li><ul><li>And challenge the team when they're behind </li></ul></ul>
    58. 58. Agile Roll Out <ul><li>Sprint retrospective </li><ul><li>But don't follow up on actions </li></ul><li>Ship working software </li><ul><li>But not till the end of the last sprint, obviously </li></ul><li>Congratulate everyone on a successful agile project </li></ul>
    59. 59. Checklist Agile <ul><li>Now a checklist of processes to implement
    60. 60. Agile manifesto: </li><ul><li>“ Individuals and interactions over
    61. 61. processes and tools” </li></ul><li>Ironically – the success of process over people </li></ul>
    62. 62. <ul><li>“ Developers started the Agile movement to get closer to customers not project managers”
    63. 63. -- Bob Martin </li></ul>
    64. 64. Software Craftsmanship <ul><li>All about the people </li><ul><li>If your business makes money from software, the people building that software are the most important in your business </li></ul><li>Professionalism in programming </li><ul><li>Taking responsibility for our craft
    65. 65. Taking responsibility for our careers </li></ul><li>A culture for learning and improving </li></ul>
    66. 66. Team of Craftsmen
    67. 67. Team of Craftsmen <ul>What would a team of craftsmen look like? <ul><li>Autonomous
    68. 68. Balance of experience
    69. 69. “ Just enough” process
    70. 70. Producing high quality product </li></ul></ul>
    71. 71. Autonomy <ul><li>Small team (7 +/- 2)
    72. 72. Deliver an increment of software independently
    73. 73. Minimize number of dependencies
    74. 74. Productive partnership with customer </li></ul>
    75. 75. Experience <ul><li>“ Correct” balance of experience
    76. 76. Continuous learning
    77. 77. Best developers writing code, not managing
    78. 78. More developers ≠ faster
    79. 79. Avoid “dead sea effect” </li></ul>
    80. 80. Process <ul><li>Rigid process is a constraint
    81. 81. Process should be internal to team
    82. 82. Standardisation is good – but hard! </li><ul><li>Limits team’s flexibility in face of change </li></ul><li>Some mandatory process inevitable </li><ul><li>E.g. legal compliance </li></ul></ul>
    83. 83. Quality <ul><li>“ The only way to go fast, is to go well”
    84. 84. -- Bob Martin
    85. 85. Rushing will make you go slower </li><ul><li>Corners cut this morning will cost you this afternoon </li></ul><li>We cannot successfully trade quality for time </li><ul><li>Write clean code first
    86. 86. Schedule implied
    87. 87. Cut features not corners </li></ul></ul>
    88. 88. Agility <ul>Responding quickly to a change 1. Determine next required change 2. Implement small product increment 3. Get feedback from customer </ul>
    89. 89. Agility <ul>Responding quickly to a change 1. Determine next required change <ul>Productive partnership, trust </ul>2. Implement small product increment <ul>Autonomy, experience, quality, minimal process </ul>3. Get feedback from customer <ul>One team, fast process, partnership with customer </ul></ul>
    90. 90. Three Layers <ul>XP </ul><ul>Scrum </ul><ul>Craftsmanship </ul><ul><li>Pair programming
    91. 91. TDD / ATDD / BDD
    92. 92. Continuous Integration
    93. 93. Small releases
    94. 94. Coding standards
    95. 95. Collective ownership </li></ul>
    96. 96. Three Layers <ul>XP </ul><ul>Craftsmanship </ul><ul><li>Prioritised product backlog
    97. 97. Product owner
    98. 98. Daily scrum
    99. 99. Sprint planning
    100. 100. Sprint review
    101. 101. Sprint retrospective
    102. 102. Information radiator </li></ul><ul>Scrum </ul>
    103. 103. Three Layers <ul>XP </ul><ul>Scrum </ul><ul>Craftsmanship </ul><ul><li>Autonomous </li></ul><ul><li>Balance of experience </li></ul><ul><li>Just enough process </li></ul><ul><li>High quality product </li></ul>
    104. 104. Craftsmanship in Software <ul><li>Autonomy over shared responsibility
    105. 105. Better developers over more developers
    106. 106. Permission over process
    107. 107. Quality over crap </li></ul>
    108. 108. Questions? @activelylazy londonswcraft.com