Long working days, deadlines and team pressure can impact the quality of the software that agile teams deliver. What can we do to prevent that from happening and enable teams to improve the quality of their software? Some suggestions are to arrange for scope and deadline slack, adopt pull systems, and to make sure that people can slow down and get enough sleep.
At DevOpsDays Amsterdam, Mark Coleman asserted that all organizational's cultural changes start with one person influencing another. He finds that Charles Handy's writings on power and influence help on understanding how an organizations works and how one can go on to change it. Mark discussed Charles Handy's six sources of power and six methods of influence.
On the first day of DevOpsDays Amsterdam 2014, bol.com, an online store, reported its experiences in its DevOps journey. Full automation, careful team building and an agile mindset that cross-cuts the organisation were the keys to success. RunDeck, Puppet, Hiera and Nagios enable bol.com to build and monitor a full working environment in under two hours, in a fully automated fashion.
In organizations that are adopting agile people sometimes state that the hierarchy should be abolished and that we should get rid of managers. They consider managers and hierarchy to be something that hinder self-organization of teams.
Agile coaches David Mole and Sandy Mamoli recently presented a talk to Wellington's Agile Meetup group on their successful experience with team self-formation and a big-bang migration to a Spotify-esque Squad Model at Trade Me, one of New Zealand's largest online brands. We catch up with them to understand their motivations and experiences in this endeavour.
Trust is a decision about your investment in the relation says Anko Tijman. Agile governance should be build upon trust. At the Agile Governance conference in Amsterdam Anko Tijman presented being in control through people. Governance is often based on analytical control using structures and models.
When adopting agile teams can use (external) coaches and mentors. But teams can also develop themselves by having team members mentoring and coaching each other. Team members can learn skills and abilities from other team members in multidisciplinary teams, enabling the team to grow as a whole and become self-organized.
A report on recent commentary by Mike Cohn, Thomas Cagley and others on the topic of team self-assembly and sustaining successful self-organising teams.
Agile coaches can coach in pairs instead of coaching individually. Each coach will focus on different aspects of coaching. As every coach has specific experience and skills they can complement each other. Two coaches can collaboratively help individuals or teams to learn and improve when adopting agile.
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?