Angela Harms recently blogged about the Agile Retrospective Prime Directive. She discusses how the language of the prime directive around "everyone doing their best" could be seen as patronizing and insulting to team members. Other commentators who have discussed the intent of the Prime Directive include Esther Derby and George Dinwiddie. How useful is the Retrospective Prime Directive?
The Scrum Master job requires skills in diplomacy-- and effective communication. Team members must also communicate effectively. Tools for accomplishing these "soft-skill" tasks are now freely available. A detailed book about one of these useful tools entitled SOFTWARE FOR YOUR HEAD, is over 400 pages in total, and is now available-- free to the world in PDF format.
Agile has always stressed the need for an appropriate physical space to support the team and team practices. Ryan Martens recently wrote about the intersection of design, design thinking, and the agile environment - suggesting that open space and wall-to-wall whiteboards are just the beginning of what is needed to create an ideal agile team-space.
Cross functional teams are the teams in which all members work on delivery of the same business value. It could potentially be the same feature or the same product. Though, Agile recommends cross functional teams due to a lot of inherent advantages, there are some caveats that organizations need to be aware of.
This is the second in a series of discussions looking at factors that enable Agile teams to be successful. Diversity of gender, culture, opinion, perspective, skills and background is considered to be an important factor in forming and persisting high-performance teams. This news item examines the perspectives from variety of commentators.
This is the first in a series of discussions looking at factors that enable teams to be successful. This post reports on a recent Wired magazine article that looks at the creative process in use at Pixar Animation Studios and how their process encourages team formation, long-term relationships and trust in a “safe to fail” environment.
Agile projects are (should be?) highly collaborative team environments built on a foundation of trust and open, honest communication. Such collaborative environments don’t just happen, and they can be easily disrupted. There are many commentators who provide advice on how to establish and maintain collaborative teams. This article summarizes the advice from a few of them.
Change is constant, yet people fear change. It is mostly the fear of unknown and loss of comfort zones that makes the perception of a change painful. Though Agile teams are well prepared for change, however most of them are not comfortable when the change affects the team.
If the consolidation and integration of elementary Agile practice is ending, that means something new is starting. Does a new phase of innovation lie just ahead? Where is the edge of the new Agile frontier? InfoQ looked at the research of Michael de la Maza, an agile coach and trainer who is researching controversial topics such as intimacy in teams and organizations, to learn more.
Rashina Hoda is a PhD researcher who has been examining how self-organization actually happens on teams. She has studied teams in New Zealand and India and identified six distinct roles that emerge when teams effectively self-organize. She spoke to InfoQ about her research, which will be published at the International Conference on Software Engineering (ICSE2010) to be held in Cape Town in May.
Agile talks about small team sizes with the magic numbers of 7 plus minus 2. Agile also recommends whole teams. Whole team is a concept that advises for having sufficient skills within the team itself to get the job done. Thus the development team has the testing skills, database skills, user interface skills, apart from the core development skills. Is defining the team structure this easy?
James Carr recently published a list of five rules to help improve the effectiveness of retrospectives. The rules are based on his experiences in hundreds of retrospectives, both successful and not.
Many of us, who are new to Agile, would believe that putting an Agile team together in a room gets the job done. A few of us would actually pay attention to what makes a room a team room which can enhance productivity and motivation. Many Agile teams have already shared their perspective on what would make an ideal team room. Here are a few recent ones.
Mike Cohn and others present their case to why you should consider structuring your teams around software "features" rather than software "components".
Formalised social contracts provide a structure to help reduce the fear, uncertainty and doubt associated with organisational change, and can enable an Agile transition to go more smoothly. Israel Gat provides an example of the social contract he used at BMP Software.