InfoQ Homepage Agile Techniques Content on InfoQ
-
Key Elements of a Successful Agile Retrospective: Preparation and Participation
Agile retrospective helps the team examine what went well during the past sprint and identify the areas of improvement for the future sprints. However, sometimes the exercise of conducting a retrospective ends up as a futile effort due to lack of preparation. Moreover, key members of the team end up either not attending or not participating in the meeting.
-
Lean Is More Than a Toolset
Alan Shalloway urges people to understand that behind Lean's practices are important principles that practitioners would be wise to recognize.
-
Handling Project Termination
Terminating a sprint in Scrum is a rare event, but it does happen. An abnormal sprint termination can be called by either the team or the product owner. Most of the times terminating a sprint or the project leaves a sense of bad feeling. Robert K. Hurley and Joseph T. Jimmerson discussed the ways to deal with the trauma of a terminated project.
-
The Minimum Viable Product - a tool for exposing value
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.
-
Measuring Agile Performance with the Agile Triangle
Traditional software development teams were supposed to work within the confines of the software 'Iron triangle'. The three sides of the triangle are Scope, Schedule and Cost. Jim Highsmith suggested that the Iron triangle, imposes a lot of constraints on the flexibility of the Agile teams and suggested an alternate Agile Triangle.
-
How to Transfer Knowledge in an Agile Project
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.
-
Categorizing Tests
What's the difference between unit tests, functional tests, system tests and integration tests? What about developer tests, story tests, and acceptance tests? There seems to be no consensus on naming and categorization of tests although they are central to many Agile development processes. A discussion on the TDD discussion group examines these categorizations and attempts to clear the waters.
-
Two Types of Agile Documents - No More, No Less!
The Agile Manifesto suggests “ Working software over comprehensive documentation”. This has led many teams to believe that there is no need for documentation in Agile projects. Critics of Agile use limited documentation in Agile to showcase the weakness of Agile methodologies. Eelco Gravendeel suggested that there are just two types of documentation in Agile.
-
Enabling the Last Responsible Moment in Deployment
An interesting question can be asked during a design decision: "Does this approach create a commitment" rather than "is this the right design?". A conversation on the KanbanDev Yahoo! group explores this question, different approaches to implement an effective answer, and the benefits to be reaped by this approach.
-
Comparing Value, Velocity and Value Velocity
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.
-
Slow Down to Speed Up Profits
General understanding suggests that, if everyone on the team works at top capacity then the team would be most productive. Contrary to this, Steve Bockman discussed that this assumption might not always be true. In some cases, it may be necessary to slow down and work at less than top capacity in order to boost productivity.
-
Coping with Bugs on an Agile/Scrum Project
An often asked question is how does Scrum recommend a team to handle bugs? Should they be placed on the product backlog? Or on a separate bug list? If they’re on the backlog, does the Product Owner get to set their priority or are they automatically the most important items? Should there be a separate bug fixing sprint?
-
Presentation: Three Years of Real-World Ruby
Martin Fowler talks about ThoughtWorks's experience with using Ruby on client projects for the past three years, and the creation of a Ruby-based product 'Mingle'.
-
Fisheye and Crucible Add "Social Networking"
The latest releases of Fisheye 2 (source code repository browser) and Crucible 2 (code review) from Atlassian offer a completely revamped UI, one that allows developers to follow the team (a kind of social networking) as well as follow the work. Crucible 2 also supports the idea of "iterative code review."
-
What is Velocity Good For?
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?