Using KPIs/Getting a data-driven org.

2010-11-23T09:23:35Z

83.244.178.146:

* 2.5 years of dev got a release out every fortnight
* 27 financial projects 5 made money, 2 made most of it
* this didn't change anyone's mind
* Maybe was too aggressive
* Maybe it was embarrassing

* Don't see a correlation between the quality of the project and the value it brings
* Building the wrong thing

* Accountability is missing?
* Arguments for value wanted from one side, but not provided by the other side

* Accountability doesn't change things
* PM a project that doesn't have market
* If he said there was no market then he has no job

Maybe it has to happen early. During the initial phases decide what needs to happen

* What to do "Agile" to obfuscate accountability
* "Agile" separates accountability into team and product owner
* Team is only accountable for implementing what they are told
* Product owner

A/B testing: 1/3 of the time the change makes not diff. 1/3 they make a negative diff. 1/3 of the time it works

What are you accountable for
* In an organization you cannot make mistakes
* Everything is success!
* Do things that are safe!
* Or I can blame you!

Accountability: things can be traced back to the root cause. Making the problem yours.

Why not have an information radiator about how you are doing (products selling, etc.)

Management doesn't want to take responsibility for stopping a project or continuing it.
Having some measurements even if they are gamed is probably better than nothing. Maybe gut feeling is better than nothing.
Design companies have more of that. Microsoft version of design: user groups and testing vs. Apple: gut feeling and "good" designers

Do we make decisions rationaly. Is there a rationale for every decision. Decision models: "garbage can" model:

Problems
Participants
Solutions

Vs.

Problem connected to causes

The moment someone feels responsible is where you start improving.

The data is a placeholder for conversation. Maybe an uncomfortable conversation, but it is a starting point.

Defensive reaction to being told about responsibility.

Responsibility Virus: google for it, you'll find a pdf

Culture where people can talk about this. Talk with teammates. Don't worry about getting shot down.
Collect data that one thinks should be measured.
Maybe just voice concerns. Suggest improvements.

The under-responsible to over-responsible cycle: under-responsible -> fail -> over-responsible -> fail -> repeat

Being silent and not raising an issue is complicit. Some people stay under-responsible because they don't know how to communicate well. There is no external encouragement to share reservations. Responsibility of the management to elicit these things?

Look for ways to minimize defensiveness by looking for problems and communicating

Great question for retrospectives:

What is un-discussable right now?

Beyond Basic TDD

2010-11-09T17:26:32Z

83.244.178.146:

The session started with a question from [[Waseem Taj]], who observed that the traditional red, green, refactor TDD cycle did not always result in well designed solutions.
[[Jeffrey Fredrick]] noted that Kent Beck recently revoked his original thoughts on emergent design, with the realisation that you have to actually be a good designer for this to work.
The general consensus was that you must keep refactoring until the design is right, and have the courage to say "we need to do more." -- '''Refactor Mercilessly'''

The discussion turned to Kent Beck’s [http://c2.com/cgi/wiki?XpSimplicityRules Four rules of simple code], and particularly to the need to '''express intent in your tests'''. Ask yourself "what does this class need to do," not "what methods should it have." When pairing, one person should be ensuring that the design is moving in the right direction. Good pairing partners are relentless in their insistence on refactoring.

The conversation turned focus on going beyond TDD, with [[Gojko Adzic]] posing the question "What do we need to teach TDD practitioners to get them to the next level?" He mentioned several concepts:
* Evolutionary Design
* Exposing Design Presumptions
* Hexagonal Architecture
* Naming Conventions

The initial reaction was that it was extremely difficult to teach advanced TDD techniques, and that experiencing the benefits first hand by paring with a practitioner was the only realistic way. [[Steve Freeman]] said that "until you experience the whole rigorous TDD, refactor cycle, you will never get it."

Several ideas for learning were proposed.
* Have a sandpit codebase, or a pet project (one that actually goes live somewhere so that it isn't entirely fictional) People can often translate from an example to their real code.
* Code dojos
* Have the right to experiment and to throw away those experiments.
* Apprenticeships and staff swaps
* Give an exercise to express a difficult intent in a test (e.g. write a test for the generation of a random number)
* Try writing your test's assertion first
* Show how to do things badly (refuctoring)
* Try reversing refactorings to see if they still apply.
* Write code in the test and refactor it out ("TDD as you meant it").
* Stop after 15 minutes and Ask yourself: "Can I check in now?". If the answer is no, ask: "Will I be able to check in after another 15 minutes?" If the answer is still no, then ask why, and consider reverting.
* Get the whole team to work on the same area of code simultaneously. This encourages frequent check-ins to avoid merge conflicts (only those who commit often will 'win').
* Do a visualisation of bugs raised and fixed, allowing developers to get experience-points for cleaner code.
* Try measuring a different code metric each week. Changing the metric frequently discourages 'gaming' the system. This encourages conversation about aspects of the code.

[[Gojko Adzic]] provides a detailed write-up here: http://gojko.net/2010/11/09/beyond-basic-tdd/

CitconWiki - User contributions [en]

Using KPIs/Getting a data-driven org.

Beyond Basic TDD