Dealing with the darkness of dependencies.

As agile professionals, we learned early in our careers that agile is easy to explain but difficult to practice.  For instance, agile talks about individuals and interactions in the manifesto but does not discuss how to help a development team member through a contentious divorce.  The manifesto also does not discuss deadline pressure or the weirdness of the project budget process.  Lewis Carroll, who wrote "Alice in Wonderland," said, "Between the idea and the reality lies the shadow." As a coach or scrum master, you spend plenty of time in the shadows.  Today, I want to discuss a dark subject in agile: dependencies.  

The scrum guide clearly outlines the organization of work. With the help of a product owner, self-managing teams should work with the business to deliver value in rapid increments. Backlog items are created, prioritized, and worked on during a sprint. If everything goes well, then the team should have a working code to go into production at the end of the sprint. It is a fantastic concept, but the organization of most corporate systems plunges teams into shadow.  

People outside the scrum team's purview often control the web or database servers, and the group becomes dependent on others who have a different set of priorities. These priorities do not align with sprint goals. A developer or scrum master then wades through the politics of getting servers provisioned with the correct configuration and security permissions. The experience is a hassle and often throws off the team's timeline, undermining the rapid delivery of value to the customer.  

I hate dependencies like this with a passion that borders on pathological, and this hatred blinded me to mitigate these situations for five years of my career. Once the rage and frustration wore off, I discovered that dependency is a story in the backlog; if it is incomplete, the team can escalate to leadership.    

I worked on a project where the server team did not configure the webserver to allow Azure DevOps to deploy code from a pipeline.  It is a fantastic feature from Microsoft and saves loads of time when deploying code to different servers.  One day, a sprint ended for my team, and the server team did not configure the webserver.  Instead of showing code in a development environment, we demonstrated the software in the test environment, which returned an HTTP 404 error.  The leadership was scandalized and asked why nothing got done during the sprint.  I produced a work ticket that needed the server's configuration. The team shared e-mail, text, and corporate paperwork to get the server online.  We also showed that the server team did not respond to our inquiries for three weeks.  Based on this information, leadership made several phone calls and addressed the problem.  The server team configured our server correctly the next day.  

The moral of this story is to document dependencies in the product or sprint backlog.  The approach creates a quantitative technique to measure how long it takes people outside the team to complete work.  Transparency and openness are tools to help the team and its leadership better address organizational impediments. It works for small projects of one group or giant enterprise solutions with hundreds of developers.  

Dependencies are a shadowy subject, but if you document them in the backlog and are transparent about their impact on the project, you can overcome these organizational hurdles.

Until next time.