BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Stakeholder Content on InfoQ

Articles

RSS Feed
  • Finding Adequate Metrics for Outer, Inner, and Process Quality in Software Development

    Implementing a feature can be measured. Quality is harder to measure. This article explores how to balance improving quality and adding new features. It dives into different domains of quality: Outer quality which is owned by the product people (e.g. product owners, testers), inner quality owned by the developers, and process quality owned by managers.

  • Q&A on the Book Think for Yourself

    The book Think for Yourself by Vikram Mansharamani provides a balanced approach to working with experts to help us deal with uncertainty. Instead of outsourcing our thinking to experts, we should tap into appropriate expertise when needed. Multi-disciplinary and cross-disciplinary approaches can be used to see the whole picture and stay on top of things.

  • Q&A on the Book How to Lead in Product Management

    The book How to Lead in Product Management by Roman Pichler provides solutions for product managers and product owners to lead development teams and stakeholders. It covers practices like building trust, setting product goals, listening and speaking, resolving conflict, and securing buy-in to product decisions in order to achieve product success.

  • Q&A on the Book Righting Software

    The book Righting Software by Juval Löwy provides a structured way to design a software system and the project to build it. Löwy proposes to use volatility-based decomposition to encapsulate changes inside the system’s building blocks, and explains how to design the project in order to provide decision makers with several viable options trading schedule, cost, and risk.

  • How Developers Can Learn the Language of Business Stakeholders

    This article explores how business stakeholders and developers can improve their collaboration and communication by learning each other's language and dictionaries. It explores areas where there can be the most tension: talking about impediments and blockers, individual and team learning, real options, and risk management.

  • Why Do We Need Architectural Diagrams?

    Software architecture diagrams, when created well, and sparingly, can greatly improve communication within the development team and with external stakeholders. They require an understanding of the intended audience, and thoughtful restraint on what to include. Resist the temptation to think that diagrams are unnecessary or unhelpful, simply because there have been plenty of cases of bad diagrams.

  • Q&A with Ash Maurya on Scaling Lean

    In the book Scaling Lean, Ash Maurya explores how entrepreneurs can collaborate with stakeholders to establish a business model for a new product or service using Lean Startup principles. It builds on top of his first book, Running Lean, showing how to use experiments, measure business progress, and scale your startup.

  • Using Large-Scale Scrum (LeSS) with Feature Teams to Ship Your Product Every Sprint

    An interview with Larman about LeSS and what makes it different from other scaling frameworks and using empirical process control to increase organizational agility. Larman also explained how organizations can work with feature teams, and gave examples of how teams and stakeholders can be in direct contact with their customers and users and can work together to ship their product every sprint.

  • Evo: The Agile Value Delivery Process, Where ‘Done’ Means Real Value Delivered; Not Code

    Current agile practices are far too narrowly focused on delivering code to users and customers. There is no systems-wide view of other stakeholders, of databases, and anything else except the code. This article describes what ‘Evo’ is at core, and how it is different from other Agile practices, and why ‘done’ should mean ‘value delivered to stakeholders’.

  • The Resurrection of Product Risk Analysis

    Product risk analysis (PRA) is not only useful in testing but is also applicable during the various phases of sequential or agile system development. This article introduces a different application of PRA that elevates it from project level to domain level. It shows how you can go from risk and requirement-based testing to risk and requirement-based development.

  • Q&A about the book Common System and Software Testing Pitfalls

    The book Common System and Software Testing Pitfalls by Donald Firesmith provides descriptions of 92 pitfalls that make testing less efficient and effective. The descriptions explain what testers and stakeholders can do to avoid falling into the pitfalls and how to deal with the consequences when they have fallen into them.

  • Q&A with Barry Boehm and Richard Turner on The Incremental Commitment Spiral Model

    The Incremental Commitment Spiral Model describes a process model generator. InfoQ interviewed the authors about the principles underlying the Incremental Commitment Spiral Model (ICSM), applying the ICSM, benefits that organization can get from it, and how organizations can use the ICSM to determine under what conditions to use software-intensive agile frameworks like Scrum, DSDM, SAFe, or DAD.

BT