InfoQ is researching the factors that influence the mood of teams. As team mood is an aggregation of the individual moods of team members, understanding the individual mood and how it influences team working can help to learn more about team moods. InfoQ interviewed Gerald Weinberg about individual and team mood, influencing the mood of individuals and discussing moods in teams.
Developing and delivering products which customers don’t want and for which there is no market can be costly. Agile can help you to efficiently develop products, but you need to know what to build. How can you find out which products your customers need?
Experimentation using for instance lean startup can help you learn about your customers and find out which features and product would be valuable. The value however comes from building products and actually delivering them to customers. You need to find ways to balance between experimentation and delivery.
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.