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.
Short link: http://jkat.me/f7WMHS
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.
Short link: http://jkat.me/i5O5XB
My 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.”
Short link: http://jkat.me/eSsI3J
I’m reading Delusions of Gender: How Our Minds, Society, and Neurosexism Create Difference
Fine challenges the popular belief that women’s brains are hardwired to perform differently than men. Beliefs as old as gender roles but popularized in recent books like The Female Brain
It is her discussion of empathy that interests me at the moment.
She acknowledges that studies frequently demonstrate women are more empathetic than men.
However, she argues those differences are most observable when gender stereotypes are foremost in people’s minds.
Simply asking people in advance to check a box indicating whether they are male or female increases differences in performance during evaluation while priming people with a social identification that cuts across gender reduces them.
Differences become less significant when studies control for the value subjects place in their own empathy. For example, they disappear when men and women are given the same social or material incentives to read and effectively address feelings in others.
Yes, it was possible with small changes to degrade women’s performance to the level of men. It was also just as possible to raise men’s performance up to the level of women.
The performance leveling applies to both aspects of empathy: the awareness of feelings in others and the ability to understand and identify with those feelings.
And this is why it is relevant to our male-dominated Agile software community.
In Agile/Lean, work is collaborative. Our essential identification is with the team. We move away from a focus on self and an abstract relationship with our employer and toward a visceral and immediate social connection with our co-workers. We work collaboratively and frequently with our customers and we define our work in terms of what benefit it offers our end users.
In that context, we are incentivized in ways that potentially make us more perceptive of and more caring towards others.
I realize empathy doesn’t necessarily lead to conscientious acts. But it is reasonable to assert that where my actions and decisions affect someone, my having empathy towards them gives me some advantage in acting and deciding in a way that provides them more benefit and less harm than I might otherwise.
In other words, I believe more empathy leads to more thoughtful developers and a chance at more effective, more beneficial software. Further, I believe empathy is a factor in creating a more socially aware, ethical software development community.
I already see a limit to this premise. The social context of a team may be too narrow particularly if it is composed on one class, one race and one gender. If we all think the same, have the same narrow set of experiences, problems and advantages will we become a self-directed team who still doesn’t give a rat’s ass about other people?
Based on the admittedly light summary provided in Delusions of Gender, when a social frame or incentives improved results, they did so across the board. When men were primed to value empathy, their ability to empathize improved in general.
Still, if this is a flaw then the answer is to build diverse teams. There are so many other reasons we should all be striving for that and a collaborative environment may in itself help us achieve that goal.
I find hope in this. Hope that Agile principles are not just a path to value narrowly defined but a way towards empathy, conscience and contribution.
Short link: http://jkat.me/f86IMR
As I’ve said before, we use Thoughtworks Studio Mingle to track our backlogs.
One thing Mingle has not provided for us in the time we’ve worked with it is a daily burn up. Kind of shocking.
Last month, we migrated our instance to the EC2 cloud. I took advantage of that migration to un-cruft our Mingle instance, apply the XP template and simplify card types and states.
Now time to stop dumping data out of mingle to report status. Yes. Kind of shocking.
The first step was to track the data points we need for a burn up.
That involved creating a series of date fields to track the day on which a story moves from in analysis to ready for dev, in dev, in qa, ready for customer (QA done) and customer accepted.
We also need a way to have those dates recorded automatically as part of moving cards from one state to another.
So we set up Mingle card transitions.
This replaces the drag and drop behavior of a card from one swim lane to another with a button link on the card. This a bummer for our product team but it allows us to script transitions to both change the status and set the appropriate date field.
Now to setup a burn up chart using Mingle charts and mql.
Observations:
Here’s what the result looks like:
This chart along with selected summary counts and tables allows us a real time dashboard of the health of our sprints.
As you can tell from the burn up, we have work to do improving flow in our iterations.
Anyway, reporting is a work in progress. As is everything.
Short link: http://jkat.me/i4M0Kw
I am an executive manager, software developer, father and husband trying to do more good than harm.
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.
