Dan North shares insight on how really high-performing teams work, the patterns and ideas being genuine experiences from practitioners. This is Agile in actuality. Agile is an attitude, not a rule book.
Dan North is a technology and organizational consultant helping CIOs, business and software teams to deliver quickly and successfully. He finds most technology problems are about communication and feedback, which explains his interest in organizational design, systems thinking and how people learn. He has been coding, consulting and coaching for over 20 years, and he blogs at dannorth.net.
Joy of Coding is a one-day conference that celebrates the art, craft, science but foremost the joy of software development. It is a day for talking and collaborating with like-minded coders. The non-profit conference is not targeted towards a particular language or platform.
If Dan North were to build a bridge
1. Look straight down and begin walking. Notice the ground disappears.
2. Grab whatever building materials are readily within reach.
3. Piece materials together such that you can make some progress and continue walking.
4. Continue walking
5. Observe the bridge didn't span the canyon and more materials are needed.
6. Try to find materials within reach again.
7. Realize you didn't put any engineering effort into your initial design and what you built has fallen apart and you are now falling off the cliff
9. Profit because at least you delivered something early.
Notes from Accelerating Agile: Hyper-performing without the Hype
Traders should understand some of what is possible in programming. In Dan’s story, the traders learned a bit of Python to expand their perspective. This provided developers with a base to develop something better.
Putting a programmer with a trader is pairing. They learn from each other.
A Minimum Viable Product is a set of deliverables. Until that set exists, there is no value. Achieving value is a step function.
A goal of development is to attain to a business outcome, not a set of product features. Acquiring information at the start of a project is likely to be more important that coding.
In a development project, software is the scaffolding. The eventual flow of information for the intended customer is why we engage in the project.
Your idea is probably wrong. In the beginning, you do not even know why it is wrong.
Product Ownership is a team sport. It should not be confined to a single individual.
Re: If Dan North were to build a bridge
1. Dan comes across a man standing in front of a chasm who says that he'd like to get to the other side because he thinks there's gold there.
2. Dan offers to build a bridge sturdy enough for the two of them to get to the other side.
3. Dan builds the bridge and goes with the man to the other side and they both start looking for gold together.
At this point either:
A. They don't find gold and say 'Sure glad we didn't build a bigger bridge - that would have been a waste."
- OR -
B. They find gold, so much so that they have to build a bigger bridge.
I think one of the points in Dan's talk is to build just enough for what you know you need. In my bridge narrative all they knew for sure was that they wanted to get to the other side to look for gold - they didn't know if they needed to engineer for anything more than that.