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?”
My exploration of “Starter Agile” practices through the lens of Joshua Kerievsky’s “Modern Agile” concludes with this final group of three practices: standup meetings, task decomposition, and cadence-driven retrospective!
Disclaimer: this is my favorite set of practices to critique! Let’s dive in! Continue reading
An exploration of “Starter Agile” practices through the lens of Joshua Kerievsky’s “Modern Agile” continues with: burndown charts, product backlogs, and user stories. Continue reading
After sharing my thoughts on the insights Josh Kerievsky offers us through the lens of “Modern Agile,” I had a few readers request some insight into why I selected certain practices as “Starter Agile.” The comments walked the line between curiosity and concern, the latter being something I want to help alleviate.
Over the next three days, I’ll discuss nine practices and concepts that could be considered outdated as people continue to learn and experiment with Agile. I argue these topics have transitory value for brave folk learning Agile; a good place to get started… but others have discovered better ways exist.
Today’s first set of practices: timeboxes, story points, and velocity. Continue reading