Lessons learned in agile development
Sponsored Links
This presentation is the property of its rightful owner.
1 / 45

Lessons Learned in Agile Development PowerPoint PPT Presentation

  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Lessons Learned in Agile Development

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Lessons Learned in Agile Development

Jim Smith

PDX, Inc.


  • 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.


  • 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.



Hemant Elhence




  • 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

  • Our Clients


    Call Us for a Free Consultation!

    Hemant Elhence



  • Login