Noticing a recurring theme and association between Agile Software Development and speed sent me into a mild existential crisis regarding my thoughts and experiences. This "must go faster" attitude also dredged up my post-traumatic stress as a developer working in a "fast-paced environment". It also led to some serious introspection...

When I do Agile Software Development, am I going faster? No.

What happens and what was I doing if not going faster? Simplicity, agility, and principle-based development.

What tend to be the results? I actually have fun doing software development and my clients tend to forget they're doing product management.

This talk explores the implementation of the US Population Clock from the US Census Bureau (the Popclock) from both the human and software system perspectives. We will discuss the design of the system as it relates to various principles and practices typically associated with Agile Software Development; no code samples or demonstrations. At its heart, the story is about reducing the friction that can often arise between the developer doing the work and those who are there to track the work.

Roughly 60% of the story focuses on solution design for the Popclock itself using the principles and practices listed below, the other 40% focuses primarily on the interactions between the developer and the technical lead (could also be seen as the Product Owner, Scrum Master, etc.).

Ultimately, the original set of requirements for the Popclock were finished a month before project end. The rest of the features were easily added within that month. All done without "going faster". This would not have been possible had there not been a focus on technical excellence over speed from the beginning.

 
 

Outline/Structure of the Talk

  1. Mindset being explored.
  2. Emphasis on speed within the Agile Software Development Community.
  3. Story based on true events from start to finish of a project.
  4. Wrapping things up.

The design and development principles and practices discussed:

  1. Don't repeat yourself,
  2. you aren't going to need it,
  3. SOLID (mainly single responsibility),
  4. Pragmatic Dave's Razor (what I call a philosophical razor proposed by Pragmatic Dave Thomas),
  5. refactoring, and
  6. re-engineering.

The Agile Software Development values and principles touched on:

  1. Individuals and interactions over processes and tools
  2. Customer collaboration over contract negotiation
  3. Welcome changing requirements, even late in
    development. Agile processes harness change for
    the customer's competitive advantage.
  4. Agile processes promote sustainable development.
    The sponsors, developers, and users should be able
    to maintain a constant pace indefinitely.

Learning Outcome

What can it feel like to do agile software development as a developer?

The answer:

Yes, have some! (or agility + productivity + fun)

Target Audience

Developers

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  1 year ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • It sounds like there might be a good story in here

    I think the submission could be improved by:

    • Josh Bruce
      By Josh Bruce  ~  1 year ago
      reply Reply

      Thank you for the feedback, George!

      I have updated the proposal. There are some bits I'm reflecting regarding the second bullet of your feedback as well.

      Thanks again.

      • George Dinwiddie
        By George Dinwiddie  ~  1 year ago
        reply Reply

        Is this talk geared toward technical people? Would it be better in the "Code & Tests" track?

        It sounds like your message is that paying attention to technical excellence "saved the day" in terms of reliably getting things done. If so, I would offer that (expanded as you see fit) as the benefit in the abstract, and move the list of principles and practices down to the outline/structure.

        • Josh Bruce
          By Josh Bruce  ~  1 year ago
          reply Reply

          Thanks again, George!

          This one's a bit longer, apologies, if I had more time to edit it would have been shorter. smile

          Full disclosure, my brain has a hard time dividing people. I'm concerned about putting it in the "technical people" area, because I actually think non-technical people would benefit just as much, if not more. But, I think they might say, "Code & Tests? That's got nothing for me." Having said that, I once did a demo to a business operations unit to show them how agile (literal definition) software development could be, following the demo they didn't become "technical" but they changed all sorts of things about how they operated and interacted with developers and what they thought about when it came to what's possible.

          Also, I recall looking for but don't recall finding something that described what each category is all about (maybe I missed it or forgot where it is?). "Improving your game" seemed the most appropriate as it can improve the software design game of someone or the human interaction game.

          Thanks again for making the time to offer feedback, I appreciate it. Hopefully the changes are an improvement.