Posts Tagged ‘Collaboration’

The Tribe has spoken …It’s (fr)agile…

Monday, February 22nd, 2010

Author: André Harvey

Extending to Susan’s recent post, “Agile is not the holy grail!”, I’d like to add to the provocation by suggesting that ‘change’ is the Holy Grail and momentum is key; and critical to unlocking the benefit and to mitigating the fragility of a change movement is to know the Whys and What Fors.

For those who are personally, or though their organisation, embarking on an Agile methodology change movement – be it adoption, re-acquaintance or the velvet glove of a performance push ask yourself a couple of questions:

  • Do you understand why you use Agile and what the benefits of Agile are?
  • Could you explain it to your mum?

These are important questions. If you don’t get it, how will you become a catalyst for change? An Agile advocate? Change movements are fragile and need your help.

frag•ile
adj.

  1. Easily broken, damaged, or destroyed; frail.
  2. Lacking physical or emotional strength; delicate.
  3. Lacking substance; tenuous or flimsy: a fragile claim to fame.

Teale Shapcott gets it – for her it’s about usability. No point in building the world’s best ‘thing-a-mijig’ if it’s horrible to use. If your staff and colleagues don’t like using it, what type of customer experience do you think will transpire?

Real world example of the above:

I recently opened an account for my daughter at one of the major banks. A seemingly simple request – I thought. It took 2 hours! The entire time all I heard was how poor the system (read: technology) is and how the users experience is worse – no mention of the customer! Perfect example of an implementation performed in isolation of its users and with little OR no thought for its end-customers.

This is where Agile kills its competition – iterations, prototypes, tangible and timely improvements. To market faster with expectations met and the value of the customer experience in top of mind. Even my mum understands the commercial significance of beating competitors to market.

Mark Palmer also gets it – Based on his post - Agile as a Fundraising Tool about workshop facilitation outside the software development environment. It’s a way of thinking and acting. Anyone who can get ~40 people to work through, short-list and agree on 5 key ideas in an hour is worth his weight in gold (Gold bugs take note – resources will boom!). The fact that he’s taken an Agile concept and broadened its application to rugby in a non-corporate setting is advocacy beyond expectation. It takes courage to suggest and commitment to follow through. NOTE: The Agile Academy should sign this man up for a coaching role!

Seek out those that don’t understand…and then listen, Don’t preach.

Humans have been blessed with a physical design that all but encourages you to listen first, then speak: two ears and one mouth. The least we could do is use our human design in its correct ratio.

In my experience there will undoubtedly be and will always remain some resistance to change. This is a good thing. Creative tension so to speak. It keeps us on our toes. Makes us hone our stories.

A constant reminder of change’s fragility. Seek out the resistance. Understand why it is is isn’t happening. As Susan’s post indicated – it might be justified.

This is where Fiona’s earlier blog post on Leadership is magic, whilst not strictly Agile related, which is refreshing, it’s a nice pointer for when you get stuck with a problem or face an explanation that needs more weight behind it – seek to understand first, then find help.

A behavioural science interjection – in a recent McKinsey article, a case study was performed on interactions with customers via call centres. Whereby, if the call had a bad news element the operator would bring it [bad news] forward to the beginning of the call. In doing so, the operator was then able to coach the customer through the news, in turn giving the customer a sense of control of the outcome and improving customer satisfaction.

What I’m suggesting is something very similar for our colleagues that don’t understand the subtleties of Agile or any change movement for that matter.

  • Seek them out.
  • Then coach, don’t preach.
  • Give back control but take the lead.
  • Give your advocacy stories purpose and meaning – make it an fragile claim to fame.
  • Ps. Final Food for thought – Imagine Pixar without story boards.

“Stories drive a stand-up”

Thursday, February 4th, 2010

Author: Marc Galbraith, Iteration Manager

On a recent project the rather large team came to a consensus that stand-ups they were doing didn’t have the value attached to them they had been expecting. A suggested change in format was, “Let’s just talk about the stories!”.

OK, so we started to talk about the stories on the wall. The first issue that came up was WHERE DO WE START? We soon realised the best place was at the end of the story life-cycle and work backwards from there.

Complete > Sign Off > Test > Dev > Review > Analysis > Scope

  • We would reflect on what we had completed the previous day (Team).
  • Discuss current challenges to Signing Off stories (QA and Business Rep).
  • Issues in Testing would be discussed (QA / Dev).
  • Devs would walk down in priority order each story they are pairing on currently (Devs).
  • Stories that are ready and may need final review are highlighted (BA / QA / Dev).
  • Issues in Analysis discussed (BA).
  • Any new Scope highlighted (Team).

So this approach is driven by two key points, the state and priority of the story. We start from the highest and work to the lowest. In our case the highest priority story is in ‘Complete’ and was the latest addition to that pile. So if you were looking at a Scrum backlog it would simply be the item at the top of the backlog and work down the list.

As the project team is split across Melbourne and Sydney it is performed by each part of the team locally in front of their respective walls. Then twice a week we bring the whole team (approx 25 people) together over video and perform the same stand-up, which we call the ‘National Stand-up’. Just focusing on the stories has made the large stand-up more efficient, informative and productive for the team.

We achieve this over videoconferencing by printing out an electronic version of the wall, as we need to be in a room with dedicated video facilities, and nominate a facilitator to conduct the driving from the printout. At the end, the team walks out of the rooms with a good picture of where they are at overall, and where the focus needs to be.

Having a natural process to the stand-up also enhances the self-managing ethics the team wishes to improve on. It appears to take the guess work out of “What should I cover off at stand-up?”, especially on Mondays when the weekend has had a negative impact on their memory.

Are two heads better than one?

Thursday, January 21st, 2010

Authors: Alexandra Hooper and Tammy White

During the graduate program and in permanent positions, we have worked on several projects and are still puzzled by the way in which Business Analysts and Developers are resourced. One thing we have noticed is how pair programming is used as a standard practice amongst developers but not by other disciplines (for example, Business Analysts), particularly given the obvious advantages that pair programming provides in the developer ‘world’, like:

  1. Improved quality
  2. Reduced cost of development
  3. Learning and training
  4. Overcoming difficult problems
  5. Improved morale
  6. Decreased management risk
  7. Increased discipline and better time management
  8. Resilient flow
  9. Fewer interruptions.

With such benefits we wondered why more often than not, is only a single Business Analyst assigned to a project or stream especially within a large program of work? Surely many of the same benefits that developers experience could be achieved through a Business Analyst partnership/BA pairing. So why is this technique not used in the Business Analyst ‘world’?

At a Business Analyst team discussion recently a comment was made around the variation of skillsets amongst the Business Analysts in the room. Each person had different business experiences and knowledge of tools to offer, which could have led to a truly complementary partnership.

So this made us ponder a couple of questions.

  • Can we really expect a single Business Analyst to understand and facilitate the use of all analytical tools on a range of projects?
  • Why stop at pair programming with developers, why not expand such an effective practice across other disciplines on a project like to business analysts?

In summary, are two heads better than one?