A few months back I stumbled onto some research done by Gallup on employee engagement quoted from above. I would like to say that their findings were shocking, but having been an Agile Coach at many large organizations, I find the statistics (and conclusions based on the statistics) to track quite close to my own experiences.
For example, Gallup found that only 30% of all employees in the United States are “engaged and inspired at work” and about 20% are what have been defined as “actively disengaged” employees who “aren’t just unhappy at work; they’re busy acting out their unhappiness. Every day, these workers undermine what their engaged coworkers accomplish.” The remaining 1 out 2 workers are defined as “not engaged” and “essentially ‘checked out.’ They’re sleepwalking through their workday, putting time — but not energy or passion — into their work.”
When You Have A Project Focus Coach: If we take some time to learn and adopt excellent software development practices … More "Are You Crazy?!" – Project vs Product Focus
I am often asked as an Agile Coach when I know that I have been effective at my job. The answer is simple- my work as a coach is done when the team in question is capable of being predictable.
And what, you may ask is predictable? For me it is a team that is capable of consistently delivering 90% or greater of points that have been planned for an iteration. I have given this capability a name. I call it the Gold Standard.
When you are an Agile Coach you sometimes must resign yourself to the fact that it will usually take team members awhile to get it and victories can be few and far between. One thing that I can recommend for a quick win and something that has worked well for me on multiple occasions (when it could be implemented) is something that I called office hours. I can only assume that I am not the one who invented this, but it is something that I “discovered” independently to solve the issue of resources being pulled into unproductive meetings when I needed them to be on task for our stories.
Like any professional should I spend a great deal of my time attending user’s groups, reading professional articles, speaking with leaders in my field, etc in an attempt to find ways to do my job better. This morning I stumbled upon a couple of interesting articles, The Unintended Consequences Of A Leader’s Lack Of Trust (whose link has gone inactive) and Employees leave managers, not companies. While not exactly writing about the love, these got me to thinking about love and its place fostering Agility.
It is the nature of my job to bond tightly with the teams that I work with and also to have to leave these teams frequently, as they achieve a high level of self organization, to pursue opportunities to help other teams. I am currently faced with one of these moments and the feeling, as always, is bittersweet. I am excited about my new opportunity but will genuinely miss the teams I have worked with over the past few months.
Continue reading Looking for Agile Success – All You Need is Love
In Daniel Pink’s bestseller Drive: The Surprising Truth About What Motivates Us, the author persuasively argues that what motivates people in the knowledge economy (of which software development is squarely seated) “is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world. ”
People are no longer motivated by the carrot and stick approach of past Tayloristic, manufacturing, assembly line business. What motivates new workers, and what has been supported by a wide range of scientific studies, can be summarized by the acronym AMP which stands for Autonomy, Mastery and Purpose.
As an Agilist, I am always curious why in one company an Agile implementation succeeds and in another it does not. While there are many reasons for Agile implementations to fail, one thing that many have in common is that they fail to take into account the three factors Pink describes in his book.
Continue reading Drive: The Surprising Truth About What Motivates Us and Why Agile Works
I had the wonderful opportunity to have a panel discussion recently regarding Agile. In my warped world, there is no greater pleasure than getting grilled on how Agile can be implemented in the real world. As such conversations are wont to do, a consistent theme emerged. In this particular conversation it was all about Trust.
If someone asked me to pick one word that could be used to describe a low functional Agile team versus a high functioning team, there are two words that come to mind – Discipline and Trust. Of these trust is probably the most important in that it can be hard to acquire, difficult to keep and easy to lose. As a scrum master, my team has to trust that I have their best interests in mind at all times, that the metrics I compile will never be used to punish them. They need to trust each other to be able to commit to a body of work for any particular sprint, etc.