Category: Werk / Work

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 — Leave a comment

Scrum Day Europe abstracts

On 11 July 2012 we organize the first Scrum Day Europe event in Amsterdam (Netherlands). The aim is to yearly unite executives, CxO persons, thought leaders and practitioners on agility via Scrum. Have a look at the program and register at the website.

Here are the abstracts from the session of Ken Schwaber and of me:

Ken Schwaber (“Scrum and Continuous Improvement”):

“Organizations need to be agile. This may mean responding to opportunities better, solving existing problems, removing waste, or just developing better software. Scrum is a tool many organizations use to gradually become agile. Ken will present a framework for continuous improvement toward agility. Stage by stage, the model demonstrates the application of increasingly sophisticated practices in the areas of value, productivity, quality, product development and change. Ken will show how these relate to metrics and the organization’s unique agility signature. An organizational model that drives continuous improvement is also demonstrated.”

Gunther Verheyen (“Emergence of the Customer-Oriented Enterprise”):

“Scrum and Enterprise Agility – Scrum is a widely adopted framework for complex product development. Gunther Verheyen, Capgemini’s global Scrum leader, has witnessed how Scrum is a powerful mean to adopt the new, Agile paradigm of software development. Gunther will share his observations how Scrum is currently surpassing the walls of the software department. Gunther has a vision that helps people and organizations capitalize on this evolution and use Scrum to grow into Enterprise Agility. Because organizations can do more than just faster and better software development to delight its customers. What emerges, according to Gunther, is the “Customer-Oriented Enterprise”. But Gunther will demonstrate why it is highly unlikely that this is the last stage of organizational evolutions…”

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

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 — Leave a comment

10 years, or so. Piece of a career. Rückblick.

It’s been 10 years since the world was shocked by the brutal airplane attacks on the US. It’s a terrible birthday, but it also reminded me of the fact that it’s been only 10 years of working in IT consultancy for me. But, boy, what a path it has been.

On 9/11 of 2001 I was guiding a junior analyst of a customer of the consultancy company I started working for not too long before. After having heard of some crazy attack, but not even knowing what the twin towers really were, I drove off to an interview with another customer for an analysis assignment. They approved of me, and I started… analyzing. Having no formal background, except a 3-day UML course (hmm, don’t have the attached diploma anymore, I fear), I tried to be pragmatic. Mixing plain text descriptions with Visio drawn screen drafts and flow charts and other diagrams. Whatever seemed most appropriate to get the message across. I later on estimated the project upon a model built by a senior colleague, upon listing screens, field and data types, and expected difficulty. And my management strongly insisted on communicating less days to the developers than estimated. You can’t trust ’em, ya know. But I didn’t, as I didn’t hide the included contingency. Did create a predictive plan. A giant MS Project something matching the expected elapse time.

Having no formal background in project management, I managed to get my team in the same room and do intermediate sessions with the customer. Project room however was organized in a traditional class style (rows) and I was regularly disappointed because my extremely good contacts with customer staff didn’t prevent them from abusing my intermediate sessions for adding scope and changing their mind. Still, we had a fine time, and the project ended (for my employer) in a break-even, which made it even a fantastic fixed price project.

After this project I was asked to start up a new, critical project in very difficult circumstances, i.e. the project hadn’t started yet and was already nearly over time. It only took 2 smart software architects 15 minutes to talk me into eXtreme Programming. Because I saw how XP made explicit, structural and inescapable what I intuitively had tried to do in my traditional project: communication (pair programming, face-to-face) and consistent, clear iterations. Project wen extremely well, ended in time and with profit. Quite extraordinary for a fixed price project. Big-time success!

When scaling up for that same project in a next phase, I was pointed to this thing called Scrum. I read the 2 books by Ken Schwaber available at that time. I went to a CSM course by Ken, where I learned formally not so much, but was excited about the collaboration with Ken and the other participants. We then replaced our organizational practices from XP with Scrum. We kept on applying XP engineering practices though and this felt really natural.

Today I am reading “The Black Swan” (Dutch translation though). On unpredictable, high-impact events. Like 9/11. And I just officially became Professional Scrum trainer from Scrum.org and… Ken Schwaber (Professional Scrum Master and Professional Scrum Product Owner class). You can’t even imagine how proud and happy I am about this. It seems such a long road. Yet, the seeds were sown not more than 10 years ago. And no terrorist or traditional manager is going to ruin my pride.

Posted on by — Leave a comment

The iron triangle of valuation

My daily business is software development. I live, breath and practice it from the evil and deviant perspective of Scrum. Scrum is a lightweight framework for complex product delivery. Although the focus is on a product being created, built, maintained, much software development work is organised in projects. There is -semantically- nothing wrong with a ‘project’ in itself. A ‘project’ can be described as a focused endeavour towards an objective. The real problem in the world of IT is the past, and at many places still current, interpretation and definition of a project as a ‘fixed price’ project, a project in which price, scope and time are fixed. A viable return on a project however can only be achieved by balancing 3 elements: time, scope and budget. If there’s no active balancing act (one of the elements is forced or twisted beyond some boundaries) the only element remaining that can vary is… Quality.

Sidenote: if there are no frequent, intermediate releases -see the time constraint- there is also no guarantee on the optimization of value, regardless whether the 3 expectations of end_time+budget+scope are met.

I used to illustrate this ‘fixed price’ mechanism by representing a project as a machine with 4 levers, where the lever for Quality is non-negotiably fixed at ‘High’. As the operator can only move 2 levers at the same time, the last, free, lever will automatically re-position. Trying to fix the last lever will break the machine.

Iron Triangle of Software ProjectsAlthough I still like my machine metaphor, let me hereby revert to the more known iron triangle. And let me start by emphasizing that, although unfortunately often forgotten, there is a 4th element, the inner element, Quality! My triangle with its three project controls on the legs is a music triangle. If one of the legs is deformed, clinging the triangle will lead to an ugly, out of tune, non-qualitative sound. Fixing scope, time and budget will lead to a terrible sound.

Let me use the iron triangle representation in another area to explain where another ugly sound originates from.

In my software business there is a typical and deluding career path, i.e. the virtual ladder that forces people on the path of ‘growing’ from developer to analyst to project manager (and beyond). Scary, enforcing the Peter Principle like that. I fight this unfortunate hierarchical vision by always referring to ‘roles’, and never ‘positions’. And ‘roles’ have everything to do with talent and insights, and not with bossy importance.

Iron Triangle of Work ValuationMy triangle of Valuation illustrates this vision upon the core idea that every person should look for a balance in (1) interests (the love for a ‘role’), (2) the talents to perform well and the ability to do it in an appropriate (3) (working) domain. The outcome of such balanced iron triangle will be proper Valuation, the fact that people feel and are respected. Respect should be interpreted in a broad sense, i.e. financially & in various non-material ways.

Does this model solve everything? Of course not. One’s talents might be big in a domain that the person doesn’t care about. Or a person may believe in having a certain talent, that aligns with his/her interests and make it a working domain. And still not be valued. Might be that your talent isn’t what you hoped it is. Might take time to get valued. Might never come. If you’re happy and having FUN, you might not care and keep believing.

An Agile approach to Human Resources policies does not only respect people (as individuals and as Teams) and promote sustainable pace (to name a few). But well performing in ‘Roles’ will be valued more than striving for positions, and the iron triangle of (work) Valuation is a better reference model to have a good (frequent) dialogue over the balance in it, job satisfaction, performance and… Valuation.

Posted on by — Leave a comment

The roots of Business as Unusual

Before joining Capgemini Belgium in March 2010, the VP of Technology Services gave me a book that was co-authored by Andy Mulholland, CTO of Capgemini global.
Mashup Corporations (The End of Business as Usual) turned out to be a curious book. It has a story line, but it’s not a novel. It’s not a highly literate, fictional or romantic piece of work, but a very direct and effective tale about… technology. About uplifting technology to Service-Oriented Business Transformation.

The authors describe the transformation process of a fictitious company. Vorpal inc. is an important, but very traditionally organized, player in the market of popcorn popper machines. It enters new markets through the use of its ‘shadow IT’, leading to a top-down transformation to fully service-oriented operation, in order to cope with the continual changes and new demands of the new channels. It thereby builds new internal structures and more integrated (win-win) external relationships.

Vorpal makes the shift from ‘hub IT’ to ‘Edge IT’ on the wagon wheel:
(1) The ‘hub’ holds core enterprise data, clear and predictable processes and monstrous applications to maintain it;
(2) To reach new businesses, Enterprise applications are customized and refined;
(3) The ultimate level of flexibility and dynamism is achieved by opening up to new worlds via controlled services.

Agile is only briefly mentioned in the book, but in my Scrum Evangelist opinion, Agile development methods are the perfect match for this transformation. Deliver quickly, with high quality but on a less formal base. Go to market, learn and adapt.

This book should be on the reading list of every CTO or CIO !!!

Note: You can download my full paper on the book and the link to Agile.

I also published the complete story on the Capgemini Technology Blog, for our Business As Unusual program:

Posted on by — 2 Comments

Managing Risk & Quality with Scrum

It’s a strange, yet wonderful, world, our world of Software Development. Where success is often considered a coincidence, a lucky shot and too anecdotal to believe. Although I have a proven track record of successful projects with Scrum (figures and data included) I still try to present various angles to my results. Here’s my perspective on Risk & Quality…

Risk

In a traditional project, a number of phases and activities are typically performed separately and sequentially, upon the belief that extensive descriptions, signatures, sign-offs and hand-overs assure a good result. However, as practice shows, users and customers don’t realize what they’ve asked, described and signed until they get their hands on it. In the absence of that, risk just piles up. And when the usable application finally becomes available, all additional work, rework, tasks or activities will immediately force the project out of time and out of budget.

In our Scrum projects we slice the work in timeboxed iterations (Sprints). We re-organize the typical IT activities drastically because we perform them daily, in parallel and in every Sprint. We build and demonstrate working software at the end of each Sprint. Feedback and change is processed in the next Sprint, keeping us at all time in line with (changing) expectations. But, it’s true, we do not spend countless effort and time on upfront work. Risk therefore seems high at the start, but upon delivered results it will quickly decrease and keep steadily decreasing:

Quality

The ultimate evidence of quality is in working software. As we deliver that frequently, functional quality can be easily determined (and quickly improved). Business Value therefore continuously accumulates where in a traditional approach it is more delivered as a big (disruptive) burst.
The underlying technical quality of the software is assured by the daily, integrated testing and the application of good ‘engineering standards’. We implement these standards with our (daily performed) “Quality Loops”:

Here’s a movie

When creating a presentation on the above, I started a little experiment with the recording option of PowerPoint (version 2010) and succeeded in creating a movie of my presentation. And however improvised and somewhat rudimentary it may be, I’m just gonna leave it like that…

Posted on by — 1 Comment

Adding people to a project

I don’t align with Fred Brooks’ Mythical Man-Month, and certainly not with his law, “Adding people to a late project only makes the project later”.

I asked Jeff Sutherland about it at our Agile Consortium Belgium in April 2010. Jeff demonstrated with data from major projects that Brooks’ law is plain wrong, that adding people can positively affect productivity.

In September 2010 I checked it with David J Anderson at a Kanban training I followed. He went through the roof because of such ‘laws’ that haunt our profession and also had the data to disprove Brooks’ law.

Well-oiled Agile Teams take in new Team members without a productivity relapse. Thanks to iterative-incremental processes and technical practices like Test-Driven Development, Pair Programming and automated integration and regression testing (aka ‘Continuous Integration’).

Proven experience

Beyond my personal conviction I then realized I’ve proved it myself. At an atom sized scale compared to Jeff or David J, but still…

My Team was responsible for the core (Java) application of a large media platform (digital tv), centralizing business logic and system interfaces. A major new Release was to be developed from October to December 2004. Our pre-game investigation had turned out this to be feasible.

Despite frequent reminders, important prerequisites were not met, limiting our Velocity. Beginning of December I announced an extra Sprint (January 2005). Unhappy and angry customer. Although settlement of our needs was still too late I didn’t want to be the showstopper again. And decided to add people… shown in this weekly chart:

But… productivity increased and we finished in time, as is shown on our Product Burndown chart:

Looking back, all parties around the table in December must have been very happy with ‘our’ delay. Because we were the only ones that delivered end of January… Customer happy. With a great recommendation.