“Agile Coach” is a made-up thing. I’ve met countless people who hand me a business card with “Agile Coach” on the front. I have worked with stables of coaches from consulting organizations. I’ve lost count of the number of “Agile Coach” job descriptions I’ve been asked to review. Describing the responsibilities, behaviors, and activities of “Agile Coach” often varies among people. And in my experience, asking management to describe how the role delivers value to people comes out vague and equivocal. I’ve observed the role tends to be about “driving” things (process, training, change) and, speaking as someone whose career has primarily been this very title, often does more harm than good.
Could you imagine what the human body would be like if each organ in the body were incentivized and managed according to separate role-specific criteria?
Perhaps we want all our body parts to pull their weight and be productive. The heart may be encouraged to increase its beats per minute by 15% day over day. Your poor eyes might be measured on reducing blinks to ensure more constant sight. The stomach could be subject to any number of possible scenarios – keep up the flow of digestion with less stomach acid (“do more with less!”) or ramp up productivity by creating more acid (“100% utilization!”). Just think about how your lungs could be subject to performance management! What a mess it would be… the human body would be so out of sync you might even question if it could remain functioning. No need to wonder; when we manage the body this way, the results are catastrophic.
If the detriment to complex systems is evident in managing parts, why do we similarly manage our companies to the tune of “Role Success”? Continue reading
Annie looked down at the table and softly said to her fiancee, “I’ve never been this nervous, or excited, about a job.” Sitting on the table was a package from the company she had been interviewing with. The interview process had been unlike anything she’d ever experienced; she felt fairly evaluated, trusting of the company mission and values, and she knew the company was a perfect fit for her. The day prior, the company informed Annie she would receive a package–the very package on her table–and would contain everything needed: the company’s hiring decision, feedback, and other insights from the hiring process.
Annie took a deep breath and opened the package. Continue reading
Have you ever been asked to work with a team, then observed team members interacting with each other, well… never?
The desire to transform an organizational culture to one inspired by teams is understandable. There is no shortage of evidence, both anecdotal and scientific, which suggests teams (and teamwork) are a competitive advantage. The desire for such results through the use of self-organizing teams has led to the popularization of teams as a common organizational design.
What I’ve found in my career, however, is a tendency for organizations to both manage and incentivize teams like a “matrix” (of individuals) despite the assumption or label of “team”. The net effect is predictable: silos within teams. Research has shown my experience to be prevalent and related to inattention of cause-effect relationships between people and their environment, plus absent knowledge of base conditions which invite teamwork (Devine et al., 1999). Continue reading
I enjoy when people contribute their knowledge about agile software development to other humans living on planet Earth. The wisdom I’ve gained from such mentors aside, I think it’s terrific people are passionate, engaged, and excited enough to share their insights with others. As the most popular way to put agile values and principles in play, Scrum is arguably the subject most frequently written about in the agile community. Again, these articles and discussions about Scrum (and inferences about agile) are intended to assist, educate, and inform others in improving their careers and/or perspectives. This is terrific, too. Unfortunately, much of what is written tends to be misguided, misunderstood, or flat-out wrong.
With respect and kindness for all those who take time to contribute, especially those cited as examples of problems, I’d like to share some truths of what Scrum is, what it isn’t, and how you can improve as a practitioner. This isn’t an all-inclusive list; just a handful of topics which I see misrepresented often. Continue reading
Two years ago, I wrote the following blog post discussing my general dislike for the Open Space conferences I’ve attended. While I attempted to convey a logical reason for my feelings—and how I propose a remedy—the post sat in my drafts list for concern of upsetting folks, or generally coming off as an incoherent rant.
Recently, I’ve observed a few folks I admire state concern over the prevailing use of Open Space, as well. This has given me courage to add my voice to the mix, as I believe Open Space conferences really aren’t. Continue reading
You’re sitting in the director’s office with a nervous feeling.
“So, about those agile metrics I asked from you…”, she says. Your stomach churns and pulse quickens.
How will you show the progress of agile transformation? How will you measure improvement in teams and people? And how will you avoid the trap of shallow metrics like say:do ratios and velocity?
I’ve written a post in collaboration with Derek Wade to share a wonderful retrospective technique I learned from him. The “WADE Matrix” is a simple design to help retrospective participants identify opportunities for improvement, as well as see the cause-effect relationship of the system (beyond the team). This retro format has been my “go-to” method for new teams, new facilitators, and anyone interested in systems thinking.
Colleen Johnson, co-founder of ScatterSpoke (a highly recommended digital tool for facilitating retrospectives), has kindly hosted the article on her ScatterSpoke blog. You can learn about this retrospective technique by following the link below – enjoy!
At an agile gathering in St. Louis a few years ago, I learned a pretty nifty game/simulation to help people (especially those unfamiliar with programming) learn basic concepts of TDD. Taught by the ever-so-sensational Amitai Schleier and Mark Balbes, I’ve been meaning to write about this for more than a year. Thanks to a curious member over at the Agile Uprising forums, I finally put it to words. With all credit to Amitai and Mark, this fun little simulation is a good addition to your mentoring toolkit. Continue reading
It was Monday afternoon on her first day of work at a new company and Sarah was feeling anxious. Having studied Scrum over the last few months, Sarah had been hired to serve as a Scrum Master and she was eager to begin applying her new skills, however nothing she had been told today seemed congruent with her lessons. As Sarah listened to her new manager explain why the company’s software required the organization to field a “UI team,” “service team,” and “back-end team,” she felt especially troubled by the phrase she’d heard multiple times on this day: “No one does Scrum by the book.”
“If no one actually follows the design of Scrum,” she wondered to herself, “why did my Scrum trainer teach it to me?”