Measuring Success, Measuring Value

The aim to deliver valuable software is a great, core principle of the agile movement. The difficulty however is that ‘value’ in itself is hardly quantifiable. Yet, I do believe it is imperative to think in terms of value in software development and therefore overcome some fluffiness attached to ‘value’. If we don’t find actionable ways to deal with ‘value’ it might remain meaningless; another buzz word, another way of getting people to think it’s time to move on to the next hype. It is not only difficult to quantify value, it is not even necessary, maybe even undesirable. It is better to measure whether we are delivering value (effectively).

What we thought defined success

For many years we were tricked into believing that software development can be considered a success if we meet 3 criteria: deliver (1) all promised requirements (2) within the planned time (3) for the allocated budget. It is reflected in the famous iron triangle of software development.Iron Triangle of Software Projects

That in turn tricked us into believing that, in order to be successful, we had to exhaustively analyze, detail and describe all requirements upfront, and get formal approval and sign off over them before the actual programming can be done. The underlying motivation is to secure the first element of what we were told defines success, the ‘requirements’.

This beforehand gathered information then becomes the input to careful and exhaustive calculations for the delivery part, often with the addition of some ‘contingency’. The underlying motivation is to set and fix the other two elements that we were told make out success, time and budget.

The result is poured into a plan, often complemented by risk mitigation strategies and other exception procedures. When this plan and all its components and clauses are approved and signed off, implementation can -finally- start. And then, obviously, it is just a matter of following the plan to be successful. Deviations from the plan, seemingly happening sometimes, are unlikely to cause any real problems, because it’s what ‘change request’ instances are for (meetings, documents, approvals, and sign offs).

Unfortunately, this was (and at many places still is) believed to be the only way we can ensure the ‘success’ of software development.

Yet, things aren’t that easy. The installments of the mentioned extra safety nets are already an indication that, despite our firmness, this approach isn’t really giving us the certainty it claims to have. And despite the safety nets, the detailed preparations and the seemingly perfect plans, many projects are plainly cancelled (29% according to the Chaos Report by the Standish Group of 2011) or in the end still fail in meeting the widely accepted success criteria of scope+time+budget (57%).

Some however are actually successful in delivering according to the three predictions (14%). But then, success doesn’t take into account that often quality was lowered to unacceptable levels in order to live up to the success criteria; reason why it’s good to add that as a fourth variable to the iron triangle (see figure). Success doesn’t take into account that the elapsed time might be according to plan, but may business-wise be extremely slow. Note that it is not unusual for projects to deliver software no sooner than 12-24 months after the start! Success doesn’t take into account that by the time the software actually becomes available for use, nobody really sees much ‘value’ in the features anymore; at all rendering them useless or in the functional way the features are implemented. More innovative ideas for them have emerged, or improved technological ways to implement them are discovered. It connects to the finding that 64% of features, produced in this way, are rarely or never used.

The three factors they told us defined ‘success’, fail in doing exactly that. And even if they are met, they still only reflect how successful the ‘delivery’ of the software to the market is, not how the software is being received or appreciated on the market place, let alone that the approach helps us addressing changes or new requests from the market place. The three factors fail in showing how valuable the software is; it only says that a version of software got out the door at certain predicted conditions.

What we say determines success

Agile overcomes the fallacy of traditional, upfront predictions and descriptions with collaboration, communication, incremental progress and continuous improvement. All risks taken are limited in time through time-boxed iterations. Time-boxing allows adaptation and adjustment within the process.

Agile Value Delivery (general)

The agile movement stresses the importance of active business involvement as part of cross-functional development work. The agile movement stresses the need for frequent releases to the market place to learn what actually is appreciated. There is no better risk mitigation than regular feedback from actual users.

Scrum, as leading framework for agile software development, is designed upon the foundation that software development is too complex for a predictive approach. Scrum implements empiricism in software development, thriving on frequent inspections to decide on the best possible adaptations. Inspections however are pointless if the inspected information is not fully known, opaque instead of transparent, and if the inspection is not done against known and agreed standards and definitions.

The target of the adaptations is not only the software being produced, it is also about the tools, the engineering practices, the relationships, the process and the three elements they told us define success, i.e. budget, scope and time. Scrum does not care about the abused notion of ‘project’. The concept of ‘project’ generally only serves the idea that success is possible if software is delivered on time, within budget and has all the predicted features. Scrum focuses on the software product (having a role and an artefact for its owner and its backlog) and incremental sustenance of the product.

The foundational belief to this is that the success of software development is defined by the capability to satisfy and impress the consumers of the features, at a reasonable price, at a cost that has an effective return, with creation happening in a way that is sustainable for all people in the ecosystem of the product.

Yes, we can… measure

The success of an organization, in terms of survival, prosperity and leadership, increasingly depends on their ‘agility’, i.e. their overall capability to deliver value in a context of constant change, evolution, innovation, improvement and re-invention.

The difficulty in establishing the value of software or software requirements is that it depends on context, time, technology, market, business domain. It also cannot be reduced to one parameter only. Predicting value doesn’t make much sense either, since it can only be validated by the market place.

But if value defines success, how can we then measure whether we are successful?

Scrum.org has developed the Agility Path framework to help organisations increase their agility and move toward a value-driven existence.

Agility Path Circle

Agility Path focuses not on the illusive goal of calculating and predicting value or similar magic. With Agility Path the outcome of an organization’s work is measured with metrics to help them think about the way that outcome is achieved. Organizations get a clear indication on whether they are delivering value or not. If from the metrics it seems they are not, they have many areas and domains to inspect further, and do adaptations by installing, removing or improving practices, tools and processes. It is how the Scrum framework is used to manage the change process, the transformation of an organisation required to increase their agility.

The metrics provide the transparency needed to identify the areas where adaptation has the most impact. Think in terms of business metrics like employee satisfaction and customer satisfaction, revenues, investment in agile, etc. Think in terms of delivery capability metrics like cycle time, release frequency, defects, etc.

All metrics are consolidated into an overall Agility Index for the organization. This Agility Index is an indication of how effective the organization is in delivering value. One Agility Index is bound to time, place and context. The exact figure is of no importance. The evolution is of importance. The underlying set of metrics is of importance. The insights gained from the metrics, as a source of improvement, are of importance.

No magic, just hard work

There is no magical formula to calculate value, and even when trying to calculate value to steer development priorities, it is a prediction, an assumption that remains to be validated (or contradicted) when you actually go to market. You can never be sure.

The best we can do is to capture the results of our actions with metrics, and do those measurements regularly. We detect trends and patterns (and prefer that over a naked, singular figure). We relate that back to how we work, change how we work, and measure the change in outcome of that assumed improvement. We do that endlessly and relentlessly. We continuously improve by learning and adapting. We get the most out of what we do.

This flexibility primarily helps organizations respond better and faster to change, it implements openness to change over ignoring or blocking it. Once the thinking gets ingrained and new ways of working are installed, organisations discover that there may be different options to respond, thereby embracing change as a source of information. And, finally, organisations start innovating, be ahead and cause change (for the others to follow). Thus an agile approach harnesses change for the customer’s competitive advantage, and the organization’s agility.

The Potential of Agility

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.

Take It To The Team

Lyssa Adkins - Coaching Agile TeamsI have read Coaching Agile Teams by Lyssa Adkins in a gradual way. I regularly stopped reading for a while because I wanted time and mental room to absorb, practice and reflect about what I was reading before continuing down the fascinating path of insights offered by this book. Although I require from every professional book to give me something I can immediately apply, in this case the richness was so huge that the need to stop-start seemed a lot bigger. I also regularly stopped reading to take my newest gained words and insights to the team; test and try them, plant some seeds, watch out for sparks that might turn into a fire.

In Short

Lyssa Adkins has written a very comprehensive book that covers a great, all-round collection of topics concerning agile, professional coaching and… agile coaching. She uses her past of traditional project manager to describe how she discovered the beauty, the power and the value of agile via Scrum and self-organization. But Lyssa is also a co-active coach, doing coaching from a peer perspective with an emphasis on active collaboration between coach and coachée. The book blends the aspects of agile (via Scrum) and (co-active) coaching in a fantastic and enlightening way. But I highly appreciate Lyssa’s strong emphasis that our journey as Scrum coaches is not only about coaching in general, nor about life, personal or love coaching but that it’s about agile coaching. It’s about helping, mentoring, facilitating people, teams and organizations to become great in agile, to achieve high performance through agility. And that is a lot more than producing still mediocre products, just faster.

Audience

On its cover the book says to address a rather broad audience (‘A companion for Scrum Masters, Agile coaches, and project managers in transition‘). But I see Scrum Masters as an important target audience:

  • Because the book has its origins in Scrum, the most applied agile framework, and Scrum foresees the roles of Scrum Master, Product Owner and Development Team.
  • Because this companion holds extremely useful material on behavioral aspects in facilitating Scrum and from my practical experience and as a Professional Scrum trainer for Scrum.org I see much room for improvement there for many Scrum Masters.
  • Because Scrum Masters are expected to be coaches too, doing much more than just managing the process of Scrum.
  • Because too many people think ‘coach’ is a title to achieve, and not a level of mastery to grow into.

Lyssa clearly depicts what it might take to ‘be’ a Scrum Master (or agile coach as you wish), not just ‘do’ it. Remember that, as servant-leaders, Scrum Masters help the other roles within the Scrum Team to play their part (like a conductor would do, one of Lyssa’s metaphors). They help Development Teams achieve great team dynamics. They help Product Owners interact with stakeholders and discover better product ideas. They inform the organization about the Scrum process. They promote agility, agile behavior and the agile principles. They make sure that the wider organization gets the absolute maximum out of Scrum, as part of the continuous search for the art of the possible. And Scrum Masters know how to adapt their communication and working style according to place, time and audience.

Content

Coaching Agile Teams starts by helping the reader to introspect on behavior, habits and attitude in “Part I: it starts with you”.

Part II (“Helping the team get more for themselves”) obviously is the main part as it shifts the focus to the role of a facilitating coach towards the team. It does so by highlighting the various appearances a team facilitator might want to learn to master, the natural fluency with which appearances can be switched, the honesty and openness it takes to learn and admit failures while learning. Some important coach appearances include the teacher, the mentor and the conflict navigator. Throughout Lyssa offers advice, techniques and insights all based on practical experience.

In Part III (“Getting more for yourself”) Lyssa reverts back to the reader with a chapter that describes failure and success modes, skills and abilities that might help and war stories of some world class coaches. It makes most sense for experienced and seasoned practitioners. The danger of reading this chapter too soon is that people will turn some of the topics into incentives, objectives and goals to strive for, rather than real life findings one wants to match his/her personal experiences against.

At a personal level

Lyssa’s book has helped me in many ways. It gave explicit words, a vocabulary, to some of my existing -often unspoken- observations, practices and behavior. It enriched my existing ways of working with additional insights, evidence and perspectives. It offered many new ideas, insights, practices, papers and backgrounds. It helped me further transcend the technical views on agile and Scrum with the book’s strong focus on human behavior, psychology, people and professional coaching. And I can share this transcendent perspective better with others now.

Many great books on agile have I read, but Coaching Agile Teams by Lyssa Adkins is one of the few agile books that truly changed my life. And it’s been a while since I had that feeling over an agile book again.

Impediments (and where to find them)

Probably the most known purpose (task) of a Scrum Master is to remove impediments. If that is reassuring: it’s even described in the Scrum Guide. A Scrum Master is indeed ‘officially’ expected to remove impediments to development and to the Development Team’s progress.

Unfortunately, this is sometimes interpreted as the Scrum Master having to be an ‘impediment hunter‘. That suggests that a Scrum Master should proactively search for impediments in order to track them down and kill them. There is a danger in this wording, besides the very negative feel to it. I particularly wonder how this aligns with the self-organization of teams and transparency? Self-organization is essential in Scrum and it’s to be promoted, served, coached, taught and mentored by that same Scrum Master. Transparency is required to know about reality, inspect it, learn from it and make proper adaptations.

An impediment is an “obstruction; hindrance; obstacle”. And Scrum is a framework that helps teams in finding better ways to create working software in 30 days, or less, and handle the complexity attached to that. An impediment in Scrum is therefore anything that blocks the (development) team in its creation of a valuable piece of software in a Sprint, or restricts the team in achieving its intrinsic progress.

Where to find an impediment?

We can expect a team to raise an impediment, any annoying problem that is truly blocking them. Actively looking for (‘hunting’) and removing impediments is solving problems that are not a problem yet. It assumes that a Scrum Master, as 1 single person, knows more -or pretends to know more- than the united brains of a complete team of up to 10 people; a team that daily makes hard choices by disciplined collaboration.

Solving a problem before it’s a problem points at a lack of belief in the self-organizing capability of a team. Solving a problem before it’s a problem prevents learning and improving because it obfuscates transparency to the team. Solving a problem before it’s a problem is mostly a waste of time and energy because the team will probably handle it by itself anyhow, without the Scrum Master, preventing it from turning into something that truly blocks them. They probably even solve more problems than the Scrum Master knows or can imagine.

It’s simple, an impediment is not an impediment if it hasn’t been raised by the team. Impediments cannot be anticipated. And if there undeniably is an impediment (not an anticipated one and not an issue that the team is already handling) and it is not being raised, the question of the safety of the environment arises. What is preventing the team from raising the impediment?

Not raising an impediment does block the team. What’s then the real problem for the Scrum Master to solve?

What does an impediment look like?

Issues only become impediments if they cannot be tackled within the self-organizing ecosystem. The concept of ‘impediments’ is not a replacement of the traditional escalation procedures. Traditionally people are told to escalate whatever bothers them to a person external to their work to solve it for them. Easy and convenient. But is it also helping?

Scrum delivers great results because it thrives on self-organization, accountability and skills; it appeals to those elements. Scrum restores the respect for people and the understanding of software development as complex and creative work. By definition, in Scrum an issue only becomes an impediment if it can’t be unblocked through the authorizations of the (development) team.

Let’s illustrate this with the example of a team conflict, a conflict between team members.

A team might have problems in resolving a conflict and call the conflict an impediment, expecting the Scrum Master to remove it for them. They expect the Scrum Master to solve the conflict. However, working as a team inevitably includes getting to know each other, finding ways of building software together, exploring different ways to collaborate, outgrowing the desire for personal heroism, and improving through constructive disagreement. Conflicts are a part of working with people, part of becoming a self-organizing team, part of aiming at high performance.

Once again we should raise the question what the real problem for the Scrum Master is to solve? Is it the Scrum Master’s role to solve the conflict? Or would that be an undesired intervention in the self-organizing ecosystem, undermining future honesty, learning and self-improvement? How can the Scrum Master facilitate self-organization? Is it by offering teams an excuse, an external decision to hide behind? Consider how to help a team work out their problems themselves and offer any tools, trainings and insights on how to do this.

Not dealing with an issue does block the team. What’s then the real problem for the Scrum Master to solve?

Fixed Price bids. An open invitation to bribe, cajole, lie and cheat.

I have been fortunate. Because some things take time and I have had the time to experience Scrum deeply before the demand rose sky high at my local markets. Time and experience formed the foundation upon which I build in some larger scale Scrum transformations that I am involved in.

I have learned much. I have much to learn. Yet, some people ask for my opinion.

A frequently recurring question is on the combination of agile and fixed price bids (and contracts). Here are my thoughts:

I have an opinion

Fixed price bids are an open invitation to bribe, cajole, lie and cheat.

  • Fixed price contracts introduce a blaming culture. They don’t aim at collaboration and sharing but at shifting all risk to one of the contracting parties. It invites people and organizations to be dishonest and fight in order not to take the blame (and the penalties). It might end up with the supplier financially getting hung, or the requester getting bad quality or not getting work by devious (and clause-wise) omission.
  • Fixed prices deny the very nature of our business. Software development is complex and creative work. There are a lot of elements that influence process and progress, and the number of unpredictable elements surpasses the number of predictable ones.
  • Fixed prices thrive on the belief that time, budget and scope can be fixed and planned upfront. Although everybody (at least off the record) acknowledges the truth in the metaphor of the iron triangle of software development, few seem to say it aloud. Hereby, fixing time, budget ànd scope creates only one certainty, i.e. low quality.

I have experience

Fixed prices define ‘success’ as the predicted combination of in-time+on-budget+promised-scope. Research by the Standish group has shown that agile is more successful than a traditional approach, even against these old criteria. This is not a reason to promote the combination! Yield rate is better but still low by setting the wrong expectations in the context of software development, i.e. that the unplannable can be predicted in a plan.

In the early years of my life in agile, I have delivered several fixed price projects successfully with Scrum. I even developed a framework for it. Still, from a contracting point of view it introduced the notion of ‘fixed price-negotiable scope’. Every single time that this notion was neglected or ignored I ended up in a one-way scope negotiation situation. The bleeding, the pain and the war situations never positively contributed to quality, time to market, user satisfaction, ROI, TCO. Blaming and penalties just appeal to a primitive sense of revenge.

In our Professional Scrum courses we work with the people in the class to figure out options to use Scrum. We try to facilitate bottom-up knowledge generation. We consider parameters and complexities that influence IT and software development, to find that in general we can’t be sure we have them all, and that at least some of the known ones are still quite unpredictable.

Agile via Scrum restores the understanding of the true nature of software development, and offers new ways of working and control to deal with uncertainty. It helps us to shift from the industrial to the creative paradigm and to accept that software development and fixed price contracts are not fit for each other.

I have a dream

Against all experience in, proven low yield rate, failures, burnt-out people and caused distress, the belief remains that a fixed price contract offers certainty. Although there is a tangible and incredible way to deal with the natural uncertainty of software development, Scrum. Scrum allows us to collaborate and behave as partners. We can jointly evolve, learn and check regularly on what does/does not work. But it still requires the first, huge step to let go of the false belief in planned certainty.

I have a dream; the dream that IT professionals stop offering on fixed price bids. Because it is unethical, risky and untrustworthy to make that kind of hard-coded promises in a complex and fast-changing environment. It is… unprofessional. And there is a great alternative option.

Agility can’t be planned

I have been fortunate. I have been involved in some larger scale Scrum transformations. I have learned much. I have much to learn.

Here are some basics that are fundamental to set the right expectations for a enterprise Scrum transformation. I will relentlessly repeat and remind these. Because introducing agile without accepting these essential truths closes the door to the path to agility instead of turning it into a gateway of opportunities.

Agility can’t be planned. Agility can’t be dictated. Agility is never ready.

A time-planned way to introduce agile at an organizational scale sets unfavorable expectations. Change processes are highly complex and therefore not predictable. And agility is much more than following a new process. It is about behavior, it is about cultural change. In a transformation towards an agile way of working, there is no way of predicting what change needs will be encountered at what point in time, how these are to be dealt with and what the exact outcome will be. There is no way of predicting the pace at which the change will spread and finally take root.

A decision to move to agile is a decision to leave the old ways behind. It is not only about accepting but about celebrating that agility is living the art of the possible. It requires the courage, honesty and conviction of acting in the moment, acting upon the reality that is exposed by iterative-incremental progress information. Agility is about doing the highest possible at every possible moment, given the means we have and the constraints that we face.

Time-plans create the illusion of deadlines and an end-state. Agility has no end-state, but introduces a state of continuous improvement, a state in which each status quo is challenged, all the time.

Agility can’t be planned. Agility can’t be dictated. Agility is never ready.

This must be in the hearts and minds of every person guiding or driving a Scrum transformation. Because agility needs to settle in the hearts and minds of every person impacted by a Scrum transformation. And in general those people have been instructed the wrong behavior for 15 or 20 years. In general a plan will slow down the transformation process, as it just extends the old thinking. Living the art of the possible engages people and accelerates a transformation as it thrives upon the future. A bright future if you have the vision, the determination and the dedication. And if you have, I hope I can help you. And I will bring metrics, practices and tools that will light your path.

Personal Scrum Day Europe Impressions

On 11 July 2012 we organized the first edition of the Scrum Day Europe (for which I previously published the abstracts of Ken Schwaber and myself). 130+ enthusiast people gathered, interacted and connected at the beautiful location of “Pakhuis De Zwijger” near the Amsterdam docks (Netherlands). I was delighted to see so many friends of Scrum; Professional Scrum students, colleagues, clients and personal friends. And I am extremely grateful for the appreciation and the energy received.

Ken Schwaber opened the day with an inspiring talk on the global accomplishments of Scrum, and how well this positive change for the software industry is currently being embraced in Belgium and the Netherlands. He announced he is working on further evolutions of the Scrum framework towards management and organizational improvement.

The CIO of Tele2, Svenja de Vos, talked us through the practicalities of their ‘big bang’, ‘no guts, no glory’-style transition to Scrum.

Subsequently the audience split up to (1) join an OpenSpace, (2) play some agile games and (3) enjoy more perspectives to Scrum (change basics, coaching people and Scrum in a hosting environment).

After lunch the full group joined again in the central room to listen to the highly energetic story of Amir Arooni, member of the ING IT management team. He gave the crowd an honest insight into their findings, impediments and future hopes after a 1+ year, large-scale transformation to Scrum. I was honored to be mentioned by Amir as one of the crucial guides of their transformation.

As Capgemini global leader for Scrum I was asked by Ken to do my talk on the ‘Emergence of the Customer-Oriented Enterprise’, an organizational pattern to build on the Scrum framework to achieve enterprise agility. Beyond the appreciation I received I was particularly glad for getting away with a form of humor. My presentation is free for download. All pictures and presentations of the event are available at the Scrum Day Europe website.

Here’s a very personal selection of (mostly mobile) pictures by friends:

A big thanks to Scrum.org, all co-organizers and I hope to see you next year!

Why It Took Time (to become what I didn’t know I wanted to be)

The terrorism of an alcoholic father left me with serious damages and memories of a loveless youth. Nevertheless I graduated as Industrial Engineer in electronics in 1992, age 22. An opportunistic choice of study as philosophy or literature didn’t offer the same job certainty. Purpose?

Time for a little retrospective exercise. What has happened in the 20 years since my graduation? What has been most influential in becoming who I am today? And why did it take that time?

The formative years

I was deeply disappointed when entering the labor market as my grade created the expectation of thorough technical insights while I had hoped for some staff position, and the possibility to work with teams.

My first job was software engineering on VAX but I remember most the great times I spent in the great country of Ireland. After a little project on OS/2 I moved to a small company in 1993 to do assembler programming on Micro-PIC controllers. My 6 months trial period wasn’t too convincing but a one month prolongation did show some success in planning and purchasing, combined with Borland C++ and Paradox programming.

Blind enthusiasm and overwork burned me out so I left in 1996 to take over a bookshop of a large chain on a franchising base. A client of our shop pointed me towards Nietzsche and his ‘Beyond Good and Evil’ (and later on his other works) was an incredible eye opener. Since then I kept saying that 90% of who I am, I am due to my wife and 9% due to Nietzsche. Nietzsche revealed the bare truth to much of my struggles with life to that date. Although my wife and I had the time of our lives being all around books, and we moved to a bigger shop twice, on the last day of 1998 we had to decide to quit. The reason was the imbalance of income, social life and personal development; and being on the verge of debts.

In 1999 I started as business developer for the first Belgian e-commerce site for books and CDs, where I soon grew into a senior management position. By the end of an exciting but burning period I remember me creating a mega (no, wait, giga) analysis for a complete new back office (from IT to logistics), which was my domain to lead. It only took me 3 hours to get a team through it. Once. I don’t know whether it was that analysis or the complete renewal of our server park, but just after I resigned in 2001, I was offered the position of IT director at the company. Although I did co-write a post-crisis survival business plan for the company, I still decided to leave. I felt too young, too inexperienced and -above all- my views on the people aspect were quite different from our investors and other leading managers. I rightfully left, is my opinion still. Later that year, our first son was born.

The Years of Dedication

In 2001 I started working for a large local (Belgian) consulting company.

For my first project I did a complete functional analysis, took the lead in contracting and other negotiations and continued as ‘project manager’. Management advised me not show the estimates to the team. But I did, and it didn’t prevent the project from ending up break-even where all other fixed prices ended in major losses. But I specifically remember helping a team member through a difficult divorce situation. Without minding the actuals.

In 2003 our second son was born. He turned out to have Down Syndrome. Professionally I got called to urgently lead a new project that seemed unfeasible despite the fancy MS Project promise. It took 15 minutes for 2 software architects to convince me about eXtreme Programming. It just had all elements fixed in the method that I had -to a certain extent- tried to do in my first project: communication, iterations, feedback. In December 2003 I presented this project as the first major production XP implementation in Belgium at Javapolis.

When scaling up with the next phase of the project we added Scrum in 2004. I went well-prepared, i.e. having read his 2 books at that time, to a CSM class by Ken Schwaber. And we replaced our organizational XP practices with Scrum practices and names, but we kept doing the core engineering practices (pair programming, TDD, continuous integration, automated testing).

By the end of 2006 we had successfully delivered 2 more phases of our early Agile project, and applied Scrum + eXtreme Programming in 2 additional large website applications, incorporating extensive front-ends, back-ends, integrations and interfaces. Those projects learned me that inclusion of incremental development of even major UX-components is feasible, and even to be preferred.

Due to lack of respect for our results and for the people I decided to leave in 2007. And to date I’m still struck by the observation of an esteemed colleague and team member that I had never consciously made myself, i.e. that he loved the way I tried to turn a project into a total, 360° experience of joy, fun, energy and… results. Never satisfied with less.

Richard Dawkins deepened my Nietzsche experience by adding a genetic and memetic dimension to it. By the end of the year I started at another consulting company, led and blinded by promises of a management position. Around that time our oldest son, age 6, was diagnosed with Duchenne Muscular Dystrophy. Having read Richard Dawkins helped in surviving and dealing with the genetic flaws of our 2 children.

The empty management promises finally covered 2 years of my life in stress and agony. I fought, battled and barely survived, before returning to my Agile roots. I realized that I had never cared about any ‘CS*’ certifications or whatever career, that my satisfaction had been in working with teams and clients, joyful projects, and that I still didn’t care about careering. Therefore I was attracted by the community orientation of Ken Schwaber’s new platform, Scrum.org and followed and joined it from the early days in 2009.

2010 did not only see me giving consultancy a last chance at my current employer, but after 2+ years of medical uncertainty and wandering our daughter was born. No genetic problems, not even carrier of DMD. My first professional experience wasn’t too comforting, but I applied my iterative-incremental approach and turned my first project, once more, and once more against all odds, into a 360° success. In the mean time I evolved with Scrum.org and did the Professional Scrum Master assessments (level I and II), and decided to firmly proceed on that path. I applied for Professional Scrum Trainer for which I went to a PSM class by Ken by the end of 2010 in Zürich.

Booming Business

And then, suddenly, there was 2011. Dutch colleagues found me. I developed an internal Scrum training, which was highly appreciated and became very successful. It opened important gates at clients, caused some amazing breakthroughs and I mutated to another division. I followed the early Professional Scrum Product Owner program and soon became Professional Scrum Trainer in PSM and PSPO.

I had a boost in understanding and living Agility, not in the least through the mentoring and lessons by Ken. My perspective quickly broadened. Authors like Daniel Pink (“Drive”) and Nassim Taleb (“The Black Swan”) augmented my general world views, and greatly supported my belief to use people and empiricism to cope with the complexity of our world. I am now the global expert on Scrum at my company (120.000 people worldwide). And the end is not nearly in sight. Scrum has become a substantial part of what we do and offer. We train our consultants and our clients, we coach and guide them, we promote Enterprise Agility and we inject more and more agility into our own organization.

Soon I will be talking at the Scrum Day Europe event that Scrum.org initiated and that we co-organize. I will introduce how I perceive the Emergence of the Customer-Oriented Enterprise. Previous ‘confessions’ gave some insights in what might have influenced how I developed my views. Who knows what will happen next to change how I see things?

Not Future

Some things take time. Beauty. Growing flowers. Becoming what you didn’t know you wanted to be. Unlearning. Mastery. Dedication and determination.

I am still without much formal title or position. I regularly struggle with the gigantic, monstrous machines that corporations tend to be. I regularly want to flee back to the underground when balancing my personal ethics against my desire for impact. Overall however, I manage and it works out… without power games. I am epigenetically (the seeds sown in my youth) unable to play power games, but I’ve learned to use that in my advantage.

In 2012 I am even making enormous progress on my scales of valuation. In the past I usually was merely tolerated, in the best case appreciated.  Here I am now, not just being motivated, but even able to innovate.

Note

I started writing this blog note to give people insight in what it sometimes takes, at least time, to learn and evolve. I was long in doubt whether to continue this text when I started reading Lyssa Adkins’ book Coaching Agile Teams. Having read the first chapter I decided to go for it. Because my message reflects how I became to ‘be’, not only what I ‘do’. Painful sometimes, but honest. Hoping it might help or inspire others. Hoping it helps people understand that it takes time. The path and the patience pay off. I can now go back to Lyssa’s book again and finish reading it.

Let’s make the Definition of Done a Scrum artefact

In the last Scrum Guide (July 2011) the Definition of Done was given considerably more attention. Rightfully, as the DoD is crucial in Scrum.

The Importance Of Done

The Definition of Done is essential to fully understand the Increment that is being inspected at the Sprint Review with the stakeholders. The Definition of Done implements the expectation of an Increment to be ‘shippable‘, so ideally it is comprised of all activities, tasks and work to release an Increment in production. The addition ‘potentially‘ to shippable refers to the Product Owner’s accountability to decide over the actual release of an Increment; a decision that will likely be based upon business cohesion and functional usefulness. But the Product Owner’s shipping decision should not be constrained by ‘development’ work.

The Definition of Done should be clear and concise for the Scrum Team as it will determine how much work a Development Team can reasonably take in into a Sprint during the Sprint Planning meeting.

The empiricism of Scrum only functions well upon transparency. That includes the Definition of Done. Transparency means not only visible, but also understandable. Besides being available, the content of the Definition of Done should be clear by just reading it.

A New Scrum Artefact

I suggest to make the Definition of Done an official Scrum artefact.

Because it is an adaptation of Scrum to reality, a mere formalization of an existing practice; because it is extremely important to put quality even more at the heart of what we do; because we want to clear out that little grey zone in the base Scrum framework allowing some people to doubt the formal need of a Definition of Done. With regards to the latter, it will provide additional guidance for people and organizations to improve, and investigate the next steps on the cobblestone path to Agility.

All existing Scrum artefacts support the ‘inspect & adapt cycles of Scrum; they provide accurate, up to date and transparent information to be inspected and adapted at the rhythm of the Scrum meetings (or sooner). I suggest to primarily do an inspection on the new Definition of Done artefact at the Sprint Review, along the inspection of the working Increment. This pair-wise inspection serves to get feedback and input from the stakeholders that goes beyond mere functionality and business requirements. It will invoke a collaborative conversation over quality, and requirements with regards to the quality of working software in the organization.

The Sprint Review is also the time to inspect the current state of Product Backlog, i.e. what is now Done, what was left undone in this Sprint, what was additionally turned Done. From this current state, including the latest Velocity measurement, the actual product progress is available to the stakeholders.

I suggest to lay ownership over the Definition of Done with the Development Team. A Definition of Done can’t be forced upon a Development Team. Neither can it be cut short by forces outside of the Development Team. The Development Team will obviously include functional quality expectations from the Product Owner. The Development Team will obviously include general, organizational expectations and compliance (e.g. from the engineering organization). But it’s up to the Development Team to process it in the Definition of Done. Decisions over the Definition of Done will depend on the presence of skills, authorizations and availability of external systems, services and interfaces. Probably a Development Team would include stubs and simulators for non-available systems, add this to their Definition of Done and make the impact of these dependencies clear to the Product Owner in her/his sorting of the Product Backlog. The effect on the planning horizon will no longer only be clear to the stakeholders by inspection of the Product Backlog at the Sprint Review, but also via explicit inspection of the Definition of Done accompanying the working Increment.

The inspection of the working Increment and the Definition of Done at the Sprint Review, and the related collaboration of the Scrum Team with the stakeholders, will provide the Development Team with important information to sustain, evolve and grow the Definition of Done. They will probably have a deeper conversation over it at the Sprint Retrospective. The self-organizing drive of the Development Team will include all that’s actually possible, dig deeper, taking into account the feedback from the stakeholders, and evolve it as part of their continuous improvement of quality.

This ownership is comparable to the Product Backlog ownership. The Product Owner has accountability over it. But it won’t withhold the Product Owner from taking into account the technical and development input from the team. It won’t withhold the Product Owner from taking into account dependencies, non-functionals and organizational expectations. And after all, the frequent inspection of a working Increment provides information on reality to all involved so they can incorporate that in their work via their accountability.

A Desirable Side-effect

Although it is not an objective of promoting the Definition of Done to a Scrum artefact, I do see an optional side-effect: additional transparency to the overall agile adoption.

Obviously the Definition of Done will not always immediately, from day 1 of the adoption of Scrum, hold every possible task, activity or requirement to render every Increment completely production-ready. There will be a gradual evolution in applying Scrum. This is good as it helps all players continuously exploit the possible to a maximum extent.

Promoting the Definition of Done to an artefact, that needs to be inspected and is open for adaptation, will help identify improvement areas in capturing enterprise agility. The finding of what is/is not included provides an indication on involvement of the broader organization in agile product development, even of organizational impediments. And stakeholders, in consultation with Product Owner and Scrum Master, might want to act on these from a management change perspective.

In a transformational period, including the Definition of Done as an explicit artefact in the Scrum framework will help people and organizations in the software industry to… improve from better and more realistic insights.

The Scrum Gameboard

In our Capgemini trainings on Scrum we’ve been using the Scrum Gameboard to represent all Scrum framework elements in one overview.

We’ve taken the liberty to already add the Definition of Done. Because, whether an official Scrum artefact or not, the importance can’t be overstressed.

How Scrum Blends the Philosophies of Lean and Agile

Some management or governance philosophies should not be mixed. Because the mix will be a blurry amalgam and the unique flavor of the individual ingredients will get lost in the mix. In general it’s even worse. Not only the flavor and the envisioned benefits get lost, the total ‘product’ may be even well less performant than the sum would suggest.

Lean is a management or organizational model that thrives on a typical mindset, with powerful but distinct fundaments, principles and thinking. But beyond the assumption that such strategies are best not mixed, I see not only much common ground to Lean and Agile, I am even convinced of the power of the combination. I believe that combining Lean management principles with the Agile product development spirit, as a total outcome, will result in a more powerful mix. I believe that Lean and Agile are truly blending philosophies.

As Professional Scrum Trainer I worked with Scrum.org to release my views as a whitepaper at http://www.scrum.org/storage/articles/The%20blending%20philosophies%20of%20Lean%20and%20Agile.pdf.

In this paper I highlight the main aspects of the distinct views of Lean and Agile, and indicate the similar grounds to them. But I have also included the Scrum perspective to Agile to make very clear how the tangible, yet open framework of Scrum aligns and blends the underlying thinking of Agile and Lean.

My paper elaborates on my statement that the houses of Lean and Scrum are similar houses, just different materials: