A recent post by Paul Dolman-Darrall on the Value, Flow, Quality blog proposed a list of the 20 most influential people in the Agile community.
The Agile community has a great tradition of making fun of itself and April Fools Day 2012 was no exception. Here is a wrap up of some of the best gags from this year that you may have missed.
Pair programming is an agile software development technique in which two programmers work together at one workstation. The benefits of pair programming are well known and the technique is widely practiced. However, what is the best way to sit while pairing?
Agile coach Morgan Ahlström recently turned to the Agile Coach Support mailing list to ask how to deal with an organization that said they wanted the benefits of becoming more agile, but was behaving in ways contrary to that goal.
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.