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

Lessons Learned in Agile Development PowerPoint PPT Presentation


  • 92 Views
  • 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

Lessons Learned in Agile Development

Jim Smith

PDX, Inc.


Disclaimer

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

Context

  • PDX. . .

  • The original PDX Agile project. . .


Lesson 1

Lesson #1

  • Everybody thinks they’re already Agile.


Lesson 2

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

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

Lesson #4

  • Write good user stories.

    • Good user stories are beautiful.

    • Apply the “no system” litmus test.


Lesson 5

Lesson #5

  • The industry feels that pre-planning is necessary.


Lesson 6

Lesson #6

  • TDD: a way of life


Lesson 7

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

Lesson #8

  • Even the best and brightest have trouble with collaboration.

    • It’s a required skill in today’s software development shop.


Lesson 9

Lesson #9

  • The team will gladly turn in slackers.


Lesson 10

Lesson #10

  • [Lean] documentation is still good.


Lesson 11

Lesson #11

  • “Nothing is over! Nothing!” –John Rambo


Lesson 12

Lesson #12

  • The team must understand: You can’t do everything that falls out of retrospectives.


Lesson 13

Lesson #13

  • Although not ideal, team members can be scrum masters.


Lesson 14

Lesson #14

  • You can get executive, managerial and customer buy-in with your first demo and through training on user stories


Lesson 15

Lesson #15

  • Customers and other stakeholders at demos = bueno!


Lesson 16

Lesson #16

  • Let the scrum team stay focused; retain a production support team.


Lesson 17

Lesson #17

  • Get your DBA team to agree to an SLA.


Lesson 18

Lesson #18

  • Break down those user stories!


Lesson 19

Lesson #19

  • Keep noisy managers and executives out of kick offs.


Lesson 20

Lesson #20

  • The stand up is for all.


Lesson 21

Lesson #21

  • The PO must appreciate the value of paying technical debt.

    • 20%


Lesson 22

Lesson #22

  • The PO is not the team owner.


Lesson 23

Lesson #23

  • People won’t talk? Slamming doors? Putting up walls? = dysfunctional Agile team.


Lesson 24

Lesson #24

  • Parties and other rewards after demos == bueno!


Lesson 25

Lesson #25

  • Don’t let a sprint go longer than five weeks.


Lesson 26

Lesson #26

  • Train your developers to sign off on user stories early.


Lesson 27

Lesson #27

  • The PO position is a fulltime job, for a member of the business, who can appreciate technical debt.


Lesson 28

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

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

Lesson #30

  • Don’t treat your India folks like warm bodies. . .or they’ll act like warm bodies.


Lesson 31

Lesson #31

  • Sashimi is a great idea, but not always 100% possible.


Lesson 32

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

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

Lesson #34

  • The Scrum Master is a strong servant leader.


Lesson 35

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

Lesson #36

  • Developers are professionals – not privates in the army. Treat them as such.


Lesson 37

Lesson #37

  • “Scrum” is not an acronym.


Lessons learned in agile development

Q&A


Lessons learned in agile development

www.synerzip.com

Hemant Elhence

[email protected]

469.322.0349

84

  • 42


Synerzip in a nutshell

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

    Our Clients


    Thanks

    Thanks!

    Call Us for a Free Consultation!

    Hemant Elhence

    [email protected]

    469.322.0349


  • Login