Scrum, XP, Management and the Ethics of Agile Software Development

software development

Life lie (Excuses)

Are there lies you tell yourself to face work each day?

“If you take the life lie from an average man, you take away his happiness as well” — The Wild Duck Act V, Henrik Ibsen

Developers often feel powerless in their workplace. At agile conferences I’ve heard:

  • it’s the nature of the business
  • it’s not my responsibility
  • I don’t have the authority
  • I do what I’m told

Yes, we have to pick our battles and yes we can’t always win. Fear is a hard thing. But it seems obvious that a way of working doesn’t mean anything unless we use it to change what we do.

A personal manifesto (Agile Values)

In my decisions and actions, I balance the following:

  • I care about the people who use what I create.
  • I care about the quality of what I create.
  • I care about the people with whom I create.
  • I honor my commitments to my employer.
  • I am loyal to people who have earned my loyalty.
  • I provide for my family.

I reflect on my decisions and actions to avoid:

  • negligence,
  • incompetence,
  • deception,
  • waste, and
  • harm.

Agile practice is a means to these ends.

Note to self regarding retrospectives

I can never know someone’s intentions.

I only know their actions and how I felt about them.

For the same reason, I should never be surprised by how different someone’s perception of my intentions are from my own.

Focus on cross-organizational dynamics, pathologies and development (agile adoption)

I agree with the conclusion of israelgat’s post on Agile Manager, Persona of the Agile Team:

If the spread of Agile in your company has stalled, providing qualitative and quantitative data on the benefits of Agile might not be the best way to win over support for broader adoption. Instead of hard sell of Agile benefits, focus on cross-organizational dynamics, pathologies and development.

Why do some Agile projects succeed while others fail? Is it the company? Is it Agile methods?

Failure DartsMy response to the question:

Why some Agile projects succeed while others fail? Is the reason of that in the company itself or is there something wrong with Agile methods?

What is success and what is failure in this question?

Agile is a set of human values embodied in a wide array of practices. To call it a tool is to dismiss the tenacity, honesty, courage, empathy, trust, generosity, pride, discipline, respect and loyalty that inspire the practices and that explain why those practices can change people and organizations.

But being Agile is also fundamentally about specifics. What is the best adaptation of a set of disciplined practices for a specific team in a specific context to achieve a specific goal? How to evolve those practices day by day, acknowledging our shortcomings and our immediate obstacles, working to our specific strengths as individuals and as a team.

The definition of success is critical. If it is undefined, unachievable, subject to forces outside of the efforts of the team, or subjective in the eyes of people who don’t participate in the project then success or failure is arbitrary. Outside the scope of the participants.

In many cases, failing fast, failing decisively is a kind of success in that no amount of additional expense ensures meeting subjective, arbitrary or external measures and, at the end of the day, even meeting those measures doesn’t necessarily benefit customers and end users.

Completely understandable though why human beings who value material means, family and interests outside of the workplace would opt for the long, slow ambiguity over short, concise defeat. Besides there’s always the hope that time will allow for the change that makes success possible. This is the constant tension in inspecting and adapting – in any given situation is it better to shove, nudge or work around an impediment.

That said, even a smart project with a great team and a perceptive product owner can fail in the marketplace, or fail to impress funders, or fail to fit in the corporate culture, etc. etc.

So, Agile projects can fail as all human endeavors can fail. They fail because the participants call whatever crap they happen to be doing “Agile”. They fail because a team doesn’t adapt fast enough or because they try to force change too fast. They fail because a great team is working for a bad product owner. They fail because a great team and product owner are building the wrong product or the right product for the wrong company or at the wrong time or in the wrong place.

Provide a specific example and you can get specific answers. Provide a generic question and the answer is, “Yes, all of the above.”

ken h. judyI am an executive manager, software developer, father and husband trying to do more good than harm.
Working to spend each day doing a little less crap and a little more not crap than the day before. Without delegating my crap to others.
Aspiring to pride in my accom- plishments and pride in who I become as I attain them.
IEEE CSDP
CSP
I'm speaking at Agile 2012

Papers

Presentations

 

Site menu:


Meta

Creative Commons License

Post text is licensed under a Creative Commons Attribution - Noncommercial - Share Alike 3.0 United States License.

Unless otherwise indicated, Images in posts are not cleared for redistribution under creative commons.

Copyright © 2006-2012
Ken H. Judy.

This is a personal weblog. Views expressed are my own and not those of my employer.