BT

InfoQ Homepage Planning Content on InfoQ

  • On Uncertainty, Prediction, and Planning

    This article describes the software industry’s dismal history with predictions and planning in the face of uncertainty. It details some of the reasons why we fail to learn from our repeated mistakes. It suggests alternative approaches that are based on learning and include the strategy of hypothesis testing (Hypothesis-Driven Development) for deciding which features to deliver.

  • Agile and Late! End-to-End Delivery Metrics to Improve Your Predictability

    Agile teams may need to deliver milestones expected at a certain time, so will need to forecast or risk being accused of being “Agile and late”. There are metrics that relate to the “Logical Six” potential sources of delay which are key to improve forecasting accuracy. The metrics can used to create a Root Cause RAG Progress Report – to share a more accurate forecast and clear mitigations.

  • Author Q&A on the Book Software Estimation Without Guessing

    George Dinwiddie has written a book titled Software Estimation without Guessing: Effective Planning in an Imperfect World. The book discusses different approaches to estimation for software products, the ways they can go wrong and be misused, and when to use them

  • 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.

  • Agile in the Context of a Holistic Approach

    In this article Jon Kern, co-author of the Agile Manifesto, describes a set of critical practices that serve to build up a holistic view of the project, from which all else proceeds. Fail to do a good job at taking the systems view, and your project will likely not go as well as it could. It might even fail.

  • Scaling Autonomy at Zalando

    Autonomy isn't something you can just give to a team, it’s something that teams learn and earn over time. It has to come with accountability to amplify working towards a purpose. At Zalando, creating the right architecture and organizational structure reduced the amount of alignment needed and freed up the energy to be more thorough where alignment is needed.

  • Q&A on the Book The Professional Product Owner

    The book The Professional Product Owner explains what Product Owners can do to become real entrepreneurs who initiate and drive products, and what teams can do to release frequently. It provides ideas and personal anecdotes for effectively applying the Scrum Product Owner role and activities.

  • Three Things to NOT Do with Your Software Development Projects

    Experience has shown that a software project that is rushed into development is likely doomed to fail. Estimation and up-front planning are the keys to delivering desired quality without running over schedule or breaking budgets.

  • Q&A on the Book Agile Management

    The book Agile Management by Mike Hoogveld explores how the agile principles and values can be implemented in an agile way to improve the flexibility and entrepreneurship within organizations. It shows how the “voice of the customer” should be the starting point for designing the products, services, channels and processes you offer to your customers.

  • PAL (Planned Agile Leadership) Schedule

    Develop a PAL Schedule to harmonize agile methodologies with static package Go Live dates to enable a visual representation of planned project progress, enable the same methodologies used at an agile sprint level to control the project at a high level, act as a harness for quantifiable and measurable high-level deliverables, coordinate project activities and enrich meaningful communication.

  • Scaling Agile – Big Room Planning

    This third article in the series about making scaled agile work explores how to do big room planning. It’s two days of planning together with all program and team members every three months providing an overview of all the work to be done in the next quarter. Towards the end of the two days, team and program objectives for the three months are agreed upon, and risks are discussed and mitigated.

  • Scaling Agile - Master Planning Together

    The first article in the series about making scaled agile work shared a true scaling agile story; the second article described the importance and the how-to’s of slicing your requirements into potential releasable epics. So now we’re ready to build on top of those slices and that common understanding; we’re ready to do the master planning together.

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.