When Suncorp started down the path of rolling out its agile program over four years ago, it was viewed by many internally and the industry with much scepticism and angst, yet now it is approaching mainstream adoption in the industry.
One of the key challenges of becoming agile was improving our approach to testing and quality.
In this talk we will talk about why we had to change, why we had to improve the “speed to cool” in relation to testing, our challenges and approach and our blueprint for the “future tester” at Suncorp.
Like our agile journey, our vision for testing has been regarded as ambitious, so join us to hear why we believe raising the profile, empowerment and skillset of testing is critical to our (and your) future success.
There has been a lot of discussion recently about the tension inherent in the Agile Manifesto value “individuals and interactions over processes and tools”. This item examines some of the points that have been made.
Craig, Tony and Renee talk about Lean Startups, Tony’s Agile training in India and great places to work, discuss Quotable Kanban and solve a listener problem, all in 50 minutes!
AgileTODAY is a publication associated with the Agile Australia conference that is run by SlatteryIT. It is published quarterly and I have been lucky enough to have articles in the first two editions.
With 15 years of software development and eight years of Agile practice under his belt, Craig Smith is an experienced and vocal advocate of the Agile methodology. He has regularly spoken at both the global and Australian Agile conferences, and currently spends his days as an Agile Coach at Suncorp’s Agile Academy.
Craig is a Certified Scrum Master, a member of the Scrum Alliance and Agile Alliance, an advisor to Agile Australia, and will be speaking at Agile Australia 2011.
Everybody starts their Agile journey somewhere. What was your ‘a-ha!’ moment?
My a-ha moment was in the days before many folks were even calling it Agile in 2001 – 2002. I worked on a project to write a lending application written in Java where we overtook a small meeting room, started writing tasks and designs on a whiteboard, split designing screens down via CRUD and core functionality and we paired and worked as a team to get things done. I could never go back after that. What has been your greatest challenge when introducing Agile to an organisation?
How did you overcome it?
In the early days it was trying to get people to take you seriously, as not delivering reams of documentation at the start of a project was seen like being a cowboy yet we were delivering faster than the teams around us. It felt much like working in a bubble because when we went outside our team environment we had to fall back to the waterfall processes used by the rest of the organisation. When Jeff Smith joined Suncorp, it was refreshing that someone in higher management had similar views, and since that point it has been a challenge to fi nd approaches to make our IT teams (and now the entire organisation) to work more effectively.
What is your favourite Agile-related quote?
I am always having to remind people that “our job is not to do quality Agile, it is to deliver quality software or solutions”. We just use Agile values, principles and practices to help us do that. I am quite concerned how much the term Agile is overloaded or used as an excuse by many people now, so have started a movement to come up with a new label, and joked we should call it “raccoon”. (in hindsight I should have come up with a better name!)
What is the strangest situation you’ve applied an Agile principle to?
It’s amazing how many situations the core practices of stand-ups, retrospectives and Big Visual Charts are applicable to. I fi nd it more amazing that when getting together to plan work with other Agile coaches or working on different Agile conferences, how often I have to remind people to visualise their fl ow or do a refl ection on progress.
If you could have a total career change, what would you be?
I never set out to work directly in IT, as I did a dual IT – librarianship degree at university. Part of me still wants to tick that box at some stage. But if I could fi nd a job that I had the skills for that related to my love of motorsport, that would be awesome.
What is your favourite thing on your desk right now?
I don’t have a desk, so I live out of a backpack (one of my colleagues calls me “the turtle” because I carry my desk around). So when I do fi nd a real desk, a power pack is usually pretty good. As for the cool stuff, I have a Spongebob Squarepants and a bunch of Simpsons characters on my desk at home!
Volume 2- September 2011
In this edition I wrote an article entitled “The Wow Starts Now”
This year marks the tenth anniversary of the ‘Agile Manifesto’. This historic document was the culmination of the ideas of 17 passionate guys who got together on a mountain outside of Salt Lake City with the aim of focussing on delivering quality software rather than following mundane process.
This document was not the invention of Agile, as approaches like XP and Scrum were already around at this point, but it was the document that gave us the label ‘Agile’.
In the years since, we have seen the rise and rise of the adoption of Agile methods. However, while its core values and principles have remained the same, many new and improved practices have evolved.
We saw this in June this year when we held the third annual Agile Australia conference in Sydney. It was full of buzz and enthusiasm from the 700-plus attendees and it brought home to me what I appreciate most about being part of the Agile community. The fact that everybody – both your friends and competitors – are willing to share their experiences, good or bad, is something that I am sure would not have happened ten years ago.
On the flipside, one of the criticisms I have heard of late, is that there is no “WOW” in the Agile community anymore.
This got me questioning. Where has all the “WOW” gone?
I think in part, Agile is now seen as having well and truly crossed the chasm into mainstream. However, have we gone so far that have we have actually jumped the shark?
Judging by what I have seen at this and other recent Agile conferences, there is in fact “WOW” happening everywhere. You just have to notice and appreciate it.
These range from small examples like the different ways that people tackle retrospectives or organise their iteration planning, right through to innovative approaches to testing and deployment. We need to bring these innovations out of the shadows and shine a light on them, and not be too quick to dismiss them.
My thoughts are that we need to make sure that people who are still on their Agile journey have some basic practices and approaches to build their Agile foundation – which is a huge “WOW” on its own. For the rest of us who have made the leap, we need to remember the twelfth Agile Manifesto principle: “
At regular intervals, the team refl ects on how to become more effective, then tunes and adjusts its behaviour accordingly.”
In other words, we need to continually adjust and share our findings, and every now and then we might just come up with a “WOW” moment. That’s how practices like user stories and test driven development were invented.
My challenge to you, reader, is what is your ‘WOW’? Sharing our experiences, good and bad, is what makes the Agile community great. We need you to share your war stories and your improvements on existing processes and practices (and if you do, we welcome you to share it at the Agile Australia 2012 conference!)
To paraphrase Martin Fowler in his closing keynote at Agile Australia 2011: If you say Agile is no longer relevant, then essentially you are saying you are happy to go back to the ways of the past. If you have truly used Agile in your organisation or team, then you would agree there is no going back – and that is the greatest WOW of all.
Craig Smith is an Agile Coach at Suncorp and an advisor to the Agile Australia Conference.
My presentation from Agile 2011 that I delivered with Greg Smith called “Agile 2.0: Rebooting a Raccoon in an Imperfect World” is available on Slideshare.
On this 10th anniversary of agile, our community is struggling to address the issue of how to take experienced agile practitioners to the next level, while still providing training and tools to support those who are beginning their journey. With the “agile” word getting so overloaded, the challenge is to continually innovate without assigning labels. In this talk we will discuss how to use the best of traditional, lean and agile methods to suit any team and showcase numerous patterns that demonstrate the best process to use is often a mixture of traditional practices and new innovations.
Some of the comments on Twitter included:
@teradee: watching @smithcdau speak on “rebooting the racoon. Craig has this stuff nailed. A bright spot in our community #agile2011
@teradee: Listening to @smithcdau talk a on the Oath of Non-Allegiance via @TotherAlistair Thinking this needs more shine #agile2011
@theagilepirate: Look up the manifesto manifesto – we have enough manifestos Kumquat, raccoon is a community #agile2011
@codingbynumbers: @smithcdau gives birth to #racoon at #Agile2011 (but we know it was conceived on @codingbynumbers)! http://t.co/CyvgOer
My presentation from Agile 2011 that I delivered with Adrian Smith called “The Speed To Cool: Agile Testing and Building Quality In” is available on Slideshare.
Ensuring that the approach to testing and quality is understood and appropriately valued in an agile world can be a struggle for many organisations, especially when resources are limited and our customers are expecting business value in a timely manner. In this session we will define what quality means and share a number of tools for measuring it, discuss approaches to improving the skills, empowerment and role of testing in the organisation and share why testing is the coolest role on the team and why it is everyones responsibility.
Some of the comments on Twitter included:
@BrianGress: We tend to test only what we can see. #agile2011 @adrianlsmith
@tonyrockyhorror: @smithcdau Speed to Cool was best talk I’ve seen all week. It will take a mighty effort to top it. #agile2011
The final day of Agile 2011 in Salt Lake City was keynote day but not before a couple of announcements. Next years conference will be organised by Mitch Lacey and held in Grapevine, Texas and a number of presentations were videoed (including one of my talks) and will be available over time on the Agile Alliance website.
Finally it was officially announced that my good friend and colleague Shane Hastie had been elected to the board of the Agile Alliance (a first for our little area of the world!). Here are my notes from the keynotes:
there are two mindsets – fixed and agile – determines everything we do – determines goals, reactions to failure, belief about effort and strategy, attitudes towards others successes
we can continue to grow, you can’t measure someones potential with an IQ test
belief about yourself affects belief about others – we are hardwired to judge and stereotype others, fixed mindsets do it on very little evidence, agile mindset still does it but are less positive/negative
bright little girls are typically praised constantly
bright little boys are typically criticized or reprimanded
organisations have a mindset as well
Enron had a fixed mindset to hire the best talent – “rank and yank” – only keep the best
Southwest are about people not planes – don’t hire for IQ, but for attitude and learning
Day 4 at Agile 2011 brought a full day sessions full day of sessions followed by the conference dinner. For the first session I used the law of two feet and landed in three different sessions.
Stages of Practice: the Agile Tech Tree
Arlo Belshee and James Shore led this hands on session to build a technical tree of agile practices. I didn’t stay for long, but I was interested in the output, which I found hanging on the walls later in the day.
Steve Denning (author of a large number of leadership books) delivered this presentation based around a blog post of a similar name that I sat in for about 30 minutes. His presentation is available here.
delight is happiness, joy, customer success – everybody has a story or understands this concept
identify your project that you wish to delight – who is your customer?
what do customers say they want? – warning! they don’t always know eg. New Coke
what is it that core customers might not like about your product? eg .why they made the Nespresso machine because people did not like cleaning up, need to get inside their head to understand what you need to change
Agile From the Top Down: Executives Practicing Agile
Jon Stahl delivered this session, and I wish I had been there for this one all the way through as his presentations are always entertaining and informative. His slides are available here.
get HR to create their own room to map the organisation and look for patterns – finding the truth isn’t simple but putting stuff on walls creates conversation
create a tool wall – who cares what tool you use, as long as you are adding value
get the practice vocabulary up on the wall – matched with a booklet with more detail
when tracking practices move away from traffic lights and use smiley faces to track how people are feeling – don’t care about if they are doing stand ups but how are they working for them – good way to figure out where to send coaches, where the frowns are
transparent leadership – post and show your people what roadblocks you are working on
everybody wakes up everyday thinking they are doing the best thing they can – as a business the executives need to check each other to make sure they are working on the most important thing and allow each other to question
Relish – the only way the customer will read Cucumber tests
two way mirrors – ensure the users are integrated into development and they can use the software, outside the building
good coders find stuff hard – easy to Cucumber test the full stack but the build time blows, unit tests are hard but are fast, so limit the amount of cucumber tests and isolate them
features rot if the Customer does not read them or not exposed via tools like Relish
manual testers duplicate automated tests – expose features, pair, give Cucumber ownership to QA
how to test lots of permutations – pairwise testing is OK, or just automate the happy path and one scenario and manual test the rest
metrics – JUnit Max to predict probability of failure
Limited Red – calculates the probability of Cucumber failure to improve the way we work – found features that never fail – just keep them in nightly build – means a long build usually fails very quickly
use JMeter to check everything is up like a tracer bullet – eg. a row has appeared in a table
got 8 hour build down to 20 minutes by distributing over 24 EC2 nodes – but think we were solving the wrong problem
slice up the architecture and have thin tests to test them
Spork – helps to speed up the start up time of an application – hard to know whether to reload and it adds a lot of overload at the protocol layer, so almost as efficient to run the tests
people have core responsibilities but we all meld in our roles to be one team and deliver
I enjoyed this session, particularly as I read about Joseph’s company in Specification By Example. I am excited about the prospect of a tool such as Limited Red as well.
Telling Better Stories with User Story Mapping
Jeff Patton led this session to a packed room that included a live appearance from his children! His slides are available here.
how to change the world – start with an idea which is product > feature > specification > requirement
learnt that requirement means “shutup just build it”
outcomes result in impact – agile is to maximize outcome and impact we get
stories are a conversation about the future
stories are 5c’s – card –> conversation –> confirmation –> construction –> consequences (when we realise our ability to predict the future sucked!)
Kent Beck called them stories because they were meant to be heard
need to figure out the who, what, why – this is the richness behind the story
add a short title, add a description (story template), add notes, specifications and sketches and write acceptance criteria before writing software
stories shrink in size and grow in detail as they travel through a pipeline
start with capabilities or features (understand value) –> break to release size stories– > upcoming iteration stories (priority, UI design, business rules) –> break to iteration size stories (details user acceptance tests, small enough to fit in iteration) –> completed bits of software
user story mapping – based on story mapping in films
ultimately we have big things that break down to little things
Build story maps by:
talking to real users
brainstorm user tasks to help them organize
research and build from a narrative
discussions with users in front of a map drive out conversations
plan incremental releases as a team event – developers will actually read the plan
start talking about adding stickies and notes, finally get a fist of five for confidence
don’t prioritise user stories by ROI – target a user segment
like ripping a $5 note, the small stories are not valuable (Jeff actually ripped a $5 note to illustrate the point)
Finally, Jeff has a User Story Mapping book in the pipeline which looks really interesting. I have had the pleasure of meeting Jeff a few times and always enjoy his presentation and learnings, and I am keen to give these learnings a go in my next storycard workshop.
Flirting With Your Customers
Jenni Jepsen delivered this presentation, the slides are available here.
We started with an exercise – 3 things that make a great project – trust, hard work, common goals, transparency, clear direction, grown ups, togetherness, support, communication, budget, right skills, creativity, quality, teamwork, fun, support
We then discussed 3 things that make a great romantic relationship – trust, communication, clear expectations, respect, common goals, honesty, integrity, similar values, enjoy spending time together, depth, support, compromise, patience, back rubs, teamwork, equality, chemistry, humour, passion, sacrifice
there is a lot of commonality between projects and a relationship
flirting is about making people feel valued
need human touch to thrive, keeps immune systems strong
people who are happy and feel valued at work results in increased profit
introverts need to take care of themselves, take energy from within – they can flirt but it takes energy
extroverts thrive in social situations – if your customer is an introvert they may not share your energy
The 8 steps are:
radar – makes you aware of the people around you, takes confidence
target – figuring out who you want to connect with in an organization, who has the real power
move in – show interest, practice your opening line – make eye contact, making the person feel like they have knowledge, makes them feel valuable, interactions become richer because of this
back off a little – the other person may not be ready for the interaction, give the other person space
open up – being honest and laying it out, you have now created a comfort zone, you are also making yourself vulnerable, there might be some back and forward bargaining here
dance – have a little fun, create conversation – lunch, cook together, virtual coffee over Skype, celebration to mark a milestone, dinner club
get real – go through a crisis together, if you have flirted and built a relationship
enjoy – enjoy the relationship
have a list of questions to get over the anxiety
all good steps for people you manage
body language is 93% of communication
Conference Party
The conference party was entertaining as always. Here is me hanging out with Alan Bustamante (who I worked with on the reviews) and the gang from Seapine Software
Scaling Software Agility: Advanced Practices for Large Enterprise
Dean Leffingwell is the author of Scaling Software Agility (which was written in 2006 and, in his own words, the world has changed since then) as well as Agile Software Requirements (which is really about portfolio management). Dean presented this session, a copy of his presentation is available here.
scrum is designed for small teams and makes no claims for scale
scale might not work, you can make it work
economics and technology have changed to make agile work
Not everything is a user story:
user stories came from XP, builds the user right into the requirement
lots of teams have their own stories in their own sprints
if something is in the backlog we might do it, if it is not in the backlog we won’t do it, anything that needs to be done goes in the backlog
best code comes from XP shops – it’s a form of hygiene, like brushing your teeth
the user story model lacks context – the things around it
at enterprise scale you have a large, large amount of stories but how do you reason about that and get the context
we need an additional level of planning – features which get decomposed into stories
features need to fit into potentially shippable increments as well, because they need to ship
stories need to get tested, as do features and non-functional requirements
use epics to describe features that are too fine grained at the enterprise level – may be implemented over long periods, even years
investment themes represent the budget allocations that drive the authority – at a program level figure out your epics that make up 17% of the budget, for instance
Think agile programs, not just agile teams – manifesto does not mention teams at all
there are lots of teams in the enterprise
need to train everybody, but that is slow and expensive
regular release train, build it this way even if if the customer / factory is not ready for fit
change value system from plan driven to value/vision driven – move from Clarity driven estimates which we then fix to fixing a date which we strive to meet
in software industry we always miss dates, build credibility by meeting dates
most teams are overly optimistic
quality needs to be built in, but features need to be variable
everyone needs to be on the train – waterscrumming does not work
hindsight brings us perspective
cadence alone is not enough – worst nightmare is not the facts but the false sense of security that you are going to deliver
slowest component drags the train – if you have a VP of system integration you are already screwed
make sprints the same length – two weeks is a good cadence, three weeks is too long, you can’t figure out when you should start testing
have regular system wide integration – use PSI (potentially shippable increment) to ensure you have a product, use hardening sprints for the things you can’t do in a normal sprint and let the team catch up
release train process – when you have an asset that adds customer value, ship it or ensure you have a asset that you could ship – it could save you with large maintenance renewals
pacemaker is release planning – need a full day or two for release planning – if you can’t spare that then plan badly – also gives us full alignment, a good point to get the architects involved because at this point you can make a change – plan using stories because that is the teams currency
scrum gave us a framework for sprints – plan and commit on day 1, execute for 8 days, demo and retro on day 10
at enterprise level raise this to the PSI level – plan and commit at the program level and demo and retro together at the end, sprints at team level in between (a program is usually 5-10 teams)
do a one week all in training for the team and then fire straight into release planning – then coaching is in context – don’t have good experiences with teams that go ahead without coaching support
take into account that your first sprint will be a little rough
Enterprise systems require intentional architecture – it matters!
refactoring is part of agile, list on the wall and get the product owner to stand by them, but it doesn’t scale very well
architecture can emerge, you can’t always plan for it
principles of system architecture are important
the architect needs to be part of the team to succeed
the team owns the design of the system, gives them accountability – design spike is our currency for architecture and it needs to be demoed
sometimes we need architectural epics – architectural epic kanban system
Portfolio management must be agile too – the mothership of all impediments!
PMO is governing us to a model we have abandoned, yet we created it in the first place
need to move from a portfolio of projects to a backlog of content management
need to move from cost estimation to velocity estimation and planning – so estimate your releases and epics in points too, not in dollars or hours
the team manages a project, not a traditional PMBOK manager
Overall, there was nothing really new in this session for me, although it was great to hear from Dean directly, especially on the topic of PMO’s and leadership. His latest book is still on my list to read.
Removing Impediments with Drawings
Carlton Nettleton led this interactive session, the instructions and agenda of the session is available here.
A drawing is more memorable, particularly when related to a story, helps your audience visualize your message, pictures drawn by a human are better than those drawn by a computer because they look too perfect
SQVID is a metaphor of how to draw pictures. Are you drawing:
simple or elaborate pictures
quality vs quantity
vision vs execution
individual vs compare
change vs status quo
Imagine:
discuss why you are imagining
draw simple
don’t overwhelm by drawing too much
iteration and refinement
think outside the box
Show:
focus on the audience
feedback
evolution – start, middle, end
outside perspective
drawing is only for support
This was a very hands on session, and the charts that we used in the exercises were very good templates that I will recall and use in future. The takeaway for me was to draw pictures in real time more to illustrate and get engagement for my message. I will also take another closer look at Dan Roam’s book.
Agile 2.0 – Rebooting A Raccoon In An Imperfect World
in lean 99% of behaviors are driven by the system – people were driven by the situation at hand
focus on behaviors not values or judgements
Formula:
be specific on timeframes eg yesterday
your observed behavior
perceived impact
recommendation or suggested solution
make it a conversation – set aside time such as feedback frenzy Friday
give feedback earlier, not just at annual review time
create safety – “is now a good time”, not a public theme but in private
seek clarifications – apply the five why’s to feedback
say thanks for feedback at the end – appreciate being helped to grow
take action on the feedback
Overall I have always found Patrick’s writing on retrospectives helpful, however there was little new in the presentation for me.
After Dark
Wednesday night was the Sponsor Reception, where the prime aim was to get to every booth and get a sponsor stamp (the real rule was to get one stamp per page, but it was far more fun ensuring I visited every booth!) One of the amusing things in Salt Lake City was that they do not take themselves too seriously, as evidenced by this beer.
The usual crew get together again:
Craig Smith 
You must be logged in to post a comment.