Year: 2013

Posted on by — Leave a comment

Sweden 2013 – A Family Holiday

The last couple of years we headed south for our yearly summer holidays, to Croatia, Italy, Spain; looking for the sun and making sure a swimming pool is around. For 2013 we decided to head north, to Sweden.

Before presenting my little summary of every day and a mosaic with one picture a day, let me share some take-aways first that popped up in my head during our 2 weeks in Sweden, Småland:

Nice bread. Big trucks. Quiet Saturdays. Much green. No elks.

Diary

Day 1, Friday August.2: Antwerp-Bremen. A bit stressed (as always at the start). Some hotel swimming and an outside German dinner at Prüser’s Gasthof in Hellwege (near Bremen).
Day 2, Saturday August.3: Bremen-Malmö. Relaxed (totally, finally). Taking the boat from Germany to Denmark (just in time), and crossing the famous bridge from Copenhague to Malmö. What a fine hotel (after turning a couch into a bed for the boys). Enjoying the evening at a square with a lovely fountain and modern eating of famous chefs.
Day 3, Sunday August.4: Malmö-Öreryd. Even more relaxed. Morning market and first vintage purchase in Malmö before headinf further north. Lunch in Halmstad. Arriving following the GPS. Depressed by the house. Found a supermarket though (in Gislaved) and the lake in Öreryd.
Day 4, Monday August.5: Jönköping shopping. Most relaxed (BIG!) lunch ever including caffé frappé; the children lovelier than ever during a relaxed lunch. Noa noa sales shopping for the women!!!
Day 5, Tuesday August.6: Öreryd beach day. Morning reading (see Books chapter below), Gislaved supermarket and… Öreryd beach by the lake. Sun after rain. Hurting my knee in an overcourageous jump into the water an and overheated barbecue in the evening.
Day 6, Wednesday August.7: Country day. Pleasant surprise: quilt shopping in Tyger o Ting, and a vintage lunch in Smålandsstenar and more money well spent.
Day 7, Thursday August.8: Regensprookjesdag (rainy legend day). Going to Ljundby mainly for the ‘Sagomuseet’ (fairytale museum). Finding more country stuff. Passing via mount Isaberg and its handcraft exposition on the way home. Tired. Rain.
Day 8, Friday August.9: Götebörg. A long, terrific day of shopping, eating and relaxing in a neat and soothing city. A tapas ending near the river. Little rabbit’s asleep.
Day 9, Saturday August.10: Lazy day Saturday. Morning reading, supermarket and… Öreryd beach by the lake. Swimming in the rain. Followed by a refreshing evening walk.
Day 10, Sunday August.11: Short day out to Gislaved. Eating in Smålandia, an ancient looking truck restaurant.
Day 11, Monday August.12: Astrid Lindgren day. Early up to be immersed all day, a long day, in the world of Astrid Lindgren. Little houses, big houses, little stories and big stories told, played and depicted. Presents for all! A fantastic highlight.
Day 12, Tuesday August.13: Rain. Escaped to tiny sun beams and a vintage lunch in Gränna, city of candy.
Day 13, Wednesday August.14: Rain. Escape to the swimming pool. Evening dinner in Jönköping.
Day 14, Thursday August.15: Garden day. Visiting the Gunilla gardens in Swedish Småland by Danish artist Tage Andersen. We celebrate mother’s day. The Swedish don’t. And we end with an expected sunny stay at an unexpected beach near lake Vättern Evening dinner at a Jönköping pier.
Day 15, Friday August.16: Lazy day of awakening slowly, starting to clean the house and going for another vintage afternoon lunch in Smålandsstenar, and vintage sales hunting in the connected shop. Nienke entering the Lega värld, with her first Lego Friends set.
Day 16, Saturday August.17: Last day. In search of the second hand super market of Gnosjö. Found. It’s still there. We closed the vacation with a tapas dinner by the water in Jönköping.
Day 17, Sunday August.18: Öreryd-Bremen. Back on the boat. Germany is definitely a terrible driving country. Same hotel, same swimming pool in Hellwege. Relaxed.
Day 18, Monday August.19: Bremen-Ekeren. Home. It’s been F A N T A S T I C. Only disappointment was the house we stayed in. But we explored the region, had great excursion and the kids never before were so at ease with our habit of irregular meal times and unexpected lunches.

Sweden 2013

Books

I have read following books on this holiday: Nightwing 2 (‘New 52’ series by DC Comics), Superman Earth One vol. 2, Quarks, chaos and christianity by John Polkinghorne, Mike Scott – Adventures of a Waterboy, De Maagd Marino by Yves Petry. The Polkinghorne book was meager, but the other ones were great. I particularly enjoyed Mike Scott’s lively tales of his various adventures!

I have an endless stock of books I still have to read (in our private library), but keep a list of specific books I want to read next. For diverse reasons my holiday reading made me overwrite my short term list and replace it with Rimbaud (Illuminations and Une saison en enfer), Nabokov (Lolita), Nietzsche (re-reading some works and consuming new wisdom), Stephen Hawking and Ludwig Wittgenstein.

Posted on by — Leave a comment

Weekendje Kamperen in Ambleteuse

Omdat onze oudste zoon zijn eerste tentenkamp achter de rug had met de scouts kregen wij de kriebels om nog eens te gaan kamperen met het gezin. Dat was verleden week. De weerberichten waren gunstig. Dus wij vertrokken zaterdag laatstleden naar Ambleteuse in Frankrijk. Ambleuteuse is een dorpje in het westen van Frankrijk bij het Kanaal.

Onze aankomst verliep niet helemaal onopgemerkt omdat een busje butaangas, bij een nochtans correct uitgevoerde vervangingsoperatie door mezelf, spontaan vuur vatte :-( Onze attente Belgische buurman gaf ons in alle kalmte een natte doek en het vuur was daarna zo weer uit. Mijn armen zijn enkel geschroeid, en mijn armhaar is dus wat gekortwiekt.

Maar verder verliep alles zalig. Lekker krapjes zitten aan de picknicktafel, en zondag een prachtige dag aan zee. De zee kwam nochtans erg snel op na onze aankomst, maar daar werden we netjes voor gewaarschuwd door een zeewachter. Zondagavond hadden we een erg geslaagde mini-barbecue. De kindjes lagen 2 dagen laat in ‘bed’ (slaapzak/tent).

Maandag sloten we af met een bezoekje aan Cap Gris Nez en Cap Blanc Nez. En toen zat het er weeral op. Het was G E W E L D I G !

Mosaic Camping in Ambleteuse

Posted on by — 4 Comments

Scrum: Tactics for a Purpose

Scrum is a framework designed to help teams create and sustain complex software products in complex circumstances through the scientific method of empiricism. Scrum has replaced the industrial, plan-driven paradigm with well-considered experimentation to better deal with the complexity and unpredictability of modern software development. And although the use of Scrum is free, its roles, artifacts, events, and rules are immutable. Implementing only parts of Scrum is possible, the result however is not Scrum. By breaking its base design it is likely that problems are covered up, instead of being revealed.

The purpose of Scrum is to help people inspect & adapt, to provide transparency to the work being undertaken, to know reality to base decisions on, to adjust, to adapt, to change, to gain flexibility. The rules, principles and roles of the framework, as described in the Scrum Guide, serve this purpose. These are the rules of the game of Scrum, the base setup to have in place.

Soccer - Rules of the game

But we distinguish principles from techniques, the what from the how, the rules of the game from tactics to play the game. It’s like in all games and sports, all players and teams play upon the same rules, yet some teams seem more successful at playing than other teams. It depends on many factors, and not all are equally controllable by the teams themselves. One factor are the tactics used by the team to play.

Soccer tactics on a blackboard

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

I’ve previously described how practices from eXtreme Programming provide great tactics, ways to play Scrum, even when not mandatory from the Scrum perspective.

Here are some more illustrations on the distinction between the purpose of Scrum and tactics for that purpose:

The Daily Scrum questions

The Scrum Guide suggests that in the Daily Scrum meeting every player of the Team answers 3 questions (Done? Planned? Impediments?).

But the players might just formally answer the questions, limit it to a personal status update, and talk to the walls or to the Scrum Board. They just make sure that they -well- answer the 3 questions. Because the Scrum Guide tells them to, or some smart coach or Scrum Master or manager.

But is the team seeing Scrum as a methodology? Or use Scrum as a framework for discovery? It doesn’t help much if they don’t talk to each other. It doesn’t help much if they don’t surface the information to optimize their collaborative work plan for the next 24 hours against the Sprint Goal. Maybe they use the meeting only as a reporting obligation in which they make sure all their microtasks are logged, to cover against possible blame. They miss the opportunity to gain insight in the real situation, to inspect it and to adapt upon it.

Maybe Scrum should describe only ‘what’ is expected from the Daily Scrum in the time-box of 15 minutes. Although, actually, the Guide already does so by saying: “The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours.” We could eliminate or rephrase how this is exactly to be achieved, in turning the 3 questions into a good, yet non-mandatory, tactic.

The Definition of Done

The Definition of Done was rightfully given a lot more attention in the latest version of the Scrum Guide. However, some people wonder why it isn’t an official artefact. I did so too, even launching the suggestion to make it one. However, I got to see that the Definition of Done is an aid to transparency, and I overcame my urge to turn it into an artefact.

Here’s how the Definition of Done helps playing Scrum:

  • Scrum assumes an inspection of a working product Increment at the end of every Sprint, at the Sprint Review. The Definition of Done gives transparency to that inspection by unveiling what’s the work that has been done upon the Increment, what criteria were met.
  • The Definition of Done guides the team at the Sprint Planning to pull work into the Sprint, as the work needed to get to “Done” is likely to influence the amount of Product Backlog that can be pulled into a Sprint, as well as the estimates for that work -if the team uses any-.
  • The Definition of Done helps the team create and manage their work plan for the Sprint in getting things done, and not end up with a pile of nearly-done work at the end of a Sprint.

So, what Scrum requires is transparency. The Definition of Done is a way to provide that transparency at several levels and several occasions. It’s a great tactic that stresses the importance of seizing the opportunity to ship.

Product Backlog Grooming

Product Backlog grooming is an activity in which the Development Team and the Product Owner look at Product Backlog currently sorted for one of the next Sprints. Certainty that the included items actually are going to be implemented is growing. So teams might want to unveil dependencies or help a Product Owner understand what is useful to know from a development perspective. Grooming increases the chances to pull the work in more easily when it is presented at the next Sprint Planning.

Product Backlog grooming is not a mandatory (time-boxed) Scrum event. The ambition of Scrum is to remain simple, yet sufficient. The ambition of Scrum is to help people and teams discover additional practices that may or may not be appropriate in their specific context. Product Backlog grooming is an activity that seems to help many teams to smoothen their Sprints, and certainly limit turbulence in the first days of a Sprint. Other teams however cope without it, and perceive it as optional or even overhead if it was mandatory from the Scrum framework.

Product Backlog grooming is a great activity within a Sprint, a good tactic to collaboratively manage Product Backlog. Some can do without however.

Sprint Planning Part 1+2

Sprint Planning meeting is an opportunity to inspect the actual state of Product Backlog and identify what work is most useful and feasible at the actual point in time, with the option of pouring the work into a work plan for the Sprint.

The empiricism of Scrum assumes following for the Sprint Planning:

  • IN: Product Backlog
  • OUT: Sprint Goal & Sprint Backlog

Currently the Scrum Guide prescribes the flow of the Sprint Planning meeting:

  • Part 1: Product Owner explains highest sorted Product Backlog items. The Team discusses, evaluates and pulls in items. A Sprint Goal is crafted.
  • Part 2: the Team decomposes, discusses and designs the work.

It is however possible to respect the IN and OUT of the Sprint Planning meeting upon a different flow of the meeting. Maybe Scrum can suffice by describing only ‘what’ is expected from the Sprint Planning in its time-box without prescribing ‘how’ the Scrum Team should achieve this. Organizing it in a part 1 + part 2 might be a great tactic, but it’s probably not the only one.

Posted on by — 89 Comments

There’s value in the Scrum Values

Notice: following is my original description of the Scrum Values. I won’t be touching this description. I have however since the inception of this description (2012) slightly updated the descriptions. Find the latest version at https://guntherverheyen.com/the-scrum-values/ and the international translations at https://thescrumvalues.org.

Find and book a seat in the planned sessions of my Scrum Pocket Class to explore “The Value in the Scrum Values” via my webshop.

Scrum is not a methodology. Scrum is a process, but of a non-repeatable kind. Scrum is a framework of rules, roles and principles. The framework helps people and organizations discover what works best for them. Their real process emerges, and is specific and fitting to their time and context. Scrum can wrap existing product development practices or render them superfluous. The benefits of Scrum are greater when complemented by improved or revised engineering, product management, people and organizational practices. The prescriptions of Scrum have been limited to the essence. Every element of Scrum has a goal. Changing the core design of Scrum, leaving out elements, not playing the game by its base rules, covers up problems and limits the benefit of Scrum and any additions on Scrum, up to the level of making it utterly useless.

Less known than the process of Scrum and probably under-highlighted, but therefore not less important, are the core Scrum Values upon which the framework is based: Commitment – Focus – Openness – Respect – Courage. These values relate to the ethics of Scrum, thereby -from a social point of view- turning Scrum into a value system.

Although not invented as a part of Scrum, or exclusive to Scrum, these values give direction to our work, our behavior and our actions. In a Scrum context the decisions we take, the steps we take, the way we play Scrum, the practices we add to Scrum, the activities we surround Scrum with should re-enforce these values, not diminish or undermine them.

I have found it very useful to bring these more out in the open, as a way to assess the desirability our actions and activities. It’s even a great help in thinking about applying the Scrum framework itself. It is possible to do Scrum as if it was a methodology; organize the meetings, direct all players on every possible detail for every possible action within the framework. But is the framework then being used for what it’s designed for? Won’t it leave the individual, the team and the organization with limited improvements?

A good illustration is how I’ve observed some teams doing their Daily Scrum. Everybody answers the 3 questions (Done? Planned? Impediments?), in a slightly spontaneous way or -worst case- when asked for by a Scrum Master-pretend. But does the team use the meeting to share information, to collaborate in re-planning their work for that day, making sure they don’t get out of line with one another for more than 24 hours, to get the most out of the Sprint, in moving forward to the Sprint goal? Or do they talk to the board instead of to each other? Do they only use the meeting to make sure that the board holds all their micro-tasks so their work is logged?

Here’s some detailed view on the values, and how they can guide our actions and behavior in a Scrum context:

Commitment

There is a widely spread misinterpretation of the word commitment in a Scrum context. This originates mainly from the past expectation of Scrum for teams to ‘commit’ to the Sprint and the selected Product Backlog items. Upon the old, industrial thinking (that ruled software development for too many years) this was wrongly turned into the expectation that all scope would be delivered, no matter. ‘Commitment’ was wrongly turned into a hard-coded contract although it was always intended as an indication that the team would do the maximum possible effort in the Sprint and be completely transparent about progress. And in the complex, creative and highly unpredictable world of software development a commitment on scope is impossible anyhow.

And the definition of the word, according to Oxford Dictionaries, describes exactly how it was originally intended in Scrum:

Definition of Commitment

So, commitment is about dedication and applies to the actions, the effort, not the final result.

Yet, in the Scrum Guide we replaced commitment as a result of the Sprint Planning with forecast. Because of the relationship with scope it helps getting explicitly rid of the wrong interpretation. And fortunately ‘forecast’ greatly aligns with the empirical nature of Scrum too.

Still, commitment is and remains a core value of Scrum.

We commit to the team. Commit to quality. Commit to collaborate. Commit to learn. Commit to do the best we can, every day again. Commit to the Sprint Goal. Commit to be professional. Commit to self-organize. Commit to excellence. Commit to the agile principles. Commit to create working software. Commit to look for improvements. Commit to the Definition of Done. Commit to the Scrum framework. Commit to focus on Value. Commit to finish work. Commit to inspect & adapt. Commit to transparency. Commit to challenge the status-quo.

Focus

An iterative-incremental approach like Scrum and the time-boxing of Scrum allow us to focus. We focus on what’s most important now without being bothered by considerations of what at some point in time might stand a chance to become important. We focus on what we know now and YAGNI (You Ain’t Gonna Need It) helps retaining that focus. We focus on what’s most nearby in time as the future is highly uncertain and we want to learn from the present to gain experience for future work. We focus on the work to get things done. We focus on the simplest thing that might possibly work.

Openness

The empiricism of Scrum requires transparency, openness. We want to inspect reality in order to make sensible adaptations. We are open about our work, our progress, our learning and our problems. But we are also open for people, and working with people; acknowledging people to be people, and not resources, robots or replaceable pieces of machinery as software development -after all- is still the work of humans. We are open to collaborate across disciplines and skills. We are open to collaborate with stakeholders and the wider environment. Open in sharing feedback and learn from one another. Open for change as the organization and the world it operates in change unpredictably, unexpectedly and constantly.

Respect

We show respect for people, their experience and their personal background. We respect diversity (it makes us stronger). We respect different opinions (we might learn from it). We show respect for our sponsors by not building features that nobody will use. We show respect by not wasting money on things that are not valuable or might never being implemented or used. We show respect for users by fixing their problems. We respect the Scrum framework. We respect our wider environment by not behaving as an isolated island in the world. We respect each other’s skills, expertise and insights. We respect the accountabilities of the Scrum roles.

Courage

We show courage in not building stuff that nobody wants. Courage in admitting requirements will never be perfect and that no plan can capture reality and complexity. Courage to consider change as a source of inspiration and innovation. Courage to not deliver undone software. Courage in sharing all possible information (transparency) that might help the team and the organization. Courage in admitting that nobody is perfect. Courage to change direction. Courage to share risks and benefits. Courage to promote Scrum and empiricism to deal with complexity. Courage to let go of the feint certainties of the past. We show courage to support the Scrum Values.

Posted on by — 4 Comments

Veilig aangehaakt, bij vake aan de fiets

Paul van Vliet heeft vele mooie liedjes, maar eentje heet “Veilig op de fiets”. Het beschrijft de veiligheid en geborgenheid die een zoon voelt, jawel, achterop bij zijn vader op de fiets.

Veilig achterop bij vader op de fiets
Vader weet de weg en ik weet nog van niets
Veilig achterop, ik ben niet alleen
Vader weet de weg, vader weet waarheen

Onbewust dreven het voorbije weekend mijn gedachten in de richting van dit lied, het weekend dat we de aanhangfiets voor onze Down-zoon, Jente, in gebruik namen. Deze aanhangfiets zorgt ervoor dat we voor korte trips niet steeds de auto moeten nemen. En ik hoop dat Jente ook vreugde en veiligheid voelt onder het mom “Veilig aangehaakt, bij vake aan de fiets”.

Jente op de aanhangfiets


Posted on by — Leave a comment

Lentepoetsballonkunst(enaar)

Van AOp 27 april 2013 was het weer lentepoets in de Antwerpse wijken ondersteund door Opsinjoren van de stad. Vooraleer wij onze straten en straatkanten aanpakten, organiseerde ons Weegbree-buurtcomité eerst echter een brunch. Gelukkig genoeg was het mooi weer, dus konden we lekker in openlucht zitten.

Daarnaast was ook een ballonkunstenaar voorzien om de kinderen te entertainen, Wouter. En, wow, we waren onder de indruk. Iedereen kent de klassieke clown annex ballonknutselaar die een zwaard maakt, of een hoed, of een hondje van ballonnen. Maar Wouter maakte er net wat meer werk van.

Voor onze kleine zus Nienke maakte hij een evenbeeld en voor broer Jente een kabouter Kwebbel. Grote broer Ian vroeg een draak, een ‘uitdaging’ die Wouter heel ernstig nam, zoals je kan zien. Hij transformeerde Ian zowaar helemaal in een draak van ballonnen.

Nienke BallonnenevenbeeldJente BallonnenkwebbelIan Ballonnendraak

Posted on by — 4 Comments

Moving to the home of Scrum

Why I look forward to working with Ken Schwaber and being part of Scrum.org, the home of Scrum.

Less than a year ago I was wondering about rather surprising evolutions in my professional life of Scrum. I retrospected to find that some things take time, can’t be rushed, let alone be predicted. Ending up with the feeling of being carried to places one never imagined of entering.

That was June 2012. Now is April 2013.

Over the past years Ken Schwaber and I have developed, almost by accident, a great personal and working relationship. Beyond that, I have an awesome contact and understanding with the Scrum.org team. Both aspects contributed to my well-being, made me feel good, respected, cherished even at times. And that was just fine. It helped, it inspired me in my work, it gave me opportunities to bounce ideas off.

Very recently, my daily times and work got into turbulence, with my stress levels going red. I realized that few people understand, understand what drives and motivates me. Hmm, some would say it’s just frustration born out of stubbornness and impatience. Ken and I tightened the relationship. Until we decided to move it to a formal level. And in no more than 1 week we completely arranged for my move to the home of Scrum and become part of the Scrum.org team.

It wasn’t planned. It happened. It emerged from a chaotic situation of doubts, searching, thinking and many considerations.

Who would have guessed?

Being a bit of an anarchist myself, I consulted with knowledgeable dilettante people in that 1 week. Opinions were unanimous: it won’t be a picnic, it will be an adventure, highly challenging, but fascinating and brilliant. Hmm, Ken himself says it will be a walk in the park. But that’s probably because he knows of many past motions that I have gone through. And, despite some controversy and him being a mule, few people would doubt Ken is an honorable, intelligent and trustworthy person to work with.

Luckily we consider ourselves just about weird enough to work with each other. We are both impulsive, impatient. He’s a mule, I’m stubborn. We have much in common; above all we seem to share many views and values. We go for vision, focus and creativity. And I am proud to be creating a little room of the house of Scrum in Antwerp, Belgium, Europe. I’ll be joining a great team, and serve the communities of Scrum practitioners, promoters of Scrum and our Scrum.org Professional Scrum trainers; thriving on autonomy to work on my mastery in Scrum and Enterprise Scrum from the purpose of making this world a better place to live and work in.

Type I behavior: A way of thinking and an approach to life built around intrinsic, rather than extrinsic, motivators. It is powered by our innate need to direct our own lives, to learn and create new things, and to do better by ourselves and our world.

Ken and I made up a little news announcement to express our excitement. Find it here: News – Ken Schwaber and Gunther Verheyen tighten relationship.

Scrum.org Logo

Posted on by — 5 Comments

The Value of the Product Backlog

Grafx - Scrum Gameboard (non-branded)Scrum is a light-weight framework with a minimal set of rules. The rules help people to empirically make the most out of every single day of creating software products. Next to 3 roles and 5 events, Scrum requires no more than 3 artefacts:

  • Product Backlog
  • Sprint Backlog
  • Increment (Potentially Shippable –)

Product Backlog holds desirements

It is often said that the Product Backlog must capture all requirements. However, the Product Backlog is not a replacement for the old requirements list. This would limit it to a new name for an old habit. The value of the Product Backlog lies not in precision, in detail or in perfection, like the requirements lists pretended.

The Product Backlog is an ordered list of ideas, features and options to bring an envisioned software product to life or sustain and grow it. The list may include fixes, maintenance work, architectural work, or requirements for security, scalability, stability and performance. Each item on the Product Backlog seems at some point in time valuable for a customer. Every item on the Product Backlog holds just enough detail to make clear what it represents, but the item is also intentionally incomplete to invoke additional and explicit conversation over it. Even the definition of ‘just enough’ varies over time; items on the Product Backlog that are far away in time (ordered low) need even less detail than items that are nearby in time (ordered high).

Gradual Product Backlog Refinement

I like the term ‘desirement’ for a Product Backlog item. The level of description and detail of the item lies somewhere between what used to be a desire and what used to be a requirement; where a ‘desire’ is too fuzzy to work on and a requirement is over-specified and over-detailed. And over-specification impedes an optimal use of technology, blocks capitalizing on synergies between different functions and is a waste of money in situations of even minimal turbulence or change.

As life progresses and the earth keeps turning, Product Backlog in Scrum gets refined, adjusted and updated. The list is continuously sorted and re-sorted by the Product Owner, who thereby looks to balance the needs of all stakeholders. And by continuously keeping to ‘just enough’ descriptions and designs of the work, i.e. leaving out unnecessary details, no excessive money and time is wasted when the item in the end doesn’t get created or is implemented in a different fashion.

Product Backlog is all the plan you need

Desirements move upon their ordering from Product Backlog via Sprint Backlog into Increments of working software. To know their cost, each is assigned an idea of the effort to get it done. The cost is generally expressed as the relative size of the item. Based upon the empirical past that showed how much work on average could be transformed into a working Increment during a Sprint, an expectation can be created on when an item on the Product Backlog might become available in the evolving product. It gives predictability, yet not transgressing into predictions given that any such expectation is constrained by today’s knowledge and circumstances.

  • In a traditional plan all requirements are gathered, listed, described, analyzed, estimated and decomposed upfront. All tasks for all requirements are elaborated, sequenced and resource-wise assigned. This way the total time is determined it will take to build the plan, where ‘follow the plan’ determines the success. Dependencies are handled via the detailed tasks, their sequence and their mutual impact.
  • In the ‘just enough’ approach of Scrum however, there is no need to plan all tasks for all ‘requirements’ upfront. Desirements are gradually discovered and refined, and they are only converted into development work when included in a forecast for a particular Sprint. The forecast is based upon the relative size indication and the past progress.

Product Backlog is all the plan you need, its desirements hold all the information needed for predictability about scope and time (if that’s what you need).

There is value in value

Priorities in traditional approaches are, besides ease of work and loudmouths, mostly based upon effort and risk. This is a focus on the internal process.

An important principle of agile however is “to satisfy the customer through early and continuous delivery of valuable software.” While the ordering of Product Backlog items happens upon a complex combination of factors like dependencies, priority, cohesion and consistency, most interesting is the required addition of a notion of (Business) Value. Without it, a Product Owner has no idea on how much value a feature, an idea or a feature set presumably brings to the customer whom he/she represents to the Scrum Team. The value can be indirect, in it that not picking up a Product Backlog item might undercut the value of the system or even the organization, or produce negative value.

The notion of (Business) Value also helps Product Owners and their stakeholders move away from the (false idea of) perfection of a total product that must be completely built before releasing. Focus shifts to a minimal marketable product release, the minimal work it takes to bring as much value as possible as soon as possible to the marketplace. Techniques like leveling up can be used to group Product Backlog items into cohesive feature sets.

The value of the Product Backlog

Above all, the value of the Product Backlog lies in transparency, in making clear what work needs to be done in order to create a minimally viable and valuable product (or product Increment). The Product Backlog brings out in the open all work, development, compliances, and constraints that the team has to deal with to create releasable software.

However, too often (and especially in traditional software development environments) the sequence of implementation is based upon priorities like MoSCoW, thus leading to opaque, large clusters of requirements, loss of focus and heavy releases. Therefore, to build valuable stuff, there is value in defining, considering and adding value to Product Backlog items. A Product Backlog item needs the right attributes to be ordered, more than just prioritized.

Posted on by — Leave a comment

Scrum Day Europe 2013

Scrum Day Europe

On 11 July 2012 the first edition of the Scrum Day Europe was organized. The theme of the day was “Software in 30 Days”, after the book that Ken Schwaber and Jeff Sutherland published in April 2012. In line with the book, our objective was to address executive people of organizations interested in or already adopting Scrum. Over 130 attendants came and made out an uncommon audience for an agile conference, turning it into not your average agile conference but with tons of energy and enthusiasm.

On 4 July 2013 the second edition of the Scrum Day Europe will be organized. The 2013 theme is “Enterprise Scrum“, after the new C-Scrum framework for Continuous Improvement that Scrum.org has developed. I was so lucky to be deeply involved in this great evolutionary step in the existence of Scrum. Ken Schwaber will again open the day with a keynote. Yours truly will also do a session again. The program will be further developed soon.

Be quick, seats are limited so we can unlimit energy and interaction.

Scrum Day Europe Banner

Posted on by — 34 Comments

Scrum: Framework, not methodology

Scrum is not a methodology

Scrum has no exhaustive and formal prescriptions on how to design and plan the work, actions and behavior of all players involved in product development against time, let alone how such designs and plans would have to be documented, approved, stored, etc. Scrum has no rules for upfront predictions of document types and (intermediate) deliverables to be produced or the time at which they should be produced. Instead of installing and thriving on hand-overs, toll gates and control meetings like IT methodologies typically do, Scrum helps eliminating them as a major source of delays and waste.

Scrum has its roots in the world of software development. In that world, ‘methodologies’ are by design composed of stringent and mandatory sequences of steps, processes and procedures, implementing predefined algorithms and executors for each step, process or procedure. As such, methodologies tend to rule out the creativity, autonomy and thinking of people with components like phases, tasks, must-do practices, techniques and tools. As long as the methodology is being followed everyone feels safe, because they are formally covered, even in the absence of working results or proven progress. Methodologies depend on high degrees of predictability, otherwise the preset algorithms fail. Complex problems, for which Scrum was designed, are more unpredictable than they are predictable. Today’s world has more complex challenges than simple cases.

Scrum is not a methodology. Scrum is even the opposite of such big collections of interwoven mandatory components and instructions. Scrum implements the scientific method of empiricism, the process of inspecting in order to adapt at regular intervals, not aspiring to try to predict what the adaptations will be. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and thriving on the self-organizing capabilities of people to deal with unpredictability and address complex challenges.

Is Scrum a process?

If Scrum is a process, it is certainly not a repeatable process. That might be a challenge to explain, because the term ‘process’ typically invokes a sense of algorithmically predictable steps, repeatable actions and enforceable top-down control; the sort of expectations that in our world are typical for a… methodology.

Scrum is not a commanding process. If referred to as a ‘process’, then Scrum is a servant process. What works best for all involved players, their working process, emerges from the use of Scrum. The players discover the work required to close the gap between an inspected intermediate result and an envisioned outcome. Scrum is a process that helps surface the real (daily) process, structures and a way of working that are continuously adapted to the actual context and current circumstances. Therefore we call Scrum a… framework.

Scrum is a framework

Scrum describes the roles and rules upon given principles that help and facilitate people in a low-prescriptive way, that help people create a framework for regular inspections and adaptations. The Scrum Guide holds the definitive description of the base rules of the game. The prescriptions are minimal, but every single one of them addresses dysfunctions that were (and are) common in (software) product development.

Over the 2+ decades of Scrum, the rules of Scrum, as captured in the Scrum Guide, have gradually evolved, with small functional updates and releases. The prescriptions of Scrum, what needs to be in place to have the full benefits of Scrum, become more and more focused on emphasizing ‘what’ is expected in developing complex products over instructing ‘how’ to do it.

A good illustration of such an evolution is the elimination of burndown charts from the Scrum framework as mandatory (a ‘how’ of managing progress). This obligation however has been replaced by the explicit expectation that progress on the mandatory Scrum artefacts, the Product Backlog and the Sprint Backlog, is visualized (the ‘what’). The form or format of the visualization is no longer prescribed, thereby turning burndown charts into a non-mandatory, but still good practice; a good way to play the game and suitable in many situations.

Yes, it’s Scrum if Product Backlog and Sprint Backlog exist and if a visualization of their progress is available, accessible and clear. This may be a burn-down chart with open effort. It may also be a burn-up chart in value. It may be a Cumulative Flow Diagram. It may be as simple as a Scrum board.

The Scrum framework leaves options for different tactics to play the game, ways that can at any time be adopted to the context and circumstances. Scrum, as a framework, can wrap many practices. When applied well, the overall system will still be recognisably… Scrum.

The Scrum core values give direction to the actions, the behavior and the additions to the framework. Upon that core, in a ScrumAnd way of thinking many opportunities emerge. Have a look at some illustrations of ScrumAnd.