Organization prefer to establish and nurture stable teams, as reported earlier this year in the InfoQ news developing stable teams, and dealing with dysfunctions. But sometimes there are reasons why the composition of a team or of teams needs to be changed. If changes in team composition are needed, how can they be done?
A survey of recent commentary and presentations by Ken Schwaber and others on the merits of the multidisciplinary, T-shaped, team-member within an empowered cross-functional team.
Working in an agile team can sometimes be stressful, when the needs of the customers are unclear, if there is a lot of work to be done, or when team members are having difficulties doing their work. You might ask the question if having fun could reduce the feelings of stress, increase motivation, or increase productivity? And if that is true, then what can you do to have more fun in agile teams?
Guillaume Duquesnay uses his experience with games and roleplaying in his work as an agile coach. At the Agile Tour Brussels he talked about leadership, facilitation and management styles where no authority was involved. InfoQ interviewed Guillaume on his coaching, facilitation and leadership skills, and asked him if playing games gives happiness and fun to people, and make them more productive?
Teams sometimes consider to skip a retrospective meeting, when they feel time pressure, or do not see direct benefits of doing one. Next they question themselves if they have to keep doing retrospectives? Agile retrospectives help teams to learn and improve continuously, and there are valid reasons to keep doing them also with mature teams.
Retrospectives are often considered to be a valuable agile technique, but sometimes teams have difficulties doing them: insufficient control of things, thinking that they can’t improve, difficulties defining good actions, or much complaining. Teams may find retrospectives boring, and a waste of their time. How to deal with this, and help teams to discover better ways to do retrospectives?
Martin Fowler talked about software development in the 21st century, discussing agile essence and how teams adopt agile. He presented at the GOTO Amsterdam 2013 conference how teams can increase their agile fluency, from a first star level up to four stars.
Impediments are used to discuss issues take actions when a team becomes blocked. Impediments are handled in different ways, a look at how some scrum masters do it.
Organizations that implement self-organized agile teams need managers who empowerer the teams by using servant leadership, and who coach and mentor them to learn and continuously improve themselves.
The 10th anniversary edition of the XP Days Benelux 2012 conference continues on the second day. An impression of the sessions about agile adoption, self organizing and managing technical debt.
Mike Cohn recently suggested that the Daily Standup (or Scrum) is not a status meeting for the Scrum Master, but a forum where team members are synchronising their work. Techniques such as breaking eye contact are helpful for Scrum Masters to fix this anti pattern in their teams.
A recent Harvard Business Review article highlights the importance of finishing one task at a time and hence getting more work done. Some of the core Agile practices help minimize context switching and bring a similar task focus while building software.
Esther Derby recently posted an article examining "Manager Think" and how the focus on having individuals work to their maximum capacity is detrimental to teamwork and the maximum delivery of value by teams. She tackles the common perception that teams need to appear to be struggling in order to actually be working hard. This item also examines the danger of excessive overtime on productivity.
For years Agile has been encouraging teams to work together collaboratively in open spaces and encouraging developers to pair program, but lately these types of practices have been coming under fire.
Tony Wong, a project management blackbelt, enumerates some practical points on individual procutivity. This article wonders how well these apply to software development and contrasts his list with that of other lists.