The Agile Tribe

Be Lean by keeping words to a minimum!

Author: Susan Akers

Imagine if we limited speakers to 20 seconds per Powerpoint slide for a total of 20 slides – yes – a total of 6 minutes and 42 seconds.
Read the rest of this entry »

Leave a comment »

Agile – What's the buzz?

Author: Daniel Luschwitz

Agile development is definitely the latest trend in software engineering. Over the past 18 months I have had numerous conversations about sprints, stories, sliders, burn charts, wall ware and all the other cool techniques that fit under the ‘Agile’ banner.

When you start to understand these techniques they all make sense so no wonder the IT community is starting to see the benefits that Agile development can bring to an organisation.

The main difficulty though can be ‘selling’ the idea to the wider organisation, but luckily, the solution isn’t hard to find – in fact it is printed as point number one in the Agile Manifesto:

“Individuals and interactions over processes and tools”.

Interesting point right? Believe in your people and empower them to have conversations – revolutionary! So here is my battle plan to make this happen:

  • Become informed.

Knowledge is power, so know how to answer the mirage-hurdles such as: “it doesn’t work with distributed teams” and “regulations mean that we need documentation”. Dispel these myths! Talk to colleagues who are doing it and gather some case studies. Even those pesky sales people that aren’t!

  • Create a buzz within your organisation.

In most cases I see, Agile development is being driven by the IT community so the first port of call is to inform ‘the business’ of what it is all about. If you sell it correctly then they will be driving the change! Think about what you would need to do if you were trying to convert to Waterfall from Agile.

Your ‘sales pitch’ would be something like:

“We are going to organise a team to ask a whole heap of questions about what you want. Once we think we are ready we are going to get started on putting everything together and in 6 months the product will be ready for you. If you want changes/additions along the way, we can do it, but you will need to either give us more time or throw more money at us to hit the release date.”

How much easier is it to say?

“We want you to be a part of the team that is developing this product. Every two weeks we will show you what we have done. You can then give us feedback about you would like and what you would like us to chance. We want to work on the items that are most important to you first up. If you want additional features along the way, no problem, we’ll show you what is left to achieve and you can make a decision on what is more important.”

Support your people with training and consulting and the results will come. Agile to me is a cultural shift in an organisation and first and foremost it is important to get everyone on the same page and manage this transition carefully.

The Agile Academy courses, Taste of Agile and Agile for the Business (choose your flavour) are fantastic ways to create the right buzz about Agile. These courses deliver the message in an informative and fun manner. Where else can you see your IT Executive playing with Lego and blowing up balloons?

As Kylie once sang “Everybody is doin’ a brand new dance now, I know you’ll get to like it if you give it a chance now…”

Daniel Luschwitz is a Senior Account Manager at Software Education, a training partner with the Agile Academy. You can contact Daniel directly at, 0410 455 040 or follow him on Twitter @Daniel_SoftEd.

1 Comment »

Agile is not a four letter word, but does go by many names.

Author: Susan Akers

As a non- technical Agilist I am often flummoxed by new terms that seem to be have been created by Agile technical people to talk about Agile and its practices and values. So I thought I would put together a little quick reference guide of terms that might prove helpful.

Please remember, that this is from my perspective and undertanding, so I’d be very happy to hear your comments if you have a better definition. I have completed some basic Agile training but the terms I am talking about here seem to be ones that people use on an operational basis. I also started thinking of providing a full A to Z first up, but it was too intensive for me, so here is what I have come up with, from A to G so far.

A: Agile – is a way of thinking and working. It requires a positive attitude towards collaboration with your immediate team members (or part of a broader team), an openness to embrace change and a willingness to act quickly. The goal being to produce workable solutions your customer actually wants, creating less risk and higher business value. This means quick returns (or iterations) so real results are seen in a matter of weeks rather than months or years.

A: Artifact. (yes, this is correct, not a typo). This is anything you produce during the development of a software or business project lifecycle. These could be – Templates, Diagrams, quick “How to” one pagers, or anything you can reuse for another project.

B: Brown Bag (or Lunch ‘n Learn). Usually refers to a lunch time training or information session (hence ‘brown bag’ to bring your lunch in, so can eat and listen at the same time). Some great examples can be found at:

C: Continuous improvement or Cha cha changing. If you can’t accept change, you might think you would hate working in an Agile environment. But, I’m sure that your team will think and talk about a project when it’s completed, and what went right and wrong and what you would do better next time. Congratulations! You have just conducted an Agile retrospective and are using the Agile practice of Continuous Improvement.

D: Do realise that Agile is not just about software development. Agile, as I mentioned under “A”, is a way of thinking about things which is why our business colleagues have taken to it. They have realised that they could use it on their own projects/tasks and gotten the same positive results about solving issues and continuous improving their process to make it easier and more successful the next time. They have also found that having a standup each morning has stopped the interminable wasted status meetings they once had.

E: Experience reports (also known as Field reports). Often seen listed at conferences. My understanding is that they are presentations where experienced practitioners talk about their hands-on experience and discuss case studies, the blockers they had and the lessons they learned from both their sucesses and failures.

F: Fishbowls. Normally this means getting 3-4 seats in the middle of the room (the fishbowl) with the rest of the team in an outer circle watching. Everyone takes a turn in sitting in the fishbowl sharing their concerns, asking questions, and also discussing proposed solutions. Usually one seat is left empty so that if anyone wants to join the discussion in the fishbowl they can sit in the empty chair.

To ensure there is always a seat vacant, an existing member of the fishbowl must voluntarily leave the fishbowl and free up a seat. The great thing about this is that it gives everyone an opportunity to speak so the discussion doesn’t get dominated by just 1 or 2 speakers. An example can be found at:

G: Go for the low hanging fruit. Make the quick wins. Don’t get caught up in the end solution – cut your project into small reachable goals (wins) along the way and do the easy and quick things to complete, first. Why? Because it makes everyone feel positive, and in spite of what challenges you may be facing you are also achieving!

Stay tuned for the next instalment of H to M. Feel free to send me your suggestions as well.

But for the time being:
That’s how Sue sees it! (Source:GLEE)


“Business value as a raison d'être? Or is decibel based prioritisation the answer ..?”

Author: Dean Coulter

I wanted to just put down a few points from my experience about what I believe it really means to provide value to our business in an Agile world.


  1. Agility has value for the whole supply chain, not just the IT folk! But how well do business operational general managers understand the benefits of agility? IT as collaborators with their internal business colleagues should be able to answer the question – “What does Agile mean for my client’s line of business, their bottom line, their ongoing success in getting their product/service out quicker and more effectively?”
  2. To me, the very core of what Agile means for business people is around the question – “WHERE IS THE VALUE?” This fundamental query guides prioritisation. If there is a demonstrable, quantifiable business benefit, then it’s a candidate for prioritisation. If not, move on, or come back when you’ve got one. This is the key to managing the eternal imbalance between IT service demand and supply. “In the kingdom of infinite demand, she who can prioritise is Queen.”
  3. The value focus leads to the next building block – don’t waste energy building stuff that doesn’t have a quantifiable business benefit. This may seem kind of obvious but “decibel based prioritisation” (wherein the loudest voice gets to set the top priority) is not quite dead yet!

In summary, setting agreed priorities + business value = good Agility.


Opening up an Agile window to let opportunity fly in – co-locating SMEs

Author: Cara Talbot

In my organisational experience to date the level of Subject Matter Expert (SME)’s co-location and engagement has strengthened from project to project. Thinking of how things were only a few years ago compared to our current state, there is just no comparison.

One project team’s perspective
We (my project team and I) have a current Project Owner and SME who both attend 95% of our daily standups – between them attendance is around 99%. We have a Programme Owner who, without invitation, has jumped onto our build environment to play with our online claims prototype, and then emailed the team with several suggestions and enhancements. 66% of the members of our Steering Committee attend 100% of our showcases.

Our Project Owner is such an advocate of the project that she has voluntarily presented work to date to various Managers and Executives in addition to and outside of our scheduled showcases and usability sessions. Sometimes this has been arranged without mentioning it to the rest of the team, which has presented interesting results when we’ve been testing and deploying – but hey, the enthusiasm and support from her of the technical team is to be commended! The team feels valued and by default collaborates more directly with her and other SMEs and so the ‘meeting of the minds’ is further strengthened.

We still have a ways to go, but how have we got to where we are? Often SMEs want to see results before they’ll provide buy in, so we can probably all talk of experiences of the chicken and egg scenario of how we can prove their co-location on a project will provide dividends prior to having them co-locate with us!

Keys and challenges to success
I can’t speak for other projects however for us it’s been, I think successful, largely due to seizing any opportunity to engage SMEs in value added Agile activities, so you can quickly turn around and demonstrate the results. We lost our Business Analyst recently (to our Sydney office. Ahem.) and had a lag time prior to having a new recruit join the team.

In the interim we had a half share of another Business Analyst who was also working on the support team. We therefore had a desk free, in the team space, for a half day every day. Our project owner agreed with our proposal that in providing a dedicated SME to cover this half day with the team, we could maintain progress during a vital period of development (beginning of sprint 3). Team velocity dipped slightly during this iteration as you’d expect with resource interruptions, handover and new arrivals getting up so speed, however by the end of sprint 4 our velocity had jumped by 13% compared to our average to date at that time, and a whopping 30% increase from our dip in sprint 3.

Part of that jump was also reflected in the drop in change requests coming across, although I could also suggest that that having a co-located SME seeing Agile development ‘in the raw’ provided a unique insight much more quickly in terms of understanding the impact that decisions can make on changes – the SME himself referred constantly to our focussing question (relating it to whether the change requests were adding value to the project/end user) … in addition, to turning around decisions of what was IN (and therefore what was OUT) much more quickly.

A genuine partnership has formed
Our project team is now back to being fully resourced, so logically we could have lost our SME … however, he still spends every morning sitting with the team, and helping out when needed.


Do you speak my language? Reaching a common understanding in Agile speak

Author: Susan Akers

I loved this term “a unified vocabulary” when I recently saw it in David Farkas’s article on How UCD and Usability can live together. His comments particularly the one below really hit home with me as I have been working on a particular project which seemed to me, not to be considering the user experience at all! I have sometimes seen this lack of a unified or common vocabulary in a team at the start of projects, particularly Agile ones:

“.. the breakdowns that exist in integrating User Centred Design and Agile exist as a result of miscommunication from poorly set or unframed expectations. As Agile and UCD further develop and members of each camp have training to both methods I see the miscommunication fading as a unified vocabulary and set of deliverables form”

To me training is definitely part of the answer but it’s not sufficient unless all parties are prepared to also change their attitudes. Coming from a business background, I was totally frustrated in trying to explain my expectations to my technical team because I felt that they were always talking ‘techo talk’ to me and not explaining what they were doing in plain English. Then I completed the Taste of Agile course through the Agile Academy.

What a difference a day makes! I learned that if I was to speak and understand a foreign technical language of storycards, iterations, stand-ups and estimations, I really needed some Agile lessons. These terms had all been just noise to me beforehand. However, just training the business is not sufficient for successful collaboration. Both sides have to change their communication style and I think this recent tweet @GreenHomeShop sums up what all parties need to learn and accept:

.. two people can look at the exact same thing and see something totally different. ~James Rhinehart~

In conclusion, don’t play the blame game, be like me and accept that Agile is all about building a unified communication bridge and getting over it with your whole team!

Leave a comment »