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.