Six questions for equity, participation, and buy in


After some hard won lessons, I’ve started asking these six questions before enacting any important leadership decision.

  1. What exactly we doing?

    Answered as directly and simply as possible.

  2. How does it relate to an existing priority?

    Something I believe people broadly understand to be important.

  3. Why now?

    Why invest time & money now over things people might think are important

  4. Who’s accountable?

    Who is following through? Who can answer questions?

  5. have we consulted with people affected by the decision?

    Invite participation before or repair damage afterwards. If timing really doesn’t allow then admit it and ask for feedback.

  6. How can people help/stay informed/participate?

    Are we asking for help? If not, how will we make progress visible.

I’m interested in what people think of this or if they are doing anything similar.

Unintelligent design – the abuse of ‘inspect and adapt’ in Agile practice

Are you Agile if you don’t ____?

I just read an unpublished experience report. The report observes a team with over a year’s experience together within an organization that has several other Agile teams. Each team has a adopted different set of practices.

Specifically, this team followed Scrum with the following notable exceptions: 1) they didn’t contribute to the product vision because it is not the corporate culture 2) the team didn’t retrospect because they didn’t believe they had time.

The author then went on to conclude:

Customizing practices has allowed them to apply Agile in an effective way.

A conclusion I characterize as:

a) since the team has altered or omitted some Agile practices, and b) they consider themselves successful therefore c) the compromises were necessary and effective.

I will also note that all the adaptations described were compromises to the team’s Agile practice itself and the rationale for those adaptations was to fit into the existing corporate culture.

While the case study observes the team with some rigor, it leaps to three conclusions: that the team is effective, that the specific adaptations they note contribute to the team’s effectiveness, and that the examples are evidence of a successful Agile adoption.

I believe this is a pretty common take on Agile adoption, if not in words, in execution. And it is a fundamental misreading of the goals of continuous improvement in Agile practice.

Adaptation is both a tool for survival and optimization

building-blocks-iStock_000000102434Medium

When we strive after Agile software development, we encounter obstacles from outside our team, from team members and within ourselves. In the face of an obstacle we ask ourselves, “Can I remove it or do I move around it?” The pragmatic and necessary answer, may be to adjust our tactics, compromise our practices and move on.

Then, as our team becomes more adept some of the ceremonies may prove unnecessary as the values which those ceremonies re-enforce become ingrained as habits. And so, again, we relax our embrace of certain practices.

As we adapt our practices, we must regularly and skeptically inspect the assumptions behind those adaptations.

We must reflect on any claim that “we have to do ______” or “we don’t need to do ______”.

So, specific to the team the doesn’t hold retros, I have two lines of enquiry:

If they don’t have time to hold retrospectives but they believe they’re important then how are they going to make time?

If they don’t believe retrospectives are valuable enough for the time they take then what about their attempts are ineffective? Do they understand why retrospection is valuable? Do they know how to facilitate one? More profoundly, is something missing in their organization: low trust among the team, no authority to act on anything that arises, or lack of trust by management? These obstacles are worse than a simple lack of time management and will cripple the team’s collective ownership.

Even a necessary, pragmatic adaptation of the moment, if pursued un-reflectively will at some point hold a team back because it either protects and carries forward a dysfunction or encourages new ones to arise around it.

When reviewing your team’s practices ask yourself: have circumstances or people changed? Has the team earned enough trust, achieved enough success to take on a previously intractable obstacle? Is it the same team? Maybe it’s time to re-adopt or refresh? Have we gained wisdom or humility? Sometimes, we cannot grasp the value we unlock if we pursue a practice until it becomes a habit. It is our job to learn, to have courage, and to make that case both to our leaders and to our peers.

As Agile practitioners, we have to understand that adaptation requires contemplation and a larger perspective. We have to challenge both the immediate obstacle and the premise behind our own decision to avoid it. We have to revisit decisions over time. And we have to embrace a vision of what we are trying to achieve that is larger than the immediate problem.

My next post will go more into the last of those concerns. A vision of what Agile adoption is meant to achieve and what I see as the great danger of naive, unreflective adaptation of its practices — surrender to the cynical misuse of the development team…

Negative perceptions about software development. Do you have a solution?

Feedback on my proposed session at Agile 2012 on whether principled Agile practice is capable of creating workplaces and an industry more inviting of women software developers…

I could not agree more. There are many negative perceptions about software development these day in the US (off-shoring, hostile env, long hours, …). As a result, my friends at North Carolina State University tell me that overall CS enrollment is down. There was a similar event in Japan with the creation of the “Software Factory” in early 80s. I believe that they almost decimated their software industry. But how do we solve this? It has to start early as the career begins way before their first job. Leadership? If we want to maintain the industry, you bet.

Agile thought leaders came together in the first place to challenge the rest of us to empower individual contributors, elevate the role of craft and quality, cultivate collaborative ways of working, and create better, more valuable software products.

Following their lead, principled Agile practice is a determined process of honest observation and incremental improvement. It is dedicated, courageous advocacy for removing obstacles — an effort supported by analytics and a track record of improved performance.

The ambitions of this change don’t stop at a team or a set of engineering practices (though those are hard enough to accomplish). It is a change program within an organization.

We should see our mission is aligned with creating a software workplace and definition of the software developer inviting to articulate people, with diverse interests and points of views, who reflect our actual end users, and who want careers that have meaning and purpose.

I’ve never participated an agile adoption that didn’t ultimately set its sites on the larger company, the products that organization is building and why it is building them. I’ve never been part of a prolonged and dedicated agile adoption that didn’t bring developers closer to creative people outside the team, that didn’t make work a more rewarding place to show up each day.

Agile practitioners need to battle workplace cultures that discourage women and other talented people from entering and remaining in our field one dysfunction, one bully, one obstacle at a time, in one workplace at a time, because they are obstacles to collaboration and trust, disempower and burn out talented individual contributors, and distance us from our customers and end users.

I’m not saying this happens everywhere or that the changes are permanent. Widespread adoption brings with it mixed and often disappointing results. But enough of us need to drive for this change in enough of our shops, enough of the time that Agile remains a path to excellence for those of us capable of striving after it.

And by doing this we will create enough change to influence the rest of the industry. Agile adoption itself is an example of this kind of change.

Does this effort provide a clear path to success? Clearly not.

But is this approach capable of driving large and dramatic changes in companies and our industry? Yes.