Peter Gfader's brain noise

when an angry client comes in

Fri, 24 May 2013 08:22:22 +0200

thecodinglove:

/* by efranor */

"Good code is like a good joke - it doesn't need explanation"

Thu, 23 May 2013 16:20:04 +0200

Great quote

Source: unknown

code refactoring

Wed, 22 May 2013 08:33:04 +0200

thecodinglove:

I know that feeling ;-)

Are story points an excuse for teams not being able to estimate correctly in days/hours? via @anand003

Tue, 14 May 2013 11:30:24 +0200

I get this asked quite often as well.

Q: Are story points an excuse for teams not being able to estimate correctly in days/hours?

A: The eﬀort and time required to arrive at an accurate number in days/hours for a story weighs against the beneﬁts of estimating as such. Moreover estimating in days/hours puts undue pressure on the team to deliver within those number of days, leading to the team unable to reach a sustainable pace, and possibly burning out .

Additionally:

if we have an estimate in days:

I see the “illusion of control” or the “pretend to be in control” phenomen
and
Developers tend to follow the “Parkinsons’s law”
“Work expands so as to fill the time available for its completion.”

Great paper from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf

Organigram of Svenska Handelsbanken

Mon, 13 May 2013 11:30:42 +0200

I love this diagram. Customer on top, everyone else down below just to serve the customer. Awesome!

from Page 12 in this PDF from Franz Röösli
http://www.trendforum-basel.ch/media/7LNHC0X4/F._Roeoesli_Beyond_Budgeting_Trendforum_Basel._14._November_2011.pdf

Do you know the difference between a desirement and a requirement? via @ElegantCoder‎

Sun, 12 May 2013 11:30:34 +0200

Great article from David about “evolutionary architecture” and a nice example about it from the Microsoft Word ribbon.

David explains desirements and requirements as:

A desirement is a non-compiled request for software to change. Examples include specification documents, Team Foundation Server Work Items, index cards, and hope expressed with Microsoft Word.

Everyone can state a desirement and throw it on the bottom of the wishlist.
The interesting part is when a desirement gets closer to be a requirement (bubbles up) and the team discusses about the details and writes acceptance tests with the business to confirm them.

A requirement, on the other hand, is an automated test proving desired behavior exists in software. Requirements (tests) must pass before software may ship.

This leads to creating a ATDD Ready Backlog, which is a great way to make sure you have “always releasable software”.

Full article from David Starr:
http://visualstudiomagazine.com/articles/2013/01/07/leveling-up-agile-requirements.aspx

How do we know if the team is getting better at estimation when it is estimating in points? via @anand003

Sat, 11 May 2013 11:30:00 +0200

This is something I get asked a lot in my current project.

Q: How do we know if the team is getting better at estimation when it is estimating in points?

It is a popular belief that if the team were to estimate in ideal days, then it would be much easier to track if the estimation is accurate, by checking the actual days elapsed on a story and the progress against it. This is however counterproductive as the team spends hours to estimate few stories to arrive at the magic number of days before being pressurized to deliver on that magic number.

When a team is relatively sizing stories in points, a trend slowly starts emerging where similarly sized stories start showing similar time to implement them. If there is a bad estimate, then that bubbles up automatically as an exception.

Great interview with Anand Vishwanath in this PDF from ThoughtWorks
http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf

when I fix a bug without testing

Fri, 10 May 2013 14:19:04 +0200

thecodinglove:

/* by jazzy */

Love this one!
Especially the T-Shirt!

what the client see when I open a terminal in front of him

Fri, 03 May 2013 08:22:06 +0200

thecodinglove:

/* by zum */

The "Kanban Method" becoming more Agile by getting 2 important practices: TeamLeaderShip and Feedback Loops

Fri, 03 May 2013 08:21:47 +0200

A fellow trainer pointed me to this post from David Anderson: “EXTENDING THE FIVE CORE PRACTICES OF KANBAN”

As I’ve identified in presentations and key note speeches I gave in 2010, 2011 and earlier this year, the biggest oversight is leadership. Small acts of leadership from any member of the team need to happen regularly. It is these acts of leadership that make change happen.

So the 6th practice is: Leadership - give permission for ideas and encourage process innovation from any and all team members.

Sounds like building a team ;-)

There is also a need for explicit feedback loops. The Kanban book identifies these at two levels:

the daily standup meeting at the team and individual contributor level

and the operations review at the organization and inter-team or across services level

So the 7th practice is: Implement Organizational Feedback using Quantitative Measures of Demand and Capability

Sounds like having short feedback loops is a good thing

http://agilemanagement.net/index.php/Blog/extending_the_five_core_practices_of_kanban/

Visualizing work at the Boeing 787 battery system team??

Thu, 02 May 2013 11:30:31 +0200

Look at the background of those 2 images.

http://www.gizmag.com/boeing-battery-final-certification-test/26956/pictures#2

http://www.gizmag.com/boeing-battery-final-certification-test/26956/pictures#4

Are they visualizing their work flow?
Are they not using an electronic tool, but a physical board?

Why a Short Feedback Cycle is a Good Thing

Fri, 26 Apr 2013 11:30:32 +0200

We have to “get the requirements right!”

This is everywhere, and lots of failed projects suggest us that even more. See this article about the FBI Sentinel project

Nice article
http://www.richard-banks.org/2013/04/why-short-feedback-cycle-is-good-thing.html

Inside Portable Class Libraries

Thu, 25 Apr 2013 11:30:16 +0200

kodefuguru:

http://dlvr.it/3GWvRG

Interesting read. Look under the hood!

Big Code @ Google

Wed, 24 Apr 2013 11:30:45 +0200

Google has a single code repository
Completely open to all of the 10000 developers
All systems are released independently
Release cycles randing from a week to a month
Everything is built from HEAD without any binary releases
Repository receives several thousand changes per day with spikes of 20+ changes per minute

from Gojko Adzic
http://gojko.net/2009/12/07/improving-testing-practices-at-google/