The Agile Tribe

Agile Australia through the looking glass

Authors: Robert McDonald, Belinda Lawrence and Wayne Allan

Some views and take aways from the recent 2011 Agile Australia conference.  This is what three people saw and heard.

Robert McDonald, Operational Reporting Analyst

“If there is word to describe what happened in the Agile Australia conference of 2011, it was ‘vibe’.
Being part of such a collection of ‘Can Do’, challenging, active and clever people, all intent on making the world a better place was fun. Some had the longer scaled up version which looked towards a bright future, while others shared their ‘tactical’ excellence.
Read the rest of this entry »

4 Comments »

People Issues and performance reviews – Team Leader or Iteration Manager?

Author: Steve Jenkins (Steve presented his talk at Agile Australia 16th June 2011)

My name is Steven Jenkins, I have had all these roles on projects, projects that were sized from just a few thousand dollar budget to millions of dollars over many months. I am currently the Iteration Manager (IM) within Suncorp’s Banking Platform Program.

This lightning talk raises two main questions. 

Firstly, with regards to managing people how does the Agile framework scale for larger projects and secondly how should the delivery team and the leadership team work together.

This talk may be a little Suncorp specific role but it relates to the relationship between project staff and line leadership no matter where you work.  I will explore the grey areas between these roles, the role expectations on each other and lastly some recommendations to improve  team cohesion and managing people dynamics.

I have 5 more slides and now less than 5 minutes, so let’s get cracking…..

For context, these are the roles within a major Suncorp project. 

This diagram makes the difference between roles look clear, however there certainly is cross over and grey areas between each role, especially when it comes to people issues and performance reviews.

For a simple definition:

Iteration Manager – people’s work load and work flow. 
Team Lead  – work’s people load and people flow. 

I am flipping these words around to show how closely related these roles are to each other but they both complete very different jobs.

Now let’s explore the people based issues where the responsibilities are ‘grey’ and where accountability and control need to be delegated to ensure that the team is ‘humming’ to its greatest potential.

As a IM I feel like a need to be a control freak.  Or maybe just an ‘out of control’ freak.  After being in both TL and IM roles,  the key source of frustration for me is due to the role accountability vs. control – the IM feels that he/she is accountable for the velocity of the project, but he needs to work closely with the Team Lead who controls the people.  It is these people who give the momentum, the momentum that delivers the project. 

The two roles are therefore linked, but how far along the self managing team vs. the reliant team spectrum is your team?

The next set of problems relates to relates to the teams self management skills, how well does a team really deal with human relations issues?  In my view it would take either a very special team or a team with HR mentorship to get through many of the personal issues that can occur, these could be issues such as intra-team issues such as ‘wars’ or inter-team issues such as work that has been committed to by the team leader.

Lastly, can the team leader comparatively rank, compare and provide valuable performance feedback to the individual staff member when he or she sits outside the team. 

The key for me is that the iteration manager becomes so close to the work that he or she potentially has the greatest micro view of what is going on with the people.  The danger is when the Team Leader doesn’t have a view of the work and the Iteration Manager doesn’t feel as though he/she has got the people control required to match off with the level of delivery accountability.

The team leader is expected to be a 7 legged beast.

  1. Culture Manager – Creates a safe environment, a culture where people can make mistakes and learn from them.
  2. People Manager – Improve team cohesion
  3. Resource Manager – Resources to deliver
  4. Emotional Quotient Manager – Senses performance breakdowns
  5. Continuous Improvement Manager – Helps identify improvements
  6. Public Relations Manager – Bridge between groups (speaker for the team to the rest of the company)
  7. Best Practice Manager – Sharing best practice from outside our team.

The IM is expected to be have the following people elements under their control.

  • The Team – track iteration’s progress (day-to-day work from people), report impediments relating to people, make sure iteration’s commitment will be fulfilled, point bottlenecks in the delivery process.

The Customer – act as gatekeeper, protect people from distractions.

The Iteration – plan team’s budget (ideal hours), help customer with prioritization, motivate team, owns iteration planning and retrospective.

The Project – form a group of people working together towards a common goal (they succeed or fail together); aim for productive and happy team members and a satisfied customer.

Reference: http://tomekdab.blogspot.com/2009/03/ive-recently-read-essay-about-iteration.html

The following recommendations work as well for the team leader as they do for the IM.

  1. Keep close to the people. This is only possible in small teams where you regularly talk to the people.
  2. Keep close to the motivation, what do your staff now want from their career?
  3. Keep close to the changes, challenge the status quo and mediocrity.
  4. Keep close to the strategy – What is changing in the business?
  5. Keep close to the project – TL and IM both need to stay involved in the project as a Coach/Mentor/Water Carrier- Boulder remover.
  6. Keep close to staff performance – this makes mentoring and performance review more credible.
  7. Keep close to accountability vs. control issues.  Who needs to be delegated control.
  8. Keep close to the buzz – IM and TL need to trust each other and talk regularly.

To conclude, great inter-role, inter-personal skills and a tight working relationship is required to make this double teaming of the TL and IM work. 

I would really appreciate your comments, suggestions, ideas and recommendations on how I might improve this talk or if you feel that I’ve left something out (remembering that I only had 5 minutes). 

If you want more formal information about where the IM fits into this thing we call agile, the Agile Project Management course is one of the courses offered by the Agile Academy which covers it well.  (Editor)

2 Comments »

Can't see the wood for the trees?

Author: Cara Talbot

Introducing Agile to an organisation, as with any change program, means significant disruption. The way we do things is no longer the same. We no longer have our traditional rulebooks to clearly define what our roles are, how we’re supposed to engage with each other, or how we should go about our work.

This has heightened anxiety to some degree either consciously or unconsciously for almost everyone coming into contact with it. What’s my role now? How am I supposed to know what I should be doing? What if our team fails? What if I fail?

Most have dipped their toes in the water, and have grown in confidence as successes have been achieved. Some have quite radically removed some of the traditional roles altogether and claimed early successes. What risks might have they introduced critics would argue? It’s all a bit too early to tell. Some have turned into what is being coined as ‘Agile Purists’ where they will argue to the death about sticking to process over pragmatism. Perhaps this is because a natural inclination for some might be to seek new (Agile) rulebooks to replace the old; to firm up the ground beneath their feet and feel secure and stable again.

The irony is that debating at this level stunts productivity and can cultivate fear, uncertainty and doubt within their teams by challenging who should be doing what role instead of simply enabling the team to get on with the business of delivery. Teams can lose sight of their end goal.

My observations in attending the recent Agile Australia conference in Melbourne perpetuated this theory. No matter the viewpoint or appetite for risk, discussion threads resulting from the presentations and workshops were often on the following sorts of themes:

  • All design must be done up front/ no upfront design at all; get rid of the Architects!
  • Iteration Managers vs Project Managers. Get rid of the PMs; IMs aren’t really needed!
  • Business Analysts vs Technical Analysts; Subject Matter Experts vs Business Analysts; get rid of the BAs!
  • er… is there anyone left to progress the project?

Of course, there were also the sales pitches about the numerous methods of Agile we should be applying, although Scrum and Kanban seemed to be clear favourites du jour.

Perhaps, it’s a natural evolution of maturing Agile development for organisations. However, there appears to be a tendency to become overly introspective when faced with the challenge of change, rather than focus on what we are trying to achieve by changing. Perhaps we need to reassure people that their base skills are still valid and valued, we just need to work out how and when to apply them to achieve the Agile values of: doing enough to give the best bang for our buck; focussing on delivering benefit to our businesses quickly; being flexible enough to seize opportunities where it is sensible to do so… in other words, projects still need management (albeit there is a heightened, but not new, focus on coaching first, directing second). don’t get mee wrong though we still need to go into design; problems still need analysis; code still needs to be written and tested… and we need to figure out how to do all of this flexibly and collaboratively.

What was most refreshing to me during the conference was to hear the views of Martin Kearns (Agile Practice Lead from Renewtek), Neal Ford (Software Architect from ThoughtWorks) and Nigel Dalton (CIO of Lonely Planet). These three guys appeared to be in the minority in expressing what I feel being Agile is really about –

“…it’s just a guidebook guys, do what works for getting to your end goal.”

With all the Agile methods, tools, techniques and blurring of roles – there are two constants that run commonly between them all – the promotion of genuine collaboration; and of continuous learning. All roles bring value to the way we work. Alistair Cockburn has said: ‘people are highly variable and non-linear’ and as people aren’t software components – it inevitably introduces variability into projects. What’s great about Agile is that it fits process to people, not the other way around. Agile brings a different approach to process: the team is responsible for choosing their own processes, and as such no project will be the same, and no team will be the same.

We need to avoid the trap of holding ourselves up for too long by trying to figure out who does what activity within the project; and instead lift our eyes towards the project’s end goal. What are individual’s expertise – let them get on with it, don’t shuffle activities for shuffling’s sake. What are the team weaknesses? Get the team to collaborate on how to best address any gaps. Don’t introduce any unnecessary complexity. Think – what will success look like, and how can the team best work together to get there?

For those that are still seeking the new rulebook: http://www.Dictionary.com defines Agile as:

  1. Quick and well-coordinated in movement; lithe.
  2. Active; lively.
  3. Marked by an ability to think quickly; mentally acute or aware.

To me, this means that to be truly Agile you have to be agile! The minute you think you’ve got it right, you’re making mistakes. Agile is ever evolving, and what we see as Agile today is likely to bear little resemblance to what it will look like Tomorrow.

1 Comment »

Hi! Ho! Hi! Ho! It’s off to Agile conference world we go.

Authors: Craig Smith and Susan Akers

It seems timely to talk about content of conferences now that the “season” seems to be almost upon us. There are many great Agile related topics from a wide and varied group of speakers the world over on offer. A call for papers is like a call to arms but wouldn’t it be nice if more presentations could move away from all the fantastical things that Agile does and share more of what we have learned from our failures. There is a lot to be learned from our failures and isn’t that what Agile is about – “doing so, in a safe to fail environment:”?

As Edward Phelps says:
“The man who makes no mistakes does not usually make anything. “

You’ve got to take your hat off to Suncorp which while certainly acknowledged Agile leaders in Australia particularly in the financial and banking industry, were not afraid to showcase their pathway along a sometimes rocky Agile road with a case study presented by Jody Podbury (Suncorp) and Lachlan Leasman (Thoughtworks) at last year’s inaugural Agile Australia conference. They focussed on their journey adopting Agile in BAU. They discussed what they tried, then failed at, what they then tried instead, and its current evolution. It was the story of a transition from a directed and managed support group to a self-leading, self-governing and self-correcting team.

The great thing about the Agile community is that many of our worldwide conferences encourage experience reports where real people talk openly about their real Agile issues. And most of the time, talking to any of the attendees in the hallways opens up a wide discussion of corporate successes and failures that would have been hidden behind closed doors just a few years ago.

The problem however, is that most of these real world stories are dwarfed by the large number of self-serving or consultancy selling presentations that seem to dominate most technical conferences. There is so much “good news” noise out there about Agile that finding a gem from amongst the fool’s gold stories put out by the fan boys can mean putting your hard hat on to really go data mining.

Furthermore, presenters often talk about their sessions being open exchanges but most tend to be one way communication streams with minimal questions/comments.

What about the speakers taking some time to get real interaction and ideas from the audience of how they have overcome issues perhaps in an innovative way? We not only learn from our own mistakes but do also learn from others. As an Agile community we are very open to sharing our stories with each other.

Isn’t it now the time, as the rest of the world is starting to catch on to the Agile buzz, that we share our honesty with the wider world in a more collaborative fashion?

A parting thought:

“Flops are part of life’s menu. Everyone makes mistakes. High achievers learn by their mistakes.
By doing that, an error becomes the raw material out of which future successes are forged.
Failure is not a crime.
Failure to learn from failure is.”

– Unknown

2 Comments »