The Agile Coach is a critical role in helping leaders, teams or individuals understand, adopt and improve Agile methods and practice. Additionally, an Agile Coach helps people rethink and change the way they go about their work. For a individual to be effective in a coaching role, they must poses a wide range of skills and experience. In this workshop we will explore Agile coaching skills in the context of a competency framework and provide participants with lessons from real-world coaching experience. The workshop will provide an opportunity for participants to learn about coaching, identify areas of Agile development and to broaden skills through hands-on group and individual exercises and games.
You will:
» Understand role of an Agile coach and the typical development pathways
» Identify personal areas of strength/weakness in relation to a broad range of Agile and related skills
» Learn situational specific coaching techniques for common Agile dysfunctions
» Understand the use of maturity models in helping teams learn and adapt to Agile
» Understand organisational and role specific Agile challenges
» Learn how to adapt Agile practices to suit team specific challenges
stop doing stuff that does not deliver value, not laying people off
spend time doing the right stuff, not the wrong stuff
think systems, not software – Southwest think employees, customers and then shareholders
optimise the whole system (software is just a layer) – Amazon is structured around it services (2 pizza teams of 8-10 people)
a separate testing team is silly – just handoff / afterthought, need to build quality into your product
need to understand value before you deliver value – understand what your customers value, not what they want and build the right thing before building the thing right
setting up a new product is a set of learning loops
watch for what is making people uncomfortable
understand your customers not by bringing an idea but by taking the team to understand the problem
there is always demand in a service company – fix issues as fast as possible, but that is not the game
consumability – how much effort does the customer need to go through to get value?
customers decide value… and therefore decide waste
measure productivity on value delivered, not features
work in progress is waste – customers are not interested in your long list of things to do
good Agile teams have a low number of defects
map end-to-end flow to find the biggest opportunity in your end-to-end process
40-90% of the cost is maintenance not delivery, the cost of quality is way higher than the cost of building quality in, don’t put defects on a list (track them, fix them immediately), root cause every escaped defect, determine why every one happened
problem with readable specifications is that the text is not refactorable – any text page will have hundreds of ambiguities
every organisation that calls itself professional should be doing TDD
expertise takes 10 years / 10,000 hours of deliberate practice, need a teacher to challenge, feedback and dedication (The Road to Excellence)
marketing leader – for a successful product you should be able to name this person
technical leader – keep two top engineers free to roam around and give guidance
Empire State Building – on time and under budget, had to manage the flow of materials not tasks, had two alternating mills to keep up schedule and remove failure point
people who have dome something before should know how to deliver within the constraints
when managing an organisation you need to manage the capacity, you need to have a stable flow
kanban – reduce work in progress to expose problems (don’t crash your boat on the first day, keep your limits high then lower your limits and remove your problems one at a time
kanban board – every column is handover to the next column, the next column (downstream process) gets to define done
5 why’s – the cause of the cause of the cause of the cause…, The Team Handbook has good process improvement practices, as do the Six Sigma tools
product-centric development – 54% of Fortune 500 companies are heading in this direction
Here is a picture of an exercise we did to map the cycle time of a particular company (it highlighted some of the issues they are having around approvals).
Finally, a huge thank you to Nick Muldoon from Atlassian who helped me out with a space on this course. Also to one of my colleagues who reminded me that we should ask forgiveness not permission when I was dealing with some competing priorities!
As a precursor to the Agile Australia 2012 conference to be held in Melbourne, a product afternoon was held at the Hilton on the Park in Melbourne in November and had a good variety of Australian speakers. The success of the event means a similar event is being schedule for Sydney in February 2012. Here are my notes from the event:
Look What Happened When We Let Customers into the Product Development Loop at Lonely Planet!
need to avoid the next bench design problem – only ask the person on the next bench about quality, do not go to the wider world
for Lonely Planet, realisation was a competitor in the market who produced a colour guide, no sales the month they launched
went to customers 4 times in the process, took publishing from 2 years to 9 months, visualise the project
Rob Adams talks about getting the developers to do some of the initial marketing calls
Marketing is from Venus, IT is from Mars – and the Customer Doesn’t Care
Daniel Oertli from REA Group led this discussion that he hastily renamed to “5 Kick Ass Principles for Customer-led Development”, his slides are available here.
effect of marketing has changed over the last 5-10 years, we no longer control the marketing channel, need customer admiration
be a peeping Tom. Regularly – there is only one customer, the people who pay for products, none of this internal customer bull####, hard to put your business on the road regularly to talk to customers
5 on Friday – Silverback on Mac, 5 internal employees for 15 minutes and ask them to do specific tasks with your product (eg. show me how to change the default colour scheme), continue to do this every Friday as parts of the product are developed
don’t ask for the solution – to get creative you need to figure it out internally, great people create great things
day and half every quarter – hack day – off tools, schedule around it, put ideas on intranet and vote, teams form around the idea self-forming, winning team gets a cash prize and gets sponsored product into production
2 week inception process – use business canvas mapping to lay out the business drivers
democratize design – hard to get excited about something if you have not been part of the design, get everybody to draw
ready, fire, aim – Agile gives us opportunity to change things in motion but most organisations still execute iteratively what is planned up front, Agile gives you a bullet frequently, be very clear about your minimal marketable features, be ruthless about what you send to your Agile teams, you have a lot of go’s at this
teams win – good people outperform any processes, keep teams very small (6-8 people), have a mix of business fundamental understanding, lead designer and lead technologist and there for skills not core decision making, trust is essential
dealing with resistance – hardest change of all was getting business on the journey, need to get culture sorted and get teams focussed
more of what people do is outside of their hierarchy, biggest impact is dynamic thinking by thinking of type of things we will do rather than what we will do
public companies need a plan to show to shareholders, challenge is to make it more dynamic after that
engage people in their career progression – still report to a lead, but 90% of the time they live with their cross functional team – more about stretching their knowledge in their domain so have practice meetings
SEEK’s Approach to Product Innovation
Doug Blue from SEEK presented this session, his slides are available here.
put customers before profits – no display advertising on the front pages, founder would prefer to have a dollar tomorrow rather than a dollar today
build for the long term – customer core needs, competitive advantage, long term trends and shareholder value, in GFC let customers negotiate out of long term contracts
strive for a rock solid core and out innovate the competition – focussed on number of ads and size of audience, now need to focus on the product
focus – do a few things very well, carried this over to the iPhone app as well, but run business on the things that are do-able
people engagement – never compromise on engagement
data driven decisions – if we build or change something, we measure it
test and learn – put it out in market and do course correction
balancing customer needs – 3 different customers with different needs (job seeker, employer, recruiters) – came up with an invisible salary to balance the needs
on bigger initiatives, need to do your homework
A Start-up Approach to Product Delivery in a Corporate Environment
XP Explained lacked an explanation on how to communicate effectively with customers to understand what they wanted to achieve
base costs on optimum team sizes that can manage constant delivery of a number of system concerns
have no process, when problems occur, take those problems away
don’t use iterations, they constrain the customer, need to be able pick up any card and get it into Production
ideas wall – backlog for where the business is going, anyone can post ideas on it
don’t talk about what the product we are delivering should do, talk about what the business should do
challenge everything – stand ups are almost useless in large organisations – only say things what people in the circle need to know about, because they work together, so they should know
most people in large organisations are disempowered – how do I know I am doing the right thing? Just do it, everyone is the business
need to help everyone understand the market – understand what the impact of features are
whole of company showcases every Friday
need multi disciplined teams that understand the market they are striving for
Panel: Why is Customer-led Product Development so Hard?
Keith Dodds from ThoughtWorks led this panel with all of the above speakers. Some of the key learnings were:
if you have leaders that are customer focussed, everything else will follow
most organisations try to make the workforce effective and efficient by putting structures around them, need to retain a functionalised structure and stay away from specialisation
companies are introverted because traditionally they have not had access to customers
it’s hard to keep up with all of the tools out there – there is lots technology to seek out what the customers are viewing
most products are designed to be obsolete within 1-2 years, especially those that are consumer focussed
companies are not set up to evolve things, they are setup to build, the world has changed where everything is outdated the minute you deploy
grass roots movements are usually the most enduring
most companies lack the balls to shut things down when they need to
frugal innovation – constraints help you channel great ideas, would be interesting to apply some artificial constraints to hack days
what doesn’t work are artificial constraints and the team know it
next C level job will be the chief designer – targeting the customer
Agile helps to get a customer led product out, because the person who wants the product can talk to the person who builds the product
report on value delivered to the business rather than velocity
the pool of talent is not that big, how do you keep people motivated – sense of purpose, sense of meaning (problems that have currency in the real world), ability to react and shape, ability to be heard, about making a difference
where do great Product Managers come from, how do we develop and train these people
The YOW! 2011 Australian Developer Conference was held a couple of weeks ago in both Brisbane and Melbourne and I was able to attend with thanks to Dave Thomas and the organisers of the conference on my press credentials for InfoQ. I had the ability to record some podcasts for The Agile Revolution and Coding By Numbers as well as chat with most of the Agile related speakers. Here are some of my notes from the sessions I got the opportunity to sit in.
Dave Thomas kicked off proceedings with some Lady Java:
Keynote: Top 10 JVM Erroneous Zones
Cameron Purdy from Oracle presented this session. Whilst it is good to see management levels talking about and understanding the core business, I found this keynote rather average. The presentation is available here.
immutability – no concept in Java, introducing would be good for thread safety but would also improve garbage collection (stop the stop -the-world clauses)
primitive types – binding between interface and implementation, improving would simplify and fix auto-boxing and generics, would need to make sure code compiles the same way
interface vs implementation – they are all the same thing, a problem that we all inherit from the same parent
properties – very fixed contract currently, need to loosen this up
obvious intrinsic types – Decimal needs to follow IEEE standard 754-2008 (754r), need to upgrade to a 128- bit world
real runtime model – JVM must provide predictability, need more access at code level
constants – no constants for intrinsics or other similar types
alternate class file format – limited to 64KB in methods, hierarchies make no sense like inner and anonymous classes
Getting the opportunity to see Mary Poppendieck speak is always a pleasure, for this conference she delivered her talk on Continuous Design. As the program host for the Lean and Agile track, I also had the pleasure of introducing Mary. Her presentation is available here.
continuous delivery misses design and feedback – how do we know what to develop if we are thinking about continuous delivery, has created a need
continuous delivery uptake is increasing, takes about a year to get going
need to assemble a diverse team – frame, ideaton, experimentation then iterate
3M – make a little, sell a little, learn a little (repeat) – the fastest through this loop is the winner – fastest can be four times faster
need good people (pay attention to hiring) and a whole team (need all the functions which can break the agile 7 +/- 2 model), measure success in customer satisfaction
start with customers – Amazon (working backwards – write a press release, write FAQ, describe customer experience, write user manual)
disruptive design – companies like GE are starting to design products for different markets like China and India rather than USA and Europe – resulted in different design , thinking, price point
need to decide when it is time for people to see it – it’s hard to refactor books, hardware and first impressions but you need to take a chance and find out that you are wrong – a balance trade-off
minimum viable product – biggest waste is building the wrong thing followed by complexity – build it and measure the response (learn)
implement a show me more button and forward to to an under construction page and measure the clicks
avoid vanity metrics, need actionable metrics, use innovation accounting – start with a hypothesis, build MVP, target initiatives at improving a growth metric in your hypothesis, measure done as adding value
use A/B tests to change your conversion rate
test early – don’t waste your time arguing
cohort metrics – operate on data, as people run into my product how do they behave
feature toggles – switch features on/off on demand, wrap entrance to feature with toggle code, control via configuration file – customers love it
canary releasing – take a small amount of users and give them a new version, need to be able to tell a good change from a bad change very fast – monitor key thresholds and roll back fast if required – make sure when something goes wrong it never goes wrong again
Apple – ” it’s not about money” – understand customer problem and the revenue will turn up
Google – “it’s best to do one thing really, really well” – stay focussed
Amazon – “think long term” – you don’t want make a lot of money off your best customers, some things don’t always make financial sense
3M – “hire good people and leave them get on with it”
I also had a great half hour chat with Mary on the second day of the conference where we talked in-depth about continuous design as well as size of the product team. She believes the key is to enable the complete development cycle and discover good engineering products. We should stop using software words, including Agile, and start using system level engineering. As for the team size debate, we should use system engineering and break our teams into appropriate sub-components.
60 Years of Innovative and Agile Work Practices
Nigel Dalton led this entertaining and informative trip down memory lane, and as the program host for the Lean and Agile track I also had the pleasure of introducing him. The presentation is available here.
people who pay your wages don’t know your stuff, this is a heavy duty approach that has been used for the last 100 years
1930’s Cabinet War Room – as close to an agile room design as you can get, war is a fairly big project!, agile does scale (WWII), lucky it did or this presentation would have been in German!, military and politicians were in the same room, no battle plan survives contact with the enemy
1950’s U2 and SR71 – if you do good engineering, you will be amazed how long it lasts
1960’s moon race – iteratively learning through doing, working rockets are the primary measure of focus
1970’s Luna Tractor – Russians were striving for a different question, what is on the moon?, different question and cost a lot less money, Apollo 13 is the greatest example of an agile project, ask the right question…
1980’s cold war fears – madness of strategic parity, Russians learnt a space shuttle program cost a lot of money after duplicating it, took the USA 30 years to learn it
product engineering is overarching, top down and empathetic
think about what you are going to do before you do it…
million dollar idea – ideas don’t matter and are usually terrible, originality does not matter, it is quality
ideas – it’s like a blank but with blank…
consider your customers – start at the end by making a commercial (30 – 90 seconds on the problem you are going to solve and how you are going to solve it)
your best product tester is your arch nemesis
in user interface – it is much more important to be consistent than correct
real artists ship – plan, design, ship on time!
don’t ship the rough draft
fear social debt much or more than technical debt – you can fix technical debt (you can but you won’t!)
shipping a product is like giving birth to a kid – there is a heck of a lot more work to come
endeavor to kill your own, you are never done, when people are raving about the first one, you are already finishing the second, you want an army of evangelists
Appsterdam – the most important thing we have is the community
the hook is the difference to a defining product, but need to keep being innovative
Better Testing With Less Work: QuickCheck Testing in Practice
no scientific experiments that show agile is any better
we need sleep – but average time is dropping, naps are good too…
we are hardwired to look at the horizon, so lift your eyes and look around and blink
lying down improves your cognitive performance
research from University of Queensland – the longer you sit the sooner you will die
the startling ideas come at a time when you are doing nothing
eat before you’re hungry, drink before you’re thirsty – when the brain is lacking energy, the default is to say no
we are hardwired to be close to nature – we do better with natural light and real plants around us, take 5 minutes outside in a natural environment
explain the problem to your dog or a stuffed toy
in meetings, when at an impasse, get each person to explain each others version of the problem
fearless change experiments – test the waters, reflect, small success, step by step
I also had the opportunity to sit in on a very interesting interview with Linda Rising on the Coding By Numbers podcast with Craig Aspinall and Steve Dalton.
Domain-Driven Design for RESTful Systems
Jim Webber delivered this entertaining session, perhaps the most entertaining part was when he tried to explain a cassette tape to a young audience member (I remember loading Commodore 64 games off tape…). His slides are available here.
continuous deployment – eliminate the fear around doing deployment
tests – a version of feedback, need confidence
automated deployment strategy – need to be repeatable using tools, need to be able to do quickly
need architecture that can handle inconsistencies in the system at any one time – different versions of API’s, etc. in the system at the one time
feature toggles – need on the technical and business side, toggles for beta users, power users, need to be able to work on one code stream all the time for it to work
traffic – need traffic for this to be successful, especially to get useful metrics
monitoring and feedback – what characteristics are being used, monitoring and qa are the same thing (see Steven Yegge’s rant on big SOA)
Apollo program was basically Agile and continuous deployment in the 1960’s – 61 launches until they landed on the moon – only way they made progress was because they were monitoring everything
record all the values all the time
pay attention to long term metrics, not just instantaneous
should use the word anomoly more (not bug) – use feedback to understand and fix our anomalies
Other Stuff
Joshua Kerievsky gave two talks at the conference that I unfortunately did not get to see live (Lean Startup and The Limited Red Society), but I did get the opportunity to speak to him in-depth with Renee Troughton for the Agile Revolution podcast.
Renee and I also did a wrap-up podcast.
I have also published a news article for InfoQ where I asked all of the Agile speakers at the conference what the Agile community needs to embrace in 2012.
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.
value of quality is lower than the price of quality – quality is dead
you may get a quality product (sometimes) but you always get an expensive product
quality matters for human life, security and money
systems are designed for redundancy these days so most of the time nothing will go wrong
people value free over quality
we live in a world where quality doesn’t matter, we are used to things failing
restructure what you are doing – don’t focus on catching big bugs, but focus on productivity testing, reduce the cost of development and speed it up
it is cheaper to fix a bug when the customer finds it now we are moving to the cloud
organisations are now paying people to find security bugs, people will test for free for a free device, some companies will offer jobs if you find a bug
need to start communicating value of work in a language people understand – how much did we save?
Test Process Improvement: Testers Get Out Of Your Cave!
TMMi has 5 levels – initial > managed > defined > management and measurement > optimization
start at level 2 when assessing
results from some TMMi quick scan assessments in 20 organisations – test reporting 30%, test planning 41%, test monitoring 47%, test design 60%, test environment 59%
test design is probably high because it can be influenced within the testing team, whereas planning and reporting, etc.. require people outside of your team
testing teams are in a cave, need to get out of the cave and use the rest of the organisation
stakeholder definition – the most important people at the BBQ – the hold the power, they have mindset and ambition
it’s all political – politics is a way of life – you need to get in front of the leaders and stakeholders and have political skills
Why Model-Driven Testing is of Great Relevance to Test Managers and Test Analysts
Thomas Hadorn from Tricentis gave this very vendor driven presentation.
The STANZ (Software Testing Australia New Zealand) 2011 conference was held in Wellington and Melbourne on the last week of August (into September). I was lucky enough to be invited to speak at the Melbourne event by my good friends at Software Education, who were the promoters of the event. I rolled up on the back of a flight from Los Angeles to Brisbane (and then Brisbane to Melbourne) a little jet lagged, but got heaps from the event.
ask questions of the CEO about the vision and what the product is supposed to do, listen to customer support calls, talk to marketing, talk to the developers about what bugs they value
what are the top 10 things people love and hate about your software?
look for efficiency – use checklists instead of test cases, forget about regression testing and use the computer to be more efficient
testing is about creating value for the people who matter most, your customers
people need an emotional attachment to your product – the share market is an example of a product driven by emotion
we need to create value for our customers, but just as importantly for ourselves
we can’t just focus on business value – it’s a big stick that will erode morale
talk to your customers – what do they need, what do they like, dislike, what is missing?
talk to team – what do they like about your work, how can you be better?
self evaluation – what is new in the field, am I enjoying work, what do other team members focus on or find things that I miss?
avoid blame – excuses rather than finding and solving real problems – “we wouldn’t have this problem if we we doing agile”, “management don’t get testing”, etc… – feels good to say but is not constructive
don’t expect tools or processes to rescue you – look out for your own best interests, know the problem you are solving and use the tools/process to solve it and ensure you have a way to measure it
the key to creating value is alignment – people in different jobs or teams often have different goals
leaders – clearly articulate vision and goals to the testing team and how does that align to our goals for the product and company, leadership comes from everyone in the team, leaders need to manage the politics (an organisation with more than one person will have politics)
need to continually inject change and keep people interested
people have skills, they are not resources – find your talents and invest in it
understand your context – every team will be different
tangible quality can be measured by understanding if the stakeholders needs are met and if you are meeting ROI, intangible quality is important and not often taken seriously – would you be afraid if you mother used this, would you like your name on the splash screen?
impress the most important stakeholder – you!
most people don’t know what great testing is – you can be shocked and appalled by what most people think is good, strive to be better
tangibly getting better – learn about planning and strategy and exploit the opportunities, write good bug reports as developers really value this, be good at communicating what needs to be done and where we are going, take more responsibility and display competence in basic technical skills
intangibly getting better – be in demand for your testing service, have good problem solving ability
use external communities to develop your testing skills
work as though your favourite person in testing was coming to visit
need to be able justify your work – is your testing defensible
use repeatable or intermittent bugs as a clue to something bigger – don’t ignore the anomalies
testing is like journalism – need to do crazy things to get the story, move towards the issues, people need the news today not tomorrow
need to have a technical curiosity about what is going on in the community – what is coming down the pipe, what are the people that have the ability to change things doing?
Overall this was a refreshing session to see a passion in testing and improving skill, with some excellent sound bytes along the way.
What Does A CEO Want From Testing
Mark Feldman from IV&V Australia delivered this presentation.
wanted a team that had long term motivation, so could not motivate with carrots
Outliers by Malcolm Gladwell – mostly people are successful because they are in the right place at the right time
before you can motivate a team you need to ask yourself how motivated you are – what gets you up in the morning about testing
know your testers – give your testers a testing challenge to understand how they test, also understand what they want to get out of testing
important that your test team knows that you believe in them and that they are being listened to, important that they get excited about testing again
testers are paid to think – test scenarios often go against that
think about for every test, how is it adding value to the company
testers need to take responsibility – make and defend decisions
you sometimes need to let go of your own goals – the team need to feel empowered
exploratory testing – the tester needs to decide when it is good enough, this is the way testing is and it is hard to estimate – session based test management (SBTM) and Rapid Reporter (enter your charter/objective – time stamps and records test sessions)
I really enjoyed this session, although it reminded me how many organisations still have large test separate teams.
Test Planning for Mobile Application Projects
Jonathon Kohl delivered this session, based on some Techwell articles (part 1 and part 2).
implications – power, display size, portability, connectivity, radios, large number of devices
less power than a PC – multitasking can freeze memory, interactions with O/S can have a big impact, kinetic input (tapping, touching, pinching) can have strange behaviours, needed to test using physical movement to replicate locking
connectivity – strange things happen when moving between WiFi, 3G and 4G, driving also causes issues
distribution – you do not have control of distribution in app stores, read the guidelines and understand the timelines early
mobile project issues – time pressures due to market competition, smaller applications, constant change in environments, handsets, software, very programmer centric environments so planning, testing, etc is viewed as a bat anchor, lots of competition, high risk if your application does not work as expected
testers need to prove their worth as rigid approaches will leave you behind
key is to focus on test execution rather than planning, because everything is going to change anyway
need a strategy on how you are going to test, what devices you are going to buy, how are you going to manage the devices/cables because they go missing easily (had to chain cables to a hubcap!)
find out strategies that you are targeting so you can procure equipment
emulators are useful for basic testing, better to use real device of target platform, developers would have used the emulator anyway
supporting IOS 3 to IOS 4.1 resulted in 104 combinations between multiple devices, etc – classification trees are good to explain permutations and combinations
automation is still in initial infancy – not as nice as web applications at this point
devices are being exploited to do combined activities so need to exploit this in testing
we use these devices in environments where we do not use a PC – they are addictive and are part of our lives
testing will involve leaving the office and moving around to mimic what the users are doing – determine high value because everybody will want to do this testing!
tricky to get devices that you are targeting – standing in line for the iPhone!
may need to target different carriers and plans as technologies can be different
think about logistics of storage, charging, etc…
ergonomics are an issue whe testing mobile devices – shorter work days, can be painful on fingers, people are 25% less productive on these devices than PCs
health is an issue because devices are shared and illness spreads fast – hand sanitizers, wiping devices after use, washing hands frequently
need to factor in training as there are lots of way to use devices
taking screen shots is a lot more painful than web applications
usability testing – no standards unfortunately, look for user emotions, perceived lack of performance, one of the most important things on these devices
performance testing – no real tools, can jailbreak IOS, some emlators have rudimentary tools, can affect performance of device, use stopwatches, spoof the headers, emulate on a machine using small memory footprints and look for speed
security is often a trade-off with performance
can automate using emulator in a browser, tools are rudimentary, vendors are clamouring in the space, Opera has a mobile mode
planning needs to be a parallel activity, do just enough in regulated environments, video can be good to replace test cases, need to meet their intent and needs but rather than giving them what they ask for give them something better
research your customers for your scenario tests – how they will use the app, are they locals or visitors, is it easy to understand outside context (eg. train schedules)
trick – search ” sucks” to find and exploit common problems
allow time to keep up-to-date with platform changes
remember to test technology like GPS, graphics, camera, video, sound, messaging, data
may need to set time aside for guidance documentation
put structure and timebox around exploratory testing so that everybody knows what mission and goal is – look at application from different perspectives
express completeness as how have we done and how much we have to go from different perspectives
Session Tester – video is good for brining new testers in, easier to digest than written down test cases
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
My workshop from Agile Australia 2012 with Adrian Smith called “Agile Coaching Workshop” is available on SlideShare.
Craig Smith 
You must be logged in to post a comment.