2013/01/30 18:30 Scott W. Ambler, “Towards a Disciplined Agile Manifesto”, Toronto Agile Support Group

Toronto Agile Support Group (see http://www.linkedin.com/groups/Toronto-Agile-Support-Group-4607785 )

This digest was created in real-time during the meeting, based on the speaker’s presentation(s) and comments from the audience. The content should not be viewed as an official transcript of the meeting, but only as an interpretation by a single individual. Lapses, grammatical errors, and typing mistakes may not have been corrected. Questions about content should be directed to the originator. The digest has been made available for purposes of scholarship, posted by David Ing.

Second meeting


Two topics tonight

  • First on agile manifesto
  • Second on certification

di_20130130_191144_torontoagilesupport_scottambler

Scott Ambler Associates

  • Making agile more disciplined
  • Significant room for improvement in enterprise

Two years ago, was invited to Snowbird by Alastair Cockburn [see Agile at 10: What We Believe (Scott Ambler)]

  • To discuss the 10-year old manifesto
  • To be disciplined, extend the manifesto

Will break into subgroups to improve the manifesto

  • Afterwards, will share what happened at Snowbird
  • Then walkthrough, didn’t feel need to permission to change manifesto

Photo:  Ted Kaczynski, Unabomber

Agile manifesto at http://www.agilemanifesto.org/

  • We are uncovering better ways of developing software by doing it and helping others do it.
  • Through this work we have come to value:
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
  • That is, while there is value in the items on the right, we value the items on the left more.
  • Kent Beck
    Mike Beedle
    Arie van Bennekum
    Alistair Cockburn
    Ward Cunningham
    Martin Fowler
    James Grenning
    Jim Highsmith
    Andrew Hunt
    Ron Jeffries
    Jon Kern
    Brian Marick
    Robert C. Martin
    Steve Mellor
    Ken Schwaber
    Jeff Sutherland
    Dave Thomas

Of the 17 people who developed it, all developers or consultants

  • Bias

Twelve principles:  http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/

  • We follow these principles:
    • 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    • 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    • 4. Business people and developers must work together daily throughout the project.
    • 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • 7. Working software is the primary measure of progress.
    • 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • 9. Continuous attention to technical excellence and good design enhances agility.
    • 10. Simplicity–the art of maximizing the amount of work not done–is essential.
    • 11. The best architectures, requirements, and designs emerge from self-organizing teams.
    • 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

After 12 years, have we learned?

Exercise:  What would you change?

[Breakout]

Breakout team report:

  • Non-functional / reliability
  • Business value
  • Colocation

Only the minority of agile teams are co-located, it’s a myth, have surveys that show that

Breakout team report:

  • Development teams live within an organization structure, governance, who’s doing what to whom
  • “Comprehensive documentation” might be better as “static documentation” or “unhelpful documentation”
  • “9. Continuous attention to technical excellence” to become “Deliberate attention to technical excellence” rather than just throwing people on the problem
  • Large pipelines may drive changes that need documentation
  • Customers can’t accept changes on a daily basis

Breakout team report:

  • Customer satisfaction

Breakout team report:

  • Like that it reflects reality for some projects
  • Open to interpretation
  • Like #11 The best architectures …
  • Like regular improvements
  • Don’t like assumption that people speak the same language and are at the same level
  • Don’t like concept of infrastructure, development tools in place, need other things in place
  • Buy-in to stakeholder time, sometimes needs slack built into the project
  • Knowledge risk: about change change change, what is the risk?
  • Non-functional progress, as well as non-functional; it’s still work
  • Self-organization isn’t guided and explained, can be misinterpreted as throwing people into a room and they’ll figure it out without constraints
  • Training and skills enhancement (maybe #9 isn’t just technical excellence)
  • Customer collaboration, in a $12M contract?  We’re just going to figure it out?  Need safety measures
  • Measures of stakeholder satisfaction
  • Buy-in and running a job:  maybe the team doesn’t want to run agile
  • How to do individuals without support and tools, e.g. testing

[end of team reports]

Almost all of the 17 went into the software or tool business after the manifesto

Agile Manifesto has become a religious artifact, with discussions and debates

At 10 year anniversary, has a group with axes to grind

  • Had highly facilitated meeting, walls of sticky notes

Manifesto was by all 17, and agreed that all need to agree to change

  • Some adamant against change
  • Not adamant with change, it’s about adding a can of worms

Came up with 4 changes

Was with IBM for 6 years, as chief methodologist for IT, helping doing agile at scale

  • Started seeing common patterns
  • Most claimed doing Scrum, few were
  • Ideas weren’t being shared, as extended Scrum, that would have called recertification programs into question
  • Would have to rethink the whole religion of Scrum

Decided to share

Disciplined Agile Delivery Extends Agile Thinking

It was about solutions, not software

It’s about stakeholders, not just customers;  e.g. auditors, architects, people writing the cheque

The organizational ecosystem, not just development teams:

  • Still silo thinking, as opposed to multiple teams in flight, might need to follow standards, business value of solution may not be of interest to the organization, could even have negative value
  • Lean says to optimize the whole, not the parts: optimizing the project, need bigger picture

Changes:

  • Software to SOLUTIONS
  • Customer to STAKEHOLDERS

Added:

  • 13. Leverage and evolve the assets:  e.g. instead of ETL band-aid, what not fix them?
  • 14. Visualize workflow:  a good idea from lean
  • 15.  The organization ecosystem must evolve … e.g. enterprise architects need to change, dev ops need to change the way they work

[blogged at https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/reworking_the_agile_manifesto14?lang=en ]

Updating the Values of the Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

  1. Individuals and interactions over processes and tools
  2. Working solutions over comprehensive documentation
  3. Stakeholder collaboration over contract negotiation
  4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Updating the Principles behind the Agile Manifesto

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
  2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder’s competitive advantage.
  3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Stakeholders and developers must work together daily throughout the project.
  5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
  7. Quantified business value is the primary measure of progress.
  8. Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
  14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
  15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.

Changing manifesto isn’t going to happen any time soon

  • People who promote flexibility and change are actually somewhat unflexible and unchangeable

So, this is what Scott published some changes

  • Kent Beck has also published some changes
  • If people want to adopt, great

This is in the book:  http://disciplinedagiledelivery.comhttp://disciplinedagileconsortium.org , http://scottambler.com , LinkedIn and Google+ groups

Now past early adopters, past the chasm, have late majority government and insurance companies adopting this

  • XP and Scrum are on left side of chasm
  • SAFE, DSDM and DAD are on right side of chasm

[second part]

Disciplined Agile Certification

Have been working on this, just about to release

Disciplined Agile Delivery

It’s a process-decision framework, not a process framework

  • Helps with day-to-day decisions

Had experience with RUP, then agile

  • Ten years ago RUP was #1, now is probably still #2 and #3 (just as COBOL is still #1)

RUP message:  great idea, because you’re experts, you can tailor it down to something you need

  • Agile community is reinventing a lot of what was in RUP
  • SAFE has a lot of RUP content, as originator was in RUP for a long time
  • Have some serious problems with RUP instantiations, even though Rational advised on this, because need solid process expertise

Then Scrum became popular:

  • Similar message, but start with a small process, and then tailor it up
  • Organization is struggling with this
  • People aren’t process experts
  • 10x improvements not being seen

Two false assumptions with RUP and Scrum

  • Process expertise
  • They started at extremes:  big and cut down, or small and scale up

Would be it smarter to start with middle, and then tinker?

  • This is what we’re trying to get to, with DAD

Process decision framework?

  • (Switch to Introduction to Disciplined Agile Delivery slides)
  • Framework as goal-driven, not prescriptive (compared to Scrum as phenomenally prescriptive)
  • Collections of goals that need to be addressed at certain points in the project

e.g. Goal of Align with Enterprise Direction

  • Then, at beginning of project, should align
  • There are some issues that you may or may not want to take on
  • 1. Adopt common guidelines (as high level, detailed, optional, enforced or none)
  • 2. Adopt common templates (as minimal, comprehensive, none)
  • 3. Coordinate with enterprise teams (as collaborative, continuous, gated, formal or none)
  • 4. Reuse existing infrastructure
  • 5. Adapt governance strategy

Need to adopt what makes sense

e.g. Goal:  Explore the Initial Scope

  • 1. Level of detail (as goals driven, requirements envisioning as light specifications, BRUF detailed specifications, none)
    • e.g. moon shot was driven by one goal
  • 2. View types (as usage modelling,  domain modelling, process modelling, use interface modeling, non-functional requirements
  • 3. Modeling strategy
  • 4. Work item management strategy:  work item pool, work item stack, Scrum product backlog, formal change management, none?
  • 5. Non-functional requirements

Do want to explore the initial scope, then address some of the changes

(These diagrams aren’t in the book, they are online)

Not enough to say decisions and options

  • Decision tree is backed up with descriptions in text, advantages and disadvantages, on when to do it and not to do it
  • Problem:  still not a process expert

Other key characteristics of DAD [see http://public.dhe.ibm.com/common/ssi/ecm/en/raw14261usen/RAW14261USEN.PDF ]

  • People first
  • Learning-oriented
  • Agile
  • Hybrid
  • IT solution focused
  • Full delivery lifecycle (which isn’t prescribed, one based on Scrum, one based on Lean, one on continuous improvement)
    • If observe teams, each team is doing things differently
  • Risk value lifecycle (right out of Scrum)
  • Enterprise aware (with architects and ecosystem)

Even though book came out in June, still evolving (e.g. with goal-based diagrams)

Exercise:  What should a certification program look like?

Team report

  • Certification word:  Scrum used to be a 2-day course
  • Contextual questions:  different on test, from 10-person company to 10 year 300 person project
  • Doesn’t include communications, unless get into coaching
  • Consider virtual environment?  Proving?  (Microsoft tried this a few years ago, crashed and burned.  Doesn’t scale, certifiers lose interest quickly)
  • Peer-driven certification

Team report:

  • Like training, don’t like certification
  • Like experience
  • Like endorsement models

Have been against certifications where you don’t have a test

  • Ethical challenges in agile community
  • Certification word has been abused from greed, and lack of ethics, particularly in Scrum
  • 90% of the people didn’t want Scrum certification on the initial challenges, then other people though that Scrum would fall on itself, which didn’t happen
  • Screwed up agile training market:  first several search pages will be on Scrum
  • So now, hard to give training that doesn’t certify
  • Even lean community was against certification, but it’s the only way to get the message out
  • Not good for trainers
  • Not good for practitioners

In Canada, only ISP from CIPS is recognized legally

Civil engineering:  construction work, and then city inspectors come in — and there’s nothing like this in IT

In IT, no governing body, no agreed body of knowledge, and dealing with touchy-feely human issues not physical world

Certification based on principles

  • Have to earn, have to do some work; not showing up from course and staying awake
  • Have to have commensurate value

Using white belt, green belt, black belt, etc.

  • Haven’t yet figured out to retest people

While belt: started on the path, want to get better, shouldn’t be hard to earn, taking a course, e.g. a certified Scrum master as a novice

Green belt:  have some experience (giving references), taken some training, have one or more responsible certifications (e.g. project manager, architecture, etc.) and some knowledge about agile, can be useful

In martial arts, if green belt and asked by a lower belt, are obliged to help to get to that level

Black belt should have many years of proven experience, 2 or more respected certifications (not CSM), much wider knowledge, could project improvement coaching

Green belt tests for DAD would be on decision questions

Program will be announced in a few weeks in http://disciplinedagiledelivery.com