Community Blog

In this post I want to explore whether the Increment, a core concept to Scrum, needs to be changed for Scrum in a non-IT context. In future posts, I will do the same for the Definition of Done, or other concepts that may provide a better understanding of Scrum when applied to non-IT context.

Professional Scrum Trainer Sahin Guvenilir wrote "Why having a Definition of Done is not optional and how it helps you protect your customer, money, reputation and morale".

I believe there are three things you need to do regardless of the framework, methodology or program you are embracing with your organization.

When working with a flow-based Kanban system there are a few statements that I would suggest most teams should bear in mind.

Unclear language leads to incomplete transparency and ambiguity. The careful use of words like ‘bug’ will improve decision-making in your organization.

A few days ago, I was observing a Sprint Retrospective. The Scrum Team decided to work on the Definition of Done (DoD), identified as the most important topic to adapt for the next Sprint. The discussions were open and animated, when an unexpected discussion emerged during the session.

The purpose of Scrum is to create a potentially releasable Done Product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. The technique described here allows for greater transparency on what the Definition of Done is, and what the next steps are.

In Scrum, “Done” doesn’t support adjectives like “nearly”, “pretty much” or “almost”. Work is “Done” or it isn’t . And there is a very powerful, compelling reason behind this: the Scrum Framework only helps to reduce the risk of wasting money and effort when you deliver “Done” software every Sprint; a new version of your product that is, or with the proverbial press of a button can be, released to users. In this post I underscore how essential this rule is to Scrum.

Often I hear people say that Scrum does not take care of risk: there is no risk log, risk is not on the agenda of the Sprint Review or Retrospective as a standard agenda-item. The Development Teams need to be accountable for the quality of the product and how it's made. That's a risk right there! If there is not one person accountable for quality, being on time, within budget, building the right thing... How is risk managed in Scrum?

The purpose of Scrum is to deliver Increments of releasable functionality. So at each Sprint Review, a “Done” Increment is required to make transparent the progress made by the team.

Everyone building software products today aspire to be able to seamlessly update the production software in a continuous manner. To be able to deploy code without the ‘normal’ friction of process controls, reviews, test departments and committee meetings.

In my last post about Professional software teams creating working software David Corban made a good point. How do you determine what "Free from fault or defect" means?

The PSD training teaches the whole Scrum Team on how to do real Scrum. They work in Sprints, create Done software and use the appropriate tools and practices for it. It is a unique experience on how really good Scrum feels like.

El Daily Scrum es una reunión clave para la adopción del empirismo, es una oportunidad de inspección y adaptación para generar transparencia hacia el objetivo del Sprint.

One of the arguments used against Scrum and a common misconception at the same time is the idea that quality is traded for speed in Scrum. As a PST with years of experience in Quality Assurance I decided to challenge this myth.

What Is Self-Organization? “Knowledge workers have to manage themselves. They have to have autonomy,” says Peter Drucker.

On July 7th the Scrum community gathered in Amsterdam (The Netherlands) for the 5th edition of Scrum Day Europe. This year's theme was 'the next iteration'.

Throughout the Agile Alliance 2016 conference, I was struck by a recurring feeling that many people don’t understand what the Sprint Review is.

Over the past 10 years I have worked with many organisations and helped them to use Scrum to create innovative and sometimes market leading Products. I have seen a lot of Scrum during this time, much of it done well, but some of it done badly.

I was recently contacted by a senior executive of a mid-sized company that is evolving their product development to Scrum. He explained a situation he had been in and wanted my opinion.

Scrum brings agility to and creates Agile organizations through the implementation of empirical process control, the process of frequent inspection and adaptation.

I always spend time during training classes thoroughly covering the concept of Definition of Done, sometimes abbreviated “DoD.” As a concept it’s fairly eas

You need quality enablement to achieve predictable delivery for your organisation which takes effort to achieve.