BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Productivity Content on InfoQ

  • Is Velocity Killing Agile?

    Velocity, the measure of work completed by the team divided by the time taken to complete it, is increasingly being used to manage the productivity of a team and as a comparison between teams. Jim Highsmith, Mark Levison, and Scott Ambler discuss the misuse of velocity as a productivity measure.

  • Simple Tools Preferred in the Agile Tools Space

    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.

  • The “Do Not Disturb” Team Member

    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.

  • What Really Motivates Workers

    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

  • Need an Answer to Context Switching? Get Disturbed

    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.

  • Agile Addresses "The Five Dysfunctions of a Team"

    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 Skipping Testing for Very Short Term Projects

    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.

  • How TDD and Pairing Increase Production

    "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.

  • Is Five the Optimal Team Size?

    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.

  • J.B. Rainsberger: "Integration Tests Are A Scam"

    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".

  • Focus Improvement on Bottleneck Constraints

    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.

  • Keep Focus By Tuning Out Your Computer

    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.

  • "Good Design" Means ...?

    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.

  • Measure Agile Productivity in $

    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.

  • Handling Your Team's "Rotten Apple"

    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.

BT