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.
Programming languages that offer more power and flexibility have been lately gaining momentum. Johnatan Tang highlights, however, the flexibility vs. productivity tradeoff in terms of program structure. Whereas multi-dispatch languages provide more flexibility in arranging code, traditional object orientation makes organizing programs easier.
Getting the right infrastructure set up is instrumental for the success of Agile software teams. Teams now have the option of deploying a fresh infrastructure using Buildix or using an online workspace provided by Assembla to kick start their project in no time.
In this presentation filmed during Agile 2008, Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He measures the development progress and effectiveness and compares the results with industry averages. He also presents the factors which contributed to the success of BMC's Agile adoption.
In the field of software development, managers need measurable metrics to appreciate the performance of their programmers. Shahar Yair and Steve McConnell discuss common techniques focusing on source lines of code and function points. They highlight the limitations of these approaches and seek to define some principles that could guide the analysis of programmers’ performance.