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 going through a contentious divorce. The manifesto also does not talk about 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 shadow. Today, I want to discuss a particularity dark subject in agile: dependencies.
The scrum guide is clear about 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 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 purview of the scrum team often control the web or database servers, and the group becomes dependant 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 it was a hatred that blinded me to mitigate these situations for five years of my career. Once the rage and frustration wore off, I discovered that a 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 mighty cool feature from Microsoft and saves loads of time 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 on 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 with the need for the configuration of the server. The team shared e-mail messages, text messages, 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 a few phone calls and addressed the problem. The server team configured our server correctly the next day.
The moral to this story is 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 will have a way to overcome these organizational hurdles.
Until next time.
No comments:
Post a Comment