Tag Archives: agile

[2020 devnexus] metrics that matter

Posted on by
Reply

Speaker: Joel Tosi @jdojoandco

For more, see table of contents

General

  • Finishing on time doesn’t matter if do wrong thing
  • Can’t just say happy; need to know how much costs
  • Who cares about metrics: managers, product owners
  • People tend to measure what is easy to measure
  • Goal is to make people happy (and make money)

Bad metrics

  • # people trained as measure of agile transformation
  • measuring just a piece. Doesn’t matter how fast deploy if deploying wrong thing. Sub-optimizing

Simple metrics

Good place to start if have no metrics now. (but not always good metrics)

  • Number of defects
  • Velocity
  • Lines of code
  • Number of teams (not x% transformed b/c y teams have done it)
  • Code coverage. (bad if game system: ex: tested all getters/setters to increase)

Notes

  • Easy to collect
  • Doesn’t tell customer impact, right or usable
  • If don’t have insight, can help

Directional Metrics

Take time to capture

  • Increase in code coverage
  • SQALE (from Sonar)
  • Reduction in % of defects
  • Cycle time
  • Deployment frequency
  • Average time a bug takes to get fixed
  • Number Checkstyle violations over time
  • Size user base

Notes

  • More sustainable. Ensures not killing team in meantime
  • More depth
  • Still not measuring impact to users

Impactful/Economic Metrics

  • Reduction of cycle time for a delivery that mattered
  • Systemic cost reductions
  • Stopping bad ideas

Notes

  • How do we get rid of noise in the system
  • People need to agree to do these types of metrics
  • Need psychological safety. Must be safe to be wrong

Process Behavior Charts

  • You deliver value with a system.
  • A stable system will continue to deliver outputs within a range if you do nothing different.
  • Goal is not to react to noise.
  • Process Behavior Charts help separate signal from noise
  • Need to understand what measuring
  • Chart data in a time series
  • Calculate the moving average
  • Calculate the upper/lower bounds by multiplying by 2.66
  • Introduce change and continue to measure

Supporting Knowledge Work

  • Better decisions if faster access to info
  • Onion – team, manager(s), business, execs. Who can answer a question. How many levels need to go through

Books

  • Measures of Success: React Less, Lead betteer, Iprove More – Mark Graban. Covers health care.
  • Understanding Variation – The Key To Managing Chaos – Donald J Wheeler. Explains why 2.66 and more complex charts
  • Principles of Product Development Flow – Donald G Reinertsen

My take

Good talk. I like the interactivity to supplement the slides. I was thinking it would be more concrete. But I liked what it was actually about. I hadn’t seen process behavior charts before and found that particularly interesting.

[2020 devnexus] mothering a dev team

Posted on by
Reply

Speaker: Valarie Regas @ValarieRegas

For more, see table of contents

Wardley Maps

  • For more: https://medium.com/@swardley
  • Map/graphic inspires more confidence than strengths/weaknesses/opportunities/threats matrix or list of steps
  • Customer is anchor point – your gol is your users
  • ex: Y axis is value chain visibility
  • ex: X axis is evolution. goes from genesis (ex: in house custom solutions) to commodity (stuff can outsource0
  • Links between nodes are dependencies

Examples/Lessons

  • Must have only one anchor point
  • Everything shouldn’t link to everything else
  • Need midtier examples – something between “hello world” and enterprise software
  • Disney trip example! ex: fastpasses, pack, dining. (time bound events). Y axis dates and X axis is person doing
  • Chore chart leading to donuts. X axis is people again. Used pictures for four year old.
  • Work project with y axis as time needed to do. X axis is status (planning to completed)
  • All show movement from beginning to end, shows components clearly and shows how to get from one to another

Other axis ides

  • Cost
  • Complexity
  • # people needed

Other notes

  • There is software as well. Can make whiteboard version or electronic one.
  • Can use for sprint planning.
  • Valarie creates the maps independenly

My take

I hadn’t heard of Wardley Maps. Interesting idea. I *love* the Disney example. I have planned a trip to Disney World. What a project. Also, loved the how to make PB&J sandwich reference. I enjoyed that when I was a kid. I like there was a lot of Q&A. (I noted this last year too)

[2020 dev nexus] agile software engineering

Posted on by
Reply

Speaker: Jeff Wilson @mjeffw

For more, see table of contents

Quotes

  • “Scrum is like your mother-in-law, it points out ALL your faults” – Ken Schwaber
  • “Without requirements or design, programming is the art of adding bugs to an empty text file” – Louis Srygley
  • Cartoon – “A good architect leaves a footprint” cartoon – gave up giving them names and just name layers after the architect.
  • “Make it work; make it right; make it fast” – Kent Beck
  • “If you are releasing software into production once every six months, you aren’t very good at it. If you can release software into production every 11.6 seconds like Amazon, you are bloody good at it” – Dave Farley

General

  • In short term, those ignoring quality are faster. In long run, those focused on quality win
  • Common problems:
    • we can’t demo anything until all the layers are addressed.
      • product owner should understand enough that can demo through a test
      • hexagonal architecture/prots-and-adapters – interchangeable requirements, can unit test or demo parts. Note all parts and draw a hexagon around them. Each layer has its own port and understands format. Adapter changes data to standard format.
    • must have a database to test business rules
      • can use in memory database or mock objects
    • testers have a different interpretation of requirements than developers
      • problem that put testing at end of process
      • better to have the tests being the requirements.
      • cannot release code until all requirements met and no failing test cases
      • BDD – gets business, developer and QA to collaborate. Gherkin acceptance tests (given/when/then)
    • we don’t understand the user stories until 3-4 days into the sprint
    • tech debt is slowing us down
    • can’t get through coding and testing in the same sprint
      • happens if stories too big
      • happens if silos
      • “waterfalling” as sprint – spend first two days for design, and…
    • can only test thru gui or api
      • test should be at lowest possible level of code
      • test UI/API separate from rest of system
      • inverted pyramid for # of tests is an anti-pattern
    • Low level quality
      • Designing to interfaces, not implementation
      • SOLID Principle
      • Robert Martin’s “Agile Software Development” book
      • Eric Gamma’s “Design Patterns” book
      • Robert Martin’s “Clean Code” book
      • Focus on maintainability because changing code all the time – readable, extensible, clear design well-defined interfaces, ease of build/reuse, sufficient documentations
      • Create domain objects (ex: social security number) rather than just using Strings

My take

Hexagonal architecture was new to me. I want to read more about it after the session. It’s always surprising what the “new” thing I learn in this type of talk is. I’ve read all the recommended books, but good recommendations.