Several members of the Agile community emphasize the importance of feedback loops in the effectiveness of Agile development processes.
Building software is closely associated with managing a lot of constraints. These constraints might be in terms of time, money, technology, decisions, compatibility, regulatory, people, process or all of the above. Jim Bird discussed the constraints imposed by Scrum, XP and how they help in fostering creativity and building the right software.
The Agile 2010 conference was held in Orlando from 9-14 August. A number of commentators felt there were not enough sessions focused on the technical practices and programming techniques, including Bob Martin who twittered about the lack of technical sessions. This resulted in a number of responses and the announcement of plans to launch an XP Universe conference in 2011 targeting programmers.
Stuart Wray wrote a paper analysing how pair programming actually works in team environments and identifies four mechanisms that can be applied to improve the effectiveness of pair programming, and why it results in better quality products.
Which is better? Scrum or XP? Is there one that is more applicable than the other or is there another alternative?
Pair Programming continues to be one of the most debated and controversial practices of recent years. Most proponents don't falter in their praise of the benefits, but many of even these same people will admit they struggle to get pairing really going in their shops. Why? Obie Fernandez opinions 10 reasons why this might be so.
One thing well known by most programmers is that the best (only?) way to learn programming technique is by example; specifically, watching someone else doing it. Antony Marcano & Andy Palmer's 'PairWithUs' gives people a great place to do just that.
Knowledge transfer is characterized by transfer of understanding, about a context, from one unit (individual, team, department, organization) to another. In a series of interesting experiments, Steve Bockman tried to figure out the best way to transfer knowledge in an Agile project.
"Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.
"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.
Buddha Buck recently asked the Extreme Programming list if there were a velocity range that could be considered 'good' for a team of about seven people doing two-week iterations. He felt that a velocity of eight or below indicated that the team's stories might be too big. The resulting discussion provided some answers to the question, and the questions behind the question.
In this video recorded during QCon London 2008, Pete Goodliffe presents two Linux-based audio products with a complete different outcome, software design making the difference.
In this presentation recorded during QCon SF 2008, Neal Ford, an architect at ThoughtWorks, shows 10 ways to write better code. This is practical advice for developers, but application architects can benefit from it too.
A recent discussion on the Extreme Programming Yahoo Group explored the apparent conflict between making software reusable and the XP practice of not writing code until it is needed. Ron Jeffries and others shared insights about the costs and benefits of code reuse, as well as how and when to do it in an agile environment.
Uncle Bob Martin recently wrote about his experience with apprentices and what he considers key to progressing from apprentice to journeyman. He describes two hypothetical apprentices: Sam, a developer who has apprenticed with the same master and had the same year fifteen years in a row. Jasmine has changed jobs (and therefore masters) a number of times - growing her skills along the way.