Community Blog

I decided to conduct a Temperature Reading Sprint Retrospective after watching the video from one of the workshops of a famous American family therapist Virgi

People love stories. We love telling and listening to interesting stories. The need for this is embedded deeply by the nature. The first stories were told by our ancestors and can be seen in the preserved rock paintings.

Software is created by people; for better or for worse. That is very different from looking at software development as a robotizeable activity.

I have found that coaching managers is a different approach than with Scrum teams. While you are (most of the time) involved directly with the Scrum Team as a Scrum Master, managers are less accessible.

On more than one occasion over the years, I have encountered software development teams that are working day and night on a "challenged" project - both waterfall *and* Scrum.

There is a fundamental change in management happening under out feet that is challenging the very need for strategy. Small changes are happening every day and in ten years’ time we won’t recognise management as we have thought of it in the past.

Your plan. It will change anyway. Your detailed architecture. It should emerge. Your code. It will be refactored. Your document. It doesn’t compile anyway.

I work with a lot of companies to help them to improve their development processes and to either adopt Scrum or improve how they’re currently doing Scrum.  Lately, I’ve noticed that a fair number of companies run into problems with a certain kind of pr

In 1995, the first codified version of Scrum was made public.

At Scrum.org, we sometimes dare to talk about our what we do as “bringing humanity to work.” Sometimes I get reminded this idea is more than hyperbole or aggrandizing.  

I am a Scrum Trainer with Scrum.org.  I work with lots of organizations to help them become more agile.  I see a lot of bad Scrum.  More than my fair share.  Sometimes I see so much bad Scrum that it makes me question why I do this.  This post is my at

Today we are pleased to announce the release of ScrumGuides.org, a branding-free website providing the single authoritative definition of Scrum.

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

Many companies have started searching for self-organisation. That ideal or nirvana where teams can figure out how to work together effectively with limited or little direction to solve problems.  

I work in the public sector as an Agile coach. One of the question I often get asked is how to estimate the size of a new project, or a new delivery, as we need to determine a budget before executing it.

Scrum.org holds a consistently high quality bar for our instructors. The result is a tremendously mature and capable cadre of experts working together to realize our shared mission of improving the profession of software development.

Does your company culture resemble Survivor? Do you have a culture in your organisation where individuals that help others are considered slackers for not getting their own assignments complete?

One of the important event in Agile this year seems to be an argument around Test Driven Development (TDD). More precisely, high profile personalities in our industry debated against the statement "TDD is dead".

Did you know that the DOD has made it illegal to do waterfall? For the first time in many years the Department of Defence (DOD) in the United States had made a major update to its procurement rules.

The simple cycle of trying, inspecting, and adapting must be as old as mankind. Can’t you just picture Homo Erectus learning to control fire? I bet scorched fingers and cold nights were fairly common for a millennia or so while we refined the art of spark and tinder.

]

As a Agile coach, I refer to a few tools to help me think about where my Scrum teams should go next on their path to Agility.

Recently I gave a talk on the ScrumDayEurope 2014 conference.

 

A few weeks ago I headed out to the Scrum.org offices in Boston to participate in training to hone my skills as an Evidence-based Management Consultant.

A common challenge for businesses developing new products is having a coherent and universal understanding of what the value proposition for the organisation is.

Story Points - An Introduction

Collaboration is the key to successful agile product development. A community of practice is a technique that helps us achieve this.

The Scrum.org blog is branching out to include our entire expert community! Now, readers will get more than the occasional formal article.

I did a coaching and training session with a company recently. They're a small, early-stage company in the Greater Boston-area.

We shall talk about the most important, from my point of view, team’s trait - Helping Each Other. After discussion I will give you a powerful game that can help you to foster and promote real “one for all, all for one” team spirit.

The Scrum.org crew just returned from the Agile 2014 conference in Orlando. The great conversations with attendees were as good as the sessions themselves.

It's difficult to predict the future despite the techniques we use to try to do just that. The reality is that planning out even a simple software development project is a challenge.

When organizations consider or start adopting Scrum, a frequently raised concern is how ‘to scale Scrum’. It is worthwhile investigating this desire, and start exploring the scalability of Scrum.

‘Evidence-Based Management’ for software organizations promotes evidence-based decision-making in the managerial domain to create a more sustainable business through improved services in turbulent markets and businesses.

I have encountered many in the Agile community who love Scrum but seem to hate on the practice of Scrum of Scrums. Others describe their Scrum of Scrums as an overarching meeting of Scrum Masters, or as a meeting for a Product Owner team.

The aim to deliver valuable software is a great, core principle of the agile movement. The difficulty however is that ‘value’ in itself is hardly quantifiable.

Every year, organizations spend 4-10% of their revenues on their IT organizations. Value is expected in return for these expenditures.