Posted on 2 Comments

Scrum (all sorts of people)

logo-myfragilityScrum is also in the minds of people. My mind is set on the ability of fragility. How about you?

Are you ‘management’? Then you should not only be willing to believe that a software project can truly deliver quality and business value. You should also do (a lot) more than just gather a group of programmers with a project manager on top during a (project’s) timebox.

Okay, so far for a view the community will quickly agree upon.

What is usually less focused on is the level of commitment of the actual team members. In my experience this may turn out to be at least as difficult to achieve. Because it takes the absolute will to self-organize, not wanting to depend on other people to take decisions for you (the essence of ScrumMaster facilitation versus Project Management’s execution of control), to outweigh every (technical) choice against the (business) value and functional profit, to discuss and communicate openly, etc.

Scrum is a simple way to outperform and excel but all parties should respect its essence, that I represent on my Scrum Diamond:scrum-diamond

think (talk) about it…

Posted on 2 Comments

Kanban and Scrum (done or to be done?)

Kan and Ban are Japanese for Card and Signal. A Kanban (signal card) originates from the Toyota Production System (TPS) where it is a physical card that visualizes a pull question for inventory. It serves to minimize stock in a ‘Just In Time’ strategy and is a way to ‘eliminate waste’ while assuring a continuous flow of goods.

In an Agile context, a Story Card is a Kanban. Out of eXtreme Programming it grew into an established Agile practice in describing a feature. A Kanban Board holds the active Story Cards per ‘status’, thus being an Information Radiator (term by Alistair Cockburn, also my inspiration for the Games metaphor).

My.Fragility_logoMy Scrum Product ├ánd Sprint Backlog items are User Stories. (‘Minimal Marketable Feature’ is more generic, but I stick to ‘User Story’) The Sprint Backlog is made visible by sticking a printout from my (Excel) tracking model on a wall. Around the Daily Scrum (we do it standing up) each Story Lead writes the estimated time to finish a Story on the printout and I create the Sprint Burndown. That works fine. We use a Kanban Board only for feedback from functional testing. This is generally too small to create a Story (would be ‘waste’).

Velocity is a way to optimize the inventory and the continuity of work. Traditionally ‘velocity’ equals the #Story Points (gummy bears) that can be finished in one iteration (a Sprint). However, I apply an overall Velocity as a multiplicator on Story Points (ideal time) to result in #planning days. The size of the inventory (in #Story Points) for a Sprint is determined by dividing the available #planning days of a team (minus 2 slack days) by expected Velocity (Yesterday’s weather). Note: continuity is also assured by the presence of the Product Owner. He/she makes sure that no functional issue remains unsolved, on the spot!

Posted on Leave a comment

Scrum and the Cooperative Game

In many (IT) partnerships and implementations people seem to prefer to strangle each other rather than assure mutual benefits.

I’m applying Scrum (over 4 years already), in my projects and in my management. It continuously helps me to cross fences; between suppliers and customers, business and IT, analysts and developers, x-layer developers and y-layer developers, etc.

In my Scrum-based development process I use Pre-Game Staging to name the barely enough preparative phase for 1 stage of software development. The “Games” metaphor was described by Alistair Cockburn in his biblical work Agile Software Development. I strongly agree with him that software development should be a Cooperative Game.

  • Cooperative: a team of people works together towards a common goal, not to fight each other.
  • Non-zero sum: the players are not opposed and do not try to win by getting the other at zero. There are multiple winners.
  • Finite and goal-seeking: the game ends when the goal is achieved. The game is not meant for just staying in existence.

You will find this as well in the integrated prerequisite for supplier-customer relationships (possibly multi-tier), from Toyota’s Lean Production to Poppendieck’s Lean Software Development. It offers far more certainties than our commonly applied bidding processes. Think (read) about it!

Posted on Leave a comment

Scrum merciless exposes…

  • Old skool thinking of people as ‘replaceable pieces of machinery’.
  • Dead hierarchy (chop it of to make your tree breathe again).
  • The invaluable waste and trash piled up at the end of a sequential process.
  • The mighty power of teams to unhide, be responsible and deliver.
  • Ways to combine fun, satisfaction, discipline and results.

(maybe I should expose myself finally as being all about Scrum, Scrum as designed and intended, throw my tracking and other models into the wide, wide world and be known)

Posted on Leave a comment

scrum is so… simple

and therefore extremely effective.

  • Describe desired product ideas and options in a Product Backlog.
  • Find a motivated and committed Product Owner.
  • Find a motivated and committed Team.
  • Master the team in adopting and following the Scrum Process.

And start… delivering (month after month after…) real business value.

Posted on 1 Comment

The enterprise and Scrum

The enterprise and ScrumAfter reading Ken Schwaber’s last book ‘The enterprise and Scrum’ and my recent change of employer, I’ve put the emphasis of my approach, my presentations and my framework on the process of Scrum more. The previous 4 years I have been practicing and promoting Scrum mainly from the combination with eXtreme Programming because my professional context was custom software development (mainly JavaEE).

At the same time I have more stressed the idea of ‘Value Driven Development’ (both in my -excel based- framework as well as in my introduction to Scrum). Reminds me of the fact that I should now include ‘sustainable pace’ as essential in Scrum as well, and not merely as an adoption from XP.