The Infrastructure-First Fallacy

Early in the development of Upkeepr, we had a “lead developer” with a very command-and-control style that created some friction with the rest of our agile team.  This first conflict we had was around developing the core elements of the web application architecture.  For the first couple of sprints, this lead insisted on working on “application infrastructure” while the other devs built out some critical components like OAuth login and refresh tokens.

While the others demonstrated their work product at the end of each sprint, the lead dev failed to create even a demonstrable prototype, let alone a skeleton that the others could hang their work on. 

Now I know, as most experienced agilists do, the importance of creating a working product increment with every sprint.  So, I pushed the team to just deliver something.  It took several sprints of me talking with the lead and other Devs individually about the value of delivering a working increment and my dissatisfaction as a product owner (as entrepreneur, I was playing multiple roles) that we worked through to the point of having a basic working architecture.  But not too surprisingly, the application infrastructure built en-mass, and not delivered and tested incrementally, was riddled with technical problems and shortcomings – most of which had to be reworked for many future sprints. 

In the PSM II class we talked about the importance of team agreements, including the Definition of Done, which can evolve over time. The team needs to start with the fundamental Scrum values of transparency, inspection, and adaptation.  Creating a done product increment every sprint enables these.  Starting with Scrum fundamental values and principles to build team agreements is a much healthier and more effective way to address a friction point like lead developer hero behavior than I took just trying to coach them through “the right way to Scrum” without those fundamentals. 

If I could do it over again, I would take this approach:

  1. Start by sharing with the team the product vision AND the Scrum values and principles.  Ensure the whole team has buy-in before starting the first sprint.
  2. Work with the team to create an attainable sprint goal.
  3. Coach the team to create a rudimentary Definition of Done (DoD) that just has working code to meets the PBI acceptance criteria committed/merged to the main branch, compiling and running. 
  4. Push to create a working increment from the very first sprint and analyze the situation deeply if we fail to deliver value towards the Sprint goal.
  5. Defer creating more sophisticated DoD criteria like automated tests, CI and CD builds until later sprints.  Make the first couple of sprints about delivering something that works, preferably integrating everyone’s work product.
  6. Encourage the whole Dev team to evolve the application infrastructure towards a vision rather than building it up-front.

The goal in these early sprints should not be to build out as much of the product and DevOps infrastructure as possible, but to get the team working together and start a rhythm of delivering a working increment.  It’s counter to my entrepreneur’s urge to realize the product vision as quickly as possible. But, taking it slowly at first will avoid much dysfunction and frustration with all parties.

Return to Blogging

For the last couple of years, I’ve been running a startup to develop an app (Upkeepr) and learning many lessons along the way, which I’ve been thinking about sharing here. Also, I’ve immersed myself in Agile theory again by:

  • Taking the Scrum.org Professional Scrum Master PSM I and PSM II courses taught by Improving
  • Studying for the PSM assessments (and passing)
  • Reading
  • Applying to be a Professional Scrum Trainer (PST) and reflecting on my love of teaching

The two big books that have me thinking deeply at the moment are:

As has always been the case in my blogging, my intended audience is both the public at large who may be interested in my musings on Agility, product development, or technology, and my future self, when I’ve forgotten the clarity of thought I had at some moment or want to continue a train of thought with the next step. Plus, writing often forces me to frame my thoughts and structure ideas into something consumable by others. So maybe this will make me a better Agilist, leader, and entrepreneur along the way.

So, here goes!