The Agile landscape – should we care?

Yes, “agile” is an umbrella term, the word was chosen by the signatories of the agile manifesto. Who-ever would be referring to the agile method, doesn’t understand what agile refers to.

The existence of many agile methods, frameworks and approaches (no, Scrum is not the only agile method) for single teams and multiple teams illustrates the continuous journey of exploring and uncovering new and better ways of developing products. And that’s a good thing, isn’t it? It would be worrying if the whole world would agree for a single method or way of working.

Illustrations as the one below show the diversity of methods in the whole “agile” landscape.

agile-landscape

Some thoughts…

Continue reading →

Agile Manifesto Values add-on for large enterprises

We are uncovering better ways of working in large enterprises by doing it and helping others do it.

We value:

Delighting Customers First over Shareholder Returns First

Focusing on Delighting Customers First leads to Shareholder Returns

Enterprise-Wide Agility over Agile for Software Development only

Optimise for flow, learning and feedback along the whole value stream

Empowered Product Teams over Command & Control Role based Work Passing

Long live teams with high Alignment, Autonomy and Safety aligned to value stream

Achieving Big through Small over Achieving Big through Big

Small teams, hypothesis-driven investment, optimise for flow, for better outcomes faster

 

That is. We used to value to things on the right, we now value the things on the left more.

 

Source: https://medium.com/@jonathansmart1/agile-manifesto-values-add-on-for-large-enterprises-f3fdc1abcd65#.wtautdxcw

 

Plan Do Check Act

Plan-Do-Check-Act

Een belangrijk element in een continue verbeteringsproces is een continue cyclus van plannen, uitvoeren, verifiëren en bijstellen. De uitdaging is om deze cyclus herhaaldelijk te blijven uitvoeren, zodat de zin voor kwaliteitsverbetering een continue gegeven wordt.

De indeling van deze stappen zijn de stappen zoals aanwezig in de wetenschappelijke methode: het formuleren van een hypothese, het uitvoeren van een experiment, en het evalueren van de resultaten (om de hypothese juist of fout te verklaren). Deze Plan – Do – Check – Act cyclus (PDCA) is gekend als de kwaliteitscirkel van Deming. PDCA vormt de basis voor continue verbetering en is een element van lean productie.

Scrum als ontwikkelingsraamwerk voor complexe producten heeft zijn origine in lean productie (lean thinking). Het artikel (The New New Product Development Game) spreekt over “incrementele verbeteringen”.

Hoe “Plan – Do – Check – Act” zichtbaar maken in een team?

Continue reading →

Essential Agile

The essentials of Agile software (product) development:

Accept that you start not knowing the solution. Understanding is emergent.

Take the following approach:

  1. Find out where you are
  2. Take a small step towards your goal (and if there are multiple choices here, take the path of least regret, or the one that makes future change easier)
  3. Adjust your understanding based on what you learned
  4. Repeat

(Yes, that’s it).

by Pragmatic Dave

Continue reading →

Ken Schwaber’s original Scrum Paper (1995): “SCRUM Development Process”

ABSTRACT. The stated, accepted philosophy for systems development is that the development process is a well understood approach that can be planned, estimated, and successfully completed. This has proven incorrect in practice. SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle.

PDF file: Scrum OOPSLA 1995

Continuous Delivery

Thierry De Pauw (@tdpauw) has a great presentation on the goal and meaning of continuous delivery.

The essentials:

Continuous Delivery is NOT just tooling. It is a mindset to adopt.

It always is about the mindset and the principles.

The goal of Continuous Delivery is to sustainably minimise the lead time to create positive business impact.

Lead time as a metric (= The amount of time that elapses between when a process starts and when it is completed)

Maximise the flow of the software delivery process.

The ultimate aim is a single-piece flow (meaning 1 item at a time goes through the workflow).

Your Definition of Done is when the feature is in the hands of the users.

Indeed, not only: deliver working software, AND deliver working software in use. In fact, the Definition of Done should include validated learning.

Creating feedback loops at all stages of the pipeline.

Whenever something fails in the pipeline, stop the production line.

Build quality-in.

== lean manufacturing principles.

Creating a culture of improvement.

Apply an improvement kata. Use techniques such as value-stream mapping to make pain-points (bottlenecks) visible and to improve.

Leadership

Too much management in corporations, we crave true leadership.

  • Identify great leaders
  • Build and grow trust
  • Embrace failure
  • Create an environment
  • Focus on what matters
  • Atomise and keep things small
  • Empower your teams
  • Grow a strong culture
  • Build it with your end users

 

What would you add?

Thanks to Bertrand Dour (presentation at Agile Tour Brussels 2016)

Evolution of the Agile Manifesto

Team vision and discipline 
over individuals and interactions (or processes and tools)

Validated learning 
over working software (or comprehensive documentation)

Customer discovery 
over customer collaboration (or contract negotiation)

Initiating change 
over responding to change (or following a plan)

 

Source: http://www.startuplessonslearned.com/2010/05/thank-you.html

Leancamp (Rotterdam)

Lean Camp is an unconference on topics as Lean Startup, Lean UX, Design Thinking, Product design, etc.

I like unconferences as each attendee has the opportunity to participate (you can propose a topic), and the interactivity is really high.

I participated in a discussion on integrating UX in agile development team; and how to maximise learnings from serious games – for example Playing Lean.

Continue reading →