Tag: Agile Software development

Posted on by — 3 Comments

Branching Done

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. He accepted me to share his story here (with some abstractions, and calling him Jim) in an open-ended way, inviting the reader -much like he did- to reflect on the purpose and accountability of the Scrum Master and how that role is needed for… well, many reasons still.

Jim’s company started out doing Scrum on some smaller, carefully contained projects with individual Scrum Teams developing clearly separated products and product areas. Through these projects they discovered how iterative-incremental product development increased transparency, and how disciplined engineering practices allowed them to excel. Where Scrum in the beginning was much seen as mainly for IT people, they soon found out the need for a mandated Product Owner representing the internal business and the user base to the teams. They felt that hiring a Scrum Master with three years of experience had been really helpful.

One of these early projects was recently expanded to two teams. Both teams work on the same product and draw work from one and the same Product Backlog. The Product Owner and the Scrum Master perform their roles for both teams.

Jim contacted me after he was invited to and attended the second Sprint Review after the expansion to two teams.

At this Sprint Review the two teams took 60 minutes each to walk everyone through the software functionality they had created. Each team showed the work from their separated code branch. By the end of the Sprint Review, Jim inquired about releasing the software, but got an unclear answer. In the end it boiled down to the teams promising they would have a look at it, and discuss it with the release department who hadn’t been involved so far.

Jim felt like not straining the teams more but an uneasy feeling had crept in. After all, one of the reasons why they started adopting Scrum were their long release cycles, and unclear release dates. It had led to many customer complaints and even losing a couple of important customers.

When he asked for my advice I told him only I was very interested to hear about the conversation I suggested he set up with the Scrum Master. He seemed a bit surprised when I started talking about the role of the Scrum Master.

How about you? If any, where would you situate the accountability of the Scrum Master in this?

Posted on by — 10 Comments

Releasable in Scrum, actually

Scrum asks for a releasable Increment of product to be available ultimately by the end of every Sprint. A Sprint takes no more than 30 days, and is often shorter. A releasable Increment might be available sooner than by the end of a Sprint, not later.

The purpose of this rule of Scrum is to provide the Product Owner with the opportunity of bringing an updated, improved version of product to market every 1-4 weeks, or more frequent. It is how Scrum implements the first principle of Agile software development:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. (source: Principles of Agile Software Development)

Replacing the past wording of ‚shippable‘ by ‚releasable‘ reduced the room to avoid the rigor of releasing to the market frequently, but just shipping an Increment within the organization, the avoidance that abates the benefits and agility needed. The Scrum Guide adds the prefix ‚potentially’, to clarify that Scrum does not say that every Increment must be released. I prefer to leave this prefix out, because ‚releasable‘ in itself is clear enough. Otherwise “Released” would be required as the Increment’s state by the end of the Sprint.

Scrum lays the actual release decision with the Product Owner, as the representative of all (i.e. internal and external) stakeholders. The Product Owner’s decision is not to be limited by technical or engineering aspects. The product Increment is useable. If released, it does not break. That is the accountability of the Development Team. The Product Owner is accountable for assessing whether the Increment is functionally useful.

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. (…) This Increment is useable, so a Product Owner may choose to immediately release it. (Source: The Scrum Guide)

A Product Owner, being an entrepreneur, understands that no release means no feedback from the market place, no feedback from actual product usage. It means no validation of the assumptions built into the product, reduced learning, postponement of much anticipated improvements. In a way, it blindfolds development.

If a Product Owner decides to release an Increment, it is released. Preferably instantly. No additional work remains to do so. All work that mirrors ‘releasable’ is captured in a definition of Done. Defining “Done” creates transparency:

  • Transparency when forecasting work deemed feasible for a Sprint
  • Transparency when inspecting an Increment
  • Transparency over development progress
  • Transparency regarding the daily work required to have the software in a state of Done

Scrum, as a framework, can wrap various development strategies that increase the capability of creating a releasable (“Done”) version of product in a Sprint; pair programming, test-driven development, ATDD, BDD, Continuous Integration, DevOps, Continuous Delivery, Continuous Deployment. (note: Scrum promoting the Product Owner as the gatekeeper to release might influence how Continuous Deployment is organized.) Feature toggling is certainly an architectural choice that enables higher Product Owner dynamism.

Software being releasable, no later than by the end of a Sprint, is Scrum’s gateway to (business) agility. By the end of every Sprint, or sooner, an updated, improved product can be released to its users and consumers. Feedback can then be gathered to be incorporated into the Product Backlog, and ordered against all other product ambitions.

In Scrum, actually… releasable means all work done to release to the market. Instantly.
Posted on by — 5 Comments

Agile and Scrum, actually

In early 2001, with the creation of the Manifesto for Agile Software Development, the adjective ‘agile’ obtained a specific meaning in the context of software development. The manifesto, commonly known as the Agile Manifesto, holds 4 value statements with 12 principles behind it. In these values and principles the signatories of the manifesto captured the mindset, the DNA, common to their approaches to software development.

Over the years to follow, Agile became a proper noun, capitalized, pretty popular and ultimately big business as the methods for Agile software development were increasingly adopted. Success obfuscates and diminishes actionability, it seems. Today “Agile” is all over the place; coming in many flavors, wrappings, definitions, interpretations, and discounted. “Agile” sells. It is probably the most used prefix for roles, jobs, positions, functions and phases found in the software industry. The fact that Agile is a set of values and principles is easily ignored, as are the actual values and principles themselves.

Correlating ‘scaling’ to Agile has a similar neglect. Tactics change with scale. Strategies change with scale. Values and principles don’t change with scale. Claims and statements on the need, the ability, the inability, the whatever to scale Agile are plainly besides the point. Values and principles are agnostic of scale.

Agility, as an extension of Agile, refers to the state that people, teams, organizations hope to achieve by adopting Agile development processes. Agility, as such an extension, is a state of high responsiveness, speed and adaptiveness; a state of constant invocation of change, evolution and improvement. A state of agility enables people, teams, organizations to better deal with the natural complexity and unpredictability of the work of software development itself, the organizational context within which it happens and the external circumstances faced. The adoption of Agile indeed is an important foundation for this (business or enterprise) agility.

Scrum emerged in the early ’90s from the work of Jeff Sutherland and Ken Schwaber. They formalised and turned Scrum into a cohesive set of rules and roles for complex product development, that was formally presented to the public for the first time in 1995. The definition of Scrum, its rules and roles are described in the Scrum Guide. Both co-creators of Scrum are signatories of the Agile Manifesto. The values and principles of the Manifesto for Agile Software Development underpin the Scrum framework which thrives on empiricism and self-organization. Scrum is better understood when seen through the lens of the Agile Manifesto.

As with Agile, the Scrum Values and Scrum’s fundamental roles and rules as described in the Scrum Guide don’t change with scale. But scaled implementations of Scrum require different tactics in implementing the rules.

In Scrum, actually… Agile is the DNA driving the behavior throughout the software development ecosystem.

Agile and Scrum, actually, are two inseparable ingredients in a software development ecosystem.

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

Product Backlog and the Tea Leaves Effect

The Tea Leaves effectDo you like drinking a cup (glass) of tea? Ever had a tea bag that was torn? Spreading tea leaves in your tasty drink?

Then you know that such leaves circulate wildly and chaotically throughout your tea when you stir it, add water, or drink it. Science is somewhat more precise about the behavior of such leaves, calling it the tea leaves paradox, but let’s just stick with our more direct observations.

Floating tea leaves are best removed from the tea. It prevents obscuring of the tea, and makes a better and tastier drink. Most consumers prefer tea without such leaves. If not for the look of the tea, then certainly because it’s no fun to drink tea leaves.

The tea leaves effect is a good metaphor to understand the need to refrain from collecting and listing requirements in a Product Backlog endlessly. The tea leaves of your Product Backlog are those requirements that go up in ordering every time the Product Backlog gets stirred. They float around, obscuring your Product Backlog and decreasing its transparency, and they always sink to the bottom as the environment settles again.

Keep your Product Backlog clear, clean and tasty. Remove those features that cloud your Product Backlog. Remove those features that always sink to the bottom of what you plan for your product, and never get implemented. If those features are really valuable, they will pop up again at some point in time.

It connects to ‘trimming the tail‘ as described by Alistair Cockburn. The goal is to not build low value ideas. It sounds simple, the gains are considerable, but it takes much discipline. But you don’t want to feed your customers tea leave requirements, right?

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

Scrum is not an acronym

Scrum is a framework for Agile software development. Let’s have a look at the origins of the term ‘Scrum’. And, as a result, understand that it is not an acronym.

The term ‘Scrum’ was first used in the context of product development by Hirotaka Takeuchi and Ikujiro Nonaka in their ground-breaking 1986 paper “The New New Product Development Game“. They borrowed the name from the game of rugby to stress the importance of teams (and working as a team) in complex product development. This was about complex product development in general, not only software products. Their research showed that outstanding performance is achieved when teams are small and self-organizing units of people that are given challenges and objectives, not executable tasks. With management refraining from interfering on a daily base and managing from the outset. Teams can only achieve greatness when given room to devise their own tactics to best head towards shared objectives.

Rugby (as in)

Peter DeGrace and Leslie Hulet Stahl initially pointed out the potential of applying the “Scrum” practices from that paper to software development in their book “Wicked Problems, Righteous Solutions” (1990). However, they didn’t go into much detail on how the result would look like. Inspired by them, the pioneers of the way of working that we now know as “Scrum” inherited the name from that paper as their way of working thrived on the same principles for developing and sustaining complex software products. They additionally framed the core idea of self-organization with the boundaries of empiricism, i.e. the process of regularly inspecting in order to adapt.

The Japanese authors of the paper consider the concept that they named ‘Scrum’ as the necessary core of any system that pretends to be like the Toyota Production System (TPS), now often better known as Lean. But they never promoted copying TPS. And they never started using the term ‘Lean’ because it is typically synonymous to an outside interpretation and copy of the management practices of the Toyota Production System. The TPS management practices are not the core of the system. That core was named ‘Scrum’ by the authors and the six main characteristics of ‘Scrum’ were described in The New New Product Development Game. The management practices should be complementary to it. There can’t be Lean if the heart of it, Scrum, is overlooked, which in general is the case. The authors therefore always stress the need for the heart and soul of the system and take away the sole focus on the surrounding management practices. They never talk of Lean, but always speak about Scrum.

As Scrum is no acronym, there is no reason to write “SCRUM”.

Posted on by — 3 Comments

A smart travel companion to Scrum

Scrum is not a goal in itself, Scrum is a mean. Scrum is a path that a person, a team, an organization takes toward increased competitiveness, higher responsiveness, more learning, more creativity, optimistic opportunism, a sustainable way of working, restored respect for people. Scrum is a journey toward increased… agility.

I have written a book about Scrum, published on 4 November 2013.

Scrum - A Pocket Guide (A Smart Travel Companion)As Scrum is designed to help people, organizations and teams embark on a journey, my book is a smart travel companion for that journey. My book is a pocket guide that can help you prepare, take off, and get going. And while on the road you can always have a quick peek again to find your way or re-orient.

My book is completely focused on Scrum. It was an explicit choice to stick to the topic, Scrum. And to be essential about that. As David Starr, Agile craftsman at Microsoft, said upon reviewing an early version, it is “without a drop of hyperbole“. Ken Schwaber, my fellow-traveller at Scrum.org and co-creator of Scrum, says it is plainly the best description of Scrum currently available. Ken has also written the foreword, summarized as “An outstanding accomplishment that simmers with intelligence.”

The book has 4 chapters:

  1. The Agile paradigm. This chapter adds background and perspective to the movement that started with the “Manifesto for Agile Software Development.”
  2. Scrum. This chapter describes the roots of Scrum, the basic rules, roles and principles of the game, and the values underpinning the Scrum framework.
  3. Tactics for a purpose. This chapter introduces some common ways to play the game of Scrum. They are presented as tactics that are not formally prescriptions of the Scrum framework, not part of the rules of Scrum.
  4. The future state of Scrum. This chapter holds a look into the future and some evolutions I expect to happen.

Other appreciated reviewers were Ralph Jocham, Agile professional and Professional Scrum trainer, and Patricia Kong, director of partners at Scrum.org. Ralph says this is the book he will advise his students, coachees and organizations to read in order to learn the essential Scrum. Patricia says she would have loved to have this book when she entered the world of Scrum. Because she didn’t find one at the time.

The book, “Scrum – A Pocket Guide (A Smart Travel Companion)” will be published by Van Haren. My gratitude goes out to their team that has made this possible!

Pre-order your copy at Amazon (UK) or at the publisher’s webshop.