The Agile Manifesto states that individuals and interactions are valued over processes and tools, yet there is much more written about the processes and tools involved with Agile development than there is about individuals and interactions. Individuals and Interactions – An Agile Guide sets out to remedy that issue. Today we talk to co-authors Ken Howard and Barry Rogers.
SSQ: Your book discusses best practices for strong communication, teamwork and leadership. However, aren’t these principles true regardless of which software methodology is being used? Wouldn’t the lessons in this book hold true for any software development effort or even any team?
Ken Howard/Barry Rogers: The lessons in the book absolutely apply to any software development effort or any team for that matter. Agile itself is not revolutionary. Agile recognizes the importance of communication, teamwork, empowerment, trust and leadership on software teams. It also recognizes the importance of iterative development and responding to change. These concepts are not new. Most of the lessons in the book could apply to any team – regardless of whether it is a software development team or a team cooking meals in a restaurant.
Agile is a set of values and principles. It is not a process or a methodology. I am not sure how many times I have heard Agile being compared to Waterfall. I am not sure that comparison makes sense. I can see iterative development being compared to
Requires Free Membership to View
Waterfall
development. Perhaps I could see Agile being compared to command and control leadership. Since
there is so much emphasis on the benefits of iterative development when discussing Agile, we felt
that a book that focused more on the values associated with the team was important. These values
and the lessons in the book can apply to any software development team regardless of process and
could generically apply to any team.
SSQ: Is it a requirement of all Agile teams to work as self-directed teams? Even the Agile Manifesto does not mention teams, but rather talks of individuals and interactions. Many people are more productive working individually. Why is there so much emphasis on self-directed teams in Agile development? Do you think the word ‘individuals’ should be changed to ‘teams’ in the Manifesto?
Howard/Rogers: The word interaction means that individuals must communicate effectively which implies teamwork and collaboration. A team comprises individuals who are all different. Diversity is not only good, but it is also necessary in order to have the most productive teams. So, I rather like the phrasing of the Agile Manifesto stating, “Individuals and interactions over processes and tools.”
Even though people may seem more productive working individually, having people work in isolation simply would not work for complex systems requiring expertise from a variety of individuals. Communication is a must, and the wisdom of crowds suggests that the team will build a better product than any individual. Therefore, although delays caused by interacting with others can be frustrating, if they lead to a better solution sooner, they can save a lot of time down the road.
Regarding whether it is a requirement of all Agile teams to work as self-directed teams, I
believe empowerment is one of the most important values in a highly productive team. This is also
one of the main tenets of Lean. Without self-direction, “waste” is introduced while waiting for
direction. It is necessary to establish an environment in which individuals on the team feel they
have real influence over how they meet their commitments. Self-direction is one of the key
attributes that enables a team to work swiftly, responding to changes, and successfully meeting
their sprint commitments. The short answer is, yes, I believe self-directed teams are a requirement
for an Agile approach.
SSQ: The book talks in detail about DISC analysis as a tool to determine the behaviors and
communication styles of team members. I’ve seen Myers/Briggs used similarly. While it is true that
understanding each team member is beneficial to communication, certain Scrum rituals will be
uncomfortable for ‘C’s (Critical Thinkers) in the DISC model and ‘I’s (Introverts) in the
Myers/Briggs model, both traits that are common in software engineers. If a team has primarily
‘C’s, they may opt out of performing those rituals. Would a good Scrum Master encourage or
discourage a self-organizing team who felt the Daily Standup was unnecessary?
Howard/Rogers: A good Scrum Master is a master of Scrum and should encourage the team to perform the daily standup meeting as part of the Scrum process. For a brand new team unfamiliar with Scrum I believe in the Shuhari concept (from Japanese martial arts). That is, when the team is first learning Scrum, they are in the shu phase, where they should repeat the steps as they were initially created, remaining faithful to the process with no deviation. Next, in the stages of ha and ri, the team can depart from the process after they experience and internalize the values of the Scrum components. I have not met a Scrum team yet, after going through a correctly-executed daily Scrum meeting for at least one Sprint, that did not recognize the value of the daily standup meeting or that wanted to abandon it. If there would ever be a good reason, then I think an experienced team should be able to self-organize and create a different mechanism that provides the same benefit as the daily Scrum.
This interview is continued in:
Agile is a culture, not a process
Join the conversationComment
Share
Comments
Results
Contribute to the conversation