SGLON

Henri

Too much busyness gives bad blogging… Anyway I try to sum up my feelings and observations around Scrum Gathering London. Scrum invites new companies and people to join Agile communities and that is a great thing. It really seems that there is another wave of believers after another, but unfortunately this will not solely solve our problems. I have been trying to say for a long time that it does not matter if your team level process is about Scrum, Kanban, XP, Scrumban, Böm or what ever you want to call it. What matters is that people use the methology they feel is working for them, they get results, things are improving and we get things moving. Scrum is a great way to achieve that. If applied correctly and supported by lot of thinking around Agile in general. Luckily there is so much wisdom out there that we can use to make things better…

I loved the keynote from Steve Denning. It summed up a lot of the things I have been thinking lately. Why does cost obsessed traditional management not work? Will it ever work? Why some companies are doing better than others? I can strongly recommend his new book about Radical Management http://bit.ly/nmojGY.

http://www.stevedenning.com/slides/London.pdf

On Tuesday I attended on the session by Roman Pichler: Sin or Salvation -Using Kanban to Prepare a Scrum project. Actually the presentation was not so much about Kanban, except for the visualizing the workflow part. When this is added by explicit policies, limited WIP on different phases and measuring the cycle time we seem to have a pretty solid framework how to do fuzzy front end work. I liked Roman`s way of walking through the session with an simple example to get the basics in place. What was missing in my opinion was the role of the management. There is a lot of money flows and business ideation happening connected to early stages and those items should be connected to big picture.

Giuseppe

Here are some notes from a bunch of sessions I attended. Hope you find them useful:

 Joe Justice – The Car that Scrum built (Keynote)

The session was about the experience of the WIKISPEED team, a multinational team, which built a 158 mpg car (1,5 l per 100 km) in 3 months using Agile/Lean/Scrum/XP.

It was a top car: from 0 to 60mph in less than 5 sec, weighing only 1,104 pounds, top speed of 149 mph, 5-stars crash test approved, cargo room to fit 20 bags of groceries, high level equipment.

In the car manufacturing waterfall approach new products are based on what we believed the customer wanted 10 years ago using best engineering outcomes at that time: if an engineer founds a better design tomorrow, he has to wait 10 years.

In Agile, using waterfall iteratively, new products are based on what the customer wanted 7 days ago: the product is re-invented every 7 days.

In some existing manufacturing, any change requires training new staff, custom HW, changing power and eben the building housing production. Some have awesome speed, but use tools too power consuming and too costly too change: so they cannot innovate.

The WIKISPEED car was built in 3 months. Joe started a blog reporting what was going on in his group (goods and bads) and 44 people volunteered from 4 countries. The team was made of 16 people, who were able to iterate the entire car in hours.

The prototype won the Progressive Automotive 10 million $ prize.

There are different companies all over the world producing >100mpg engines, but they are all investing millions, funded by universities or other big companies.

WIKISPEED used Scrum as the team methodology to reduce the time spent doing anything but creative problem solving. 6 months later they created a better shaped car and presented it to an important motor show, being the less expensive car in the show.

But how did they do that?

• From OOP they took Modularity: by loosely coupling the different car modules, they could make things in parallel.
• For Safety they used TDD: they took clear succcess criteria from 5-stars crash rating. By firts automating tests, they quickly knew whether they have improved. They were the lightest car in the world being rated 5-stars.
• From Lean: Use less stuff. By reducing tooling and inventory investment they could responsibly change process each sprint. If a new technology comes up, they can embrace it cost effectively.
• From Agile: Reduce cost for changes. By minimizing cost to make changes, they innovate quickly (changes in team, tooling, even goal).
• From Scrum: Roles and responsibilities. Team morale is a multiplier for velocity (both positive and negative). And this does not happen by chance or just because of nice people in the team.
• From XP: Pairing and Swarming
• From Kanban: WIP limits and sprintless releases. Iterations and stubs made for constant success

Final message: Keep up the awesome. Rapidly solve problems for social good and have more free time.

WIKISPEED backlog is on Linoit.com, the taskboard is on Scrummy.com 

Jan Beaver – Getting beyond yes: from cooperation to collaboration

The title comes from book: “Getting to yes – Negotiating agreement without giving in”

Getting to yes means separating people from problems, focus on objective facts, interest driven fixed points (no third way).

Jan told the story of William, a SW architect cooperating with 3 teams, but acting as a dictator. There were dysfunctions all around: one team just gave up, another was conflicting with him, the third one was divided in 2 parties, one supporting William and another supporting another developer.

What a ScM could do in this case?

• Mediate? –> Not ok
• Facilitate discussion? –> Not sufficient
• Take sides? –> Hmmm…
• Negotiate an agreement? –> Not ok
• Trust the team to work it out? –> Ok, except when the team is not mature enough to face it
• Let it pass? –> ???

But what’s wrong with cooperation?

• Can’t we all just get along?
• Work and play nicely with others (learned at kindergarden)
• Smooth rippled feathers –> What does it really change?
• Challenge the established hierarchy, either technical or managerial? –> Cooperation does not.
• Disfunctional behaviours: “He/she won’t listen to what I have to say!” – “Don’t ask me, I only work here!”
• Possibly a zero-sum game: I win/You lose or viceversa
• Ultimatum game – Inequity aversion (We’re offended from inequity)

Collaboration is the key to teamwork

• Teams rely on teamwork (It’s team goal, team commitment, team taking responsibility)
• We’re smarter together that anyone of us in isolation (No individual is smarter than his team)
• “I have an idea!” –> Innovation
• Trust and courage
• Beyond negotiation

Collaboration means getting beyond yes

• Self-organization
• Empowerment
• Vision and Success
• Commitment
• Trust
• Participatory Decision making
• Consensus-driven
• Constructive disagreement

From team divergence (my idea vs. your idea) to convergence

Tools

• Myers-Briggs Type Indicator (MBTI)
• DISC model
• Emotional IQ (useful for ScM and coaches)
• Thomas-Kilmann Conflict Mode Instrument (TKI)

The rest of the session was about TKI which describes 5 different conflict modes:

• Avoiding
• Accomodating
• Compromising (Cooperating)
• Competing
• Collaborating

 Jurgen Appelo – How to change the world

The session described a meta-model Jurgen called Change Management 3.0.

The model is made up of 4 models covering 4 aspects: PDCA, Individuals, Interactions, Environment.

1. PDCA

2. Individuals

• Awareness– Make people aware of the change
• Desire– Make change desirable –> Address people intrinsic desires (10 intrinsic desires: Curiosity, Honor, Acceptance, Mastery, Power, Freedom, Relatedness, Order, Goal, Status)
• Knowledge– Make people competent about change
• Ability– Make people able to make the change: ask experts to help. In this sense Scrum is very useful in get started with Agile change; it is a bit more difficult with XP.
• Reinforcement – Make change sustainable: build habits with small successes to make behaviour sustainable

Treat individuals as emotional beings. It is not enough to send rational messages

3. Consider the interactions

Adoption curve model can apply similarly to products

• Initiators– Make sure you’re not on your own: ask others to help
• Fund the Innovators
• Early adopters– How will the leaders help?
• Early majority– How will you cross the chasm? Adapt your approach so that you’re able to cross the chasm between early adopters and early majority: maybe use a different terminology
• Late majority– How will you deal with skeptics? “It will never work” –> Show facts about success – “There’s a hiddlen agenda” –> Be silly transparent
• Laggards – Don’t stop too soon! Keep monitoring things and don’t give the laggards the chance to undo all your work and destroy what you did. Don’t quit too soon!

Behaviors are transferred from person to person: give them the chance to be beneficial viruses

4. Consider the environment

5 I’s

• Information– Keep goal visible and make people aware of their actual behaviour, use info radiators to stimulate progress
• Identity– How do you create social pressure? Appeal to a higher identity that people want to associate thmeselves with. A common tactic: them vs. us.
• Incentives– How can you incentivate good behaviours? Use small rewards, like with dolphins (even only well done, great job, etc.)
• Infrastructure– Which barrier do you remove? Remove obstacles and ask guidance to make things easier
• Institutions – Define and enforce rules of good conduct

Behaviour is a function of a person and his/her environment. Since you cannot change people, change the environment.

Ref.:

www.management30.com/change-management

www.slideshare.net/jurgenappelo

Darian Rashid – Facilitating Creativity for Breakthrough Problem Solving

The session started with a 5-steps exercise. The problem to solve was to rescue as many people as possible on Titanic, with the following criteria:

• 2500 people on board
• Lifeboats available for 1200 people
• Help a bit more than 4 hours away
• Titanic will sink in 4 hours
• Hypothermia is fatal and will set in after 4 min any part of the body touches water

5 steps:

1. Solve the problem as such

2. Pick a random word and find all possible attributes for that word

3. Relate the attributes to the problem to help with the solution

4. Find an analogy: describe it in steps and relate the steps to the problem

5. Anti-solution

The exercise was aimed at showing hot to stimulate lateral thinking is solving problems.

We spend too much time in filtering ideas. We cannot solve a problem on the same level we created it. It’s instead a lot about emotions: don’t judge the solution too early.

Incremental vs. breakthrough thinking

Beware of Trunk Monkey !! (Find it on YouTube).

Lateral thinking requires you to go off your usual track.

Lateral thinking roadmap:

1. Provocation: Get us into a lateral path

2. Movement: Escapes the natural, obvious patterns

3. Harvesting

4. Treatment

Possible steps to provocation

1. Challenge assumptions – What if?

2. Exploring analogies – Real or fictitious, but familiar

3. Anti-solution – More fun to destroy than create. Example: How can we best support our teams?

Bob Sarni – Sustainable Pace: how can we help our teams to achieve it?

Agile values and priciples over practices and tools: one of the Agile principles talks about sustainable development.
One of the XP practices is No overtime: “Every hour at the office, you don’t want to be there, is overtime” (Kent Beck).
http://www.extremeprogramming.com/overtime

You should Stop it! (Search on YouTube)

Some considerations:

• Individual team members work/life balance (teams are made of people/individuals)
• Exciting vs. routine projects
• Upcoming releases or deadlines
• Short term and long term sustainable pace
• Focus on output vs. outcome
• Corporate priorities not supporting sustainable pace (Years of management training on optimizing resources)
• Individual team members not supporting the success of the team
• Hero attitude (I will save the team on my own)
• Culture (Different cultures of sustainable pace)
• Sustainable pace encourages learning, innovation and growth

Use a Top-down problem solving tree to help the team reflecting on these aspects and take actions. The tree is built step-wise, by answering the following questions, until you get some actionable items:
1. How do we do that?
2. Are we done with this level?
3. Should we further detail?

Steve Denning – Make the entire Enteprise Agile (Keynote)

For the slides see: www.stevedenning.com/slides/London.pdf

Why did management kill all in the past years and make the economy like it is now, with frustrated customers and employees? It was because the bottom line goal was making money, by focusing on the output instead of the outcomes, on things and on efficiency (cost cutting, resource optimizations, etc.)
1. New Goal is needed bottom line: Delight the customer
Not a new one indeed (see Vitruvius’ trectise on architecture from ancient Rome).
What is customer delight: provide a continuous stream of value.
Customer delight is measurable: see the book “The Ultimate Question”.
But it’s from outside-in instead of inside-out.
We should shift from output to outcomes and from things to people.
Less is more! Deliver it sooner!
With customer delight also costs come down as a consequence, thanks to focus.

2. New role for managers: Enablers for self-organizing teams
Self-organizing teams are a very old idea: see Legal Juries in England 1166.
Diversity over a group of experts. Diversity defeats intelligence.

3. Different coordination: Dynamic linking
Work in short cycles where the customer is the boss.
See The Case of the missing button in the book “The Lean startup” from Eric Ries.

4. From value to values: Radical Transparency and Continuous Improvement.
The status quo is never good enough (Toyota).

5. Interactive communication: From top-down to peer-2-peer.
Command and control kill inspiration.

Liz Keogh – Behaviour Driven Development

1. What is BDD
2. Conversation
3. Deliberate Discovery & Real Options
4. Feature Injection

BDD starts with “should”: what should be the system behaviour?
BDD is not a tool: having conversation with the customer is the most important thing. Having conversation is more important than capturing conversation and automating conversation.
If you’re not having conversation, you’re not doing BDD.
The standards template for scenarios is Given…When…Then.
Should it? – Always question the desired behaviour.
Don’t make sure to get it right. Assume you got it wrong.
Because it is impossible to get it right, fast feedback is essential.
Is there a context where the desired behaviour does not apply?
Is this the only outcome that matters?

Acceptance criteria vs. Scenarios: 1 to multiple

Deliberate Discovery is child of Real Options, which come from applying Financial Options concept to real life.
1. Options have value
2. Options expire
3. Never commit early unless you know why

Testers have deliberate discovery skills. Why don’t we use these skills first? This implies less rework, even if not “no rework”.
No rework is impossible because of the second order of ignorance.
Every knowledge splits into: Unknown unknowns (stuff we discover), Uknown knows (e.g. stuff the PO forgot to tell you), Known unknows and Known knows.
That’s why we need feedback as fast as possible.

Feature Injection
According to D. Andersson, Outcomes are divided into: Differentiators, Commodities, Spoilers and Cost Savers (see also “Pulling power” on InfoQ).
The path is:
Vision –> Goal –> Capabilities –> Stories –> Acceptance Criteria –> Scenarios –> Code
A Story is a slice through a feature to enable faster feedback
Risk-first!
Get the tests, which give you no info, off the critical path (Don Reinertsen).
The traditional information arrival curve as the maximum during analysis and during tets in field. It is better to call it curve of awareness of ignorance.
The perception of uncertainty varies from developers, to project manager to stakeholders and it’s maximum in the early phases: that’s why put the risks first!
Then we move to better curve of information arrival, where we get most of the information at the beginning.
Ignorance is the constraint. Missing an opportunity to learn is waste.

See: lizkeogh.com or follow @lunivore on Twitter.

Joseph Pelrine – Cynefin: Making sense of Agile

Why does Agile work? Why does Scrum work?
Cynefin is a method invented in early 2000 by Davide Snowden, which can give an answer to that.

1st Question: Why?
2nd queastion: Does Scrum work?
The annswer to the 2nd question is yes, from the experience.
Scrum works because of Dracula, the king of vampires or the un-dead (so not dead nor alive).
Un- is a way to define a system, like un-ordered, it means it is in a transition state.
For instance un-comfort zone: it is the zone between comfort and panic zones. Learning happens in this zone.
There are 2 type of systems: ordered, un-ordered. Agile deals with un-ordered systems, in particular complex systems.

Systems can be categorized considering order/unorder and if they follow rules or heuristics.
Ordered systems following rules are the machines. Organizations have been for too long considered like this kind of systems: that is where process engineering comes from.
Orgnizations like machines means thinking in terms of:

• resources (storage, reduction, etc.)
• a lot of things to plan and think about in advance

Ordered systems following heuristics are biological organisms, like bacterial cultures. These organisms self-organize looking for food, but 90% sacrifices their lives for the sake of the colony.
It is hard to think at an organization like a bacterial colony, where teams sacrifice to save other teams or the organization.

Unordered systems following rules is the domain of math problems where simulation can apply.

Unordered systems following heuristics are the ones where social complexity applies. Cynefin is a school of social complecity science (see http://www.cognitive-edge.com).
Cynefin comes from the consideration that we’re not like ants, we do not act rationally. If there’s a danger, we react by running away as fast as possible: this is a pattern.
Sense-making is a drive: finding connections between the world around us and what we know.
3 aspects of sense-making:
1. Ontology (What kind of system we’re dealing with)
2. Phenomenology (What is our perception?)
3. Epistemology (How do we know things?)

1. Ontology – Domains can be defined by causality (cause-effect).
The Cynefin Centre defines 4 different types of domain:

• Visible Order (Simple Systems): Cause-Effect is obvious (you can foresee the future)
• Hidden Order (Comlicated Systems): Cause-Effect is discoverable
• Complex Un-order (Complex Systems): Cause-Effect coherent in retrospective
• Chaotic Un-order (Chaotic Systems): No perceivable Cause-Effect

There is also a fifth domain which is totally unknown.
Chaotic ans simple systems have a connected edge: a very rigid system (considered too simple) has a high risk to fall down to chaos as soon as something does not work as expected. The more structured you are, the higher risk to go into chaos is.

For complex systems social science talks about Retrospective coherence –> Order emerges, as well as Cause-effect, only when looking back (like with estimates).

2. Phenomenology.
The above domains can be addressed in the following ways:

• Simple: Sense, Categorize, Respond
• Complicated: Sense, Analysis, Respond
• Complex: Probe, Sense, Respond
• Chaotic: Act, Sense, Respond

Simple systems are regulated by Bureacracy.
Complicated systems are handled by a Ivory Tower of experts. Experts are the most conservative people, just because they have more patterns to match reality with. People often confuses complex with complicated: you do not need expert for complex systems.

Download game: Butterfly stamping.

Inspect and Adapt is not enough: there’s something missing.
Actually it is:Apply, Inspect and Adapt –> Do not do too much upfront planning. Do something and then see what happens.
Download: The circle of XP

Apply, Inspect, Adapt is the same as Probe, Sense, Respond: that’s why Agile works for complex systems.

Epistemology in Cynefin:

• Artifacts (Codifying knowledge)
• Skills (Trasfer knowledge)
• Heuristics (Improve practices. Not best practices: they apply only to ordered systems)
• Experience
• Natural talent

Hints for coaches: there are things you can teach, you can coach, etc. But natural talent is important as well.

On understanding Software Agility – A Social Complexity Point of View
www.cognitive-edge.com

MODeM: Multi-Ontological Development Model – The AND, not the OR

Alan Cyment – An impromptu introduction to Scrum: the experiment

The session goal was to prepare an introduction to Scrum by using improv tecniques.

Open Spaces

I facilitated an Open Space called: How to encourage behaviours which fit into Agile/Lean values and principles. Here is the outcome of the discussion:

• Give a reason and a vision
• Give a purpose and generate passion
• Challenge
• Make people aware of the right behaviours –> Education, training, self-learning
• Create an environment for the right behaviours
• Lead by example: Trust/Reputation
• Copying behaviours (beneficial virus)
• Make things transparent

James Grenning – Transforming the world of work thorugh technical excellence (Closing Keynote)

See www.renaissancesoftware.net  or www.jamesgrenning.com.

What is Agile SW development? Great teams of people which build great products.

Agile Manifesto was signed in 2001. The first CSM course was held in 2003: now there are above 112500 CSM. What did we achieve so far?

SW development is not about the process, not the by-products: it is about the SW, the product.
Martin Fowler says: “Any fool can write code the compiler can understand, but it requires great skills to write code whihc other programmers can understand”.
Last February was the 10th anniversary celebration of the Agile Manifesto. The same group met again in Snowbird and reflected on this 10 years of agile. What was the outcome?
“We believe the the Agile community must:
#1 Demand technical excellence
#2 Promote individual change and lead organization change.

Jeff Sutherland says: “The biggest problem worldwide is to ship working SW every Sprint”.
Do you hardening sprints become fire-fighting?
From the book “The System Bible”: Your system will have bugs and they will surprise you when you find them.
Because systems act up, we must be careful in developing SW.
The waterfall flow is intrinsically designed to have defects.
The Physics of Debug Later Programming (DLP):
Tdev –> inf ==> Tfind –> inf ==> Tdev –> inf
Being good at chasing and managing bugs is not technical excellence.

Can we realize Djikstrom’s Dream and prevent bugs with TDD?
Development and test work together to prevent bugs.
The careful way is the fast way.
Get good at being careful and you can go fast (like when you learn skiing).

The Physics of TDD:
Tdev –>0 ==> Tfind –>0
http://www.renaissancesoftware.net/blog/archives/16

Misconception and Sustainability – There’s the feeling that TDD is slower than traditional development, but actually the total time is shorter.

The Test Hierarchy is: UI, Service and Unit. Unit Test is the forgotten layer of test automation.
System Level test cannot be thorough, TDD unit tests can be.

Let’s assume test effort is proportional to development effort.
Manual test is unsustainable: as the effort grows, we accept to test only a part. This is called the Untested SW gap: it will make bad things happen (too much risk).
We have to reframe the problem: it’s not we cannot afford automate tests, but we cannot afford not to automate tests. Manual Testing takes time away to implement new features.
Why code structure matters?
The 2 values of SW: the value visible to customer and the one which makes easy to add new features.
Rushing has normally short-term positive effects on velocity, but will ruin the velocity in the long term, by increasing defects.
Therefore: Slow down to go faster.

Developers need to know and practice Refactoring’s 3 critical skills:

• Recognize what is wrong (code smells)
• Fix it (in steps)
• Keep the code working all the time

A lot of excuses not to do TDD: who says developers are not supposed to think?
TDD is faster that DLP.

Remember: Motivating an individual or a team is really hard, but demotivating them is really easy.

Developers To-Do:
1. Become an expert in your craft
2. Be willing to learn and try new things (TDD, ATDD, Clean Code, etc.)
3. Become an advisor to your organization
There are a lot book out there: read them!

Scrum Masters To-Do:
1. Make sure your team uses state-of-the-art practices
2. Coach the organization
3. Encourage people to be problem solvers, not dogma followers

Managers To-Do:
1. Stop motivating your team
2. Grow great teams (teams of craftsmen)
3. Avoid demotivators
Motivation comes from within

Demotivators

• Unrealistic deadlines
• Punishing the truth
• Encouraging poor quality work (cut the corners)
• Hiding the big picture

You don’t delight customer with the untested code gap!
Learn, try it and adapt!
Don’t try to figure out things, before trying them.