This has taken way too long to get around to doing, but here are my notes on Agile Australia day 1.
Discussed a number of perspectives of agile: Games, Craft, Flow Management and Knowledge Acquisition
#1 - Games
Just like games, agile software development requires positioning, moves and strategies.
Quite often there are two conflicting subgoals:
Deliver this system
Setup for the next game
You also need to adapt to your situation by understanding how your project can be classified. Classification is gauged by the criticality of the project and the number of people that require co-ordination.
#2 - Craft
Craft teaches you to pay attention to our skills and to the medium in which they learn.
People learn skills in 3 different stages
1. Shu: Learn a technique
2. Ha: Collect techniques
3. Ri: Invent/blend techniques
Considering that I work for Readify, I thought this had a natural affinity to our slogan Discover. Master. Influence.
#3 - Flow Management
Design == manufacturing if Inventory == Decisions
We need to learn from the queues in our process. Identify where the bottlenecks and make decisions but make them quickly
#4 - Knowledge Acquisition
The Big bang theory is a late learning strategy
In designing the solution we gain knowledge early
Every company is ready for Agile... they just don't know it!
How do you certify someone in common sense? [I think this is more of a provocative statement, as there is more to obtaining certification in an agile methodology]
Some easy tests for a good development process
- Simplicity
- Transparency
We need to close the lines of communication.
Governance gives the semblance of control.
(Rob if you end of up reading this please be aware that you ask the audience"Is that OK?" way too much!)
While it was not quite what I was looking for or anticipating, it was an interesting talk with a nice use of pollev.com (even if the execution didn't quite work).
Daniel gave a run down of the primary questions that he had to think through when taking the company from Ground Zero through to delivering results through to scaling the model and finally leading to sustaining performance.
A few key phrases that I got out of the talk:
Among other things Martin drew a picture (literally) of three teams with a different type of leader in each.
Team 1 has a leader who chains the team to them,
Team 2 has who claims to trust the team. But this is not sustainable as it take too much energy.
Team 3 has a leader who is involved. This seems great, however if a member leaves the team and is replaced by someone with different values all hell can break loose.
We's stopped being agile because we've started being purists.
Something to be aware of is that during the standups people can fall into the habit of talking about themselves and not about the story.
A team is only successful as its least committed member.
Wasn't sure if I'd pick anything new up in this one as I already new the benefits of continuous delivery. For those of you who are still debating the whether to introduce the practice into your development process, MYOB were able to quadruple the through put of the development team.
Game 1: Failure Bow
This was an odd game and very simple.
Each of us had to come up with a way of acknowledging our failure. Some of us were a little shy others not so much
We then split into groups and proceeded to throw a ball around the group with the understanding that if we drop the ball we'd perform our "bow". We then had another object introduced to throw around and then were only allowed to catch with one hand.
Game 2: Go
This is more or less a team coordination game.
Starting with one person (P1) on the team they had to point to another team member (P2) to indicate that they were going to stand in their spot. P1 is not allowed to move until P2 has said "GO".
However you can not have two people standing in the same spot, so P2 has to point to another team member (P3) to indicate they wanted to stand in their spot.
And so the pattern continues.
From my point of view this was a coordination exercise. If everyone was paying attention to what the team was doing then it was easy enough. However, it only took one person to stuff the hole thing up.
Game 3: Marshmallow Tower
For more information see: marshmallowchallenge.com
Keynote 1
Alistair Cockburn - alistair.cockburn.usDiscussed a number of perspectives of agile: Games, Craft, Flow Management and Knowledge Acquisition
#1 - Games
Just like games, agile software development requires positioning, moves and strategies.
Quite often there are two conflicting subgoals:
Deliver this system
Setup for the next game
You also need to adapt to your situation by understanding how your project can be classified. Classification is gauged by the criticality of the project and the number of people that require co-ordination.
#2 - Craft
Craft teaches you to pay attention to our skills and to the medium in which they learn.
People learn skills in 3 different stages
1. Shu: Learn a technique
2. Ha: Collect techniques
3. Ri: Invent/blend techniques
Considering that I work for Readify, I thought this had a natural affinity to our slogan Discover. Master. Influence.
#3 - Flow Management
Design == manufacturing if Inventory == Decisions
We need to learn from the queues in our process. Identify where the bottlenecks and make decisions but make them quickly
#4 - Knowledge Acquisition
The Big bang theory is a late learning strategy
In designing the solution we gain knowledge early
Keynote2
Rob ThomsettEvery company is ready for Agile... they just don't know it!
How do you certify someone in common sense? [I think this is more of a provocative statement, as there is more to obtaining certification in an agile methodology]
Some easy tests for a good development process
- Simplicity
- Transparency
We need to close the lines of communication.
Governance gives the semblance of control.
(Rob if you end of up reading this please be aware that you ask the audience"Is that OK?" way too much!)
Rock Road to an Agile Transformation
Daniel OertliWhile it was not quite what I was looking for or anticipating, it was an interesting talk with a nice use of pollev.com (even if the execution didn't quite work).
Daniel gave a run down of the primary questions that he had to think through when taking the company from Ground Zero through to delivering results through to scaling the model and finally leading to sustaining performance.
A few key phrases that I got out of the talk:
- Plans are nothing, planning is everything
- You want to be customer centric not customer driven
- Agile is a cultural change enabler
- Agile requires delegation
How Agile can go terribly wrong
Martin KearnsAmong other things Martin drew a picture (literally) of three teams with a different type of leader in each.
Team 1 has a leader who chains the team to them,
Team 2 has who claims to trust the team. But this is not sustainable as it take too much energy.
Team 3 has a leader who is involved. This seems great, however if a member leaves the team and is replaced by someone with different values all hell can break loose.
We's stopped being agile because we've started being purists.
Something to be aware of is that during the standups people can fall into the habit of talking about themselves and not about the story.
A team is only successful as its least committed member.
LiveAccounts DevOps - Continuous Delivery in the Real World
MYOBWasn't sure if I'd pick anything new up in this one as I already new the benefits of continuous delivery. For those of you who are still debating the whether to introduce the practice into your development process, MYOB were able to quadruple the through put of the development team.
Agile Games
Kane MarGame 1: Failure Bow
This was an odd game and very simple.
Each of us had to come up with a way of acknowledging our failure. Some of us were a little shy others not so much
We then split into groups and proceeded to throw a ball around the group with the understanding that if we drop the ball we'd perform our "bow". We then had another object introduced to throw around and then were only allowed to catch with one hand.
Game 2: Go
This is more or less a team coordination game.
Starting with one person (P1) on the team they had to point to another team member (P2) to indicate that they were going to stand in their spot. P1 is not allowed to move until P2 has said "GO".
However you can not have two people standing in the same spot, so P2 has to point to another team member (P3) to indicate they wanted to stand in their spot.
And so the pattern continues.
From my point of view this was a coordination exercise. If everyone was paying attention to what the team was doing then it was easy enough. However, it only took one person to stuff the hole thing up.
Game 3: Marshmallow Tower
For more information see: marshmallowchallenge.com
This was a very interesting challenge. A challenge that I consider I failed. While I knew that I needed to "inspect and adapt", it was very easy to fall into the waterfail approach of discuss... and then fail.
Anyway, there's a few thoughts on Day 1. Hopefully my thoughts on Day 2 will arrive a little quicker than these did!
Enjoy!
Matt
