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.
Scrum talks about having minimum disruptions during the sprint. However, in the real world, if the system is already in production, within each sprint there is a strong possibility of getting production support issues. The post tries to uncover some ways to take care of these interruptions with Scrum.
Mike Hill, well-known XP contributor, came forth to make a few interesting assertions about the misunderstanding often surrounding how a TDD "unit test" differs from the "unit test" of traditional lore, and how he uses the term 'microtesting' to clear the air for new TDD'ers.
InfoQ recently had the opportunity to ask 8aweek co-founders Dave Fowler and Zachary Garbow some questions about how they connect with users, prioritize work, and get things done.
On April 15th Thoughtworks will release Mingle 2.0, nine months after the initial release of Mingle. InfoQ got some time with product manager Adam Monago to talk through the new functionality provided by Mingle 2.0.
Even the very greenest of agile teams clearly recognize the word 'Retrospective'. But, alas, it is often overlooked that a retrospective may be a wasted effort if not used to initiate an actual improvement that the team follows through on. Jim Shore gives advice on how to make the most of your retrospective and reminds us of the activity's ultimate place in the agile heartbeat.
Ron Jeffries has started writing a series of fictional stories based on his observation of real teams. The first story (Kate Oneal: Productivity) focuses on the character Kate O'Neal (CTO) and one of her teams "Rimshot". In this episode Ron explores achieving and measuring Productivity improvements without formal metrics.
Microsoft has released a demo of potential Visual Studio 10 features as an extension for VS 2008. The features, collectively called PowerCommands for Visual Studio 2008, include the source code.
James Golick and Reg Braithwaite discuss the often overlooked realities of how putting teams into "Crunch Mode" can have undesirable results. The discussion looks at various ways applying pressure to a team often results in putting your project into not better but worse shape and how teams and managers might benefit by taking a different approach.
Larger team size prevents from adopting the whole range of language abstraction tools and puts constraints on productivity. Reg Braithwaite believes that tools should not be tuned to the size of the team. He advocates for building teams around the tools and keeping them small. It appears however that team growth is often inevitable. What can be done then to maintain quality and productivity?
API design affects all developers. Some APIs are a pleasure to work with, others are annoying and yet others are downright frustrating. But what's makes the difference? Which qualities make one API easy to use and another hard? The ACM Queue recently published an article by Michi Henning about API design; an article that analyzes these aspects.