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