Tag: Agile

Posted on by — 4 Comments

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?

Posted on by — 3 Comments

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.

Posted on by — Leave a comment

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.

Posted on by — 2 Comments

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!

Posted on by — 10 Comments

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.

Posted on by — Leave a comment

The importance of Done in Scrum

In the last Scrum Guide (July 2011) the definition of Done was given considerably more attention. Rightfully, as “Done” 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 ‘releasable‘, so ideally it is comprised of all activities, tasks, qualities and work that allow releasing an Increment in production. The addition ‘potentially‘ to releasable 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?

Should we make the Definition of Done an official Scrum artefact?

It would seem like adapting 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 would provide additional guidance for people and organizations to improve, and investigate the next steps on the cobblestone path to Agility, although probably not the guarantee hoped for by making it a mandatory artefact.

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 events (or sooner). In that sense, Done is already an artefact; it is in the Increment, making the state of the Increment transparent.

I suggest to formally include inspection of the Definition of Done at the Sprint Review, along the inspection of the working Increment, which it is a characteristic of. 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 development or 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 for ordering 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 the goal is not to promote the Definition of Done to a Scrum artefact (as shown that is not needed), I do see an optional side-effect in explicitly inspecting it at the Sprint Review: 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 inspection of the definition of Done with the stakeholders 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.

Posted on by — 3 Comments

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 The Blending Philosophies of Lean and Agile.

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:

Posted on by — Leave a comment

Emergent Human Performance

How did industrial people take good care of machines? They took them apart, let’s say once a year. They had a close look at the pieces, did some filing on them, added a little oil, changed some gear wheels, did some repainting and put the machine back together.

Great way to handle machines.

But there should have been a notice in the maintenance manuals of such machines saying “Not to be used on human beings”. A Team of people is not a machine you can take apart to examine the individual parts, file or replace some of those parts and put it back together.

People are not replaceable pieces of machinery.

Still, it’s what we do and how we treat them. We use the label ‘resource’, i.e. (see dictionary) a “source of supply that can readily be drawn upon when needed”. And we think we can make up for this totally inappropriate definition by adding ‘Human’ to it. So, what do we mean then? A human form of a replaceable hardware component?

People are not mechanical robots.

Too often people are reduced to just a sum of pseudo-capabilities like a diploma and a cv. But -surprise, surprise- even if different persons have near-identical lists of such ‘properties’, they still have different backgrounds, personalities, private lives, interests, senses of humor, and all those other aspects that make working with people so exciting. But -indeed- it does prevent them from being interchangeable.

Too often is the uniqueness of people blatantly ignored by an overload of ‘HR’ strategies, policies and penalizing KPI’s. And at a yearly performance measurement this human hardware part is investigated against them. And sent home with a set of reprimands that it should interpret as something ‘to learn from’. Does it really come as a surprise if the surveyed object does not feel too motivated by this type of machine-like maintenance procedure?

How then about some positive change? Improve this domain of the world we work in? How can Agile thinking help?

In The Iron Triangle of Valuation I presented the hideous career path that is projected on people in IT. It forces people on a path that typically leads from developer to analyst to project manager. And if one’s lucky the gates of management are opened to have a ‘real’ career. I introduced a triangular-balanced context to replace it, allowing people to prosper and do well in a ‘role’, taking away the focus from ‘position’ and endless stairs.

We can use that base model to fundamentally reform the way we work with people, the way we observe and assess people. Certainly for organizations making the shift in external orientation to a Customer-Oriented Enterprise this is a promising internal re-organization opportunity; it aligns the internal thinking to the external orientation.

The triangle of valuation describes the context that needs to be created first before people can prosper and develop their potential. It demands that organization and individual agree on:

  • The individual showing a clear interest in performing a set of tasks and activities (or moving to those tasks),
  • That person demonstrating a talent (or having the potential to grow a talent) in performing those tasks and activities,
  • The organization’s ability to offer (have or create) a domain in which the tasks and activities can be performed and are valuable.

Intermediate evolutions need to be transparent.

Individual and organization agree on gradual follow-up and evolution. Because it is highly disrespectful to confront people once a year with results from the organization’s perspective without having given the people the chance to adapt and improve. And in the end, the organization is neither getting any benefits from this. The core idea of an evolutionary approach is that, if a yearly review is considered important, there should be no surprises at that time of evaluation. All involved should already be aware of the results that have, or have not been, realized, and what has caused it to be like that.

The clue is that in today’s world of continual change and evolution, there is no reliable way to impose upfront, detailed definitions, expectations and predictions, not even for individual performance. This should be replaced by an incremental path allowing the assessed and the assessor to meet regularly to conversate, learn, interact, review and re-plan. They must travel a common path upon jointly set objectives and forecasted expectations, with a frequent demonstration/summary of progress.

Incremental evolution with room for empirical improvement must be added to respect the individual and lead to true valuation. The individual will perform to the maximum possible, taking into account changing circumstances beyond the individual’s control. At least yearly, but possibly earlier, objectives can be collaboratively reset, and even the base triangle can be reviewed. A win-win situation will emerge. Valuation can take material, financial or non-material forms.

If the legs of the triangle are fixed upon the wrong assumption of total predictions, without room for evolution and incorporation of new insights, valuation will suffer from that fixation, not originate from it.

Agile enterprises embrace people practices.

After the transition from ‘Human Resources’ to ‘people practices’, assessments will be focused on helping and facilitating people, no longer on mere judging. It is the only way to give rise to the emerging individual performance that has the potential of improving overall enterprise results. It’s a model that aims at emerging performance. KPI’s represent a technique that can still be added, but that should be done with the objective of providing information, not be judgmental in itself.

Results will be the result of emergent performance. At least a result will be the hard work itself, even it only pays off in the future. The introspective get-together’s serve to check whether we are still learning from it. That’s why these intermediate reviews take place. Pressure is taken away from hard-coded results and shifted to context, learning and improving. And a yearly retrospective review creates value in stepping out of the normal rush and taking a look at the bigger picture, and insert evolutions to the triangle. IF the base context, expressed in the 3 legs of the triangle of valuation, was in place. What else would be evolving?

And if an intermediate introspection requires a substantial revision of the wider context, as expressed in the triangle, take enough time to close the process and restart.

Agile enterprises embrace emotions.

And finally we can stop blaming people for being “emotional”. AS if we are not in a people business. Emotions are the essence of human nature. And in case of a conflict, look first at the triangle of valuation to check whether the right context is still in place, in the current circumstances.

Is this an emotional, highly personal desire? Of course it is! It would finally create a context that will not only just tolerate deviant people like me, but possibly even appreciate them. That in turn could be a stepping stone to stimulate them and open ways for them to truly innovate.

Posted on by — 4 Comments

The House of Scrum

The House of Scrum is a warm house. It’s a house where people are WELCOME. In the House of Scrum people from different backgrounds, in different roles, with different skills and talents work, learn and improve together, as a group, with no finger-pointing at each other or disrespectful work. The House of Scrum is an inclusive house of warm, open and collaborative relationships, not a house that excludes people.

The House of Scrum knows no versus. No business vs. IT, no team vs. organization, no Product Owner vs. Development Team, no development vs. support, or testers vs. developers (of code), our Team vs. your team, or Scrum Master vs. stakeholders. The House of Scrum is a great and energizing place where product development prospers from the combined, creative intelligence of people.

A similar house, just different materials, is the Lean house.
I created this (graphical) analogy when I was gathering, bundling, reviewing, editing and adapting some previously published blog notes to create some white paper-ish… papers. The first one covers this analogy: “The Blending Philosophies of Lean and Agile” (I will soon make it available via slideshare).

This is just partly about the result. I’m also going through it to check and improve my writing skills. Of course quite curious where it might lead me.

The paper, as I foresee it now, has 3 parts:

  1. An introductory overview of the Lean Thinking and mindset as I laid it out in The Power of Lean Thinking,
  2. Stressing the Agile Spirit (over jumping into singular practices) to demonstrate that Lean and Agile are indeed Blending philosophies,
  3. The Scrum Perspective to Agile describes the main game playing rules of Scrum to demonstrate how Scrum implements the Agile principles and how Scrum is quite… Lean.

By the way, I am encountering the interest in this topic, Lean+Scrum, more and more. Organizations are looking to ‘Lean’ to help them revive. And I’ve already had several Lean coaches at my Scrum trainings and they share my enthusiasm for embedding a product development vision upon Scrum in Lean thinking. Let me hereby quickly summarize the compatibilities as follows:

Next papers I will be working on are:

  • “Paving the path of Scrum adoption”, on challenges in challenging the status-quo state of many Scrum implementations;
  • “The customer-oriented enterprise”, an answer to the major Scrum challenges from the perspective of the total organization.

Keep tuned!

Posted on by — 1 Comment

Personal Professional Scrum

Precaution: the author (me) is lately sharing a load of personal, retrospective findings with the world (you). Must be that he’s leaving some troubles and worries behind him. Or maybe it’s just the pills he’s taking?

It wasn’t until I started doing projects upon eXtreme Programming (2003) and Scrum (2004) that I finally found my way in IT, and started feeling at ease at a personal-slash-professional level. It then still took me several years (>2011) to find a professional homebase (some call it an employer) where I could really ‘go’ for my Agile and Scrum ways.

In the early years I never cared about profile or promotion; just me, expertise & the teams. But on the cross-point of deciding yes or no to stay in IT consultancy, I decided to give it one more chance. But it would be a ‘make or break’ and it had to be Agile and Scrum. I resurrected the knowledge and experience hidden in my brain and started publishing about it again. I finally went to Capgemini (March 2010), attracted by the fact that they had co-founded the Agile Consortium Belgium.

This was around the time that saw the emergence of Scrum.org by Ken Schwaber. I had my CSM by Ken back in 2004 but that was it. Never even considered CSP, CSC, CST or any other CS*. My reluctance for profile and promotion, you know. I liked the feel and the why of Scrum.org and engaged early. Full of doubts, but I demonstrated a good understanding as Professional Scrum Master, level I and level II. Confidence grew, I applied for PSM trainer, went to a PSM course by Ken (December 2010) and qualified as trainer.

Happily invited at an early class of the new Professional Scrum Product Owner program (April 2011), I fully subscribed the program’s goal of reaching out to Business people and helping Agile Product Management emerge. I demonstrated my understanding and my training qualification was extended with PSPO.

After a little migration within Capgemini I am now in the greatest position ever of working day and night in promoting, maintaining, supporting, coaching, training and facilitating Scrum; internally as well as at customers, locally (Belgium and Netherlands) and globally. And the Capgemini Academy is rolling out a training offering for private and for external audiences that combines:

  • Our Capgemini trainings: Scrum Kickstart, Scrum for Product People and Scrum for Managers;
  • The official Scrum.org trainings PSM and PSPO.

Our strategy connects to the vision of Scrum.org in presenting Scrum as a tool for Business Agility, not as an end in itself. As from Capgemini I sincerely hope to have impact but from a positive, open and adaptive attitude. Not grumpy or bitter or aggressive. Knowing that the path to Agility will remain a cobblestone path and there will be ups and downs. Keep an eye on the overall progress trend, a burnup chart of Agile values and Agility. Make the world a better place (to work in).