Posted on 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 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 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

    Posted on Leave a comment

    The upstream adoption of Scrum

    Since 2003 I have been involved in successful implementations of Scrum, through various projects and in different organizations. This was primarily on my local market, Belgium. Since 2010 I started promoting adoption of agility through Scrum beyond my professional consulting activities, as board member of the Agile Consortium Belgium.

    While worldwide the Agile portfolio is going through the Bowling Alley and Scrum is emerging as the Gorilla, my local market seems to struggle to even cross the chasm. One of my re-occurring findings is the lack of upstream adoption of Scrum. I consider it a major impediment.

    Retrospective of a Belgian ScrumMaster

    In my position as consultant I rarely have complete control over the delivery process, and even the decision to actually call it ‘Scrum’, let alone full-scale adoption. But the least I always do is master a project instead of manage it as a traditional command & control-like dictator. I refer to it as my Scrumitude: iterative phasing with end-of-iteration demo’s, mastering a Team into Sprint Planning and self-organization, being a facilitator, removing impediments over being prescriptive, establishing a close relationship with the Business, promoting on-site presence of cross-functional team skills, using visible information radiators and high transparency. All information gets consolidated in a Product Backlog Tracking model I created. The actual course of Sprints and the reality of what the Burn-downs show is used to continually adjust expectations, for better or for worse.

    In the absence of outspoken Scrum, even such stealth application of Scrum results in regular, often perceived as on-time, and on-budget, or better high return delivery with higher satisfaction. And it does make projects fun again. No surprise that downstream adoption of Scrum, i.e. by Teams, end-users and business representatives, is generally huge, outspoken or stealth.

    Although good figures and great, highly visible results are generally synonymous for upstream ‘success’, the Scrum process and its essential causal part in this success seem hard to capture and to accept for many old-skool commandistos.

    • The first upstream obstacles are lower level management that likes to operate below corporate radars. They object the transparency and visibility as they feel personally less beneficial on the ‘success’.
    • The more upstream levels don’t care about the process, just about the figures. In the best case they tolerate a deviant process. An unpredictable and unreliable base for deeper transition.

    What we need is active and explicit upstream support and promotion. Think about operational management (‘pure’ IT), sales divisions, delivery managers and hierarchical management.

    Confessions of a Belgian ScrumMaster

    The success of stealth Scrum is limited because it disguises the essential change. Stealth Scrum is certainly less intrusive, but the leverage of advantages and benefits that will last, is generally wasted. As a consultant it remains a struggle to articulate about Scrum more clearly without losing commercial opportunities.

    PSMIIAnd a tedious effect is that people start instructing me with their fantasies on Agile/Scrum. Which is not why I re-entered the world of Scrum and greatly engage in Ken Schwaber’s Scrum.org. And decided not to let the momentum pass this time. And became Belgium’s first PSM II (in August 2010).

    Posted on 2 Comments

    Is that a gorilla I see over there?

    A topic that I frequently run into at customers is the maturity of Agile. I usually present my matching of ‘Agile’ on the Technology Adoption Life Cycle with the Hype Cycle for Application Development. To show the evolution of Agile, and its outgrowing of the stage of anecdotal evidence.

    Specific to the Technology version -for new high-tech paradigms- of the Adoption Life Cycle is the chasm, introduced by Geoffrey Moore. A phase of stagnation between Early Market and Bowling Alley. Of unpredictable length. And some products even never get out of it. Scary.

    In the post-chasm period the viable market forms, and a gorilla rises, an absolute market leader. Alternatively the market leader may turn out to be ‘merely’ a king, much more vulnerable to being overthrown.

    An important and disruptive innovation in itself, Agile is past the chasm. It’s probably in the Bowling Alley, maybe approaching the Tornado. At the same time Agile processes are applied to develop products that are subject to the (T)ALC. Best fit because there’s no time to stabilize into Main Street. And Agile offers just that flexibility while assuring a return.

    At the same time I observe the increasing number of Agile players that is referencing Scrum. Practitioners, trainers, thought leaders, customers, etc. On blogs, forums, in trainings, papers, etc. You name it. Positively (“this is great, we also do it“) or more disapproving (“this doesn’t work, we do it like this“). Although personally convinced that they’d better highlight their own methods’ merits and strengths, I don’t oppose to it.

    And Scrum prospers from it. Free publicity and a trigger to keep moving. I see evidence of the latter in the rise of Scrum.org. More community oriented as an alternative to the ScrumAlliance institute will it open the Scrum offering to a wider audience.

    But it gets very uncomfortable when it gets personal. Quite vicious attacks are regularly launched at the persons behind Scrum and the people doing Scrum, away from the value of the framework.

    Maybe that is exactly the indication that Scrum is indeed emerging as the gorilla of the Agile methods pack…

    Posted on 5 Comments

    Unsatisfied? Uncertified? Unvalued?

    When I announced having passed the Professional ScrumMaster II assessment (including getting certified) the reactions were -to say the least- mixed. People I have effectively worked with sent me warm congratulations. People more distant to me seemed more cynical and skeptical. Time to set free your psychoanalytic ambitions!

    I partly share the cynicism, skepticism and unbelief with regards to certification in general in our world of IT, consultancy and software development. But a little common sense makes one don’t consider certification solely, but experience, attitude and personality as well.

    I know that calling people Certified ScrumMaster (CSM) after merely attending a 2-day course isn’t too credible. Can I say to my credit that it was 3 days when I did it in 2004? But that was then. Nowadays the ScrumAlliance requires participants to do an online CSM evaluation.

    And it doesn’t justify any reservations on the PSM program!

    Last year, Ken Schwaber and the ScrumAlliance parted and Ken started Scrum.org (for a couple of reasons). He developed new and updated programs upon effective knowledge assessments. Jeff Sutherland and Ken updated the Scum Guide. To form the Scrum Body of Knowledge.

    The Scrum Open Assessment was created incrementally with feedback of the community and serves as a check-up on the subscriber’s knowledge. No medals attached, just knowing where you stand.

    The Professional ScrumMaster assessments are not open, but require payment. Luckily, payment is no guarantee. You do not just pay to get a certificate. You obtain 85% or more. Scrum.org has no benefits in creating an unnaturally large amount of PSM’s.

    • PSM I is about knowing how the game should be played. Limited pretensions. It’s also included in the fee for a PSM course, the follow-up to Ken’s original CSM. So it is not just about the money.
    • PSM II is about understanding and applying the underlying principles. Answers that cannot be found directly in the Scrum Guide. Often demanding multiple options with (dis)advantages.

    So let no general skepticism stand a correct judgement of the PSM assessments in the way. They emphasize on demonstrable knowledge, over paper certification, which I certainly have come to value more. Reason why I am proud of my PSM II. Though that won’t stop me from being pig-headed in my way of mastering people and projects…

    Note: The Professional Scrum Developer (PSD) is an innovative program on software development using Scrum. Resembling my Quality Loops?

    Posted on 6 Comments

    Professional Scrum Master II

    I consider myself not only an early follower of Ken Schwaber’s Scrum.org but also a mental companion on his new journey. Must have to do with the fact that I obtained my Certified ScrumMaster from Ken in 2004 in Brussels and am still fascinated with his straight-forward views.

    Despite my (pragmatic) use & application of Scrum since 2004 (and eXtreme Programming since 2003) I was hesitant to take the Scrum.org assessments. Hesitant, as in opposed to arrogant.

    But… Open Scrum went well (Jan 2010), as did Professional Scrum Master I (Jun 2010). The biggest doubts however I had about the Professional Scrum Master II, frightened by the essay-like topics. But I leaped and took the exam. On 26 August. The start of 2 nervous weeks of awaiting the result. To receive my certification… hooray indeed. #27 worldwide.

    Posted on 1 Comment

    Can there be more to Scrum than… Scrum?

    or: the evolution towards what I now call “ScrumPlus“.

    Over the years I assembled a framework of roles, practices and experience in Agile delivery of fixed price projects as an external IT supplier (consultancy). Starting with eXtreme Programming (2003), it was expanded with Scrum in 2004 (when I certified from Ken Schwaber, quite unforgettable). Still, due to specific circumstances (local market, consultancy perspective, etc.) we always did just that little bit more.

    The essence of my framework has not really changed. But it has always been a struggle to name it properly.

    In 2008-2009 I used the very personally inspired My.Fragility. As that reflects how Scrum ‘saved’ me, how it set me free to work better with teams, customers and management. The gigantic relief of being free to be fragile, personally and with people (as opposed to bossy-ish command-and-control that management traditionally tried to force me into).

    At that time my professional position blocked the use of my framework. But keeping it alive via this blog and in personal writings eventually revived me via Capgemini Belgium (yes, still consultancy): rolling out my framework and tools, a representative in the Agile Consortium Belgium and certified as Professional ScrumMaster I at Ken’s Scrum.org.

    Time to use our Community of Practice blog and a (more corporate) name: ScrumPlus. As that confirms that we do Scrum, but also more:

    • We explicitly define our engineering standards as Quality Loops;
    • We add time to (1) transform a Vision into a Product Backlog (enhance ‘Ready’) and to (2) do a hand-over to customer’s staff. But not breaking the continuity nor weakening the Sprintly ‘Done’.

    I willingly admit that this is possible with ‘pure’ Scrum as well, but the ScrumPlus framework is at least valuable in the local adoption of Scrum. And in my professional and market circumstances that is a big win.

    Posted on 7 Comments

    Definition of… Scrum

    Is there a way to check on the correct application of Scrum?

    Most attempts end up in complex questionnaires or big assessments. This is strange as Scrum is a simple process and has distinct definitions of roles, artefacts and meetings. And I also distinguish core principles.

    When presenting Scrum as the core process of my My.Fragility framework I always show my Scrum Diamond, a graphical representation of the 3 essential elements for each of the 4 Scrum ceremonies:

    It makes an assessment of Scrum simple: check whether the process and the above ceremonies are in place!

    And remember: Scrum prescribes a minimal, but tightly coupled, set of ceremonies. Skipping even only one implies affecting the essence of Scrum. Doing so does not necessarily mean that you are not Agile or don’t perform well, but don’t call it… Scrum.

    Posted on Leave a comment

    Stay tuned to My.Fragility

    My.Fragility is my framework of Agile practices for flexible delivery of software development projects.

    • It started in 2003 with eXtreme Programming
    • In 2004 I started using Scrum and certified as a ScrumMaster
    • I’ve always applied personal practices for fixed timeframe projects
    • To prepare projects I use a Product Backlog Estimation model
    • I track development with my Product Backlog Tracking model

    I have started distributing my documentation on it, beginning with my overall presentation: My.Fragility – The Essential Scrum and beyond (handouts) (4 MB).

    It includes:

    • an introduction on the general position, maturity and adoption of Agile as a software development method
    • a focus on the process of Scrum
    • the specific elements (and additions) of My.Fragility
    • addenda on eXtreme Programming, references and the roots of Agile

    Find all my notes on my framework under the tag my.fragility.

    Or stay really tuned via RSS http://en.wordpress.com/tag/my-fragility/feed/