You can read more about my thoughts on agile, software development, and other stuff in my weblog and on my homepage.

I got the idea for co-organizing the AgileOpen conference from different sources.

During summer 2004 I read Richard Gabriel's book Writers' Workshops & the Work of Making Things. I realised that many conferences are very non-agile in the way their program is created. This includes the XP Day Benelux: we did a call for sessions with a deadline, which means people have to BDUF their session descriptions. We try to provide as much feedback as possible as well as shepherding (for accepted sessions), but it's not really iterative, feedback-driven. Furthermore, we're reviewing session descriptions, not sessions (Duncan Pierce reminded us). This makes it harder to judge the session (unless the session has actually been run before).

We have several ideas how to organize conferences very differently, in a much more agile way. One of the ideas was to organize a conference for more experienced agile practitioners, where they can e.g. discuss and try out new ideas.

I also participated in the Dutch Open 2004 conference (organized by the Dutch Fractal of the Society for Organizational Learning), which used the open space format (with about 50 participants). The open space format worked very well for a group of 50 people who didn't really know each other. It was a special experience.

Willem and I mentioned the idea of an open space agile conference to different people at XP Day conferences in November 2004. People reacted positively, so we decided to just do it...]]> 132.205.221.246 15 March 2006 18:43 GMT http://www.agileopen.net/Conference/AgileTooling.html http://www.agileopen.net/Conference/AgileTooling.html AgileTooling?

Which agile tools would you like to use or would you expect to add value to your agile existance?

• What kind of functions to include into a wiki?
• How to help it pass the "surviving stage" and go to the "real life"?
• What are the patterns of wiki document organisation? Especially the dynamics of upscaling content in quantity and maybe in quality?
• What are the best wiki flavors? (this one seems very cool actually ;-) )

--BernardNotarianni.

I hope to outline my way of developing workshops with a flow diagram here, once DotGraphics are active on this wiki. --WillemVanDenEnde

]]> ehv-stm-18319.adsl.wanadoo.nl 13 June 2005 05:45 GMT http://www.agileopen.net/Conference/WillemVanDenEnde.html http://www.agileopen.net/Conference/WillemVanDenEnde.html http://www.willemvandenende.com .

My bio's are spread out on wiki's and confernce sites all over the internet, so if you'd like to know more about me, please check out http://www.willemvandenende.com or my weblog http://ruminations.willemvandenende.com .

OpenSpace WorkshopDevelopment

My Goals for AgileOpen

I started out with agile open goals in my weblog I'm refactoring them here as time goes by.

* CrossingTheChasm (or ThrivingOnAgile)

* OpenStage to balance supply and demand of SessionProposals and SessionRequests

2005 experiences:

Sessions I co-organized: ToyotaWay, BalancingAct

Self-organizing sessions I enjoyed: CynefinExperiential, CommunityOfTrust

Other session I enjoyed: SecureDesignAndArchitecture

Session / course description construction for the future:

CongruenceInActionXP2005

TestDrivenDevelopment]]> Pascal 19 May 2005 19:07 GMT http://www.agileopen.net/Conference/ToyotaWay.html http://www.agileopen.net/Conference/ToyotaWay.html The Toyota Way of running projects

Intro

*The Toyota Way - 14 management principles from the world's greatest manufacturer * by Jeffrey K. Liker describes the management philosophy behind Toyota's "Lean Management". It goes beyond the better known "Toyota Production System" and "Lean Thinking", whose ideas are starting to be applied to IT projects.

The session

In this session, participants get to examine some of the 14 principles, to see if and when they are or aren't applicable to IT projects. They work in small groups to create a short presentation, which they present to the other participants. The session ends by a plenary discussion to draw up the conclusions of this session

Schedule

• 10 min Introduction
• 20 min Overview of the principles
• 30 min Select principles and form groups to examine them
• 20 min Each group makes their presentation
• 10 min Conclusions

None required, although some experience with management and development processes could be helpful.

The session organiser will provide copies and an introduction to the "Toyota Way" book.

This session will also be held at XP 2005. The aim is to compare and contrast the output from both sessions.

Session results

Introduction

The session started with a quick overview of the 14 principles:

We often accept someone else's concepts, as we hope they make sense for us in our context. All too often, metaphors from other disciplines are applied to the creation of software (e.g. software engineering, six sigma, lean), without adopters having a deep understanding of what it is that would make the new concept different and applicable to their capabilities and in their local context.

Major problems are just as easy to resolve as "minor" ones. Problems come, just like everything, in fractals. Each small problem is a microcosmos of the larger ones it is part of. The resolution of the problem, both for minor and major ones, depends on completely understanding what the problem is. Once we have understanding, even of a major problem, the solution is a question of just a little corrective push applied in the right place. Virginia Satir created many tools for learning and practicing a healthy balancing act.

Relevance for XP and Agile

The Agile Manifesto states: we have come to value: Individuals and interactions over processes and tools. Tools and techniques are not enough for running your projects, you need 'people skills' as well. We all know e.g. that blaming others doesn't make our projects finish early, yet it is hard to stop doing it. This session provides tools and processes for individuals and interactions, to help you take a step further towards peaceful, effective projects.

To assess if a concept truly makes sense for our context, we need to understand the roots of the concept. The tools we explore in this tutorial are based on fractal patterns, meaning, we have to make them our own. Once we have done that, we can use these tools to better understand the application of new concepts in our context, adjusted to our skills and capabilities.

Session Data

• Duration: 4 1/2 hours (including breaks)
• Type: Experiential
• Area: Advanced Practices
• Intended audience: Journeyman and Master desiring to co-create healthy futures
• Maximum number of participants: 20
• Facilitators: WillemVanDenEnde (Changing the way we change), MarcEvers (Interactions), NynkeEtkFokma (Congruent action)

Session Choreography

Peace within: Congruent action (1 hour)

"Our challenge now is to develop human beings with values: moral, ethical, and humanistic. For me, this means learning how to be congruent, and that leads to becoming more fully human. When we achieve that, we will be able to enjoy this most wonderful planet and the life that inhabits it." - Virginia Satir

• Experiencing (in)congruence in fun and enjoyable blaming/placating/irrelevant/superreasonable roleplay.
• Sculpting Extreme Values, AgileValues or a set of values you bring.

Peace between: Interactions (1 hour)

Virginia Satir believed that all levels of human interaction need congruent communication in which intentions align with verbal and non-verbal messages. We explore how humans interact in guided simulations using the Satir interaction model:

Peace among: Changing the way we change (1 hour)

The first model is called the "hole in the floor" model. In this model, coming up with a decreed "Faster, Better, Cheaper" is expected to just "do it" instantly (figure a). This model is similar to the "oblivious" cultural pattern, a first setting to mark a starting point. But of course, no company really does it that way, because of the realization that it may take some time for people to get used to the "new ways" (figure b). Some "enlightened" managers may understand this and believe they can shorten learning time required by external motivation. With individual learning styles averaged out, we get the "learning" curve" model. In this model, management seems to believe all that is needed to externally motivate creators is by rewards and punishments like a pat on the back, and a lash of the whip now and then or withholding resources.

Mind you, the "pat on the back" motivation works only for a short while, because if we do it too often it might loose it's meaning and the creators will be asking for more money saying "put your money where your mouth is". And we wanted "cheaper", so that's not such a good idea. Withholding resources is a seriously bright idea for keeping control. A definite party pooper in such realities can be finding a sustainable balance between short term and long term effect on creator productivity (figure c). People with self-esteem, your best and most creative problem solvers, will vote with LawOfTwoFeet if and when they have experienced you tyranting them in this way three times.

Experiencing the Satir change model in a Ball Game:

Re-entry (half hour)

Smooth and safe return to full consciousness of the world outside we are to return to.

One line summary: tutorial about three tools for effective communcation in teams, originated by Virgina Satir and Jerry Weinberg.

Abstract

We often accept someone else's concepts, as we hope they make sense for us in our context. All too often, metaphors from other disciplines are applied to the creation of software (e.g. software engineering, six sigma, lean), without adopters having a deep understanding of what it is that would make the new concept different and applicable to their capabilities and in their local context.

Major problems are just as easy to resolve as "minor" ones. Problems come, just like everything, in fractals. Each small problem is a microcosmos of the larger ones it is part of. The resolution of the problem, both for minor and major ones, depends on completely understanding what the problem is. Once we have understanding, even of a major problem, the solution is a question of just a little corrective push applied in the right place. Virginia Satir created many tools for learning and practicing a healthy balancing act.

The Agile Manifesto states: we have come to value: Individuals and interactions over processes and tools. Tools and techniques are not enough for running your projects, you need 'people skills' as well. We all know e.g. that blaming others doesn't make our projects finish early, yet it is hard to stop doing it.

To assess if a concept truly makes sense for our context, we need to understand the roots of the concept. The tools we explore in this tutorial are based on fractal patterns, meaning, we have to make them our own. Once we have done that, we can use these tools to better understand the application of new concepts in our context, adjusted to our skills and capabilities.

Audience and benefits of attending

Intended audience: Journeyman and Master desiring to co-create healthy futures

Maximum number of participants: 20

In this session, participants learn three tools to improve communication in teams and to help taking a step further towards peaceful, effective projects.

Session Choreography

This tutorial is highly experiential: it has just enough theory and lots of practice.

Duration: full day

Peace within: Congruent action (1 1/4 hour)

"Our challenge now is to develop human beings with values: moral, ethical, and humanistic. For me, this means learning how to be congruent, and that leads to becoming more fully human. When we achieve that, we will be able to enjoy this most wonderful planet and the life that inhabits it." - Virginia Satir

• Experiencing (in)congruence in fun and enjoyable blaming/placating/irrelevant/superreasonable roleplay.
• Sculpting Extreme Values, AgileValues or a set of values you bring.

Peace between: Interactions (1 1/4 hour)

Virginia Satir believed that all levels of human interaction need congruent communication in which intentions align with verbal and non-verbal messages. We explore how humans interact in guided simulations using the Satir interaction model:

Peace among: Changing the way we change (1 1/4 hour)

The first model is called the "hole in the floor" model. In this model, coming up with a decreed "Faster, Better, Cheaper" is expected to just "do it" instantly (figure a). This model is similar to the "oblivious" cultural pattern, a first setting to mark a starting point. But of course, no company really does it that way, because of the realization that it may take some time for people to get used to the "new ways" (figure b). Some "enlightened" managers may understand this and believe they can shorten learning time required by external motivation. With individual learning styles averaged out, we get the "learning" curve" model. In this model, management seems to believe all that is needed to externally motivate creators is by rewards and punishments like a pat on the back, and a lash of the whip now and then or withholding resources.

Mind you, the "pat on the back" motivation works only for a short while, because if we do it too often it might loose it's meaning and the creators will be asking for more money saying "put your money where your mouth is". And we wanted "cheaper", so that's not such a good idea. Withholding resources is a seriously bright idea for keeping control. A definite party pooper in such realities can be finding a sustainable balance between short term and long term effect on creator productivity (figure c). People with self-esteem, your best and most creative problem solvers, will vote with TheLawOfTwoFeet if and when they have experienced you tyranting them in this way three times.

Experiencing the Satir change model in a Ball Game:

Re-entry (half hour)

Smooth and safe return to full consciousness of the world outside we are to return to.

Presenter resume and contact information

Facilitators: WillemVanDenEnde (Changing the way we change), MarcEvers (Interactions), NynkeEtkFokma (Congruent action)

Willem van den Ende

I am currently working as a software developer and coach, based in Eindhoven, the Netherlands. I enable organisations to continuously create and add value through software development and deployment. I strive to do only those activities that really add value, to empower myself and others, and to improve teamwork, quality, and pleasure. I recognize that each organisation, team, and individual has a unique context and capabilities. I leverage these capabilities by looking at what works well, and adding to that.

Since 2000, I co-organise workshops, user group meetings and conferences around agile software development, XP and congruent communication.

See www.willemvandenende.com for contact details and information about my services.

Marc Evers

I help developers, customers, and project managers in co-creating value through meaningful projects, through coaching, consulting, and developing software. Since 2000 I co-organize workshops and conferences based on systems thinking, XP, and agile values, principles, and practices.

Nynke Fokma

I provide strategic communications facilitation and integrated marketing services to non-profits and small companies to generate agile business. I help my self and others generate positive commercial benefits by minimizing required amounts of energy and reserve capital and more safely maximizing returned value through in(ter)dependence and collaboration.

See www.moebius.nl for more information.

History of tutorial

The different parts of this tutorial have been run at different conferences.

At the beginning of the session, I was wondering if XP did not already cross the chasm. Maybe XP could be for only, say 10% share of “projects market” and majority of those projects already would have moved to XP.

VeraPeeters gave me the correct vision: every project has its own chasm to cross. Then, at an “industry” (I hate this word) level, we can expect to have a chasm to cross.

Laurent Bossavit seems to have a related vision. Read and comment it: http://bossavit.com/thoughts/archives/000811.html

BernardNotarianni]]> ehv-stm-18319.adsl.wanadoo.nl 02 May 2005 10:33 GMT http://www.agileopen.net/Conference/FridayAfternoonPictures.html http://www.agileopen.net/Conference/FridayAfternoonPictures.html CommunityOfTrust session:

ProjectPlanningMetrics session:

CynefinExperiential session:

XPGame:

]]> pascal 01 May 2005 21:10 GMT http://www.agileopen.net/Conference/TheoryOfConstraints.html http://www.agileopen.net/Conference/TheoryOfConstraints.html The Theory of Constraints

The animation at http://www.tocca.com.au/Services/demoprojectM.htm clearly shows the way the bottleneck determines the throughput of the system and how to recognize the bottleneck:

• Watch the work in progress piling up
• Watch who's busy and who's not so busy

Main variables

• T = Throughput = fresh money coming in to the system
• OE = Operating Expenses = money going out to keep the system going (E.g. wages, energy costs, rent....)
• I = Investment = money that is tied up in the system to be able to generate Throughput (E.g. requirements, machines, unfinished/unsold work...)

• NP = Net Profit = T - OE
• ROI = Return On Investment = NP / I = (T - OE) / I

We can improve by (in order of importance)

1. Increase T, unless the OE and/or I increase required is too big
2. Decrease I, unless it decreases T or increases OE too much
3. Decrease OE, unless it decreases T or increases I

If we believe that these are the right goals, which metrics can we use to tie our work back to the results that work will have? The metrics I use are:

• SP = Story points = an abstract measure of the intrinsic complexity (effort required to implement) of a story. This is estimated by developers
• Velocity = story points / man day. This is measured at the end of every release
• BP = Business points = an abstract measure of the expected value of the story. This is estimated by the customer(s)
• V = Value of the project/product. For products this is simply T, the sales of the product. For internal projects it could be the increase in T and/or decrease in OE or I of the company caused by the project.

• MD = man days per release = sum(SP) / velocity
• OE = (MD x cost of a man day) + fixed costs (rent, energy...)
• T = V = BP x X ? (where X = "Business velocity")
• I = ???

• Find the stories with high Business Value (in story writing and planning game): developers+customer
• Find the stories with low Story Points (in story writing and planning game): developers+customer
• Improve velocity (by refactoring, buying better tools, learning more about technology or domain...): developers
• Improve business velocity (by selling the same features to more customers, by selling at a higher price...): customer

• Can we measure V?
• If so, can we see if there is indeed a correlation between changes in BP and V? And thus, we can measure business velocity? Business Velocity = money earned / business point
• How can we express and measure Investment in IT projects?
• What are examples of investment in (agile) projects?
  • Setting up an automated build system?
  • Setting up an automated acceptance testing system?
  • Refactoring code?
  • Writing documentation?
  • Unfinished work? Requirements, analysis, design, code... not sold?
  • Add your examples

Exploring the Theory of Constraints

Eliyahu Goldratt's "Theory of Constraints" is a continuous process improvement method that was developed in the manufacturing world and is now being applied to other industries, among others in IT. In this respect, its history is similar to that of "Lean Thinking". Where Lean tells you HOW to optimize a system, ToC tells you WHAT to optimize.

The basic insight of ToC is this: every system has ONE constraint (or 'bottleneck') that determines the throughput of the system. If you want to improve the system, you have to find and work on the constraint. The same way you need to strengthen the weakest link if you want to make a chain stronger.

From this idea, ToC derives a program of continuous improvement steps to increase throughput, by attacking the system's constraint. These ideas have been developed for manufacturing plants, but, like "Lean Thinking", they can be applied suprisingly well to software development. ToC principles have been applied to planning (the "Critical Chain" planning method), to accounting/management decision support ("Throughput Accounting") and to Systems Thinking (the "Thinking Processes").

Session Description

This session is a mixture of tutorial, simulation and workshop/discussion.

To start the session, we run a small simulation of a development team. This simulation provides a visualization of some of the ToC concepts and can be revisited when we want to experiment with some part of the theory.

The "5 focusing steps" for optimization are introduced. Participants try to apply them to the simulation.

ThroughputAccounting is introduced as a model for measurement and management feedback. Participants apply the

Finally, participants are asked to summarize how and when they could/couldn't apply ToC to their projects.

Schedule

• 5 min Introduction
• 20 min Experiencing the bottleneck
• 20 min The 5 focusing steps to optimize a system
• 20 min Throughput Accounting to measure a system and define the goals
• 25 min What does this have to do with my job?

Some experience with different software development processes and/or optimization could be useful, but is not required. Depending on the previous exposure of the participants to the Theory of Constraints, the session will devote more or less time on explaining the basic principles vs discussion of its applications.

This session was run before at the Belgian XP Users group meeting

This session was run before at the SPA 2005 conference. See the session description and the session output

The session will be run again at XP 2005

We want to compare and contrast the outputs of the different sessions.]]> 159.19-136-217.adsl.skynet.be 01 May 2005 20:26 GMT http://www.agileopen.net/Conference/HowtoDealWithVelocity.html http://www.agileopen.net/Conference/HowtoDealWithVelocity.html Questions:

• am right? or....
• is this trying to avoid responsibility for team effectiveness?
• can/may velocity be used as productivity measure.

Output

Things we learned:

• When velocity is made a target, people might change their estimates. (evil; not effective feedback loop)
• Some tasks / stories do not have business value (e.g. infrastructure tasks and such.)
• Velocity can give us a clue that something is wrong with team effectiveness, but such clues should be combined with other indicators like business value and information (problems) gathered from stand-ups)
• In relation to throughput accounting: Productivity = Throughput / Operational expense (formula not complete - Pascal please help): Business Value measures Throughput and Velocity (indirectly) measures Operational expense. So it IS valid to relate Velocity to productivity.
• We can use business value to measure productivity, but this does not help us with team efficiency. ()
• Customers optimize on (business)value; developers optimize on velocity.
• If you only looked at value and the customer would put highes value stories in early iterations, it would look as if our productivity was decreasing. (which is true :-))

The measurement perspective of the TheoryOfConstraints is summarized in ThroughputAccounting -- PascalVanCauwenberghe]]> marc 01 May 2005 14:10 GMT http://www.agileopen.net/Conference/SaturdayAfternoonPictures.html http://www.agileopen.net/Conference/SaturdayAfternoonPictures.html BalancingAct session:

ImNotaBottleNeck session:

Closing drinks:

]]> marc 01 May 2005 14:06 GMT http://www.agileopen.net/Conference/Pictures.html http://www.agileopen.net/Conference/Pictures.html PreConferenceDinner:

FridayMorningPictures

FridayAfternoonPictures

FridayEveningPictures

SaturdayMorningPictures

Saturday lunch:

SaturdayAfternoonPictures

Newsroom:

]]> AMontsouris-151-1-45-183.w82-123.abo.wanadoo.fr 01 May 2005 11:04 GMT http://www.agileopen.net/Conference/CommunityOfTrust.html http://www.agileopen.net/Conference/CommunityOfTrust.html

• What are the difficulties to create those communities?
• What are their boundaries? How to determine who is inside, and who is outside?
• What are the enablers?
• Which tools can help?
• What are the anti-patterns breaking the communities of trust?

--BernardNotarianni

Output

Format:

We tried to initiate a System Thinking analysis of communities of trust. The group agreed that given the duration of the session, we could first try to identify topics in relation with the concept of trust, for later try to organize them in a System.

Things we learned:

Trust could be related to risk analysis: “I trust you for that, because I accept this risk that that could fail”

Things positively influenced by trust, and/or enforcing trust (in random order):

• Feedback
• Acceptance of mistakes
• Self confidence
• Respect
• Common goal
• Focused appreciation (I appreciate you for THIS specific event)
• Courage
• Ask for help
• Trust back
• Trust can help CrossingTheChasm

Things enforced by lack of trust, or having a negative influence on trust:

• Scary
• Manipulation
• Hidden agenda (or hidden objectives)
• Fear of judgment
• Blaming

Please, modify/enrich this page if you can remember other things, or read the photo (sorry, I am not ablle to read all postits, especially those on the right side)

-- BernardNotarianni]]> marc 30 April 2005 12:14 GMT http://www.agileopen.net/Conference/SaturdayMorningPictures.html http://www.agileopen.net/Conference/SaturdayMorningPictures.html

HowtoDealWithVelocity session:

AgileDocumentation session:

Agile Security session:

CrossingTheChasm session:

]]> ip-213-49-134-28.dsl-static.scarlet.be 30 April 2005 11:06 GMT http://www.agileopen.net/Conference/Outputs.html http://www.agileopen.net/Conference/Outputs.html Sessions held:

Friday
Morning
ToyotaWay	AgileTooling
Afternoon
ProjectPlanningMetrics	CommunityOfTrust
XPGame	CynefinExperiential
Saturday
Morning
HowtoDealWithVelocity	AgileDocumentation
Security Requirements Engineering Secure Design and Architecture Security Risk Analysis	CrossingTheChasm
Afternoon
BalancingAct	I'm not a bottleneck, I'm a free man!

]]>