Linda Rising shares influence strategies that you can use to more effectively convince others to see things your way. You’ve tried and tried to convince people of your position. You’ve laid out your logical arguments on impressive PowerPoint slides—but you are still not able to sway them. Cognitive scientists understand that the approach you are taking is rarely successful. Often you must speak to others’ subconscious motivators rather than their rational, analytic side.
People and team member management for Agile project management and Scrum software development teams.
Martin Alaimo thinks that personal issues are rarely discussed in Scrum retrospectives. In this article, he discusses how he includes in retrospectives a special section to address personal issues. He explains how he uses retrospectives to build Scrum between the Scrum team members.
In Agile and Scrum, we spend a lot of time talking about how to better manage software development teams using processes, methods, prescriptions and other rules of thumb. We spend very little time talking about the largest and most important ingredient of any agile team: the team and people themselves
Self-organizing Scrum and agile teams need to determine how best to manage the flow of their work to get the job done each iteration. Flexible and high-performing agile development teams are composed of members with T-shaped skills and a Musketeer attitude that enable them to swarm to success.
If Scrum provides the project management framework used in a majority of Agile projects, eXtreme Programming (XP) is the main source of technical practices for Agile software development. This book written by Alan Shalloway, Scott Bain, Ken Pugh and Amir Kolsky is focused on these technical aspects. The first part deal with the coding and testing activities, and the second part discusses how to handle the software design activity with an Agile perspective.
Scrum likes to rely the technical practices recommended by eEXtreme Programming to improve the software quality. Pair programming is one of these practices, even if surveys tell us that it is not used as much as other practices like test-driven development (TDD). In this article, Zee Spencer shares four common pitfalls of pair programming and tell us how to avoid them.
Most of us do the exercise of rating team members every year even if we know that software is built by teams, not individuals. Moreoever, each individual needs to actively collaborate to produce quality software. This means that everyone on the team needs to take collective ownership and help each other, because the motive is not to be a hero but to build an end product of the utmost quality and predictability.