BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Complementary Practices Content on InfoQ

  • Enhancing Scrum with "The Core Protocols"

    Alex Champandard has written a piece on using Scrum within the game development industry, and how Scrum can be augmented with Jim and Michele McCarthy's "Core Protocols."

  • Mind Maps Foster Thorough Test Design

    In Better Software magazine, Robert Sabourin's article "X Marks the Test Case: Using Mind Maps for Software Design" shows how the practice of Mind Mapping helps with test design. The author says: "If you've run through the standard design approaches and still need that killer test case, try mind maps." And he goes on to suggest how to get started.

  • Case Study: DSDM Bridges the Gap Between PRINCE 2 and XP

    PRINCE 2 is a traditional project management method, mandated for government agencies in the UK. Extreme Programming (XP) is considered one of the lightest Agile software development methods, relying on team self-management. In this case study, Barbara Roberts uses one of the more management-oriented Agile methods, DSDM, to get these two approaches working together within a single project.

  • Holacracy - The Self-Organizing Enterprise

    The fit between Agile teams and traditional enterprises can be challenging. Agile may highlight or exacerbate pre-existent dysfunctions, in areas a project manager may not be well-placed to address, so those involved in Agile roll-outs are thinking about alternate ways to organize the enterprise. Holacracy, created at Ternary Software, suggests that self-organization can extend outside IT.

  • InfoQ Article: When and How to Formalize Business Rules

    The terms "Agile software development" and "Business Agility" are confusing: are they orthogonal or complementary? James Taylor says that for even the most complex systems, Agile development can deliver business agility - particularly when supported by the right technology. For business rules he recommends a Rules Engine, and provides guidance in how to distinguish rules from requirements.

  • Opinion: Code Coverage Stats Misleading

    John Casey recently spent some time refactoring Maven's assembly plugin, using coverage reporting to mark his progress and make sure he didn't break anything as he went. It didn't exactly go as planned - but at very least it was a learning experience. His conclusion: when you're seeking confidence through testing, perhaps the worst thing you can do is to look at a test coverage report.

  • Agile Coach = Agile Secret Police?

    Software engineer Paul Tyma, in a recent blog entry, tells us "I don't get this new craze of a job called 'Agile Coach'. I mean, everything I've read about Agile and XP seems dead simple." Though not a proponent of Agile, Tyma has done XP, so perhaps there's a basis for his view that an Agile Coach is not so much a 'coach' as "a hall monitor or a secret police officer."

  • Tackle Testing Debt Incrementally

    Technical debt can shorten a product's life. But when technical debt mounts, it can be difficult to see how to pay it off. In her StickyMinds column, Johanna Rothman explains practices to help teams start paying off that debt - thereby easing their product's development and maintenance for a long time.

  • Tips for Effective Kaizen Process Improvement

    Agile software development and Lean Thinking go hand-in-hand for many practitioners. Six-Sigma blackbelt Mike Wroblewski has blogged some lessons learned from a recent kaizen session. People are a key variable in both manufacturing and software environments, so his lessons learned in manufacturing are also interesting for Lean Software practitioners using kaizen events for process improvement.

  • Tech Stories Need to Include People and Technology

    Brian Marick, reflecting on conversations heard at Agile2006, blogged about his concern that some of us are telling stories from the purely human or social viewpoint, while other are telling technology-only stories, noting that that XP isn't a story you can tell well without talking about both of these. Marick encourages us to include both when we communicate in and about projects.

  • Mary and Tom Poppendieck Discuss Their Next Book

    Bob Payne interviewed Mary and Tom Poppendieck at Agile2006 about their next Lean book, which focuses even more on software than the last. Mary summarizes it as "So you think Agile is a good idea: now what?" saying it will help people get started with Lean, going beyond the recipes of the first book to provide practical information and case studies to help teams do their own process experiments.

  • Synergy: Agile and User Experience Design

    Scott Ambler believes that User Experience Design (UED) is critical to the success of agile software development techniques, because it increases a team's chances of building the right software to meet customers' real goals. This article describes how Agile and UED communities can work together closely for project success.

  • Agile Work Cheatsheets Posted

    It's been said before: Agile may be simple, but it's not so easy. Mishkin Berteig contributes some one-page quick-references to jog our memories and keep us focused on delivering value.

  • Outsourcing Gone Bad - Another Reason to Consider Agile

    Proponents of Agile methods suggest they can spare organizations some outsourcing nightmares, by helping in-house teams produce ROI comparable to outsourced solutions. Stories from Sprint and Sears provide incentive to at least give them a hearing.

  • Agile Fixed Price Contracting

    On the high-volume ScrumDevelopment newsgroup, an interesting question has appeared, once again: "Is it possible to run SCRUM with fixed price contracts especially custom projects?". Ron Jeffries, Mike Beedle and others offer replies from experience.

BT