Here is a compelling animated video from Daniel Pink on what really motivates knowledge workers. Pay enough to take money off the table; then focus on Autonomy, Mastery and Purpose. Leaders everywhere should take note.
As agility becomes more widely practiced, more people and organizations are giving it a serious look and we are seeing more of what Geoffrey Moore (Crossing the Chasm) would call the Early Majority starting down the agile adoption path. It is important that this new group of adopters have the right aim in mind. 
Agility in of itself is not the goal. I may want to be more physically fit, but setting that as a goal is not likely to make it so. Setting a goal to ride 50 or 100 miles in the upcoming charity bike ride event is more likely to be achieved. An agile adoption needs to start with some set of improvement goals. Want to improve the alignment between your business and technology groups? How about getting your products to market faster? Perhaps being more predictable in delivering your projects? Getting a better return for your projects? Maybe improving the morale of your teams and retaining your current employees longer? Launching an agile adoption to "become agile" is not likely to produce much in the way of desirable results. First we should set expectations. What are we trying to improve? What will we achieve by that improvement? How will we know we are making progress?
Similarly, the agile innocent tend to think agility only in terms of practices. They shouldn't. Agile adoption is not about swapping out practice set X for practice set Y. Agility is first about culture. It is a way of thinking; a mindset. I like to think of agility as a set principles and values coupled with any number of practice sets. An agile adoption is an organizational level change; we expect to change how people work and interact. It is traumatic and we need to be certain that the improvement gains we anticipate are worth the trauma.
Read more...With agile principles and values becoming more widely accepted at the team level, a natural conversation heard in the agile community today is how to move beyond that. How do we grow agile organizations and agile enterprises? What does an agile organization actually look like? Not surprisingly, the answers remain elusive. Agile teams vary greatly in makeup and practice, all the while respecting a common set of principles and values. We should expect the same for agile organizations so rather than looking for a precise definition we should observe some common characteristics.
Ricardo Semler’s Seven Day Weekend paints a great example without ever using the word agile. He describes his company Semco as a democratic organization where employees at all levels are engaged in all aspects of the business. From deciding their own jobs and salaries, to deciding what work to do, to deciding to open or close plants, to actively participating in board meetings. All information is made available to all employees and they are implicitly trusted to deal with it appropriately.
This sounds like an incredible fantasy compared to most of today’s corporate organizations where high structure and high ceremony rule the day and teams are engaged not so much to solve business problems but to complete predefined sets of work by prescribed dates.
Harvard Business Review describes another example (Building a Company Without Borders; April 2010 issue, reprint R1004K). The Reckitt Benckiser (RB) name is not the household name that its competitors Proctor & Gamble, Unilever, and Colgate are; but you likely buy their products and over the last decade they have handily outperformed their competitors even in the recent downturn. What is their secret? CEO Bart Becht identifies four keys for us.
Read more...
I've finally been taking the opportunity to try out the Pomodoro Technique that Tony Akins so ably explained to APLN Houston in March. I suppose the fact that it took three months for me to do this should have been my first warning sign. What I've found has been both enlightening and disheartening, and it has pointed out pretty clearly just how un-focused I can be with my own time when I don't have the obligation of meeting a client's needs and expectations.
Here is a pretty typical experience, this one attempting to write a new article for my blog:
- Started outline for the blog
- EMAIL ALERT! - have to see who sent me an email and if I need to reply
- Back to my outline
- TWEET! - oh, who sent a Tweet, oh that's interesting - have to follow the link
- Where was I with my outline?
- ARRF! - My dog wants out to bark at the cat across the street (not that the cat cares, which I think makes my dog bark more)
- EMAIL ALERT! - oh, got to answer a question about next month's APLN Houston meeting
- Now what was I doing? Oh, yes, here's my outline and where was I?
- Back into the groove, the outline is coming toget...
- ARRF! - My dog wants back in, he's tired of the cat now and the couch is looking pretty good
- Now to my outli...
- BRRIIIINNNGGG! - Pomodoro timer goes off, my 25 minutes are up
I can hear Venkat Subramaniam talking about shaving yaks now. I can even hear myself patiently coaching my Scrum teams about focusing on iteration goals. Email, IM, Twitter, office phone, cell phone, Skype, newsgroups, LinkedIn groups, Facebook, Gist, Plaxo, MySpace, HisSpace, HerSpace, MyDogsSpace… Isn’t it just amazing how all these productivity tools and gadgets actually sap our productivity? I have 5 work related email accounts, which does not include a client's email, and I monitor 6 more for the professional organizations I am either associated with or doing some work for. How much is enough?
The disheartening thing about all this, is that this is now considered normal, if not even desirable behavior. We slavishly react to those things that are really distractions at the cost of accomplishing something of longer term value. What's worse is that it is an exceeding easy trap in which to find ourselves in almost any corporate environment. Activity has replaced Productivity and we reward ourselves for it.
Ok, so let's try again.
Read more...
I was very pleased to see that the current issue of PMI's PM Network publication (May 2010, Volume 24, No.5) contains a couple of good articles on agility. In particular, Sandra Guy gets it right in her article Philosophical Makeover when she talks about agility being a fear-inducing paradigm alteration. She also goes on to discuss the fear factor in agile adoptions, shaping them to the adopting organization, as well as the need for strong executive support. Coming full circle the article concludes with the thought that armed with good basic practices and fundamentals such as PMI's own PMBOK and the Agile Manifesto, companies and individuals can learn from both ways of thinking to adopt what produces the best results for them.
For those looking to understand what the agile movement is all about, this article is a great introduction, and makes a great case that agility is more about culture, values, and mindset than any particular set of practices.
That makes it all the more unfortunate that the piece also includes the well-worn "Tip" that agile is not for every team or for every project. This clearly takes us back to the "agile is a set of practices" school of thought doesn't it?
Rising above the practices view, agility is about improving business outcomes by more directly interacting with customers to understand business needs, objectives and priorities. Agility is about engaging teams in ways that allow them to accept a shared accountability for achieving those outcomes. Agility is about taking small steps and assessing them to ensure that the work being done actually moves us close to achieving our goals. Agility is about recognizing that we do not live in a static world and that we should stop doing work as if we did. Agility is about shortened feedback loops that allow us to incorporate learning as soon as we learn it in order to improve the work we do and the way we go about doing it.
So in that vein, I have to ask. What team or project would not benefit from those things? On what project is it acceptable not to seek the best business outcome possible? What team would not benefit from validating the work it is doing actually solves the business problem they are trying to solve? What set of practices is so honed to perfection that we would not seek regular reflection and refinement?
I am puzzled by the persistence of these type of "not suitable for agile" comments. In reality is it not saying that we have discovered a new domain in which we don't yet understand what set of practices to apply in order to achieve the cultural and values based concepts that agility represents? Wouldn't we be better served by finding those practices, rather than retreating into "this project is not suitable for agility"?
- Agile2010 Experience
- The Power of Self-Organizing Teams
- Everything Super Talkcast
- Control is Not Evil
- That’s Not My Problem – and That’s OK
- What's a Manager to Do?
- Brian Marick’s Seven Years Later: What the Agile Manifesto Left Out
- Pollyanna Pixton’s Collaborative Leadership: A Secret to Agile Success
- Agility: What’s In It for Me?
- You Want That When?
- The Art of Burndown
- Agility: Its Advanced Citizenship
- Individuals and Interactions
- What is Wrong with Waterfall?
- Succeeding With Agile: A Guide To Transitioning
- The Role of Leadership in Software Development
- Requirements Truths