Agile Needs To Be Driven From The Top

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.

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.

Keynote 1

Alistair Cockburn - alistair.cockburn.us

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

Keynote2

Rob Thomsett

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!)

Rock Road to an Agile Transformation

Daniel Oertli

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:

• 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 Kearns

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.

LiveAccounts DevOps - Continuous Delivery in the Real World

MYOB

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.

Agile Games

Kane Mar

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

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

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.

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.

Great Scrum Resources

I just read a nice little post on Richard's Braindump regarding a new Professional Scrum Developer Course being offered at Scrum.org. Rather parrot what Richard said go read his post.

Anyway, while having a look through the site I came across some awesome Scrum Instructional Videos. Even if you've worked with Scrum, or maybe you think you've worked with Scrum, these are worth a look.

Enjoy!

Poker - Planning Poker

Had my first game of Planning Poker not long ago. Even though I'd been working with Scrum for the last three years never had I performed planning of this type before. For those who are/ have been in a similar situation to myself you're probably asking, what they heck is this all about?

As the term poker suggests, there is a deck of cards involved, how ever this is no ordinary deck of cards. Each player has the following set of cards... ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.

So how does it work you may be asking?
Firstly we should explain when the game is played. This game is played when the project team is estimating the effort required for each of the user stories in the product backlog. But how do the numbers listed above work? You need to keep in mind that you are not trying to estimate the number of hours a user story is going to take, you are just giving an indication of how much effort you think is going to be required to complete the task in relation to the other tasks. The other major benefit of playing is that it generates discussion amongst the team.

Anyway rather then going on and on, read here: Planning Poker Estimating in Detail

Here's another very good read on Planning Poker - Agile Estimating

Hope this is helpful

Agile Development - Made Easy

While I've developed in a Scrum environment for the last three years, I was never really exposed to the construction of the product backlog. Now though, I've recently started on a project in it's infancy stages and this is all changing.

The client practises Scrum actively and they go about creating the backlog by writing User Stories. User Stories? I'm thinking. What are they really?

Thankfully Google pointed me in the right direction => http://www.agile-software-development.com/.

Here you will find an awesome array of information on the Principles of Agile development, implementing Scrum, user stories, estimating within an agile environment, agile project management and a number of eBooks and presentations.

Enjoy!