Last year I read an article on how Agile Development Must Be Driven from the Top.
For the last couple of months (approx. 9) I have been acting as Scrum Master, on the biggest project I've been involved in, and I have been battling this very thing. The overall project is being run in a classic waterfail (aka waterfall) approach and for some reason my colleagues and I thought we could convince our client that we could do our component of the project in an agile fashion. Boy were we wrong!
The project has shown all the classic symptoms of a classic waterfail project and as you could expect requirements were always hard to come by until certain "milestones" were reached. My thoughts were that shouldn't be a problem, we'll create user stories that cover the requirements that are known now and cover the gaps with extra stories later. In theory this should be fine, except for one tiny problem...
The agile approach we were using wasn't being driven from the top!
The project manager we were under, while he was happy for us to drive the agile approach, he and some of his own colleagues didn't truly understand the benefits of the metrics that can be derived from a well run agile methodology. He was too focused on sticking to his original plan - one massive development phase followed by a massive testing phase.
Where are things at now? I have gone back to development, the client has fallen back to complete waterfail approach. They are evening phasing out the end-to-end tests in favour of manually testing during the test phase.
So what did I learn from the experience? Unless management are TRULY willing to adopt the requirements of following an agile approach, don't waste your time.
Thursday, August 4, 2011
Monday, July 4, 2011
Notes on Agile Australia - Day 1
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
Saturday, June 4, 2011
Trial and error vs. Inspect and adapt
I recently watched a video on using an agile approach to work in a non-software environment (ABC Nightline - IDEO Shopping Cart). There were a bunch of very cool catch phrases that were used one of which really stuck to mind...
What I do love is the reference to the planning of the lone genius.
A great dig at waterfall! :)
"Enlighten, trial and error succeeds over the planning of the lone genius"While this is a might be great from a non-development perspective, I don't think that it is quite right from a development perspective. It implies that the group don't really know the direction they're going and that they could get it wrong. This doesn't work for development. The development team should always know the direction they are going otherwise they increase the chance of incurring technical debt. I prefer the well known phrase, Inspect and adapt.
What I do love is the reference to the planning of the lone genius.
A great dig at waterfall! :)
Friday, May 27, 2011
Don't Deliver To Promises
The other day I read a great article on building trust one iteration at a time. Considering I'm operating as Scrum Master for the development team in a large waterfall project, something that stood out to me in this article was a comparison of Waterfall to Agile.
I had a quiet chuckle to myself.
In a waterfall delivery, all progress reports are proxies. You’re reporting on intangibles–designs, test cases, or code that isn’t fully integrated or tested. This is all reporting on faith, because it is not verified by working software.Just this morning this was proven true. A waterfall PM was tracking the progress of some work with a BA who said "I'm waiting on John. He told me that he'd have it ready for me by COB yesterday. In fact he said the same thing last week."
I had a quiet chuckle to myself.
Subscribe to:
Posts (Atom)