Year: 2015

Posted on by — 2 Comments

Meetings in Scrum, actually

Scrum has no meetings, actually. What we call ‚meetings‘, even in the Scrum Guide, are planned occasions at which people meet, where meeting (the activity) takes place.

Scrum’s meetings are not about reporting, status, bureaucracy, spilling ink, documenting the past. Scrum’s meetings have a purpose. Scrum’s meetings are about collaboration, discovery, opportunities, conversation, ideas, constructive disagreement, looking forward to the (near) future. It’s why Scrum offers opportunistic events more than obliges (what we generally know as) ‘meetings’.

Scrum’s events provide people with an opportunity to incorporate change into the daily work, instead of locking it out. The old notion of ‚change’ dissipates. Change becomes natural, the regular way of doing business, even a welcome source of ideas and innovation. Change is used in a team’s or an organisation’s advantage.

Scrum’s events serve the empiricism that Scrum brings to software development. Empiricism thrives on inspection & adaptation. Inspection & adaptation happens at a frequency, in regular intervals. Adaptation only makes sense when inspection is done against reality, when the actual situation is made transparent.

  • Scrum’s events define the frequency at which inspection and adaptation takes place.
  • Scrum’s artifacts hold the primary information to inspect and adapt.
  • Scrum’s teams are the inspectors, the people accountable for performing the inspections and adaptations.

Empiricism in Scrum

In Scrum all work is organized in Sprints. Sprints deliver releasable Increments of software. A Sprint is a time-boxed feedback loop in itself, a container event containing the above Scrum events.

Deciding over Sprint length is a different decision from the perspective of inspection and adaptation. The Sprint length determines the frequency at which stakeholder input is formally gathered and shared with the full Scrum Team. It’s the minimal frequency at which organizational or market changes can be incorporated, the last possible moment to decide on releasing software to collect feedback so it can be adapted to, to decide what the most valuable work is to work on next. When Sprints are too long, important opportunities that require adaptation may be missed. When Sprints are too short, the ability to get significant work done might be lost.

The time-boxes for all events, as set by Scrum, provide focus. It avoids the creation of waste. It focuses people’s minds on collaboration and importance.

Scrum frames the creativity of people. Scrum provides boundaries that re-inforce self-organization. Scrum says not how to run the events. Scrum defines the input to the meetings, the expected outcome and a timeframe.

In Scrum, actually… meetings are opportunities where people meet to change their mind.

Posted on by — 12 Comments

Team size in Scrum, actually

Self-organization is an essential management principle of Scrum. Yet, its importance and potential are only seeping through slowly. Despite the wide adoption of Scrum.

The most basic form of self-organization in Scrum holds that Development Teams organize and manage their own work within a Sprint, autonomously, against a forecast and a Sprint Goal. Where acceptance of this practice grows, few organisations take it a step further. Few teams are supported to figure out their own team size in order to best collaborate towards the creation of a releasable Increment of product in a Sprint. Understanding that the foundations for great work are commitment and motivation, Development Teams should be able to also create and re-create their structure and composition across time.

Collaboration is key. From collaboration performance emerges. Teams have the highest cohesion, the deepest trust and the most effective interconnections when the size of the team is around seven. Scrum used to have the rule known as 7 +/- 2, meaning a Development Team was expected to have at least 5 people, and 9 at most. The Scrum Guide has evolved this guidance to 3-9 people. This is confusing when looking for academic exactness, less confusing if this is seen as guidance against the goal of being “small enough to remain nimble and large enough to complete significant work within a Sprint“ (quote from the Scrum Guide).

Although the Scrum Guide sets an expectation for the size of a Development Team, there’s no formal process needed to really enforce this if self-organization is enacted. Through self-organization a team will adjust its size autonomously for optimal performance. Rather than instructing a team on their mandatory size, help a team discover what works best for them, including what team size maximizes the communication bandwidth. No external body can do this better. No external body can assess the combined effects of team dynamics, being co-located or not, availability of people and resources (tools, infrastructure), and all other parameters better than the people actually doing the work.

Try something you believe might work for you. Inspect it, adapt to your findings. Repeat. When heavily constrained in doing this, sticking to the guidance of having 3-9 people in a Development Team is a good idea.

In Scrum, actually… team size is a team decision.

Posted on by — 3 Comments

The “Scrum Practitioner Open” assessment

People and organizations regularly ask us at Scrum.org (1) for our ideas on scaling Scrum. They are keen to learn from Ken Schwaber‘s and our community‘s experience in scaling product development done through Scrum.
At the same time (2) we frequently get asked for an assessment that tests a person’s ability to join a Scrum Team, often in a scaled context, and be productive in terms of having practiced Scrum.

They are satisfied with our existing Professional series, offering rigorous help and insights to adopt, implement and grow Scrum and Scrum Teams. Additionally however they look for (1) help and inspiration in their scaling efforts and (2) courses and assessments for Professional Scrum Practitioners. As part of our on-going mission to improve the profession of software development and guide the maturing of Scrum, we have taken action. We are in the process of (1) launching a practitioner course to scale Professional Scrum and (2) we are revisiting our assessments accordingly:

  1. The “Scaled Professional Scrum for Practitioners” workshop introduces our framework for scaled Scrum. It introduces techniques and practices for horizontal scaling, amongst which defining and growing a Nexus, a networked structure of 3-9 Scrum Teams developing a product. Find the next planned session here.
  2. We have also created and made the “Scrum Practitioner Open” assessment available, free to anyone taking it. The Scrum Practitioner Open assessment provides anyone with the ability to assess their skill to productively participate in a Scrum Team that is developing increments of software. This assessment is particularly useful for people on one of multiple teams engaged in a scaled development initiative.

Scrum Practitioner OpenTry the Scrum Practitioner Open assessment. Our industry will benefit from an assessment testing the ability to develop software effectively in a Scrum Team, in a scaled context, and optimize common development issues based on the values of Scrum and the basis of empiricism and transparency.

Thank you for your participation.

Posted on by — Leave a comment

My OOP 2015 talk visualized

On January 29 2015, I was given the opportunity to explore the topic of “Empirical Management” at the OOP congress in Munich.

One of the attendants, Fabian Schiller, shared not only his satisfaction over my talk verbally with me afterwards, he was also so kind to share a visual representation of my session:
IMG_2046

You will recognize how the talk covered the smell over many adoption, scaling or transformation efforts, the (needed) focus on value, and empirically managing software upon evidence of value.

A huge thanks to Fabian, and the rest of the audience.

  • Find the slide deck of my presentation at SlideShare
  • Find an interview on the subject at InfoQ
Posted on by — 4 Comments

Tactics for a Purpose – The Daily Scrum’s questions

In my book “Scrum – A Pocket Guide” I distinguish the rules of Scrum from tactics to implement the rules.

  • The rules of Scrum reflect the principles, values and empirical foundation of Scrum. They provide boundaries and a frame to augment self-organization.
  • Tactics are possible good practices. A tactic should be selected, tried and tested, made right-size and fitted to context and circumstances, or be rejected.

Over the years the basic elements of the Scrum framework remained the same, as did the principles and rules that bind them together. But the mandatory prescriptions of Scrum grew… lighter. The focus shifted toward describing ‘what’ is expected as opposed to instructing ‘how’ to achieve that outcome.

There are many tactics to use within Scrum. Good tactics serve the purpose of Scrum. Good tactics re-enforce the Scrum values, rather than undercut them.

The Daily Scrum is a mandatory event in Scrum, a daily inspection of the team’s reality to adapt the Sprint plan to it. The Scrum Guide suggests that in the Daily Scrum every Development Team member answers three questions with regards to the progress of the team towards its Sprint Goal (Done? Planned? Impediments?).

Does that necessarily assure a great Daily Scrum?

Everybody might just answer the questions mechanically, as a personal status update, not opportunistically looking for the best way forward for the next 24 hours. They might be talking to the walls or to the Scrum Board, not exchanging information with the other team members. They might just make sure that they simply -well- answer the three questions, possibly just because the Scrum Guide says they must. The rules are formally followed without understanding the ‘why’ of the rules.

Is the team merely seeing Scrum as a methodology? Or is the team using Scrum as a framework for creativity, discovery and collaboration? Maybe the Daily Scrum event is only seen as an obligation, a meeting with a reporting purpose? Maybe the team feels pressured to make sure all their micro-tasks are logged, and they use the Daily Scrum to cover themselves against possible blame. It doesn’t help much when the three questions are merely formally answered, if the people involved don’t actually talk to each other. It doesn’t help much if no information is revealed that helps the team optimize its shared work plan for the next 24 hours against the Sprint Goal. The event turns into a missed opportunity to gain insight in the real situation, to inspect it and to adapt to it.

The goal of the Daily Scrum is to share information, and to re-plan the Development Team’s collective work so that they progress in the best possible way towards the Sprint Goal. That should be the background from which the Daily Scrum runs, not to blindly answer 3 questions from a ‘best practice’ stance.

Posted on by — 4 Comments

The house we didn’t know we wanted (the surprise that 2014 brought)

After the silent resurrection of 2010-2011 (with the birth of our daughter and my re-discovery of the path of Scrum) 2012 was a pivotal year. 2013 subsequently was pretty explosive in growth and global expansion of our views and lives. The first half of it, 2014 was turning out what we were hoping for, a year to harvest, a year to reap some fruits of those preceding years. But in June things changed. Unexpectedly.

A couple of years ago my wife had clearly hinted at spending our yearly holidays in the US in 2014. It had something to do with her reaching an unspeakable age in 2014. Part of the preparation for that trip was ordering a wheel chair for our son, who has Duchenne Muscular Dystrophy, to help us move faster through New York City.

IMG_1377The wheel chair made us realize that our house in the future would require more adaptations than we had already made for our son. We didn’t like that. What manifested suddenly was a partial elucidation on our overall feeling of being locked in. It explained how we made many considerations over the past years on our house, plans that were never made real. That was only re-inforced by looking beyond today and beyond tomorrow, into the future where both our sons, one with DMD and the other with Down Syndrome, might just stay at home always given their disabilities.

So, suddenly we found ourselves in a position that we were looking for a new house, something that we had never before even considered or were aware of. It was unexpected. Not unpleasant. We felt the urgency.

And then urgency was followed by opportunity. A rare combination, and we moved fast.

IMG_1794We discovered a beautiful house, built in 1975, having the amount of ground floor we were looking for (thinking of our son’s immobility), the space we were looking for (thinking of the long-term future). It had character and style, a rural look that we immediately fell in love with. It was not too far from where we lived. But… way beyond our budget. Or so we assumed. We went to visit the house, discovered it was more of a project than a house, but our minds were stuck on it. We discovered that rate of interests are historically low (a ‘positive’ effect of the banking crisis), and that the sellers of the house were willing to give in on their asking price. The smell of opportunity.

We decided to jump. The day before we took off for the States we signed all papers at the bank and the contract was finalized! We had a wonderful holiday in the US, and our fall was spent dreaming of our new house, and obtaining the keys on October 7th.

IMG_1914We subsequently set a goal, i.e. to spend Christmas in our new house. It was not a realistic goal, looking back. It required some miracles, like removing old carpets, scraping off old wall paper, getting craftsmen in to sandblast and clean old wooden stairs and floors, to check the plumbing, to order and get a new stone floor laid, to assure some base electrical installations, to pack and arrange the moving, to start selling our old house, and much more. IMG_2369But we made it. On Monday December 22nd we moved over all large furniture and spent our first night in our new, little cottage.
During the first week we only lost power 3 times and some other minor outages, problems that were all fixed at the root and would not have been discovered so quickly if we hadn’t just moved in like we did.

Now, the rest of our years can be spent on further renovating, redecorating, refurbishing, expanding, and restoring all sorts of facilities, hopes and dreams. It’s good to be fully aware of the fact that nothing ever is complete. It explains our restlessness. I am glad that it got restated in all of its beauty in our hearts and minds by getting a house that 6 months ago we didn’t know we wanted.

IMG_1975