The Agile Tribe

Agile is a Fad!

Author:  Jonathan ‘Kupe’ Kupersmith

Jonathan 'Kupe' Kupersmith

Jonathan “Kupe” Kupersmith is Vice President of Brand Development, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at
(This blog was originally written on the BA Times blog site. It is kindly reproduced here with Kupe’s permission).
Agile is the hottest word in our profession these days. Go to any BA or PM conference and there is at least 1 session dedicated to agile. Even if the session does not have agile in it, you’ll hear the agile word over and over. On sites like this one, there are many blogs and articles written about agile. Here is the article that inspired me to write this post, Four Agile Tips to Eliminate Rework in Application Development.
 The article lists these four tips which are credited to agile methods.
  1. Collaborate – Involve multiple stakeholders in requirements definition.
  2. Be Lean – Quote from article – “Agile methods teach us that a 400-page document is not required in order for development to begin. In an agile environment, development can start with high-level user stories with perhaps one layer of detail added.”
  3. Iterate – Approach requirements definition in an iterative process.
  4. Visualize – requirements do not have to be written in paragraph form.

I agree 100% with all of these tips not because they are agile tips, but because they are smart practices. Before the Agile Manifesto was developed, I worked on teams that collaborated, were lean, iterated, and visualized. I wrote about this in a blog post last year, My First Agile Project. I would guess you have been doing this for some time too. This is why the word agile is a fad. In the near future we will stop having debates of whether you use agile vs. traditional approaches. We’ll just start doing what is appropriate for projects to drive results.

This spring I saw Scott Ambler speak and he said we don’t need repeatable processes we need repeatable results. What this says to me, is do what is needed to drive results.  Teams need to come together and determine what will work best to give them the best chance to deliver results. This is just smart.

The agile movement shook our community and made us all think about how we were running projects. It made us make sure we are focusing on business value. Don’t push for agile over waterfall, push for what is right for the project. Push for what is right for the business in the short and long term. Even though I think the word agile is a fad, the agile movement is definitely a trend.

All the best,


Don’t forget to leave your comments below.

Leave a comment »

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 »


The Definition of Done

Author: Susan Akers et al.

The Definition of Done is an interesting one.  When is Done, actually Done?  While we say that the team including your customer should all agree on the same definition – this can be a challenge.

For example, a developer would probably describe the Definition of Done as “the minimum work that needs to be done to make the piece of code related to the story successfully integrate with the build” or something but how do other members of an Agile team see it?

According to a product owner, it may be “when they get what they have asked for”

For UI designers – and yes, they should be part of the Agile team right from the start.  It may be all about DONE DONE DONE”.

  1. Done – with writing the code and unit testing it
  2. Done –  with having it functional and integration tested…by the tester mainly
  3. Done – with UAT and accepted by the user.

All three DONE states have to be passed and only then is a story DONE. A story card can be broken down into multiple tasks if there are specialist skills to be applied ( i.e. Mainframe build, FE build, UI design) but the card is only DONE when all tasks are DONE, DONE DONE.  We would not write a story card for a UI designer separately…hence it is not relevant to them separately. The UI bit would be a task on one or more of the story cards and the card will not be done till ALL task are DONE and DONE and DONE.

A team may feel it is done when:  “A story is done when we truly believe that we will not have to touch it again”.  Simply – when the team thinks it is finished. This allows for undetected defects pushing it back. Typically, it’s after UAT.

The Agile Academy’s Definition of Done video explains in plain English how the different roles see Done and I would certainly recommend having a look!   Also feel free to share your comments and thoughts with the rest of the Agile Tribe here and on Twitter (@theagiletribe).  So what’s your Definition of Done???  Should it be different for different roles?

1 Comment »

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.


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)


12 Agile Adoption Failure Modes with Jean Tabaka

Author: Renee Troughton (@AgileRenee)

I had the pleasure on the 9th June to see Jean Tabaka in action at the Brisbane YOW night. Topic in reflection: 12 Agile Adoption Failure Modes.

My interest was immediately peaked when the opening question was:

“Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.

What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.
Read the rest of this entry »

Leave a comment »

The Evolution of Test Driven Developers

Author: Peter Sellars (Reprinted with thanks to Peter)


Test Driven Development (TDD) since its rediscovery by Kent Beck in the early noughties has led to an evolution in the information technology developers of our species. So where on the test driven developer evolutionary tree do you or your developer kind sit?
Read the rest of this entry »

Leave a comment »

Just give me a 'G & T'!

Author: Susan Akers

We talk about having a common language in the world of ‘Agile’ so that all members of the team (both IT and business) have a shared understanding. However, we still can’t seem to get away from the overuse of acronyms. I saw a new one this week and got to thinking about how clever are they really? 
Read the rest of this entry »


Agile Q&A: Wording User Stories

Author: Craig Smith

A former colleague contacted me the other day with a question along the lines of: “I am working with some guys who are looking at creating User Stories and there is a lot of discussion about how they should be worded.”
Read the rest of this entry »

Leave a comment »

Why so little good Agile?

Author: Shane Hastie (reproduced from Shane’s blog)

Today I gave a talk at the NZ Government Testing conference in Wellington. I presented a case study about how the Farm Systems Division of Livestock Improvement Corporation have adopted Agile methods.

I told the story of Team Awesome (they choose the name themselves), how their practices have changed and the measurable benefits that have resulted from their new way of working:

  • Massive reduction in residual defects
  • Increased team satisfaction
  • Shorter time to market
  • Increased customer satisfaction.

Read the rest of this entry »


'A Rose by any other name?'

Author: Tony Ponton

That’s not Agile!

You haven’t dotted the I’s, crossed the T’s and conformed to this checklist!  You’re not following dot point 27 of document three! Agile is only for software development! Every time I hear statements like this it perturbs me greatly, they are usually repeated with such conviction that I know I have to set about demystifying these rumours lest they continue to grow.
Read the rest of this entry »