Tag: Professional Scrum

Posted on by — Leave a comment

Promoting Professional Scrum (in Ukraine)

In March 2017 I enjoyed being in Kyiv (Ukraine) to open the first Scrum Day Ukraine, introducing “re-vers-ify“.

I am continuing to support my local friends of Scrum, Slava Moskalenko and Bogdan Misyura (Brain Rain UA) in promoting Professional Scrum in their region. On 27-28 April we organise a Professional Scrum Product Owner class in Kyiv. Join if you want to explore the diverse aspects of product ownership in Scrum!

With ‘Professional Scrum‘ we promote the use of Scrum beyond the mere following of the formal ceremonies (‘mechanical Scrum’), but employing Scrum from an understanding of the underlying values and principles. In our Professional Scrum workshops we follow the difficult path of helping people explore how to build on the empiricism of Scrum, the intelligence of people and the Scrum Values, to tackle difficult and complex challenges. The easy path would be to be instructors, treat attendants as mindless robots and give people easy black/white solutions. 

Posted on by — Leave a comment

Agile Greece Summit – netweek interview

Yiannis Mavraganis and a crew of Agile enthusiasts organized the first Agile Greece Summit on Friday 18 September 2015 in Athens. It was an honor to be there and give a talk on Nexus and Scaled Professional Scrum. I hope attendants got many ideas and inspiration from the sessions and from sharing problems and insights. I hope it helps the Greek economy in these difficult times.

Netweek logoPreceding the event George Fetokakis published an interview with me in the Greek IT magazine netweek.

Netweek interview (Greek)The publication was in Greek. Thanks to George I can share the English version here. George published it under the header “Respect for developers”:

  1. What is Scrum?

Scrum is a lightweight framework for complex product development. Scrum has, by design, a minimal, yet sufficient, set of rules and roles. Scrum prescribes no techniques or practices to apply these rules to allow teams and organizations to devise the best possible tactics, depending on their context, to apply Scrum. 

All basic rules of Scrum are described in a lightweight document, the Scrum Guide, which is available at http://www.scrumguides.org. The Scrum Guide is maintained by the co-creators of Scrum, Jeff Sutherland and Ken Schwaber.

  1. Do you see any challenges in the organizations which use only Scrum? What do you think are some of the big threats to Scrum adoption or growth?

In my 2013 book, “Scrum – A Pocket Guide”, I describe two future challenges of Scrum. 

The first challenge concerns the way the role of the Product Owner is fulfilled. We often see that representatives or proxies of product management are fulfilling the role. The benefits realized through Scrum would be higher if product managers would directly engage in Scrum, through the role of the Product Owner.

The second challenge is the improved understanding and adoption of Scrum by management, think about operational IT management, sales divisions, delivery managers, product departments and hierarchical CxO management.

I would add a third challenge, related to scaling. Many organizations have adopted Scrum and see the benefits at the scale of one or some teams. Organizations pursue the same benefits with many teams, but struggle in scaling Scrum while respecting the principles and foundations upon which Scrum are built.

  1. Why should a Development Team choose Scrum?

Scrum thrives on self-organization, inviting and inspiring Development Teams to plan, organize and track their own daily work. Product Owner set out a vision and goals against which Development Teams work. Stakeholders are expected to provide the Development Team with new or changing insights by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter.

Scrum fundamentally restores the respect for the creativity and intelligence of Development Teams, allows them to fully exploit their skills and insights.

  1. What is Scaled Scrum and how important is this method for big software development projects?

‘Scaled Scrum’ is any implementation of Scrum in which multiple Scrum Teams create one software system or product. The purpose of Scrum, independent of the scale at which it is used, is to create high-quality, releasable versions of product by the end of every Sprint. This allows organizations to quickly and regularly serve their customers, and to incorporate feedback into the development process fast. It is what we call ‘business agility’. It is crucial for companies to survive and prosper in today’s fast changing economy.

At a larger scale, keeping a high level of such agility is highly important. It assures companies of flexibility and responsiveness. Translated to the adoption of Scrum for product development, it holds that the big challenge of scaled Scrum holds the ability for multiple teams to produce releasable software by the end of every Sprint.

Our Nexus framework provides organizations with guidance on how to grow and scale Scrum, on how to implement Scaled Professional Scrum.

We recently published the Nexus Guide at our website, https://www.scrum.org/Portals/0/NexusGuide%20v1.1.pdf

Posted on by — 2 Comments

Scaled Professional Scrum – Nexus (Nederlandstalig)

Op de Scrum.org  website publiceerde ik recent de whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF).

Hierbij vindt de geïnteresseerde lezer dit document in (een licht aangepaste) Nederlandstalige versie terug als “Scaled Professional Scrum – Whitepaper (Nederlandstalig)”.

Achtergrond:

Scrum is een framework voor complexe productontwikkeling.

  • “Scaled Scrum” omvat elke implementatie van Scrum waarbij meer dan één team een product realiseert.
  • “Scaled Professional Scrum” omvat elke implementatie van scaled Scrum die bouwt op de fundamenten, principes en waardes van Scrum, met inbegrip van software development professionalisme.

Het framework voor Scaled Professional Scrum van Scrum.org biedt de ruggengraat waarop organisaties hun productontwikkeling op basis van Scrum kunnen opschalen mèt behoud van de eigenheid en de voordelen van Scrum. Het framework bundelt de practices, ervaringen en inzichten van een wereldwijd netwerk van experten, waaronder Ken Schwaber en Jeff Sutherland, co-creators van Scrum.

Het kloppend hart van Scaled Professional Scrum is een Nexus, een ‘exo-skeleton’ voor Scrum. Een Nexus implementeert het Scrum proces zodat 3-9 Scrum Teams zo efficiënt mogelijk gezamenlijk aan één product kunnen werken.

Nexus_Titled_Transp

Het Scaled Professional Scrum framework bevat 40+ practices. Elk van deze practices, indien met kennis en kunde geselecteerd en geïmplementeerd, kan de werking van een Nexus optimaliseren naar een specifieke context.

Posted on by — 4 Comments

Introducing Scaled Professional Scrum – Nexus

Scrum is a framework for complex systems development.

  • Professional ScrumScaled Scrum is any instance of Scrum involving more than one team creating and sustaining a product or system.
  • Scaled Professional Scrum is any instance of scaled Scrum that thrives on Scrum’s formal rules and roles, complemented by software development professionalism, and Scrum’s values and principles.

The Scaled Professional Scrum framework of Scrum.org provides guidance to organizations engaging in efforts to scale their product development done through Scrum. The framework cohesively integrates practices, experience and insights gained from efforts to scale Scrum worldwide, including the substantial efforts that involved Ken Schwaber and Jeff Sutherland, co-creators of Scrum.

At the heart of Scaled Professional Scrum is a Nexus, an ‘exo-skeleton’ for Scrum. A Nexus employs the Scrum process to inter-connect 3-9 Scrum Teams building one product.

Nexus_Titled_Transp

The Scaled Professional Scrum framework holds 40+ practices. Each of these practices, if chosen and used against context, augments the operation of the Nexus.

The whitepaper “Scaled Professional Scrum – Rationale of the framework” (PDF) is now available through the Scrum.org website.

At the “Scrum Day Europe” event of July 2 in Amsterdam I introduced the Scaled Professional Scrum framework of Scrum.org and the Nexus in my opening keynote. Find the presentation at SlideShare. The recording of the session is available at YouTube.

Posted on by — 9 Comments

Done is a crucial part of Scrum, actually

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. The typical term in Scrum to describe the state of software being releasable is “Done”. All that this state of releasability encompasses is captured in the “definition of Done”.

Done Increments are THE way to achieve agility through the empiricism of Scrum. 

Empiricism

The empiricism of Scrum, the process of regular inspection and adaptation, only functions well upon transparency. Transparency is having insights into reality but is is additionally upheld through standards and agreements, against which inspection and adaptation happens. The definition of Done is such a standard. The definition of Done is part of professional Scrum development. Other standards, like development and engineering standards, might even be derived from the definition of Done.

The frequency of the inspection and adaptation should be high enough to be able to act in the moment yet not too high to preserve the ability to get considerable amounts of work done.

The definition of Done serves empiricism

The definition of Done should be shared, explicit, clear and concise.

A Development Team will use the definition of Done to consider the amount of work to be pulled into a Sprint during Sprint Planning.

The evolution of an Increment is managed via collaborative inspection and adaption of the actual development work against the forecasted Product Backlog and the Sprint Goal; at least on a daily base, possibly sooner. A Daily Scrum assures that the people accountable for the actual development optimize their work plan against new insights and achievements. The definition of Done supports identification of work remaining to get the software to “Done”.

No later than at the Sprint Review, the Increment is collaboratively inspected and adapted with the stakeholders. This inspection opens up the opportunity of incorporating feedback from these stakeholders to identify what is most important to do next. Purpose is the open identification of what is important to do next, not hindered by unknown, unpalatable, unestimatable remaining work.

Releasing the software closes the feedback loop to the market and the users of the software. Releasing sooner is better in order to remain in line with external expectations and experiences. It is the only way to ultimately validate all assumptions (of functionality, and others) built into the product. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility. The decision of releasing an Increment by the end of a Sprint is a Product Owner decision, as the sole representative of users and stakeholders on the Scrum Team. The Product Owner’s shipping decision should not be constrained by ‘development’ work.

Undone software is best not released. There might be situations in which undone software is consciously released. An extreme crisis maybe? The least to do is make the undone work transparent via Product Backlog, knowing and understanding that any estimate of such corrective work is probably totally off and the nature of the work unplannable. This ‘registration’ does not render an undone release any more professional, and probably the crisis you are hoping to solve with the unrelease, will re-appear because an unrelease will not fundamentally solve it. Unreleases backfire. Probably better to Scrumble.

At the Sprint Retrospective, the Development Team might inspect and revise its definition of Done; incorporating new insights, new expectations, higher standards. Ownership over the Definition of Done lies with the Development Team. It is their accountability to develop software that lives up to the definition of Done. In many organizations the definition of Done is likely to be derived from organizational standards for development quality. A Development Team will enact them, expand them. If “done” for an increment is not a convention of the development organization, the Development Team will create their definition of Done, appropriate for the product.

Regardless, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.

Done is a crucial part of Scrum, actually

Although no official artifact, the definition of Done is a crucial part of Scrum in upholding transparency over the state of releasability of the software created. No transparency means no meaningful inspections, and no meaningful adaptations of Product Backlog through stakeholder feedback upon review or through user feedback upon release.

In the last updates to the Scrum Guide (most recent: July 2013) the definition of Done was given considerably more attention. Rightfully, as “Done” is absolutely crucial in Scrum.

Here’s how I stressed the importance of Done in my book, “Scrum – A Pocket Guide“:

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.

 and

The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.

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 — 4 Comments

A Software Development Profession

Creative, artful thinking and craftsmanship are ESSENTIAL QUALITIES for any software developer. But shouldn’t software development be about more than an act of art, a craft in best case? Isn’t there a need to add professionalism to it? Shouldn’t software development be a profession?

It is tempting to believe that software development already is a profession. After all, many people are employed in developing software, making a living out of creating and sustaining the working code of software products and services, as a team or as individuals. Many more are employed in and make a living out of all the side-activities in the wider software development industry; like funding, exploiting, selling, promoting software products and services. This however is not sufficient to state that software development already is a profession.

Some take their dreams for real and call software development a profession. For others it is more a matter of pride, status or ego to say they are part of a profession, instead of an artisan discipline. That still is not enough to state that software development already is a profession.

A profession has regulations, codes, expectations and rules, all building upon a recognized body of knowledge. A profession sets explicit expectations on ethics, conduct and behavior to be demonstrated by any member of the profession. Official exams are in place for members to demonstrate a level of required skills and knowledge before receiving an attestation, and the permission to bear an official title that is protected and reserved. A healthy profession’s regulations and standards have a purpose, a purpose that goes beyond self-serving the profession and the profession’s institute. All regulations and standards should serve to assure the best possible execution of work in order to protect the people and organizations taking part in or being subject to the profession’s activities and its outcomes, and the decisions taken as part of it.

It is difficult to predict if and when software development might transform into a profession. It seems unlikely in a short term. There is the gigantic amount of software development work, there are the endless variations of what might be considered ‚software development,’ the absence of a widely accepted definition and understanding of ‚software development,‘ disagreement over the work activities that should or should not be part of the profession.

Reasonable doubts may be expressed on whether being a profession will augment the quality of service, avoid charlatanism, etc.

Furthermore a variety of people and instances may have personal, political, career, financial or other interests in software development, possibly even outside of the activity itself. Such people and instances might see regulation as a threat to their interests. Or might see it just as a limitation to their artistic freedom. Not to speak of the difficulty in growing a body, ethics, assessments, instructional guidelines and a code of conduct that would be widely accepted within the industry.

Where there are many elements that probably impede software development from growing into a regulated profession, there are also very valid reasons why software development would be better off if it transformed into a profession.

Not the least reason is the overwhelming and crucial presence of software in society and our daily lives. Software has become increasingly vital to society. A major shift is happening. Software products and software services are at the front and at the back of many public, industrial and consumer services and facilities. Software no longer is a ‚nice to have,’ for amusement purposes only. Software is at the heart of the economy. Software is core to many, often even critical, services in the private and in the public domain; financial services, taxes, energy, retail, health care, education, defense, telecommunication, transport, the automotive industry, just to name a few. Numerous organizations thrive on software. Even when they are not software companies, their services largely depend on software.

The omnipresence of software leads to a huge demand for talented and skilled software development people. The demand for professionalism that goes beyond talent and skills is less acknowledged but equally important in the light of the crucial functions of software in society. It would be comforting to know that the level of professionalism shown in the industry grew at the same rate as the growth of presence and criticality of software products and services itself, although even a higher rate is required.

Software development deserves professionalism in doing and in managing it. Such professionalism would benefit much from being structured in a profession.

This post is one of the inquiries I have planned into the values of professionalism in software development and the potential of the scrum framework to induce the formation of a software development profession. A matter of incremental writing. I hope you enjoy it, and the future follow-ups and iterations.

Posted on by — Leave a comment

Scrum Day Europe 2014

As from 2011 there has been a genuine boom of Scrum in the Netherlands. And it is still going on. A virus improving the lives of many people in the fascinating world of software development. I have worked with several Dutch organizations, of which ING is probably one of the biggest, one that I documented by the end of 2012.

In March 2012 Ken Schwaber, Scrum co-creator and my working partner at Scrum.org, asked whether I saw room for a Scrum event in the Netherlands. Yes, and we named it “Scrum Day Europe”. We set it up with 3 co-organizing companies around the ideas of “Software in 30 Days”. The goal was not to make it just another average agile event, so we went for a smaller event, with a clear management focus and much room for interaction. It turned out a great success, so a 2013 edition was organized with some small, incremental changes. Ken and I opened the 2013 edition with a keynote on the Agility Path framework for Enterprise Scrum that we were working on.

ScrumDay4Pros-logo_whiteThis year, 2014, will see the 3rd edition of the Scrum Day Europe event. The event is now part of Scrum.org’s prestigious Scrum Day for Professionals series. We have limited the co-organizing companies to our Scrum.org partner-in-principle Prowareness and have complemented that with a more substantial involvement of the communities. Because, in the end, Scrum.org’s role is to serve, help and facilitate the many Scrum practitioners out there, and this event is a great way to connect people and ideas.

The theme of 2014 will be “Evidence-Based Management”, on which I recently published a whitepaper called “Empirical Management Explored: Evidence-Based Management for Software Organizations“.  Ken and I will have the pleasure of opening the event again.

I look forward to meeting with great fellow Scrum travelers at the event, hoping YOU will be one of them. Have a look at the program and the speakers. Get your ticket via the Scrum Day Europe website, or directly at Scrum.org.

Scrum Day Europe 2014

Find all information on Evidence-Based Management at ebmgt.org.

Posted on by — 7 Comments

Ways to play Scrum

Scrum.org-Logo-CirclesIn our Professional Scrum classes we also talk about the topics of User Stories, Planning Poker and (Daily) Stand-up meetings. Some attendants have never heard of it. Some have never practiced it. Some are convinced, or have been instructed, that Scrum says these are mandatory to do.

I have grown my own little pattern to work with a class whenever we run into one of these topics during my classes.

  1. I start by asking what Scrum actually says on the practice. In general, people don’t know or are not sure, and conclude that Scrum says nothing about it.
  2. I ask where the practice then does come from, if it’s not Scrum. Few people know that it is eXtreme Programming.
  3. I end up by saying that, despite the XP origins, we do support them in many cases as they represent good ways to play Scrum, they are good practices to chose from. And that this is the reason why we cover them in the course; to inspire people with different options to play Scrum.

But, they are not mandatory from the Scrum framework described in the Scrum Guide:

  • Extreme Programming Explained: Embrace C16614_fUser Stories, written on story cards, are the practice in Extreme Programming to hold and describe requirements from a user perspective. Bill Wake, author of ‘eXtreme Programming Explored’, suggested the ‘INVEST’ acronym as a simple way to remember and assess whether or not a User Story is well formed.
    A Scrum Product Backlog though serves to provide transparency to all work that a Scrum Team needs to do, which might be more than only functional requirements. The obligation, from Scrum, to use the User Story-format would endanger forgetting other important work to be undertaken, or it might force teams spending more time and energy on using the ‘right’ format, thus creating waste. However, for functional items on the Product Backlog, User Stories may be very good.
  • Planning Poker was invented by James Grenning during an eXtreme Programming project where he suffered from having to spend much, much time on producing estimates.
    In Scrum, estimates are to be created by the Development Team and, although not mandatory, Planning Poker is a good technique to do that. It leads to more honest estimates from a complete team. But don’t forget that the intention is to invoke an honest conversation over the estimates. Because that results in a good understanding of the work attached to implementing the discussed item.
  • Daily Stand-up are described in Extreme Programming, which recommended participants stand up to encourage keeping the meeting short.
    Scrum describes this meeting as the Daily Scrum, but doesn’t oblige to do it standing up. However, it is a good idea to do, especially to keep the time-box of 15 minutes.

That is often a relief to students, knowing that it is not mandatory. And I am glad I can help people. I am glad they see more opportunities to discover their own best way to play Scrum respecting the intentions and design of Scrum. They see better how Scrum can help teams and organizations emerge their own process. These ways to play Scrum in teams’ specific contexts turn the selected good practice into best practices.

Scrum, after all, can be called a ‘process’, but it’s a servant process, not a commanding process.

Posted on by — Leave a comment

Writing Scrum Writings

On top of managing the agile offering of Capgemini (Dutch description here) as a Product Owner and mentoring our Scrum coaches and Scrum trainers I also give Professional Scrum trainings.

Scrum.org-Logo_with_taglineAfter my classes I send out a thank you to the participants in which I include some guidelines to prepare for the online assessment they get access to. I also point people to some background readings. Over time I have created a small library of blog notes I’ve written from which I can select some to refer attendants to for additional information on top of the courseware:

I always pick some of following topics to add:

Fyi. have a look at the most beautiful location I have ever trained in.