At some occasions we stop to look back. It happens rather irregularly in my life, although regularly in Scrum. We see the trail we left behind. We notice landmarks, missed chances, forgotten events, achievements. Small or big. We cherish that we cannot undo it. And we look ahead of us, and think of the paths we might create moving forward understanding that our current actions continually determine our future.
Looking back, two fairly recent, symmetric landmarks stand out on my trail of Scrum created since 2003:
Two and a half years ago I left consulting and moved to that home of Scrum, Scrum.org, to shepherd Professional Scrum and be its face in Europe.
Looking back, I am humbled by the opportunities to travel, to speak, to think, to write, to publish a book, to collaborate with people across the globe. I thank anyone who crossed my path, regardless how they chose to interfere with me.
Just for a split second, I pride myself for having gone my ways, having made my choices. In that split second I see some impact on people, on individuals.
Looking forward, I shiver and doubt takes over again. I embrace the solitude that is often my companion and look forward to the future that, to date, is unwritten. There are many unknown futures that can unfold. In a short flash I realize that there are probably much more options than I know of. There are more paths than I can possibly identify.
Although the future will be nothing like the past, it’s fair to assume that my journey ahead will keep including Scrum. The exact directions however…
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.
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;
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).
;-) Confession
I did eXtreme Programming before I did Scrum. Although this may seem trivial, it has positively affected my further Agile career.
Let’s go back in time…
In September 2003 my management (consultancy company) assigned me on a project that they hadn’t hoped to win and that was allotted far too late. Result: our company was facing a development effort of 700 days and delivery in December. Two software architects, literally in 15 minutes, convinced me of applying eXtreme Programming. Because I recognized what I had been trying to do in previous projects, but was now sort of ‘hard coded’ in the approach, i.e. iterations and communication.
In only a couple of days we created User Stories, replaced the MS Project phasing by 3 iterations of 3 weeks and convinced the external customer to intermediately attend demo sessions. Our roles included the Team, a project manager/Big Boss (me), a Coach and a proxy Customer. As we soon discovered that our proxy Customer was fully occupied in functional guidance to the Team, we included a Tester to assist her. The Tester incrementally wrote hands-on functional test scenario’s for the User Stories being developed. We added 2 days of slack before the stakeholder demo; to fix small issues, prepare the next User Stories and do spikes.
In 2004 we had to scale and the same fellows (now Coaches) directed me to Scrum. I read the 2 books by Ken Schwaber and registered for his CSM course in May 2004 in Brussels. It was a great experience and as from then we used Scrum for our organizational practices (Sprints, roles, meetings, artefacts) but we kept using eXtreme Programming as implementation for the general Scrum demand of Engineering Standards (PP+TDD, CI+Refactoring). From those engineering standards the use of User Stories emerged, as well as the roles of Coach and Agile Tester.
We always delivered fixed price projects as an external supplier. So we had to translate the customer’s Vision (mostly an RFP) into a Product Backlog, more READY than you would expect in pure Scrum. But we put a maximum length of 1 Sprint on the effort (but usually did it in less time). Our Sprints delivered DONE and potentially shippable work, but we added a final hand-over Sprint (no development!) to close the project. Oh yeah, our ‘slack’ turned into Product Backlog Grooming sessions.
A framework was born.
I went through lots of yo-yo movements over the next years. Even quitting for a while, tired of the slow local adoption (supplier ànd customer side). But… relaunched my ideas as My.Fragility to re-enter the market. And at my current employer we renamed the framework to ScrumPlus, because it does respect Scrum completely, but just extends the base pattern of Scrum to the particular use for delivery of fixed price-negotiable scope projects.
Back to the future
In February 2011, my management decided to apply only Scrum and ScrumPlus in some major Service Lines, abandoning RUP or other traditional approaches.
So I have set up a training program while I will be coaching people in the field. From the training people will get a deep understanding of the base mechanics, principles and emergent Scrum. Project practitioners will get a good understanding of ScrumPlus as instance of Scrum, its base Philosophy of Done, its Agile Project Life Cycle and the 2 Excel tools.
And as you have understood this is largely rooted in my early eXtreme Programming experience.
or: the evolution towards what I now call “ScrumPlus“.
Over the years I assembled a framework of roles, practices and experience in Agile delivery of fixed price projects as an external IT supplier (consultancy). Starting with eXtreme Programming (2003), it was expanded with Scrum in 2004 (when I certified from Ken Schwaber, quite unforgettable). Still, due to specific circumstances (local market, consultancy perspective, etc.) we always did just that little bit more.
The essence of my framework has not really changed. But it has always been a struggle to name it properly.
In 2008-2009 I used the very personally inspired My.Fragility. As that reflects how Scrum ‘saved’ me, how it set me free to work better with teams, customers and management. The gigantic relief of being free to be fragile, personally and with people (as opposed to bossy-ish command-and-control that management traditionally tried to force me into).
At that time my professional position blocked the use of my framework. But keeping it alive via this blog and in personal writings eventually revived me via Capgemini Belgium (yes, still consultancy): rolling out my framework and tools, a representative in the Agile Consortium Belgium and certified as Professional ScrumMaster I at Ken’s Scrum.org.
Time to use our Community of Practiceblog and a (more corporate) name: ScrumPlus. As that confirms that we do Scrum, but also more:
We explicitly define our engineering standards as Quality Loops;
We add time to (1) transform a Vision into a Product Backlog (enhance ‘Ready’) and to (2) do a hand-over to customer’s staff. But not breaking the continuity nor weakening the Sprintly ‘Done’.
I willingly admit that this is possible with ‘pure’ Scrum as well, but the ScrumPlus framework is at least valuable in the local adoption of Scrum. And in my professional and market circumstances that is a big win.
Is there a hidden secret to the success of software projects?
Of course there is not. No silver bullet. But often was I asked for such a secret and often have I wondered on the subject.
My My.Fragility framework grew out of an attempt to describe my recipe. And although I firmly believe in this toolbox, there is simply… more. An undefinable extra?
Intrigued by the term ‘Engagement Manager’ I ran into a great blog post that essentially states that a Project Manager must be involved in Sales. And Legal, technology, Accounting, etc. To act cross-functional.
– Hey! That’s not new. That’s my way of doing Project Management.
– Okay, okay. I understand. Finally. It’s not the traditional view.
So, there you have it. My secret. Vision and attitude. Beyond pure delivery. A continuous and steady focus on satisfying and lasting working software, beyond politics, small talk and short-term reactivity.
Dedication, engagement, commitment. The will and the force to be more than a Project Manager, to be… Engagement Manager.
Is there a way to check on the correct application of Scrum?
Most attempts end up in complex questionnaires or big assessments. This is strange as Scrum is a simple process and has distinct definitions of roles, artefacts and meetings. And I also distinguish core principles.
When presenting Scrum as the core process of my My.Fragility framework I always show my Scrum Diamond, a graphical representation of the 3 essential elements for each of the 4 Scrum ceremonies:
It makes an assessment of Scrum simple: check whether the process and the above ceremonies are in place!
And remember: Scrum prescribes a minimal, but tightly coupled, set of ceremonies. Skipping even only one implies affecting the essence of Scrum. Doing so does not necessarily mean that you are not Agile or don’t perform well, but don’t call it… Scrum.
The book Implementing Lean Software Development (from concept to cash) by Mary and Tom Poppendieck gave me an additional perspective and language (terminology) on quality and testing, thus enriching my existing insights.
Traditional testing is focused too much on bug hunting, mostly after a development cycle and including a devious rewarding or penalty policy. There is too little attention for verification of quality while building.
The development process should be oriented towards creating quality upfront (i.e. before UAT, release or whatever post-process control), and verification during the development process. If verification reveals a defect, the ‘line’ is stopped, the cause identified and resolved.
My My.Fragility framework holds Quality Loops. These are performed continuously and at least daily. It is based upon eXtreme Programming practices. They serve as engineering standards within the Scrum process that is at the heart of my framework. It shows our focus on quality and integrated testing:
Despite maybe chaordic circumstances, most (all?) customers are very attached to having a good upfront price indication. Even as a convinced Agilist and Scrum Practitioner I still want to serve those customers.
My My.Fragility framework tries to align both views upon a well-defined (Agile) Project Life Cycle:
During a (timeboxed) Pre-game staging effort, an initial Product Backlog is created, estimated and given a total price/elapse time (following my Definition of Agile Planning). The Product Backlog and Release Plan (split up of elapse time into monthly Sprints) is included in all proposals and contracts. It is the formalization of a mutual understanding and trust of what is included and what is not.
During implementation, the full Scrum process is applied, but the number of Story Points is kept in balance with the estimated number. I.e. when changing or adding User Stories, the priority of a comparably sized effort (in Story Points) should be adapted. And, yes, this might result in not implementing the lower priority Stories. Unless impact on timing and budget is accepted.
Keep track of the changes (delta) in a Delta Backlog.
Play the Planning Game with the customer to maintain the balance:
During a Sprint, refine next priority Stories and assess their estimates upon the actual knowledge
Let the customer decide on the selection of Stories for the next Sprint. Intervene as little as possible. Assist
Iterate until the selected #Story Points matches the available #Story Points
So, Agile techniques may well be used to deliver total results in a fixed timeframe, when adding the notion of Negotiable Scope.
