Anthony Gardiner's Blog

To celebrate the launch of iMeta Agility (beta) our new scrum management tool., we are running a prize draw to win one of the following:

To enter the prize draw, all you have to do is register here and you’re in.  Once you have registered, you can improve your chances of winning dramatically by forwarding the personalised link we give you, to all your friends, family and colleagues – for every entry we receive from your personal link we will give you 3 extra entries into the draw.

Keynote from Agile testing days in Berlin - Jose introduces Stuart as an old dog – the father of STQB.

Stuart starts with the well know Pig and Chicken story:

• Chicken - Why don’t we open a restaurant
• Pig  - Mmmm sounds fun,, what shall we call it?
• Chicken – Ham ‘n’ eggs
• Pig - No thanks id be committed you’d only be involved

Pigs are committed in agile chickens are stakeholders

Stuart goes onto the agile manifesto and highlight the part he is going to talk about ‘individuals and interactions’

What’s special about an agile team?

• Self organising
• Communal ownership
• Typically any two can make a change to the product, process, tests etc

Stuart questions the following common statements about agile teams.

• Highly motivated
• Highly skilled – Stuart states that they should be the same as with traditional projects
• Cross functional

Stuart shows an agile team Skills matrix to illustrate the make up of a team and where the weaknesses lie

Stuart defines the middle 2 skills (test & DB) as deep long term skills.  The others are shallow. i.e. Java is shallow if you understand programming.  He adds coding to the grid as a deep skill to underpin the Java example

Other deep skills that could be added:

• planning
• software engineering
• technical
• test

shallow skills that can be learned at a project level

• Specific language
• Specific db
• domain knowledge

Skills needed by an agile team

• Development – Design, programming, build/integration, testing technical
• Management – planning, enforce process, conflict management
• Customer / User – requirements, acceptance test, business domain knowledge, user manual

Plus very importantly - the ability to communicate and collaborate.

Structure

Specialist skills from outside the team

Can’t duplicate skills in every team e.g. security testing

• Test strategy selection – Stuart says this should be defined at company level
• Specialist testing
• Test tools
• Environment set-up maintenance
• Test process improvement

Specialist testing skills at a team level should be the same as those on a traditional team (design, exploratory, performance, usability, tools, TDD, system acceptance)

Roles that fulfil the required skills

• Management – scrum master, lead engineer
• Development – Designer, programmer tester
• Customer / user – Business analyst, Test

Typical team is 7 people – Scrum master, 2 testers, 4 developers and a BA

Would scrum master and 7 developers work?  Yes, the developers could fulfil the role of BA and Tester

Would Scrum Master 5 testers and 2 BAs work? No

Transition to agile often starts with 4 dev, 2 testers a BA and Project manager.  PM loses his role, needs to fulfil a different role as scrum master.

Mythical agile team member

Cross functional – skilled across the board (programming, testing analysis)

Stuart doesn’t believe this person exists but multi-skilled people do and is a positive.  We should strive for Cross functional and be happy with multi-skilled.

Scrum team capabilities

Do we need better than average people?  Stuart doesn’t believe so – where will they all come from?

On start-up its suggested that 2 or 3 (at least some) are both competent and experienced in agile.

on any team you will have a mixture of experience and capability

Self optimising

agile teams perform self optimisation

• Identify hidden skills
• Help each other
• Allow team to grow skills
• Hide the nice but dim from the management – [not sure I agree]
• do not tolerate non-team players

No-one can hide from the other pigs on an agile team. – unlike traditional teams.

Structure of team

• Not hierarchical
• Pair programming – driver and navigator. better to have the expert navigating the learner. [if you use pairing for learning purposes]
• Mentor / Apprentice – BA/Tester, Dev/Tester, BA/Developer, Tester/Developer
• Natural or forced rotation – Stuart doesn’t think you should force rotation

Injecting skills into your agile team

• Injectable skills – a mix of methods and tools capability
• Get it through – new staff, contractor, training , coaching
• Team should be empowered to organise this for themselves

Injecting skills can be self medicating [I think this is so important]

Tester core skills

• Test skills
• soft skills
• IT skills
• Domain Knowledge

Motivating individuals is not about pay

Calculating motivating potential score

• Skill variety
• Task identity
• Task significance
• Autonomy
• Feedback

Stuart highlights that the individual jobs of a tester can be quite de-motivating test reporting, black box testing etc

if you combine them and give the tester a different title they are happy! [Isn’t that obvious?]

[Sorry I lost the thread of what Stuart was talking about on scoring and categorising – mainly because I don’t agree with him]

People decide the process

• The agile manifesto supports individuals and interactions
• Higher skills are needed / should be learned
• Higher motivation comes with higher skills and responsibility

How does it feel to be in an agile team – it feels good!

The keynote started a little earlier than I expected, Mary delivers her material at a break neck speed and last night was Oktoberfest at the Agile Testing Days conference so I have missed some of Mary’s great keynote.

Complexity is the enemy

Edsger Dijkstra – said “Those who want reliable software will discover that they must find means of avoiding the majority of bugs to start with.” The forefather of structured programming.

Harlan Mills – Top down Programming – The principle criterion for judging if top-down programming was actually used is the absence of any difficulty at integration – This was possibly the fore-runner of continuous integration.

Dave Parnas – Criteria for decomposition – divide the program into modules based on their responsibility and the likeliness of future change rather than structure – the fore-runner of object orientated programming

Vinton Cerf and Robert Kahn – TCP/IP – each distinct network stands on its own, no information retained by gateway and routers, no global control at the operations level, communications on best effort basis.  The inventors of the modern Internet.

Divide by process

[I missed a large chunk of this – if anyone can help me elaborate then please let me know and I’ll update]

Barry Boehm -

• The problem - Mary shows a graph that explains the evolution of hardware-software cost trends.
• The solution – Mary shows a slide of the SDLC (waterfall style) with a 10% effort of testing at the end.

Following on from last nights closing keynote by Tom Gilb, Mary quotes Tom and his early work.

[For those of you who were unsure of Tom’s closing keynote, have a chat to him in person.  I did last night and his presentation made much more sense to me after that.  Thanks for your time Tom]

Evolutionary Development

1. Start with a short summary of the measurable business goals – these are the real requirements. Unambiguous, testable, no design – include all stake holders – no more than 10
2. Proceed with incremental deliveries
3. Trying to inspect quality in doesn’t work
4. Prevent defect injection in the first place – or find them as soon as they appear! Make sure you can see a defect and when you do you stop immediately. – CI does this for us

A Defect injection process

1. Start with a software requirements spec – not necessarily one big document
2. Then we code
3. Then we test

Does the code match the test?  Not always?

This is a defect injection process through the interpretation of different groups of people – so, why don’t we write the tests first and then right the code to fulfil the tests?

• The question - How do we deal with complexity?
• The answer - Divide and conquer.
• The real question - Along what lines do we divide ?
• The Answer is - Divide by responsibility and value .

The 3 rules of lean system development

[I didn’t keep up with Mary for this bit – she was running out of time and therefore going even quicker! So sorry, its a list of quotes without clear context – can anyone help elaborate?]

1. Design matters – if we don’t think about it we have a good chance of building the wrong thing.
2. Correctness can be confirmed at any time
3. Failure is a learning opportunity

Design – Mary uses the iPhone as an example – its the system that matters not the software. 175 iPods a minute and more than 1 a billion songs a year sold. Nokia makes more than 13 phones a second and tailor service for every market

Customer – anyone who pays for uses, supports, or derives value from the systems we create – also known as the stakeholders.  Product owners are not customers.

Envision the product – understand the problem, the market, the customers, the constraints, where technology has been and where it is likely to go in the future

1. Understanding
2. Ethnography – watch what the problems are and solve them
3. Modelling
4. Experiments

Construct – Every system development process ever should be designed to find and remove defects as early in the process as you possibly can.

Release cycle – often 30-50% of a release cycle is dedicated to finding bugs. if you get the process right you move it forward and final verification can be as low as 10%

Agile development is nothing more and nothing less than – correctness can be confirmed at any time.

Agile@IBM – define their process as - short, stable iterations; with stakeholder feedback every iteration.

Lesson - Give your teams the right support means giving them the freedom to innovate, but also give them the tools and training they need to be successful.

Quality by construction

Test Driven Development

1. Always be able to determine correctness
2. Test for correctness very frequently in small batches
3. Roll up testing to the next level as and often as practical
4. Stop if the tests fail – fix the problem immediately

The system should test itself – The biggest defect is tolerating defects – do not accept that they will be there at the end

Learn

Complex systems will fail - each failure is a learning opportunity

• Determine root cause
• Stop it happening again
• Don’t work around problems

Toyota’s Improvement Kata

1. Visualize perfection
2. Have a first hand grasp of the situation
3. Define a target condition on the way to perfection
4. Strive to improve
5. As obstacles are encountered, they are systematically understood and overcome.

Test to learn

• Test to failure – the system can bee expected to meet spec. you know what it should do – exploratory testing finds out if does what it is not supposed to
• Test to seek knowledge – start with a hypothesis of results .

[Sorry for the bits I missed – if anyone can fill in any of the gaps then let me know]

Agile Testing Days, Berlin, Key Note 2 -  a summary overview.

Elisabeth starts with a humorous anecdotal whistle stop history of her career to date.  To fast for me to type but very funny!

She states that agile processes are not going to guarantee success but they will increase your odds of success.

The challenge being – “Building software that you can sell and selling software that you can build.” – Jerry Weinberger

What does agile really mean?

Adhering to the agile manifesto? Doing Scrum? Standing up every morning? Being flexible?  - No!

Elisabeth’s definition is:

• Deliver value through releasable software regularly – at least once a month
• At a sustainable pace – not just the right hours but keep the technical debt down.  Don’t let your capacity be slowly depleted with tech debt.
• While adapting to the changing needs of business

Releasable means done, done means tested and implemented, tested means checked and explored.

Elisabeth quotes Mary Poppendieck “To go very fast you must be very disciplined”

4 big sources of tech risk

1. Ambiguity – we don’t know or haven’t articulated what we are building .
2. Dependencies – too many moving parts increases the potential to go wrong.
3. Assumptions - its not the stuff you know its the stuff you know isn’t so.
4. Capacity – lack of velocity or capability.

7 key testing practices in agile

1. ATDD – a practice in which we work collaboratively with the Product Owner. The product owner is “The voice of the what.” and the implementation team is “The tribe of the how.”  (Tobias Mayer) This reduces ambiguity by reducing the translation of the product owner’s request.  The side affect of ATDD is a suite of automated system-level regression tests
2. TDD – Write a small test that fails, write the code to make it pass then tidy up the code.
3. Exploratory Testing – simultaneously learning about the software, designing the test and executing the tests – using the feedback from the last test to inform the next.  The goal is not just to find bugs the goal is to characterise the capabilities and limitations of the system.
4. Automated system tests – side affect of ATDD
5. Automated unit tests – side affect of TDD.
6. Collective test ownership – artefacts are project artefacts not the ownership of silos.
7. Continuous integration – CI tools do automated builds, execute tests and report the results.  Developers practicing CI merge their changes locally and execute tests before checking in.

Conclusions

I was going to try and be first to blog about Lisa’s keynote but Gojko Adzic beat me to it! (o: http://gojko.net/2009/10/13/are-agile-testers-different/

Jose and Alessandro Collino introduce us to day 2 of the Agile Testing Days conference and then hand over to Lisa Crispin for the first keynote of the day.

Lisa starts by introducing Tammy the inexperienced agile tester before embarking on a journey to describe the role of an Agile tester.

There are blurred lines between roles – Agile developers are ‘test infected’ everyone should test, everyone is responsible for testing and everyone understands the business.  The difference is between traditional silo teams with development, test and project management working separately and that of a combined agile team where everyone collaborates as a combined team.

Tammy asks “Who owns quality?” – Lisa says its not us the testers, we are simply responsible for providing the customer with sufficient information to make an informed decision.

An agile testers mindset:

• Constantly looking for new challenges and improvements – seeks out new tools and new approaches to get the job done better.
• Proactive and willing – get out of your chair and do what it takes to help.
• Collaborate with the rest of the team to deliver the best possible product

Agile Testers are:

• Results oriented
• Customer focussed
• Collaborative not antagonistic – work with the developers from the start.

Agile testers should be willing to get out of their comfort zone and try to adhere to the agile manifesto – internalise culture and values – not something that is easy to teach.

Back in the 90s a 6 month release cycle was ok for a database company – in 2009 you have to react quicker to keep up with the internet and SaaS era – release cycles must be more regular or you will be left behind.

Lisa’s top 5 principles of agile testing:

1. Continuous Feedback – Agile Testers are information providers – remove obstacles, track progress, enable corrections, guide development. How? Kanban board, story board, Fitnesse tests
2. Direct Communication – Collaboration – maximise real time communication person-person, pair test, multi-view “power of 3”(tester,dev and product owner), challenging for distributed teams but not impossible – Lisa is on a trolley for meetings and pairing when she is remote (well, there’s a laptop with a webcam on a trolley and that gets wheeled around to meetings).
3. Simplicity – What is the simplest thing that can work, set standards up front, test ‘just enough’, lightweight tools and techniques, push automation to lowest level possible, keep regression as simple as possible, test core functionality first – the software has to work happy days before testing edge cases, identify bling.
4. Responding to change – code is constantly changing, every day there is a new build. Be involved, question and be proactive.
5. Enjoyment – if you’re not having fun you wont do your best work. Agile development rewards passion, the team values testers, everyone is test obsessed , makes our job fun and rewarding.

An agile team should be test obsessed

• These principles help customers
• These principles help testers – unique perspective of tester gains team respect, adaptive for team, learn new skills to meet new challenges.
• These principles help the whole team – roles are blurred so team needs to be able to jump in wherever – when testing is the hold up the developers jump in and help, teams with skilled testers are more likely to communicate with the customer.

Use your new agile mindset to reach beyond what you already know

Conclusion

Are agile testers different – Lisa thinks yes. 

It is good to have excellent testing skills BUT,

We must adapt and change as fast as the technology around us does.  Collaborative nature of agile means that how a tester contributes has to change.

• Help team deliver value quickly
• Help team find better solutions
• Transfer skills
• Have courage to get out of comfort zone
• Keep it rewarding

Question from the floor

Q: How do you get a traditional tester converted to agile thinking?

Lisa - “You can teach skills but attitude is everything.”

This is a similar theme to Rob Lamberts “What tester are you?” talk that he will be presenting tomorrow morning at the conference 11:05 in the vendor track room (14th October) .

After a white knuckle ride through suburban Berlin with a German speaking Jackie Chan we finally made it to the hotel!

We spent our first evening in Berlin with Elizabeth Hendrickson and Lisa Crispin amongst others.  Rob Lambert was greeted with great enthusiasm by both Elisabeth and Lisa who were both clearly expecting a much older person from what they had learnt about him from his blogging – a real testament to Rob’s efforts from two important names in the testing world.

Day one of the Agile Testing Days conference has been an interesting one.  We caught up with Tom and Mary Poppendieck over breakfast and they were raring to go with a shortened version of the day they spent with us at iMeta two weeks ago.  The first day is focussed on day long seminars from some of the most sort after names in the agile testing world. See the Agile Testing Days website for the full listing - http://www.agiletestingdays.com/tutorials.html

As exhibitors we came with iMeta Agility our scrum management tool and were lucky enough to be the only exhibitors to have arrived on day one!  Jose, the event organiser, was most accommodating in allowing us to set up ahead of schedule and make the most of the day with our flyer being the only one in circulation for the day.

There was a long lunch break to make the most of and we were met with quite some interest from various people including Declan Whelan, a popular agile coach from Canada – the beauty of being the only exhibitor!  We are now awaiting the end of the days tutorials with another opportunity to meet some prospective iMeta Agility users.

Tomorrow promises to be a more steady flow of visitors with the day being more geared to a conference than seminars – the other exhibitors are now starting to set up.  Rob is also presenting his “What Tester Type are You?” talk and we are hoping to organise some break out session with the planning poker cards – we’ll keep you posted.

If you want to follow the conference activity on Twitter then the tag is #agiletd

P.S. They are threatening to get us in some lederhosen on Tuesday night in celebration of Oktoberfest!  I’ll be sure to take the camera!