The Agile Tribe

The path to Agile

Author: Susan Akers

 Two of the most common questions I get asked as the Agile Academy Advisor are:

“How can I start my Agile journey? 

What type of training can I get?” 

 So I thought perhaps it was about time that I put something together in one spot to make it easy for people to see a clear path ahead of them and feel confident in moving to an Agile way of working.  One way to see what training might be useful is to have a look at our role based Training Roadmap and then read the course overview to make sure that you have the necessary pre-requisites.  The roadmap shows the recommended courses and pathway.

The Agile Academy has also produced a number of artefacts to complement our training courses and give budding Agilists an opportunity to have open access to easy to understand material.  These include our Agile in Practice Help Sheets which cover a number of Agile practices and techniques.  Most of these also have a complementary video which explains more about how each of these techniques can be used. 

All the very best on your Agile journey.  Don’t be discouraged if your path becomes a little windy, there are many resources to guide you and if you have any questions at all around Agile or training please feel free to contact us directly.

Leave a comment »

What's your role in an Agile team?

Author: Susan Akers

 This is an issue that many people face working in an Agile team particularly those in the role of Project Managers or Iteration Managers

Common questions around these two roles can be – 

  • Are they the same role?
  • Should the Iteration Manager just be someone from the team?
  • How much time should be spent on being an IM? Full-time/part-time?

To help answer these questions and more, the Agile Academy has produced yet another handy Agile in Practice Help Sheet on Agile Team Roles and an accompanying video of the same name for those who want a bit more information about the difference between being a Project Manager and Iteration Manager; as well as seeing what other roles should be part of the Core Team and Extended Team.

1 Comment »

Agile's Secret Sauce – Part 2

Authors: Tracey Kay and Julian Coldrey

In part 1 of our blog our argument was that putting the right culture in place was essential for project success and without the right culture, Agile practices could not work.

Mixing the right culture

In part 2, we don’t know if it’s possible to fully describe all aspects of the ideal Agile team culture but we are going to have a try at describing what cultural themes and behaviours stood out as key contributors in our project team. We do this with the suspicion that the ideal Agile culture would look different for each team anyway.

After all, each group negotiates its dynamics according to the individuals involved and what goals are sought.

On our Agile team though, these are the elements we found lead us to project success:

  1. Humbleness. Of all the behaviours that mark a healthy Agile culture, we think being humble is the most important. After all, continuous improvement is one of the most productive characteristics of working Agile, and it’s hard to improve if you aren’t mindful of how much better things could be.
  2. Shared accountability. When everyone feels accountable for outcomes, people are more likely to step up, assist others, hold their team-mates accountable, and generally behave in a way that is aligned with project success.
  3. Intense collaboration. There seems to be a direct relationship between the intensity of collaboration, and the speed with which we’re able to power through challenges.
  4. Freedom to challenge. A team that continually challenges itself to improve and find better solutions usually does. This may not be a revelation, but it’s surprising how many teams adopt a “good enough” approach to their work, and how the solution can be as simple as remembering to ask “why?”
  5. Flexibility. We’ve gained so much from people being flexible with their roles and stepping in to fill gaps where required.
  6. Stepping up. The culture on our project has encouraged people to step up and show what they’re made of. As an aside, succession planning is a breeze in this kind of team environment.
  7. Energy and drive. Even the best run projects can be a slog at times. The team’s vibrant sense of motivation and fun has enabled us to push through these periods and come out the other end still smiling.

Feel free to let us know if we have missed any that you have found really works in your team as we are a team of lifelong learners as well and are always looking for ways to improve.

So in part 3 of our series on Agile’s secret sauce, we’ll be outlining some practices we implemented that helped drive this team culture.

1 Comment »

It's our Birthday. Agile Academy turns 1!

Author: Susan Akers

Twelve months has just flown by since the external Agile Academy website was officially launched by Jeff Smith, Suncorp’s BT Group Executive last March with 30 IT executives attending the unveiling of the new website at a breakfast event in Sydney.

The year started off with a bang, with the Agile Academy winning the Award for Service Delivery and Training which recognised the excellence and innovation in the provision of ICT Services at the ACS ICT Awards. It was a fantastic testament to how unique our curriculum is in the Agile space. The fact that it is an integrated approach covering the entire solution development and management landscape rather than just piecemeal 1 or 2 courses and there is a distinct training path for novices to experts is a real world first and we are rightfully proud of it!

birthday_graphics_09 -flashyprofile

Over the past year, the Agile Academy has also further committed to providing open source material, knowledge sharing and capability development in the Agile space to the broader Australian ICT market as well with the release of a number of Agile Practice Help Sheets whitepapers, and recommended readings on-line. We have also invited potential clients to visit our leading Agile business and software development projects on-site so that they could get a feel for themselves about Agile in action. Our regular quarterly Meetups in Brisbane have also received a great response and we recently helped launch the local Sydney Chapter of the Agile Alliance.

In addition, we‘ve more than doubled our external course offerings in partnership with our founding training partner, Software Education. We knew also that our proactivity in offering innovative courses would also pay off. An example of this was at the inaugural Agile Australia Conference last year when over 50% of the comments and questions asked of our staff on the Exhibitor stand related to our new courses including – Agile for the Business and Agile for Legacy Applications to meet a need that just wasn’t being met. It was exciting to be able to see what a relief it was to these conference participants when they saw that they hadn’t been forgotten and an organisation like the Agile Academy had recognised that they too needed training in Agile!

The Agile Academy website continues to act as the main knowledge hub to share Agile knowledge to the wider community through free access to our course overviews, whitepapers, articles, news and events around our Agile learnings though we have also actively engaged in using a range of social media such as Twitter, LinkedIN and this blog in order to encourage people to share their insights and learnings about their experience with Agile.

There has been a major cultural shift within our company with the adoption and advocacy of Agile over the past 12 months and is now being led from the bottom, middle and the top. We have a lot of offer but we still know we have a lot to learn, so here is to our second year and we hope you’ll join our network and celebrate our growing achievements on our next birthday.


Who said a CFO can’t be Agile!

Author: Byron Costas

I work in a Chief Financial Office (CFO) as an analyst within a technology services business unit, where Agile has been adopted as the principal project management methodology. Our CFO made the conscious decision that we as a division should also adopt Agile principles in order for us to better understand our internal clients and their business.

  • We have real-time portable big visual charts depicting our complete program of work; i.e. pieces of work from Concept through to the Deliver/Deploy stage;
  • We have daily stand-ups, which have proven to be invaluable in meeting reporting deadlines;
  • We do retrospectives for major pieces of work;
  • We have embraced other Agile and Lean techniques such as MoSCoW;
  • We have actively undertaken Agile training with the Agile Academy (I’ve already completed 4 courses myself and aim to do more); and
  • We have great leadership support.

The biggest realisation for me was that Agile is more about the people rather than strictly a project management methodology and its fundamental principles are equally applicable to technical or non-technical environments. I’ve seen firsthand what using Agile tools and techniques can do i.e. make a great team become an even higher performing one.

We are all aware of what’s happening around us; who is responsible and accountable for a piece of work; and assist each other wherever possible. This has resulted in mutual and trust; fostering an environment of honesty and transparency.

It has not all gone smoothly of course but with mutual recognition and belief in the success that Agile brings, a momentum for positive change and value-add has continued to build. This working philosophy has also extended to the creation of a Passion Board, connecting team members with similar interests fuelling tribes of passion!

Much to our surprise, we even have people from other areas of the business come and check out our various story walls.


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 »

Teaching an old dog new tricks – Trick No. 3

Author: Nic Woollett

As part of our ongoing Agile journey in the mainframe/legacy environment, Acceptance testing is next in our list of our three ‘tricks’.

Acceptance testing was another big change to the way we normally operate in a mainframe/legacy environment. Acceptance testing was fully automated by using scripts: scripts run for each day to perform online maintenance, create files for the batch and then to validate the data post update. We actually developed a new scripting tool that enabled the testers to create test scenarios in a easy to use interface. The scripting tool then build executable scripts from the tester generated test scenarios.

When using scripts we required a testing region that could be restored back to a base point for each acceptance test run. When a test is built it will be run in every acceptance cycle thereafter – ensuring constant regression testing. Again, this offers a level of robustness above the standard testing approach where after a test is performed & accepted it is ticked off & (more often that not) forgotten.


Despite some initial scepticism that Agile could not work on a purely mainframe project – what with moving targets, short iterations and aggressive delivery times – we agreed from the start that we would stick as closely as possible to pure Agile. Whilst we are not LIVE yet I don’t think we would be as far along as we are now under waterfall and I believe the product we install will be much more robust under Agile.

What I learnt:

Formal system and user testing have both proven to be ideal subjects for automation.

1 Comment »

Teaching an old dog new tricks – Trick No. 2

Author: Nic Woollett

This blog is the second part of what we have learnt as mainframe/legacy developers while adhering as closely as possible to pure Agile principles. In order to do this we have tried to make a series of fundamental changes to how we operate.

So the second trick we have used on our Agile journey relates to Build and Unit Testing.

This was where the biggest shift came in our mindset as mainframe legal programmers. With iterative development you have to have repeatable testing – otherwise you’ll be stuck in an endless cycle of regression testing. Also, locating or manipulating test data can be a labour intensive process and in any case. Very rarely is all logic in the program tested.

A program could be changed in multiple stories and within each story only the changed portion of the program should require to be tested – regression testing should be automated. So, for our project we needed to:

  • Take away the need to locate/configure test data for each code change
  • Automate regression testing
  • Be able to target specific code to test
  • Make every test easily repeatable.

We did this by building a unit test framework – the first and probably only one in existence for Hogan. The framework consists of various tools and utilities that we developed for the Agile process. Broadly, each program requires a test program to drive the unit testing of this program. When run in the test framework the program can be tested in isolation and it requires no specific environment data – such as files or databases. The program can be tested over and over without the need for any user intervention.

The test framework (named the HUTF – Hogan Unit Test Framework) is now at the tried and trusted level and whilst initially it adds to the development time, when a developer is conversant with the tools they should be able to code and unit test much more efficiently. We also automated unit testing – a daily run was set-up to test all the test cases – a list that grows with each story. A report is generated and should any test fail an email is sent to the development team highlighting the failure(s).

What I learnt:

Developers spend too much time doing user acceptance testing under the name of unit testing. Using a test framework greatly cuts unit testing time allowing developers to do more developing.

Leave a comment »

Teaching an old dog new tricks – Trick No. 1

Author: Nic Woollett

I’m currently working on an in-sourcing project that involves only mainframe legacy systems. We’re attempting to stick as closely as possible to pure Agile principles. To get the most out of Agile we had to make a series of fundamental changes to how we (mainframe legacy programmers) operate.

Our approach took three parts:

The first of these was – Story elaboration

This was interesting – not using the waterfall method of waiting for fully described business requirements was initially a challenge. Developers were required to be fully involved in the elaboration process & this lead to a greater understanding of our business needs. It was a fundamental shift from “tell me what you want and I’ll build it” mentality.

It was quickly realised that we weren’t going to get the full story fleshed out in one elaboration session so the mentality of “build and show” was encouraged. This is iterative development within iterative development! It’s much better to be able to show the team something than theorise. After a few tweaks here and there the story is completed to everyone’s satisfaction – that renders the old waterfall post-implementation complaint of “that’s what I asked for but not what I wanted!” moot. After a while a common understanding takes over and (as a developer) you start to know what the business will want.

What I learnt:

I don’t always know what’s best for the customer and the customer doesn’t always know what they want. The best result comes from a show and tell style collaboration and co-location is a must.

1 Comment »

Apologies to the Scrum folks …

Author: Andy Marks

I had the pleasure recently of spending some time with Martin Fowler talking about Agile Adoption. One of the topics we covered was the importance of experienced people to a successful adoption and how time is a necessary but not sufficient prerequisite to gain this experience. We used Malcolm Gladwell’s thesis in Outliers to provide some extra support to a notion I think we all fundamentally believe in.

Part of this topic included a lighthearted snipe at the CSM certification from the Scrum Alliance and how ridiculous it is to assume any competence in Scrum after only two days of training, let alone having the audacity to apply the term “Master”. Thankfully the audience in all these sessions saw the tongue-in-cheek nature of these comments and we managed to draw a number of chuckles each time.

However, because I see no correlation between being CSM0-certified and having any level of competence in applying Scrum…

  • This does not imply that all CSMs are complete nuff nuffs. “No correlation” means that you cannot make any statement about one given the other. I’m sure lots of gun Scrum people are CSMs, but it’s got nothing to do with the CSM training in isolation.
  • I hold nothing against Scrum itself. Applied appropriately and with the correct amount of technical rigour in the trenches, I think Scrum can be as useful to a project as any other form of Agile.
Leave a comment »