InfoQ Homepage Agile Techniques Content on InfoQ
-
Daily Standup Tips - a Roundup
We often hear stories about daily standups that have become nothing more than long daily status meetings where team members tune out. What techniques do people have for avoiding this and other standup pitfalls?
-
Can We Transform Agile Rules to Guidelines?
A rule generally refers to the defined standards for an activity. It is required to be adhered to. In other words, a law, may informally be called a "rule". Guideline on the other hand attempts to streamline a particular process according to a set routine. By definition, a guideline is never mandatory.Should Agile teams talk about rules or can we have just guidelines?
-
How Pair Programming Really Works
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.
-
Lean + Real Options = Reduced Complexity and Risk
Real Options, a decision-making process based on Financial Option mathematics, was mentioned by Kent Beck in his 1999 "white book," Extreme Progamming Explained. More recently, Agilists have been exploring how Real Options intersects with Agile. Now Chris Matts and Olav Maassen specifically address the Lean Software community, proposing that application of Real Options improves Lean Development.
-
Is Technical Debt a Technical Issue?
Is technical debt a purely technical issue that can be addressed directly by refactoring and tests or is it a symptom of a bigger problem? Will the adoption of TDD fix the issue or just cover up a symptom of something bigger?
-
You Can Say No to 'Pull' in Kanban
Kanban places a lot of emphasis on the pull psychology. Most people who subscribe to lean ideas prefer pull systems as opposed to traditional push systems as they are deemed to be superior for performance and productivity. However, there might be situations where you would want to say No to a pull.
-
Agile Retroflection of the Day
Retroflection is a concept in which one substitutes self for environment, as in doing to self what one wants to do to someone else or doing for self what one wants someone else to do for self. Introspection is a form of retroflection that can be pathological or healthy. Based on a similar concept Yves Hanoulle started the Agile Retroflection of the day project.
-
Minibook: Scrum and Kanban: Making the Most of Both
Scrum and Kanban are two flavours of Agile software development - two deceptively simple but surprisingly powerful approaches to software development. So how do they relate to each other? The new InfoQ minibook by Henrik Kniberg and Mattias Skarin, Kanban and Scrum - making the most of both, clears up the fog so you can figure out how Kanban and Scrum might be useful in your environment.
-
Estimating Business Value
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.
-
Overlapped or Synchronized Sprints?
When a Scrum project grows, so do the team members. The suggested way of managing a growing team is to split the team into multiple teams keeping in line with the Agile recommended team sizes. However, there could be multiple communication and coordination problems when each team starts working in a sprint of their own.
-
Stabilization Sprints, A Necessary Evil or Pure Waste?
Stabilization sprints are an additional number of sprints added to the end of the normal development cycle before shipping the product. As the name suggests, they’re usually added to shake down the product one last time and drive the last of the bugs. Do they belong in Agile environment or should "Done" be enough.
-
What do you do, Testing or Checking?
Software testing is an empirical investigation conducted to provide stakeholders with information about the quality of the product or service under test. However, this definition does not talk about sapience which brings about a subtle difference between testing and checking. Michael Bolton talked about this difference and the reason why there should be a difference between the two.
-
Maintainable Automated Acceptance Tests
Automated tests that are brittle and expensive to maintain have led to companies abandoning test automation initiatives, according to Dale Emery. In a newly published paper, Dale shares some practical ways to avoid common problems with test automation. He starts with some typical automation code and evolves in ways that make it more robust, and less expensive to maintain.
-
Software Katas - Practice in Public Makes Perfect
Thought leaders in the agile community are talking about software katas - where one practices specific exercises until they are memorized. Robert Martin has calls them "performance art". Lately there has been an increase in blog posts and sites devoted to katas. The latest addition: weekly screencasts at katas.softwarecraftsmanship.org.
-
System/Acceptance Testing with Time and Dates
Unit Testing Time and Dates is an often talked about problem with relatively simple solutions. More difficult is the acceptance/system testing with Time. What strategies are used?