Working on a colossal software project is an endurance exercise. Based on my experience in software development, no one agrees all the time during a project. Coordination with thousands of people across continents to get something done is challenging when everyone agrees; it is next to impossible when there is a dispute. The amount of money, time, and reputation wagered during each software project is tremendous, and this high-pressure environment arouses strong passions. As a coach or scrum master, a person needs to adjust to those strong waves of emotional energy and find ways to move the work forward. I want to discuss how to make this happen.
Large projects are a Rube Goldberg contraption of competing interests, visions, and skills. Systems which need to work together are often incompatible. The people doing the work rarely understand the systems they are working with and how they are supposed to work. Finally, no one person understands how the entire system operates. What is not apparent is what the team must do and why it needs doing. The only clear thing is that the project has funding and something needs to be delivered.
Soon, skilled professionals will attempt to collapse the cone of uncertainty and figure out those two crucial questions. By the time work begins, some understanding should be part of the project. In reality, work is done blind, and the organization attempts to dig through the complexities of the task at hand.
It also does not help that there are considerable gaps in power between the people commissioning the work, those leading the job, and the developers doing the work. An executive vice president wants to know a completion date, and when they ask a developer who they can fire, the developer will create a comfortable fiction. It ratchets the stress on the development team because the executive now treats the comfortable fiction as an actual deadline. If the deadline is missed, the CIO becomes involved in the project, escalating the tension further.
What happens is an awful cycle of failure which undermines trust up and down the chain of command. It leads to micromanagement and arguments about service level agreements and contracts. Sadly, I have experienced these situations more than I would mention.
Clearly, as a coach and scrum master, we need to address this awfulness. First, recognize a power imbalance and make it clear to everyone involved. Let people know that someone will not return your calls or email without getting a director or vice president engaged in the conversation. Next, state that you do not know what to say in a situation because you are not in a position of power. For example, “ I want to provide an estimate for that feature, but I am understaffed and do not have the authority to hire.” Finally, state the uncomfortable truth instead of a convenient fiction. It is the hardest part of an agile professional’s job because it puts you at risk, especially contingent workers or consultants.
Business is overflowing with convenient fiction, but if you want to get work done, you will have to point out uncomfortable truths and ambiguity in what is happening. If you don’t, it will create the cycle of mistrust and escalation, which I outlined earlier. Robert Sutton points out that corporate leaders often live in a “Fools Paradise,” where they only receive good news because subordinates are afraid they will be ostracised or fired for bringing bad news. It is true in an organization with little psychological safety, but leadership will be grateful for the clear insight in an agile organization. Thus, it is courageous to tell uncomfortable truths instead of a convenient fiction to leadership because if they are good leaders, they will act on these truths instead of burying them.
Massive projects are challenging. Working on one makes you feel small and futile. What will help you and others get things done is admitting uncomfortable truths and working through them. It requires courage and strength, but it will be better for everyone involved, and the project might get done sooner.
Until next time.
No comments:
Post a Comment