450 likes | 462 Views
Learn from a seasoned developer turned manager overseeing 250 professionals, sharing 37 crucial agile development lessons. From empowering developers to handling documentation & collaboration, these insights are valuable for software development success.
E N D
Lessons Learned in Agile Development Jim Smith PDX, Inc.
Disclaimer: • I am not a consultant! (not that there’s anything wrong with that) • I am: • Developer, by trade. • Been in management for the past eleven years. • Oversee development of four complex product lines. • Approximately 250 programmers, QA testers, Software architects and DBA’s.
Context • PDX. . . • The original PDX Agile project. . .
Lesson #1 • Everybody thinks they’re already Agile.
Lesson #2 • Enabling developers to commit has spectacularly good effects: • They own it! • They manage their own overtime! • They drive teammates! • They escalate!
Lesson #3 • Managers get to do good things: • Coach/mentor • Strategic organizational and infrastructure enhancement and fixes (e.g. – switch from proprietary bug tracking system to Jira) • Audit • Get and stay plugged into business • Keep foot soldiers educated • Give morale maintenance the care and feeding it deserves • Talk to each other
Lesson #4 • Write good user stories. • Good user stories are beautiful. • Apply the “no system” litmus test.
Lesson #5 • The industry feels that pre-planning is necessary.
Lesson #6 • TDD: a way of life
Lesson #7 • At all levels, currents push us back toward waterfall: • More docs • More time up front • More time for regression testing • Email, IM and bug record correspondence
Lesson #8 • Even the best and brightest have trouble with collaboration. • It’s a required skill in today’s software development shop.
Lesson #9 • The team will gladly turn in slackers.
Lesson #10 • [Lean] documentation is still good.
Lesson #11 • “Nothing is over! Nothing!” –John Rambo
Lesson #12 • The team must understand: You can’t do everything that falls out of retrospectives.
Lesson #13 • Although not ideal, team members can be scrum masters.
Lesson #14 • You can get executive, managerial and customer buy-in with your first demo and through training on user stories
Lesson #15 • Customers and other stakeholders at demos = bueno!
Lesson #16 • Let the scrum team stay focused; retain a production support team.
Lesson #17 • Get your DBA team to agree to an SLA.
Lesson #18 • Break down those user stories!
Lesson #19 • Keep noisy managers and executives out of kick offs.
Lesson #20 • The stand up is for all.
Lesson #21 • The PO must appreciate the value of paying technical debt. • 20%
Lesson #22 • The PO is not the team owner.
Lesson #23 • People won’t talk? Slamming doors? Putting up walls? = dysfunctional Agile team.
Lesson #24 • Parties and other rewards after demos == bueno!
Lesson #25 • Don’t let a sprint go longer than five weeks.
Lesson #26 • Train your developers to sign off on user stories early.
Lesson #27 • The PO position is a fulltime job, for a member of the business, who can appreciate technical debt.
Lesson #28 • Co-location of sprint team members is good! • At a minimum, members of a given sprint team should live on the same continent (except business analysts and architects)
Lesson #29 • Your development and test environments are production environments. • Enormous waste when they’re down. • Many grumpy people when they’re down; they’re missing deadlines to which they committed!
Lesson #30 • Don’t treat your India folks like warm bodies. . .or they’ll act like warm bodies.
Lesson #31 • Sashimi is a great idea, but not always 100% possible.
Lesson #32 • Velocity steadily increases when your team rosters are constant, and working on the same product(s). • If you frequently change team rosters, then abandon hope that velocity will increase.
Lesson #33 • The product ought to be ready for production after every sprint. • Although not always practical, strive for it with every sprint!
Lesson #34 • The Scrum Master is a strong servant leader.
Lesson #35 • Plaster that product backlog EVERYWHERE! • The whole team needs to know it! • The company brass needs to know it! • Customers need to know it!
Lesson #36 • Developers are professionals – not privates in the army. Treat them as such.
Lesson #37 • “Scrum” is not an acronym.
www.synerzip.com Hemant Elhence hemant@synerzip.com 469.322.0349 84 • 42
Synerzip in a Nutshell • Software product development partner for small/mid-sized technology companies • Exclusive focus on small/mid-sized technology companies, typically venture-backed companies in growth phase • By definition, all Synerzip work is the IP of its respective clients • Deep experience in full SDLC – design, dev, QA/testing, deployment • Dedicated team of high caliber software professionals for each client • Seamlessly extends client’s local team, offering full transparency • Stable teams with very low turn-over • NOT just “staff augmentation”, but provide full mgmt support • Actually reduces risk of development/delivery • Experienced team - uses appropriate level of engineering discipline • Practices Agile development – responsive, yet disciplined • Reduces cost – dual-shore team, 50% cost advantage • Offers long term flexibility – allows (facilitates) taking offshore team captive – aka “BOT” option
Thanks! Call Us for a Free Consultation! Hemant Elhence hemant@synerzip.com 469.322.0349