From pear-shaped to illuminated in one project

"I know you like Agile because it's new and shiny but..." is a line I've heard a few times over the past few years.

To which I usually respond, "It's not because it's new and shiny, it's because I know what's possible with it."

"How's that?"

"I came to it on my own...before I read or was told about it. I wasn't trying to learn how to do it, I just started doing it."

In 2007 I had never heard of Agile Software Development. I had also decided to try work as a full-time freelancer to help facilitate a career change after having no luck doing so two years after graduating university. I was brought on to a project to convert a 1500+ page, static website to a database-driven content-management-system-backed one; the CMS was also a custom build because that's what you did in 2007.

36 month project. I came in at 18 months. The only real progress made was the design for the home page had been agreed upon. Further, the committee had appointed a sole responsible individual (not called a Product Owner). I would be the only developer for over 90% of the project; from database architecture and migration to user interface.

It was actually worse than that in the beginning. The framework they had been building didn't work consistently and the developer who wrote it was no longer working on the project...he also didn't strike me as a people person. Most communication between the three of us was through email at inconsistent times of day. There was no real project management plan or strategy beyond, "just get it done." And the Project Manager, Not-A-Product-Owner, and myself did not operate as a team...oh, did I mention the PM was in New Jersey, the NAPO was in Pennsylvania, and I was in Atlanta?

It took less than three months to turn the project around and begin gaining momentum and focus. We finished with the initial set of requirements within the 18 month mark and were so caught up in the momentum and ease of it all that we barely realized we were still adding features six months later.

We will discuss each set of pain points that led to a decision being made and how each decision ties in with or results in one of the values from the Manifesto for Agile Software Development. My personal favorite is probably the conversation to throw out the framework that had been developed over the first 18 months and start pretty much from scratch because working software (and it's the only measure of progress).

 
 

Outline/Structure of the Experience Report

  • Lead in.
  • On-boarding to the project and learning that the framework didn't work consistently. Can I just start from scratch? (Working software)
  • Emails are contracts. Having to go through the PM (or BA or whomever) are contracts. Can I just talk to the customer? (Customer collaboration)
  • This is the way we've always been doing it. Can we change the way we're doing it? (Adapting to change)
  • Becoming a team and the benefits of the Agile mindset. (Individuals and interactions)
  • Closing out the project. So, when's it going to be done?

Learning Outcome

Improved embodiment of the values from the Manifesto for Agile Software Development through tactile experiencing leading to them. (Some possible "whys" behind the values.)

Target Audience

Those considering adopting or recent adopters of agile software development

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:

    • presenting an experience report structured around the values of the Agile Manifesto

    I think the submission could be improved by:

    • letting the reviewers know what might be in those bullets. (We already know the Manifesto)
    • Josh Bruce
      By Josh Bruce  ~  1 year ago
      reply Reply

      Thank you again for the feedback!

      Please see the changed proposal.