Almost any improvement method is hailed as the best way to save busi-ness from problems when it is new. Unfortunately, a few years later, this same method is now the reviled, flawed method that a new method is replacing. This parable tells how this happens.

On my recent visit to Wellington I was talking to some colleagues working with government departments interested in Agile. It was a bit of an eye opening experience and given the AgileNZ Conference in Wellington is only 2 weeks away is something I would like to start talking about.

So…. can Agile work in government?

I love being Scrum Trainer, mentor and coach. It provides regular insights into human behaviour that I personally find utterly fascinating.One of my favourite exercises that I use in Scrum Training is the Ball Game. It is a simple game and gives teams a wonderful opportunity to experience the power of self-organisation, frequent micro-planning and retrospection.

Recently I was fortunate enough to attend a workshop by the legendary Donald Reinertsen called “The Science of Lean Product Development”. The workshop was part of QCon San Francisco 2011.

What happens to the role of the Business Analyst in an increasingly Agile world? I tried to answer this question a few years ago in a Modern Analyst Article and now having been through a number of Scrum implementations it seems like a good time to reflect on these predictions.

With a transition from Waterfall to Scrum the role of the Business Analyst changes and my opinion improves for a number of reasons.

In this movie "I want to run an agile project" we follow the experiences of one such brave project leader, Luke, as he has many different encounters throughout the enterprise, working to establish and deliver his Agile project.

Clarus had a great time presenting to the Auckland chapter of the IIBA recently.  Colart Miles and Milan Holzapfel took the group of 24 business analysts through Tom Wujec's Marshmallow Challenge (http://marshmallowchallenge.com). The Marshmallow Challenge is a remarkably fun and instructive design exercise that encourages teams to experience simple but profound lessons in collaboration, innovation and creativity.

Recently I was asked to participate in writing a testing best practice for a company and honestly I struggled to come up with it. There are so many
things to cover and the last thing I want is to write a big fat document to cover everything. After tinkering many ideas, I’ve come to a conclusion that 
whatever I present it will be alright as long as it adheres to ‘ABCD’ of testing.

There was a shockwave of disbelieve and anxiety on Saturday night as the New Zealand rugby public saw their heroes handed a loss by a very energised and deliberate Wallabies side. The All Blacks lost the game for one reason and one reason only – an inability to change tactics to meet the scene in front of them. And this isn’t the first time they have suffered this flaw either. The funny thing is that it has striking similarities to software projects.

It seems everyone is obsessed with Scrum tools these days. Every time we run a Scrum course people ask “what tools do you recommend?” The answer is always the same – whiteboards, index cards and post-it notes. The reasons for this are many. In my coaching work I see team after team try one of the myriad of tools available and the result is almost always the same – a slow Scrum uptake. Why is this?

Wow recently a major bank has picked up on something we’ve all known for a long time.  Stories are powerful.  We engage with them, we grow with them and we use the context of their knowledge to help build our own understanding.  And who has the best stories?  One group is great writers who can link their experiences with our own; and the other is US the people in business who make business happen – often this needs some BA help which we’ll come to further down – but the key point is remember how much engagement you have in a great story... you could have heard it many times but it still involves you  :-)

In our experience helping companies implement Scrum, Product Ownership recurs over and over again as THE big issue. In this blog article we provide some guidance on what makes a good product owner and include a Product Owner position description.

Recently I was assigned to a new Scrum team consisting three developers and one tester. This team is having a problem: the tester is limited to only doing work related to testing and the developer is limited to doing work related to development. The tester is so reliant on the developer to make a build/installer and the developer is so reliant on the tester to tell them if their code is ok. On top of that, the team is refusing to collaborate and is divided between tester and developer. If you are having a hard time imagining the situation, think of Montagues and Capulets.

Agile Australia was a really good event this year. Quite a reasonable sized contingent of Kiwis made it over the ditch to Sydney to enjoy what was a really good few days of complete Agile immersion.

The highlight for me was Alistair Cockburn. I attended his Advanced Agile pre-conference workshop and really enjoyed hearing another perspective on Agile. It was particularly relevant to study with another one of the original Agile Manifesto signatories during a celebratory 10^th year since its inception.

Here are some of my learnings from the two days. I have posted them here as something of interest for the Agile community that could not attend.

The recent Gartner/FEI survey of CFO’s faith in IT is damning and well, frankly, downright embarrassing. IT is increasingly been seen as a necessary cost that fails to deliver the promised benefit. This has been going on for as long as I can remember so what the hell are we doing about it?

On 26^thMay four Clarus staff delivered a presentation outlining some of the lessons we have had learned using Scrum at a range of companies throughout New Zealand. It was a capacity session.

Thanks to Dynamic Controls for providing the venue and to the ANZTB and Clarus for sponsorship.