Working as a technology professional does not have the working-class credibility of being a plumber or ironworker. We do not get dirty, and we do not pay a physical price for our work. The worst injury we can suffer on the job is a repetitive stress injury or the occasional heart attack caused by chronic stress. The biggest challenge in the profession is coordinating numerous savvy professionals to work together to accomplish a goal. Today on the blog, I want to take time out to review dependencies for agile teams and mitigate them.
When a project is small enough to require one agile team, dependencies are not a significant problem. Often, the scrum master or a team member will take the initiative and address the situation. At most organizations, a different team manages the production servers, so when it is time to promote code into production, someone from the agile team makes arrangements with the server team. Dependencies are simple on these projects.
A larger project quickly becomes a tangle of dependencies. For instance, an extensive enterprise application might have an AS/400 team working with enterprise data, a group writing a web interface, and finally, a group writing middleware to connect the two. At this point, dependencies grow on a logarithmic basis. Add an extra team, and the number of dependencies jumps from three to six. Add a fifth team, and you get ten and so on until you get a tangle of communication channels. The PMBOK guide has a fancy mathematical formula to calculate how these systems get out of control.
Doing the math, a team of ten people or groups has forty-five different connections. It is clear to see that the number of links and dependencies will be a problem for people to follow.
The solution to this problem is to isolate those lines of dependency to make a clear connection between groups. In my previous example, the middleware team is connected to the AS/400 team and the web interface team. Upper management wants to add a team to write a mobile application. Instead of linking the mobile development team to the middleware team and giving them more dependencies, the new team should collaborate with the web team because they already understand how to connect to the middleware already generated, saving cycle time and distractions. It seems counter-intuitive, but the knowledge from the web team will be more valuable than the middleware team attempting to educate the mobile application team on how to consume the web services. Organizing your groups in this fashion prevent your dependencies from looking like the bedroom wall of a conspiracy theorist.
To address dependencies, isolate them into narrow paths to reduce the number of connections between groups. Not only does this conform with the PMBOK Guide, but it conforms to the theory of constraints because it allows a scrum master or coach to isolate and exploit limitations in a system. Doing this will help remove complexity and lower your stress levels below heart attack severity.
Until next time.
No comments:
Post a Comment