Tag: Scrum

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).

Posted on by — Leave a comment

Reflecting on Sprint Length via 1-day Sprints

The foundation of Scrum is empirical process control, a technique to build complex products in complex environments, where few activities are repeatable and the course of work is quite unpredictable. Which is the case for the creative work that software development is.

In empirical process control objectives are fed into a system, and via closed-loop feedback results are regularly inspected against the objectives in order to adapt materials, tasks and process. Skilled inspectors do inspection at an appropriate frequency, so focus and time to create valuable output are balanced against the risk of allowing too much variance in the created output.

Scrum includes 2 cycles and a lightweight set of events and artefacts to do inspection and adaptation upon transparently available information and commonly understood standards.

  • At the Daily Scrum the Development Team inspects its progress, estimates, planning and tasks within the container of the Sprint. All of these elements were initially laid out at the Sprint Planning. They use the Sprint Backlog, the Sprint Goal and a progress trend on remaining effort. It assures they don’t get out of sync with each other and with the Sprint Goal for more than 24 hours.
  • At the Sprint Retrospective the Scrum Team inspects the complete, well, ‘process’. Rather the way they have played the game of Scrum in the performed Sprint. The objective is to define what playing strategies will be applied in the next Sprint. No topics are excluded; tools, technology, communication, relationships, quality, engineering standards, definition of done, … It’s basically about establishing what went well, what shows room for improvement and what experiments might be useful to conduct in order to learn and build a better product.

There seems to be a tendency to move to shorter Sprints. The last version of the Scrum Guide advises Sprints of 1-4 weeks. 4 Weeks being an absolute maximum, I think 1 week is an acceptable minimum.

Let’s say you would do 1-day Sprints. Both Scrum’s described inspection events will occur at the same time, or at least take place at the same frequency. The danger is very substantial that a Scrum Team will focus merely on its daily work and progress, but takes no time to inspect & adapt the overall process and ways to improve quality.

We should also keep in mind that Sprint length is best defined upon the frequency at which the Product Owner and the Development Team need to consult with the stakeholders over a working version of the product and the decision on a functional release of the product. Sprint length will take into account the risk of losing a Business opportunity because Sprints are too long. Well, if your business is indeed so volatile that it is only 1 day, please do 1-day Sprints and release daily. But be careful in burning your inspection mechanisms.

Above all, do organize the Scrum events and enjoy the adaptive power of the 2 mutually re-enforcing inspect & adapt cycles. If you would only release on a weekly base, be realistic and go for the optimal approach, a Sprint that matches your product cycle and takes 1 week within which you will still adapt to reality on a daily base.

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

Distinguishing Distributed from Dispersed

An upscaling technique for Scrum is installing Multiple Scrum Teams, i.e. fully enabled Scrum Teams that work in parallel. It includes the introduction of a ‘Scrum of Scrums’ to discuss integration aspects across the Teams and the identification of integration tasks for the Teams. The working increment at the Sprint Review should be an integrated result.

It’s all about inspecting reality. A Product Owner cannot figure out whether separate increments work well together without real… inspection. Less than integrated increments leaves unknown, undone work in the system. Putting Quality, time and predictability at risk.

And it would eliminate transparency. Taking away the basis for adaptation, not? Gone are then the pillars of empiricism. No use in putting a cloth over the thermostat if you want the heating to adjust to the real room temperature.

When applying Scrum in a non-collocated mode (or whatever deceptive term is used) the concept of Multiple Scrum Teams is usable if you have complete Scrum Teams at globally spread locations. You will still need some grouping notion over Product Backlog items (themes, packages, features) to orderly distribute work. But every Team has its Sprint Backlog, sprints as a ‘Whole Team Together’ and does a Daily Scrum. The Teams share a ‘Definition of Done’ and engineering standards (as well as source code and integration systems). They figure out a way to do common Sprint Reviews. These are Distributed Teams, full Teams that work together on a Product/platform at different locations in the world.

But people use ‘distributed’ even if they in fact mean Dispersed Teams. When the Team members of a Scrum Team are spread over the globe. It requires a different approach to organizing Scrum, looking for solutions to have a Daily Scrum… daily, with the complete Team (of Developers) at a (convenient) fixed time, and a fixed place. To organize a Sprint Planning with the complete Scrum Team. To have short, direct communication.

Important reasons to think very consciously about the type of ‘distribution’ teams are working in, in order to be well organized.

And, whatever formula is being applied to collaborate across the world, voice calls do not suffice. It requires video conferencing, electronic whiteboards and a virtual form of a shared visual workspace. There is additional overhead. And traveling should be included in the calculations (for collocated Team formation, regular visits, social contacts). It tends to cut the cost cutting that (let’s be honest) offshoring is being used for.

Posted on by — 1 Comment

Different shades of Yes

Training and coaching are important when implementing any new paradigm. Scrum is no exception. But beyond formal assistance, enthusiasm is required, belief, trust, support. After all, it is… change.

Scrum makes enterprises find fun in being competitive again by re-uniting people beyond organizational borders around corporate objectives. But it cannot be forced onto people in an downward way only, nor in an exclusive upward way. Although downstream adoption might seem obvious, it is not always. It can make the real source of improvements unclear. And upstream adoption is surely a lot harder, you can’t do without. Scrum done well, no matter how simple the framework, will transform the way of work so deeply that it will not happen unidirectional only. Because there is more to Agile than meets the eye…

Even confirming a transformation may hold various forms of Yes:

It is very clear that the most desirable attitude is the “Yes, and” form. The minimal form within it is that people mean that they will go for it and will resolve possible impediments. Yes, and we will fix whatever comes in our way. Even better is people saying Yes while thinking ahead, about emerging options and how to already further exploit the adoption. Yes, and we will try x and y as well.

Most commonly people will act from a “Yes, but” attitude. Primary reluctant. Doubting. A tendency to raise objections. Yes, but what about z. This is in general not insurmountable, but it might take time to answer or remove the objections. Wanting to do so requires empowerment, may be time-consuming and is therefore to be observed carefully for real progress. 

Dangerous is the “Yes, but no” response. It represents a political “Yes”, that is at the same time a factual “No”. The promise of a firm decision takes away the conversation. Working results are doubted and blocked again and again. If reviewed at all. Variants include “Yes, but not now“, “Yes, but not all at once“, “Yes, but not too much at the same time“. And new variants will pop up as you try to move forward.

A hideous sub-form is the “Yes, but reality” disguise. Reality can probably not be denied, but is also a very flat generalization. A small dissection will show that ‘Reality’ refers to the existing status quo, where the core idea of change is to challenge that, to build a new reality. This is a very bad case of “Yes, but no” answer.

But, don’t be distracted or discouraged. After all, it is just… change.

Popo Emotions Icons by Rokey.