I’ve noticed a piece of advice repeated in many Agile blogs, articles, and books.
Seeing it makes me roll my eyes until it hurts. (Why I would hurt myself on purpose will be the subject of another post, on a blog reserved for psychotherapists.)
I saw it in Jim Highsmith’s new book, too, although by the time he’s done discussing it he does make a couple of good points. It’s an old piece of advice that pre-dates Agile.
What is this old chestnut? Here it is:
Hire the best.
I mean, come on. Is this supposed to be a big lightbulb moment? Where do they find stuff like this, in the “Journal of the Totally Obvious?” Am I supposed to leap out of my chair, smack my forehead and exclaim “Eureka! All I have to do is hire the best! Why didn’t I think of that?”
Is this really good advice? Is it actually possible, or necessary in an Agile world? Is this sensible, if trite, piece of advice useful at all? Talk amongst yourselves while I blather on for a bit.
The problem with “Hire the Best” as an operational principle is that:
a) it immediately excludes most of us, and b) it’s extremely difficult to do.
What’s the best? The top 5%? 10%? Certainly no more than 20%.
So what about the rest of us? What are we supposed to do? Are things hopeless for us? Should 80% of companies worldwide just give up and shut down because the top 20% of people are taken? What about big companies and the Law of Large Numbers? Can you really hire only the best when you’re hiring 10,000 or 20,000 people?
Something that makes much more sense to me, and which has much more power, is this idea:
Hire well, and develop people.
Check it out! Everybody can do this. “Develop People” is one of the two pillars of Lean, while “Hire the Best” is not. So far, those Lean folks have been right about pretty much everything, so why not this, too? Why would I need to develop people if I only hired the best? Why not save the money so I can pour it into my “Hire the Best” employment initiative?
The Agile Principles say something like […find motivated people and trust them…], and I believe in Agile. So I cannot find in the bedrock of either of my professional beacons, Lean and Agile, any indication that I should “Hire the Best”.
My common sense and experience tell me that it is incredibly hard to actually hire the best, and I like that it might not be absolutely necessary for success. How cool would it be to hire the ‘pretty good’ and then kick the butt of some company that thought it was hiring the best? Is that possible? Yes.
“Hire the Best” is really hard to do.
I’ve worked as a full time hiring manager at more than a dozen companies, all of which thought they hired the best and only one of which actually did. That company really worked hard at hiring the best. At that company, one rule of the hiring thumb was that you only hired people onto your team who would immediately place in the upper 50th percentile.
In other words, when you were on an interviewing team in that company, you were expected to vote to hire somebody who was better than half the people on your team. You think that’s easy? You think that isn’t scary? Try it sometime.
What I’m really really really interested in is something that can take my average team (and let’s face it, Ms. Wishful Hiring Manager, it is overwhelmingly likely that our team is average, for some value of average) and make it better or improve its ability to deliver value to my customers. That’s worth some effort to achieve because it is worth money to my business. If I believe in “The Art of the Possible” then I like this better, because it’s a lot more possible than simply hiring the best.
Anybody can embark on a long, expensive and likely unachievable quest to only hire the best, but if Agile were really valuable, it would help me to take my team of competent professionals and make them significantly more effective than they were. It might even make them more effective than a gaggle of “the best” somewhere else.
The Agile Principles talk about motivated people, but they don’t actually mention “the best”. I view this as a good thing because I strongly believe that the best teams are not built from a homogeneous mix of the smartest, fastest, bestest people.
Teams work best when they are diverse and when the power of the team can be unleashed by empowerment and self-organization. I also know from bitter experience how hard, and frankly scary, it can be to really hire the best. (Sorry if I harp on that, but I have scars…)
What I want is what I think both Lean and Agile offer to me as a businessperson. They offer me a way to take solid professionals and then ignite their passion and professionalism within a framework of continuous learning in a way that allows them each to contribute to the fullest extent possible.
That’s something that make Lean and Agile worthwhile to me, and not some lazy idea about hiring the very best (somehow) and then automatically winning.
About the Author: Alan Atlasis a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
“It took me more than 53 years to understand that culture isn’t just important, it is everything.” -Lou Gerstner
In the coming decade, software and product teams must provide the critically needed innovative approaches to organizations throughout the world. The visual metaphors and practical, hands-on ideas in these posts will give executives, managers, and engineers ways to speed up this evolution. Starting on Monday.
To make and maintain a culture of innovation requires a team to consider that task as a part of their work, complementary to, and as important as, the commercial task. Work on the culture must go forward during the workday. We’ll suggest, for example, that you include a warm up as part of the daily stand up. The team leader will lead this at first, but when it has become part of the routine, leadership will rotate among the group. Team members who learn a new exercise somewhere else will bring that to the stand up. You won’t tack this on to the day as something extra: it’s central.
As well, on analogy with the public schools, an executive or team leader might propose in-service learning requirements. Normally schools don’t require that teachers take specific courses. They demand instead a required number of course hours per year or other interval. Such courses include learning new techniques applicable to the work at hand; but, more important, they can be general—education rather than training.
Google is only the most well known of modern corporations to suggest that workers spend up to 20% of their work time on personal projects. Google encourages personal projects that have no readily discernible connection to current work, and imposes no requirement that such projects result in marketable outcomes. Now and then, of course, they do. And they’re a main reason why the competition has such a problem keeping up with Google. Not even Google knows what the next thing will be. More important, they serve as practice in innovation: people discover and refine their skills in a no-stress situation. They are free to be wildly creative.
In colleges and universities a similar situation obtains, though with considerable pressure attached at certain times in a professor’s career. We mean the custom called “Publish or Perish!” To achieve tenure or to be eligible for promotion, a teacher must make a contribution to the field. Mostly this means publishing the results of research.
Some places, Harvard Business School among them, grant tenure only to men and women who have achieved an international reputation within one or more fields. While this requirement weighs heavily on young faculty, the purpose is clear: research offers faculty an opportunity to practice the skills they teach.
More important, though less observable, accumulation of knowledge beyond what’s needed for tomorrow’s class supports a career after the initial thrill of teaching wears off and interest wanes. Of course these are ongoing programs; they have their true effect over the long term, as they become embedded in the company tradition and in an individual’s sense of work.
But, you say, “How do we have time to do this?”
Turns out that a reasonable amount of time spent in these pursuits increases productivity. When Frederick Taylor began his time and motion studies of workers shoveling coal at the steel mill, they balked at his requirement that they take breaks on a schedule he devised. They were paid for piece work, and feared that Taylor’s breaks were a management device to reduce their paychecks. Taylor insisted, and the workers discovered to their amazement, that their pay went up noticeably.
This notion of pay for story points has not caught on in the software field.
Many folks in the Agile community would argue that Agile is all about culture change. As you know, we do not see Enterprise Agile adoption as solely about anything. For most teams it starts out as a process change, runs headlong into weak testing technology and then confronts some major cultural elements as the scaling or replicating come into play.
Our Flow-Pull-Innovate approach can be mapped into a state transition diagram that blends changes on all these fronts. It is our experience that teams neither have nor take time to appreciate these cultural items until they have shown some improvement. At this point, it becomes easier and paramount to reinvest some of these gains into continuing the journey. This can be in the form of slack time, schedule time for innovation, or new infrastructure in building, testing, or planning.
Now once teams get to the benefits of pull at a program level, the focus of adoption needs to move towards organizational culture. I believe the transition from traditional to Agile, involves quite a shift in infrastructure, methods and guiding ideas. The awareness for the changes in Guiding Ideas seems to come primarily from bottom-up adoption or occasionally from a new senior level executive who was brought into drive change.
Making changes of the magnitude we’ll suggest won’t be fast and easy. If you want to move fast, you’ll want to get help. This can be tricky. Consultants are typically a quick-fix; this won’t do in the long-term, but they can help with a push. However, a culture lasts, and work to create and maintain it should last as well. The consultant’s techniques stop lasting all too soon. We suggest that you find ways to learn about companies and teams that can become role models. This can be difficult. You’ll need to take time to build ongoing relationships of trust and reciprocity.
You can also consult people who routinely work in a culture of innovation. These include (but aren’t limited to) three groups.
(1) Actors make a new thing each night they perform the play, and their rehearsal processes are a compendium of good ideas for innovative agile teams.
(2) Theatre directors are a great source of method and lore for team leaders in an innovative culture. They every day address the difficulty of supervising men and women who have skills that they do not. They can’t bark out orders, but must find ways to encourage constant innovation.
(3) Painters (not house painters) in their work interact with an emerging form, the key element of collaboration, as they create a new and unique thing each time they make a picture. They can be especially persuasive and helpful on the question of replication: since they can’t do it (Every painting they make is new and unique, even if they try to copy themselves.), they have developed views and attitudes that software development teams and their leaders can use to advantage.
We remember a teacher who told his classes, “The way to improve your writing is to apply the seat of your pants to the seat of your chair.” The way to get started is to get started. Make the commitment. This can be a top down or bottom up movement, but support from above is key to a good beginning and to ongoing success. The budget for subsequent projects should include time and funds for preparation and team building of the kind we’ve described. Team leaders and managers should commit to constant reinforcement of the aim, and to vigorous support of performance by individuals and particular teams.
Keep an eye out for upcoming posts on this theme, where we will cover many of these concepts in greater detail. But, as always, your feedback in the form of comments would be tremendously valuable in shaping our ultimate path and conclusion.
An Introduction to Lee
Jean and I, along with other Rally coaches write on the concepts of Agile Enterprise Adoption and our recommended approach called Flow-Pull-Innovate; however, most of that copy has been dedicated to the first two states of Flow and Pull.
Personally, I have struggled to write about Innovate because our language seems to be all-wrong. So we recruited a friend to help, his name is Lee Devin. With Lee’s help we are going explore the state of Innovate with words and stories that will help us understand this advanced state of Agile adoption. There are a number of topics that we have discussed in this collaboration and we plan to share all of them through this first quarter of 2010 (see How to Foster a Culture of Innovation)
Lee fishing in Colorado's 11mile Canyon
I met Lee Devin through my next door neighbor Gordon Wickstrom. Lee was a colleague of Gordon’s in theater and a fellow fly-fisherman. Gordon is an old school theater professor, he believed in structuring the performance to give the actors a place to create. He like Lee has a passion for his craft and feels absolutely fortunate to have been able to work in the theater profession his entire life. Gordon and I have shared many a lively conversation about theater and software and it was one of those conversations that led me to Lee.
According to Gordon, Lee has a more creative approach to theater development; one that is more emergent than Gordon’s. After numerous professional interactions and three fishing trips, Lee and his family are good friends. And his son, Sean has got to be one of the best anglers on the planet; fishing with him is like fishing with Yoda.
Now into Lee’s book with Rob Austin, Artful Making. This book blends Rob’s research into innovation and agile product development with Lee’s mastery of theater; it is a real joy to read. It conjures up some of my best memories of creating beauty and greatness in software. Their contribution to our profession is to help us break our mental models or metaphors around the work of software development. You can let go of your mechanical metaphors and let Lee give you a complete vision of software as a creative and messy design process for conjuring up real beauty and innovation. After a fishing outing last summer in Boulder, Jean and I had breakfast with Lee and decided to collaborate with him on work around the topic of innovation. You can read Jean’s words about Lee and Rob, in her post “What do Actors and Programmers have in common?”
Recently, I was working on an introductory presentation about Kanban. A “thorough” Google search revealed how drawn out and convoluted many Kanban explanations can be. Was there one true answer I was missing? Something nice and succinct like, say, a tweet on twitter?
Acting on this and laziness, I decided to pose the following question to twitter:
I was so surprised by the number of great responses that I’ve decided to compile and share them with you here:
giff24:#kanban 130 chrctrs? PLS!!! I dnt hve time or patience 2 rd that much
erwilleke:#kanban combines systems thinking with a work-limited pull system to allow rapid maturation of teams and delivery of software.
davenicolette:#kanban “What 100-130 characters would you use to describe Kanban?” I’d use the cast of _Who Framed Roger Rabbit?_
knoxgourmet: Kanban is Scrum without the mess, no sprint planning, no midrange planning, no MSG headache.
kjscotland: Map the value stream, visualize, limit WIP & establish cadence. Reduce WIP to improve flow of value and individual fulfillment
agilemanager: #kanban visualize flow & limit WIP to encourage evolutionary change towards a lean outcome & high maturity culture
Sprezzatura: First establish your value stream. Next limit your work in progress. Then visualize & learn from your workflow. #kanban
most_alive: . #kanban: value flows, post-its move, step,step,step, workers unite
neontapir: Kanban uses visual signals to track and optimize work delivery through key stages in its lifecycle.
I like the commonalities around value, visualization, limited WIP, pull systems, cadence, and flow. This tells me that Kanban is speaking a common and useful language to a lot of us. And, its value can be articulated in a tweet.
But my quest goes on!
I encourage you to add to this list by submitting your own 130 character Kanban definition either as a comment to this post or as a tweet to me (@jeantabaka and use #kanban in your answer.)
In April, I’m attending the Lean SSC conference in Atlanta. There will be a lot of discussion about Kanban. I’ll personally carry all comments and tweets to the conference for inclusion in the discussion. If you’re able to attend, let’s stretch the envelope and go beyond 130 characters on Kanban.
Dan describes how the Agile impact in software is similar to the Lean impact in manufacturing of the 90’s. I initially struggled with the analogy until I realized he is not saying that software development is like manufacturing. He is saying that the concepts and techniques applied in Lean manufacturing are coming to large-scale software development.
I completely agree and believe the model of how we build software is changing just like Dan describes. Using the model from the Fifth Discipline Fieldbook, the change looks like this:
Lean Software Concept
That was a great decade – I see much of the last decade of improvement coming from a real effort to take responsibility for how we perform our craft. The ground up work in Agile, Scrum, XP and Lean has increased velocity, increased quality and increased the quality of life for many in our industry. I am personally in a much better working environment; how about you?
So what’s ahead for 2010?- With Agile software development hitting the mainstream, the guiding ideas on how to design and deploy software is changing for most software driven organizations. As more teams and organization make the transition to the Agile/Lean triangle, I see us increasing our investments in skills training, teaching, experimenting and innovating with an increasing number of new tools, techniques and methods. As a result, I see this decade moving us past the Lean models of Toyota to something uniquely our own. I am really excited about the improvement this decade could bring to our industry and all the industries that we impact with our software.
I have been back in the Fifth Discipline Fieldbook this week thinking about strategies for creating a shared vision to 2020 at Rally.
With our newest round of funding, we will be growing rapidly in multiple locations and beyond the max tribe size of 150-170 people. (Dunbar’s Number) Over that last year, we grew the business well but without advancing our total headcount numbers. Now with headcount growth slated in the field and in two development centers, we need a stronger foundation to steer our growth. Doing this work, hit me with a BFO (Brilliant Flash of the Obvious) that is impacting many of largest Agile adoptions that I am working with.
Many leaders are seeing the benefits of Agile and “Telling” or “Selling” their organizations to go there. But, the “Telling” and “Selling” strategies run counter to many of the guiding ideas behind Agile itself. I have seen this rub limit or slow the positive impact of an Agile adoption. This rub almost guarantees you will only get incremental benefits from Agile and will most likely fall back to your old ways.
As Bryan Smith and Peter Senge remind us “Telling” is just the first developmental step in creating a shared vision to adopt. This strategy has many flaws including that fact that most people only remember 25% of what they are told. However, it might be the right strategy given a dire current reality.
In extreme contrast to Telling, is the Co-Creating strategy that has the whole organization working together to create the vision and implement it. This requires a leadership group that can truly let go and an employee base that has enough personal mastery to understand their own personal vision. Those are big pre-requisites to this strategy, but it should be obvious that if you can run this strategy, the self-motivating benefits will be highly supportive to getting the most benefit out of Agile.
The complete model, from the Shared Vision section of the Fieldbook includes five strategies that can be grown into over time:
Telling
Selling
Testing
Consulting
Co-Creating
We have discussed our Flow-Pull-Innovate approach for adopting Agile in larger organizations, but I have talked very little about strategies for leading this adoption process. I think it is because most Agile adoptions get started in a grassroots approach and are led by the teams that testing it out. The success of these teams then caused people to take notice and start talking about how to replicate this success. In essence, I have been assuming, and the market has been executing a Testing level strategy.
I believe to put an organization on the path to continuous improvement, you must at least be executing a Testing level strategy to scale your adoption. Over time, I believe your ultimate ability to move to the Innovate level of Flow-Pull-Innovate will be tied to your ability to adopt a Consulting or Co-Creating strategies. As Agile is a journey to greatness, this journey depends upon your organization maturing in all including strategy execution.
What are your experiences with these strategies in your Agile adoption?
At Rally in 2010, our planning team is running a two pronged approach using a Testing strategy with the organization in Q1 for our 2010 plans and a three quarter long co-creating strategy for our 2020 vision.
Over the last several months, I led four breakout sessions on Agile quality at our Agile Success Tour and in the process I heard these troubling comments:
“We don’t have enough time to test, because the developers give us working builds way too late in the cycle.”
“I wish our quality was better, but it’s out of my control to change anything.”
“Poor quality must be our fault as testers, since we are the ones responsible for testing.”
“We should test more, or we should develop slower, or we should specify our requirements better – that should improve quality.”
Agile development advocates that the whole team owns quality, but clearly many teams face barriers to accomplishing that goal. I’ve been thinking about these comments a lot lately, and I think the problem is that basic and predictable human responses are getting in the way of achieving higher quality.
You can certainly improve quality through changes in process (and many of those changes are at the center of Agile adoption), but more often when people ask me process questions, I hear teams struggling with the human aspects of those process improvements. By paying attention to the ways everyone naturally avoids responsibility, you will be able to move past the barriers that contribute to poor quality.
The best model I’ve seen for how to do this is Christopher Avery’s Responsibility Process. The basis of this model is that when problems arise, every individual goes through a very predictable series of thoughts that allow him to cope with what just happened, but also block him from moving into a mindset of learning and improving.
It starts with blaming someone or something. When you move past blame, then you justify the event with a story you tell yourself. Once you move past that story, then you turn the blame to yourself and feel shame. Acting on that shames often leads to feeling a sense of obligation. If the shame and obligation become too unbearable, then you will quit or detach to escape from those feelings.
All of these thoughts prevent you from taking responsibility and ultimately moving into a mindset of learning and acting. Sound familiar?
This same pattern subtly plays itself out every day for you and your team around you, especially with issues of quality. According to the Responsibility Process, there are three keys to taking responsibility: (1) intention, (2) awareness and (3) confront.
To learn more, I encourage you to join me and Christopher Avery for our January 12thOn Demand webcast, The Best Kept Secret in Agile Quality, where we will talk about:
the relationship between quality and ownership
the difference between accountability and ownership, and how this difference affects quality
how the Responsibility Process can be used as a framework to continuously improve quality through a focus on people and interactions
how to apply the Responsibility Process to your development team
About the Author: Zach Niesis a golfer, expert on Agile quality and VP of Products at Rally Software Development. Subscribe today to get free updates by email or RSS.
RallyDev.com
It 
