Tag: Scrum

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.

Posted on by — Leave a comment

More to Agile than meets the eye

Agile is, less acknowledged than but much like Lean, a set of thinking tools and interwoven principles. They are the levers that empower people to faster create better products in a sustainable and respectful way. Typical misconceptions like using Lean for mere cost cutting, limiting Agile to the software department and expecting one, silver bullet, process prevent the emergence of larger benefits.

In Agile, better software products with Built-In Quality are faster achieved by fundamentally re-organizing all activities in an iterative-incremental way and by performing tasks in parallel on a daily basis. A different approach to Managing Risk & Quality.

But let’s have a look at Agile and Lean as blending philosophies, the matching of Agile practices with the main Lean principles.

There are at least 3 major approaches to Eliminate Waste:

  1. Potentially unused inventories (requirements, predictive plans, overdesigns) are not produced upfront. The highest priority work is detailed just in time. A Team will Pull in the amount of work they deem feasible for an iteration, commit to it and build it upon progressive learning and continuous improvement.
  2. Partially done work won’t pile up as an iteration results in working increments. Undone work is prevented by an overall Kaizen thinking, made explicit in a daily Inspect & Adapt stand-up meeting and an iterational Retrospective.
  3. Active Business Involvement excludes unwanted or invaluable requirements. Knowing that only 20% of software functions are regularly used, this represents an enormous waste while showing much disrespect to the people having to spend their time on it.

A Shared Visual Workspace facilitates fast decisions, high interaction and short communication. Openly available Information Radiators are used for the Team to self-inspect and adapt and for external transparency. It shows the real progress upon real efforts and protects the Team in maintaining Sustainable Pace, to assure product quality.

Iterations are timeboxed to Deliver Fast and usable, end-to-end working software that can be put into production. A review with all stakeholders gives the Team outside feedback, remarks and enhancements. Besides this product inspection, an Agile Team will improve its overall operation with a retrospective meeting. Within an iteration however each Team member has the right to immediately Stop the line.

Optimizing The Whole is achieved through active Business involvement and the on-site presence of all technical skills to turn ideas, options and requirements into working software. The Value Stream is optimized because traditional waiting activities like hand-overs and external decisions are eliminated. No macro hand-overs due to a sequential process. No micro hand-overs within the collectively responsible Team.

And, finally, a Manager-teacher, facilitates the Team in teaching the process and removing impediments.

Attached is my complete paper on The blending philosophies of Lean and Agile. It was previously published as 2 blognotes, one for the Lean part and one for the Agile part of the text at the Capgemini Techno Blog.

Posted on by — 2 Comments

Respecting Scrum by doing more

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

Posted on by — Leave a comment

Why I loved going to the PSM Course

Early December 2010 I went to a Professional Scrum Master (II) course in Zürich, taught by Ken Schwaber and facilitated by Zühlke Engineering. Already being a PSM II, I went mostly to see Ken and to look to improve my own teaching skills. And it was a very enjoyable event!

Ken and the ScrumAlliance parted in 2009 leading to Ken establishing Scrum.org. As an outsider I don’t care about the circumstances or the rumors surrounding this. I’m only concerned with the profession of Scrum, that I have now been practicing for 7 years and for which I truly believe that Agile is finally crossing the chasm in the lowlands of Belgium and The Netherlands (and other parts of our old continent of Europe).

And I can only conclude that Ken has learned his lessons by:

  • Separating course attendance from assessment/certification;
  • Incorporating community feedback;
  • Creating a development course and for Scrum Teams in general;
  • Setting up a Product Owner program with a separate assessment;
  • Upgrading the PSM course material.

For the latter I can testify that a number of topics were already treated in my CSM by Ken in 2004, but new stuff and ideas have been included far better than in recent CSM course material that I compared it to.

What I strongly like in Ken’s teaching is his holistic perspective on Scrum, like the spirit of the Scrum Guide that he co-wrote with Jeff Sutherland. His courses go well beyond the formal mechanics of Scrum. It’s much more about why Scrum works, its psychology, the positive thinking, the social aspects. And the empirical foundation of Scrum to help us not even trying to predict the unpredictable. And beyond the theory, luckily, Ken has tons of stories and cases to share with the training participants.

This PSM course has certainly inspired me in my teaching of the Scrum Trainings that I launched at Capgemini. At a considerable scale of internal participants and geographical spread. Hoping that I can open these trainings to external audiences, and maybe even as PSM Trainer…

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

More to Lean than meets the eye

I have read The Machine That Changed The World, Poppendieck books and the great Lean Primer. I have had a Kanban training by David J Anderson. So I am not an expert on Lean, but still… knowledgeable. At least knowledgeable enough to detect that Lean is far too much confused with ‘eliminating waste’. In its turn mostly a faint excuse for ‘cost cutting’ by mislabeling workers as non-value adding. Quite tiresome.

From that popular misconception it is a long journey to the understanding that Lean is primarily about respecting People and optimizing Value and Quality. That adopting Lean requires to look beyond mere practices, but introduce a mindset and a culture that enables and encourages people to reflect on their daily work and self-improve.

People

The corner stones of any system claiming to implement Lean are People.

They work in a cross-functional way upon a practice of self-management. In a Go See style Manager-Teachers help people on the workfloor to understand Lean and self-management to build better products. The workers get to embody the spirit of Kaizen, the attitude (!) of continuously minding the process and looking for improvements. Every involved person can stop the line if a problem occurs, so the root of the problem can be immediately detected and countermeasures installed.

This refers to all people that contribute to the Product: customers, workers, teams, suppliers, managers. And implies the abandonment of traditional relationships based upon large volume purchases, big negotiation rounds and pressuring one another. Likely to end up with at least one strangled party. It’s about building relationships on profit (and risk!) sharing. Mutual growth.

Waste

To start with, I prefer Avoiding Waste over Eliminating Waste. At least it implies a subtle difference in timing on when to act… Furthermore ‘Waste’ refers to steps in the process, not to disposing of people.

But, naturally, waste can creep in. The base to detect it is Kaizen. But upon that base attitude, a good practice to structurally identify waste is Value Stream Mapping. The full process from ‘idea’ to ‘build’ is timelined. The Value Ratio (time on Value adding / Wasteful activities) is the baseline figure against which to improve.

Another hands-on method for root-cause analysis are the 5 Why’s. Keep searching for the deeper cause of a found problem, until the bottom is reached. And, although not much, it may require more than 5 attempts…

Flow

People work together in Team Rooms and apply Visual Management.

A very popular approach has become the Kanban board. Within Lean in general, a Kanban is a physical signal-card intended to optimize stock or inventory (just enough). The term ‘Kanban’ is however becoming more and more known as the name of the tangible method for software development.

Physical cards represent work items and are placed on a whiteboard to show the work-in-progress (‘WIP’), with limits per state. The Cycle Time is the total time for completing a work item. Work cannot be pushed down the line causing disruptions to the flow. Work is taken in on a Pull base. The Team focuses on optimizing the flow by removing piled up work, thus safeguarding the overall cycle time (i.e. timely delivery).

Process

There is no definite end goal, no final process. The improvement itself is the goal. This however does not exclude installing a proven process at startup as a baseline implementation against which to endlessly improve and adopt installed standards. But the actual process, its phases, roles and states, must be constantly tuned to the actual situation. There is no standard Lean process template to be copied.

And Agile approaches like Scrum are a natural fit to these Lean fundaments. No mixed, but blended philosophies.

Posted on by — Leave a comment

Scrum – Beyond the ceremony of certifying

Why would you want to certify in anything Agile, and Scrum especially?

Well… you don’t. The right attitude will make you:

  1. want to learn about Scrum from an expert as a head-start for practicing it. Truly taste it by using the tool to get more Agile.
  2. want to assess your knowledge and experience.

Exactly the needs that Scrum.org is addressing. To think beyond courses. Knowledge, understanding ànd experience over paper certification, which I certainly value more:

  1. For learning purposes there is the Professional Scrum Master course, i.e. a retake of Ken’s former CSM.
  2. But there is a unique set of online assessments:
  • With the help of the communities an open assessment was created. I participated in it at the time it was still called Scrum I. It’s free of charge and you can use it as a quick check on your knowledge.
  • The level I assessment checks the fundamental Scrum knowledge (the cost of 100 $ is also included in the PSM course fee). A score of 85% is required!
  • The level II assessment requires 85% as well, which is not achievable without even more demonstrable knowledge, having applied Scrum and understanding the underlying principles. As I wrote in my blog note “Unsatisfied? Uncertified? Unvalued?“.

And, finally, Ken is assisting the development communities with the Professional Scrum Developer program, holding a course and assessments in a .Net and a Java version.

The knowledge of Scrum is verified against the Scrum Guide from co-founders Jeff Sutherland and Ken Schwaber. Capture their insights!

An highly unserved and underrated audience however are still the Product Owners, although a crucial role in Scrum. The ScrumAlliance offers a Certified Scrum Product Owner course (‘CSPO’). But… no assessment yet. I don’t want to go into CSP, CSC or CST options because I feel they are heavily over-institutionalized. CSD is too unclear.

The ScrumAlliance verifies knowledge of Scrum against the Scrum Primer, from the Scrum Training Institute. I’ve read both and find the Scrum Guide to have the in-depth Vision of Scrum, while the Scrum Primer is more about concrete practices.

Posted on by — 2 Comments

Definition of… Agile

There is no final ‘definition of Agile’, no silver bullet / fits all approach. ‘Agile’ is not even one tangible method, but holds the common principles to a number of methods, that are as such stated in the Agile Manifesto.

I try to address this topic with the presentation of key characteristics. For both ‘Agile’ and traditional methods. That seems to be very recognizable.

Key characteristics of traditional methods:

  • Plan-Ceremony driven;
  • Single pass waterfall (sequential model);
  • Success = compliancy with predictive plan, i.e. end = original set destination;
    • Progress = ‘deliverables’ (specs/design/code/reviews/signatures);
    • Resisting/blocking ‘change’.

    Key characteristics of Agile methods:

    • Change-People driven;
    • Iterative-incremental process;
    • Success = delivered Business Value;
    • Progress = frequent delivery of working software;
    • ‘Embrace change’. Even encourage change!

    It is quite possible to get organized upon these general principles, and find a way through it and successfully build software. It is however a lot faster and more productive to select an existing, tangible process. Start by implementing it ‘from the book’ to get a firm grip on it. In a next step, it can still be optimized upon specific circumstances.

    And, while you’re at it, have a good look at Scrum. It is the most spread Agile method worldwide, has lots of communities with well-documented cases, is technology-independent and there are great coaches to assist a Scrum transition. A good starting pointing might be Scrum.org…