Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
Posted by Amr Elssamadisy on Feb 12, 2008
Successful Agile teams are predominantly characterized by their culture and not their practices. This sentiment rings true to many (if not most) in the Agile field. Christopher Avery, who has made his name in the world of organizational transformations, has taken his work on Responsibility and focused it directly on Agile practices. Is Personal Agility the key to successful Agile adoption?
Mike Griffiths blogged about a conversation with Avery:
We were discussing motivation and how to motivate peers who you do not necessarily have positional power over. Bosses may try to create motivation via carrot and stick approaches, but these are weak and short lived. People grow tired of such manipulation and find ways to break the system.
Instead, Christopher talked about “Intrinsic Motivation”, a more powerful motivation that comes from within. People want to be on a winning team, but are not sure how to find or create them. The secret lies in understanding what “winning” means for others and then creating wins around you. In practical terms this means asking people “what is in it for them?” i.e. what is it they would like to learn, do, or gain (beyond a paycheck) from the project and then provide opportunities for these things to happen.
At first this sounded a little odd to me, a bit too touchy-feely. Asking people what they did over the weekend is one thing, but asking them what they want out of a project seems, well, invasive, too personal. However when you think about it, that is backwards, after all the project is something we all have in common. What they did with their spouse over the weekend, now that could be personal!
A. Singh has also blogged on Personal Agility, back in June 2007:
My hypothesis is that these gains often do not materialize due to a lack of personal agility, where personal agility is simply the “awareness” of things of value and adapting behaviors and mindset to use it.
Singh cites the work of Eli Goldratt of The Goal and Theory of Constraints, Peter Senge of the Fifth Discipline, and Christopher Avery's work on Responsibility.
In an article for the Agile Journal, Ashley Johnson of Gemba Systems and I co-authored Personal Agility for Agile Adoption (also citing the work of Avery, Covey, and others):
As Agile becomes better known, many troubled teams are deciding to adopt Agile practices to help fix their problems. Most clients seeking our help in Agile adoption want to start by pursuing process and tools. The more dysfunctional their teams, the less tolerance they have for focusing on individuals and their interactions. We have found that the most effective teams- those that show a tremendous improvement in productivity and value to their organizations - have individual team members who take ownership, act responsibly, and are disciplined in recognizing and responding to change at a personal level. These individuals adopt Agile practices because they have made a conscious decision to do so. They do what it takes to make things work.
So what does Avery say? In his blog, Avery talks about Agile Dynamics vs. Agile Mechanics and states that the dynamics beat out the mechanics every single time:
Consider arranging results in a classic two-by-two matrix that measures agile tools quotient (i.e., mechanics) on one axis and personal agility quotient (i.e., dynamics) on the other. The scaling trend I've seen has been that most agile adoption efforts today attempt to move from quadrant 1 (low agile tools quotient, low personal agility quotient) to quadrant 2 (high agile tools quotient, low personal agility quotient) by teaching and installing agile tools and processes — i.e., the mechanics. The result is much pain. When enterprises instead focus on developing the leadership and people dynamics of agility, what I call personal agility, they move from quadrant 1 to quadrant 4 (low agile tools quotient, high personal agility quotient). From there, it is a much easier and more successful move to install the mechanics.
So, what Avery and others have found are that the touchy-feely skills (Agile dynamics) are much more important than the mechanics such as TDD, Stand-Ups, etc... Do you agree?
Agile Development: A Manager's Roadmap for Success
Learning to be a Good Product Owner: Foundation Skills
Design in Agile, Software Craftsmanship, Product Development, Testing @ QCon London in March
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
I have been doing for some years the question "what´s in it for you", "what kind of project would you do in your spare time", and things like that for team members in recovery and troubled projects, and found that if you treat people like volunteers, and redefine "together" the meaning of the work to allow that team members interests and personal goals be included into the projects as complementary goals, creating a more inclusive and long reaching goal, the flowers starts to bloom again.
It´s very nice to see people, that were frustrated, angry, sad, pity, to start to feel that they can, they are valuable and they want to realize their potential and share value with others.
Juan Bernabó
Teamware do Brasil
I wrote about intrinsic motivation a few weeks ago. I agree it ismuch more important then anything else.
paircoaching.wordpress.com/2008/01/18/intrinsic...
I think the Core Protocols of the McCarthy's (Remember "Software for your head") help people to find their own internal motivation. (next to creating good rules for communicating in an technical team)
www.mccarthyshow.com/Portals/11/docs/TheCoreV3.pdf
A friend of mine (he knows who he is) and I have had an ongoing, friendly argument about what matters most in a developer: technical or "soft" skills. He tends to argue the technical side, I take the other position.
Of course, you need both. But it's interesting these days to surf technical forums and boards (such as Joel on Software). I find there's great interest in the latest framework but little in talking about why our current project, which uses all these latest toys and is staffed by very smart people, is failing.
So, while I very much agree with the article, I'd probably take it one step further and try to apply it to any project, agile or not. I suspect that we'd find that the obstacles to personal agility are the same ones that are prevent our current non-agile project from succeeding. Or maybe it's that personal agility isn't just about enabling agile projects to succeed. Increased personal agility will help you succeed no matter where you find yourself working.
So, while I very much agree with the article, I'd probably take it one step further and try to apply it to any project, agile or not.
Yes - absolutely. Whether we call it 'personal agility' or 'responsibility' or 'kookoo waaawaa', the soft skills are a necessary, but not sufficient, skill-set for any successful project work.
Since we've started Gemba Systems we've realized the same thing. We no longer talk about Agile, or even software development, only project work. These skills are important for any team doing project work.
Although the Core protocols are free and pretty easy to understand (much easier the SFYH), I noticed that it is not so easy to implement them as long as you have not seen them in action. Some of these rules feel strange to use in a team.
It was not untill I have followed the Bootcap (Reboot To Team 2.0) I found the courage to use them in my teams.
I like it so much I started to Organize these camps in Europe.
If you can make yourself free from 24 till 28 February, contact me and I can make you a nice offer for the next camp.
Nice discussion. I agree with the importance of intrinsic motivation. And, of course, it is essential to every kind of team working, not just for agile. But, the emphasis here, is show that we should care about personal aspects of agility, more than the mechanisms (and the agile manifesto itself says that). Another article about this theme: here.
A note to managers of people: carrots and sticks only work when the subject is interested. Research (I'm no academic, but I read this in Good to Great by Collins) showed no correlation between executive compensation and results. People do what they want based on their values, not your values.
[Now that's off my chest] The matrix is a great way to model what I think about when discussing tools vs. 'people dynamics'. I worked as an Outward Bound instructor for years, and one of my pet peeves was the compass. I stopped issuing them to the groups - because as soon as we finished the 'orienteering training' groups would inevitably be 'led' by someone with Absolute Faith in the red end of the needle. I can tell you with 100% confidence that walking in the wilderness, staring at a compass, you will get lost - especially when the people at the back of the line (who are looking up and around) don't speak up and get everyone back on track.
Bad teams form easily enough when leaders hesitate. But throw a 'tool' in to validate the desire for a sense of control and you may lose the wisdom of the leader to the illusion of security and promise of a simpler solution that the tool suggests.
Definitely, if a team is going to change, the people need to change - not the tool. Often the same tools can be used in different ways...
How to change people? Change expectations, incentives (yes, carrot and stick but be broad-minded about these levers), policy - as a manager or leader, basically we must change ourselves.
If the PM starts standing in front of a wall with stories on it each morning and has the group gather to explain the answers to only 3 questions, we can assume the team will adapt. If the BA starts talking with cutomers along with programmers and testers to develop requirements, we can assume customer's attitudes will shift.
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
7 comments
Watch Thread Reply