In a former article about the sprint review I pointed out that the sprint review is a meeting primarily for the benefit of the stakeholders. Yet, over the years I have visited with companies whose stakeholders are often absent at the very meetings where they should…
When considering your own organization ask yourself this question: “Are you working on too many projects at the same time?” If you are similar to most organizations that I visit, your answer will be a resounding yes! I’m having a hard time remembering the last time that…
In my experience it has never been a good idea to “surprise” the stakeholders (e.g., customers, users, internal management) of the product we are building. I can’t recall the last time I’ve heard a stakeholder say, “Wow, I am really surprised by what you are showing me…”…
I frequently get asked if sprints should be required to start on Mondays and end on Fridays. No, absolutely not! Is it common for sprints to align with week boundaries? Sure, but I think that many teams do that for conceptual (calendar) convenience.
Sprints are…
At a recent class a student asked me which role I would personally prefer to fill: product owner, ScrumMaster, or development team member. I have held each of these roles in the past, so that question gave me pause to consider how I really felt.
After some consideration…
In a previous blog post I discussed the fallacy of believing that organizations can execute a significant team restructuring at the start of their agile adoption. In this blog post I will broaden the discussion to include the fallacy that an organization transitioning to…
In your organization, what term do you use to refer to the smallest set of features that would constitute a viable release to your users? In other words, how do you refer to the smallest set of must-have features you could possibly release to your users that they would…
Many companies operate with a project-based focus. When a new project is authorized, often times a new team is created to work on that project. Frequently the members of this new team may have limited prior experience working with one another. In those cases, we have to…
Many organizations find that when they start to adopt agile at scale (i.e., agile with more than a single team), their team structures need to change. In particular, companies that have historically relied on a large number of component teams as opposed to feature teams…
Ever been on a project where you needed someone (a specialist) outside of your agile development team to do work for you? For example, I once worked with a team that was developing a medical software application and frequently needed legal specialists to draft or review…