Swarming is a technique that helps agile teams to deliver working software fast and frequently. What is swarming, what are the benefits of swarming, and when and how to apply it?
Developing apps that surprise and delight can seem like an illusive goal that is difficult to articulate or quantify. But in this latest presentation just posted on InfoQ Mike Lee, the software engineer that worked on projects like Delicious Library,Tap Tap Revenge and the Obama ’08 iPhone app, proposes an algorithm for making better apps.
Scrum works most effectively with a prioritized product backlog. Prioritizing the backlog is part of the product owner role, but what can you do when your product owner won't prioritize the backlog because he or she doesn't see the value in prioritization?
A number of commentators have been talking about the perceived dichotomy between Agile techniques and architectural thinking. This post investigates some of the tensions between Big Up Front Design (BDUF) and You Aint Gonna Need It (YAGNI) thinking and looks at how the two approaches can in fact work together in complimentary ways.
UX specialist Anthony Colfelt presents a case for how agile, alone, might not be sufficient and a thorough and engaging look into how User-Centered Design can, and should, be merged with it.
A new MITRE whitepaper documents a variety of best practices and key characteristics for a successful SOA implementation.
Continuous deployment has gained a recent buzz in the Lean-slanted "eliminate work-in-progess" movement. But while many may find this an intriguing and logically worthwhile objective, many less can visualize how this might actually be achieved. Ash Maurya helps to fill this gap by describing his experience with making it happen at his company.
The traditional agile approach to prioritization is that user stories of higher business value should be implemented before ones of lower business value. The concept is simple, but implementing it well relies on having a mechanism to assess business value. Pascal Van Cauwenberghe has recently described an approach to defining business value, called "Business Value Modeling", which may help.
The goal of refactoring and rewriting is to improve the sanity of the system by improving the code readability, structure and clarity. A clean code would be easier to maintain and enhance. However, on many occasions Agile teams have a tough time deciding between the two.
Forrester Research, in preparation for their Business Technology Forum next week, has released an analyst report for free download, entitled "Lean: The New Business Technology Imperative." Aimed at management, it discusses Lean as a whole-business imperative, and its impact on IT, cautioning: "Don’t get so caught up in eliminating waste that you forget to create value and increase flexibility."
In a recent interview on Venture Hacks (Advice for Entrepreneurs) commentator Eric Ries discussed the concept of the Minimum Viable Product (MVP) – doing “just enough” to meet customer needs in order to get a product THAT PEOPLE WILL PAY FOR to market as soon as possible.
An implicit assumption made by most Agile teams is that 'value' is directly proportional to the 'velocity' of the team. While this may be true in some cases, however mostly, the team velocity gives little indication on the true value delivered.
A recent discussion on the ScrumDevelopment Yahoo! group discussed the different uses and misuses for velocity. Should velocity be used a metric for productivity? Should it be used for iteration planning? What about longer term release planning?
When should you refactor? There are times when you simply need to pay down technical debt - you should stop and refactor. No, you should only refactor when one is working on a User Story. Which advice is best? Is there, perhaps, a third option?
Is quality supposed to mean a lack of defects that are holding us back? Mike Bria, Lisa Crispin, James Bach and JB Rainsberger debate the meaning of quality and the limitations our current definition is placing on us.