Agile does not necessarily mandate or recommend the use of tools. Ideally the development could be done on a command line interface with requirements present on index cards. However, in the last few years, several tools have emerged and they have acted as a catalyst to successful Agile development. Migan and Gaia recently conducted a survey to find out the use of such tools in the Agile space.
Many developers like to work in isolation, for some time, if not always. XP recommends a room arrangement called “Caves and Commons”. Commons area is organized to maximise osmotic communication. Caves are meant to facilitate isolation for activities like personal email, phone calls or a quick spike. However, there could be a situations where a team member wants to take this isolation too far.
In a recent Harvard Business Review article Teresa M. Amabile and Steven J Kramer challenged the commonly held mnagement belief that Recognition is the most motivating and positive factor in the workplace. Their multi-year study tracked the motivation and emotions of hundreds of knowledge workers and identified POGRESS as the single most important factor for individual motivation in the workplace
Context Switching is defined as changing focus and attention from one task to the other in relatively short periods of time. It is widely considered harmful for the team member and the project that he is working on. Charles Miller mentioned a few ways of how they handle context switching at Atlassian.
Tathagat Varma, general manager with a large provider of IT management solutions, wondered whether Agile's productivity improvements could be linked to how it improves teamwork. His article analyses Agile values and practices by mapping them against Patrick Lencioni's business fable "The Five Dysfunctions of a Team."
Kent Beck suggests that on very short term projects, when you're trying to figure out if there is a viable concept, you might do less (even no) automated testing to help get off the ground quickly. This goes against all of the conventional wisdom surrounding TDD.
"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.
There have been a lot of discussions and debates about the optimal team size for maximum productivity. While most Agilists agree that smaller teams are more functional and productive as compared to larger teams, however defining the optimal team size is still a challenge.
Well-known agilist and TDD expert J.B. Rainsberger has begun a series of posts to explain why his experience has led him to the thought-provoking conclusion that "integration tests are a scam".
In My Framework is More Productive than Your Framework, Ken DeLong examines approaches to making software projects more productive. He finds that despite the hype about frameworks, languages, and project management tools, these tend not to be the bottlenecks. Ken believes that the largest productivity gains are likely to come from improved communication, code readability, and debugability.
Agile practitioners have come to understand the negative effect “context-switching” has on productivity when it comes to your projects and teams. To what degree do the same ideas apply at the daily task and personal interaction level, and what can people do to avoid micro-level multi-tasking problems? Phil Gerbyshak offers some advice.
It's not news that at the heart of successful software systems (and, frankly, fulfilling software careers) is good design. Also not news is that defining what "good design" really means has been at the heart of many debates, papers, talks, books, discussions, and more for ages. To help, J.B. Rainsberger and Scott Bellware offer some advice to follow until that one true definition comes along.
Earlier Scott Ambler posted an article of how to measure productivity on agile teams by utilizing acceleration. Recently he followed up with another post where he answers some frequently asked questions related to agile productivity and acceleration. Specifically one question answers how to measure the amount of $ saved by an accelerating team.
Recently there has been an active discussion in the Scrum Development Yahoo Group about handling an "under-performing" team member. In the 130+ response thread, "Rotten apple in Scrum team", talk ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more.
Advice from Esther Derby, George Dinwiddie, Jo Geske, Mike Sutton and Ilja Preuss on how to make retrospectives better. The ideas include tips for the facilitator/Scrum Master and new ways to use the burndown chart.