One of the most common problems I observe in Agile teams is their inability (or perhaps unwillingness) to "swarm" on difficult problems to ensure an adequate solution. When I use the term “swarm,” I’m referring to multiple people working jointly to solve a single problem. Too often teams suffer from fuzzy logic, thinking, "Let's divide our resources to conquer the stories in this sprint more efficiently."
Famous Last Words
Fooled by Randomness
Is software development a science or engineering discipline in which we can strive for perfection? Are perfectly executed software plans possible in today's market?
Feedback Driven Release Planning
It's been a while since my last article and that's because I've been busy as the Product Owner for Danube's ScrumWorks Pro product. That means I've learned a lot and I'd like to share one of the biggest lessons I've learned about the importance of feedback in release planning.
Hierarchial Requirements and Scrum
As the Product Owner of ScrumWorks, I'm often asked why ScrumWorks does not support hierarchical nesting of backlog items (i.e., user stories, PBIs, etc.). The answer is simple but highlights some profound differences in the way requirements are managed in Scrum and Agile as opposed to other methods.
Complexity Theory and Scrum
In this article, I try to shed light on the roots of Scrum as based in complexity science. Scrum is a framework designed to harness the benefits of "self-organizing" teams. But what does "self-organization" really mean, where did it come from, and why would it work in the software industry?
First and foremost, I'm not a complexity/chaos theory expert, but I find the subject fascinating and have done some light reading on the subject. But I'm finding that reading even pop books on complexity really help me understand the underpinnings of why Scrum seems to work so well for many organizations. As a primer, I recommend the book Surfing the Edge of Chaos which provides a business-centric overview of complexity and chaos theory, with a handful of real life business case studies.
First and foremost, I'm not a complexity/chaos theory expert, but I find the subject fascinating and have done some light reading on the subject. But I'm finding that reading even pop books on complexity really help me understand the underpinnings of why Scrum seems to work so well for many organizations. As a primer, I recommend the book Surfing the Edge of Chaos which provides a business-centric overview of complexity and chaos theory, with a handful of real life business case studies.
The Mythical Part-Time ScrumMaster
My colleagues and I work with a number of organizations implementing Agile and Scrum. We are starting to see patterns (and anti-patterns) emerge in the way in which many companies go about transitioning their products to Scrum. Two of these patterns are particularly disturbing: the bored, part-time ScrumMaster and permanent acceptance of the status quo. In this article I will demonstrate how these two anti-patterns weigh organizations down and ultimately lead to failure during Agile transitions. Moreover, we've consistently seen a positive correlation between successful Agile transitions and organizations that take the ScrumMaster role seriously.
Simple, But Very Hard
Ken Schwaber's comments in this scrumdevelopment thread are fantastic; we need to keep in mind that Scrum is a set of principles, not a call to follow a brainless list of processes.
I like something I heard Ken say during his course: Scrum is simple but very hard to do. Then he proceeded with an analogy to chess. We can all learn chess moves in a few hours, but mastery of the game takes a lot more.
So what does it take to be successful at a game like chess? I have some insight into this because much of my family plays chess, some even competitively.
Just Do It
In my last post, I described how Agile methods aligns individual and organizational goals by focusing people on their responsibilities in getting product out the door. This post explores a particular role that has all but vanished in traditional phased projects: product management.
"I don't care what it takes, this needs to be done by the end of the quarter. I don't know what you expect me to do, you're the programmers!" Sound familiar?
"I don't care what it takes, this needs to be done by the end of the quarter. I don't know what you expect me to do, you're the programmers!" Sound familiar?
Alignment of Individual and Organizational Goals
Individuals within organizations are motivated to work toward goals that ultimately result in increased compensation, promotion, and peer recognition. Most often, however, these individual motivations are not directly aligned with the organization's broader goals. The negative consequence is that while individuals in the organization strive toward personal motivations, very few people, if any, are directly concerned with the organization's ultimate aim: delivering products and/or services to market.
Practices Without Principles, TPS Without the Toyota Way
I've been reading about "lean" as it relates to the roots of Agile software development, specifically the creation and evolution of "lean thinking" at Toyota as described in The Toyota Way by Jeffrey Liker. The book emphasizes an important dichotomy:
- the practices and techniques used by Toyota termed the "Toyota Production System" or TPS (just-in-time, kanban, one-piece flow, etc.) as distinct from:
- the principles and philosophy that permeate the organization he calls the "Toyota Way".
