The Agile PretenderThe rise and fall and rise and fall and rise ..... of Agile

“It would be so much easier if the they all just kept their noses out until we’ve finished” - A Development Team

You never change things by fighting the existing reality.

To change something, build a new model that makes the existing model obsolete.

Richard Buckminster Fuller

Methodology Trail

• Flowcharting originated in 1930s for defining process in engineering.

• Iterative and incremental development (first recorded 1957)• Software Development Lifecycle appeared in 1960’s• Waterfall dominated in 1970’s and 1980’s (top-down

approach)• Scrum entered the world in 1993 (originally defined for

manufacturing in 1986)• Agile Manifesto defined in 2001

Common Agile Errors• Business still uses waterfall-based checkpoints to manage risk - at odds

with(“Responding to change over following a plan”). • Sprints can become Waterfall milestones (Waterscrum) in this situation –

more features in longer sprints, with Waterfall risk.• Perception that Agile projects have more risk - in fact Waterfall has more

risk, because if one feature goes wrong, it will take longer to highlight (and knock impact can be severe).

• That processes are at fault over people (common failures are due to roles being combined/omitted and team development skills gaps, or simply lack of Agile understanding)

• Sprints poorly planned leading to rapid spillover• Test Automation instead of Testers• Poor Continuous integration pattern (ideally, with complete build and

testing)

Agile Test Manager

• The main reason why the traditional role of Test Manager has carried forward? People are not used to being without one.

• The Test Manager’s role has to change in the long term, by expanding their role beyond defining strategies and plans (the expectation is that testers generate test plans)

• The Agile Test Manager has become akin to a QA Manager – who is concerned with the overall QA process to deliver a quality product.

• I do not believe it’s a cause for concern, simply an evolution in our positions as Test Managers.

• One of the weakest areas in Agile specifications is test management – and it’s down to us to address that.

• The Agile QA Manager can spread between on multiple projects – defining test strategies, reviewing project processes and maintaining testing momentum.

Agile Tester• A big difference for testers on Agile projects is that test cycles

change – it never stops.• Regression testing is always wise, so a pre-Sprint demo testing

(after iteration) is prudent - best performed by the testers.• The team is an important part of Agile philosophy and

contributing and bonding into that process is imperative for testing.

• Test Automation is the future, so learn it now. • Remember there is no room for Tester (or Developer)

wallflowers on a Agile project!

We’re working Agile!

Agile Business• The business approach to risk needs to change, avoiding Waterfall type

check-points (milestones) to measure risk.• Agile focus is on delivering fully-tested small features which diversifies

risk, which should be an effective selling point.• The Product Owner is there to put the Agile business approach into

practice, in Sprint planning process.• Each project can run to its own Agile methodology.• The lines of communication and reporting methods to the business

should be a standardised set of processes (Agile framework)• This framework should define project core team structure, project

submission requirements, and reporting checkpoints & exit criteria.• Test Assurance can help to ensure that Agile business approach is carried

through.

Startup project• Daily standups including all Agile roles• Continuous integration• 2 week Sprints• Product Owner that filled the role• Scrummaster that filled the role• QA involved in every process review• Free flow of ideas across the team

Nothing in this world is perfect, but that was as closest as I have seen to Agile in action..

Middleware Mobile ProjectProject inclined towards a purer development methodology

• Daily stand-ups• Continuous code integration and build testing• Complete unit test automation• Well planned SprintsWhat was missing that QA facilitated?• Testers!• Load testing (an Always-on Email service)• End to end testing

Software Development Methodology

• Agile development focus is on completing smaller working features.• Continuous integration principles to minimise integration issues. • Applying software methodology as intended, with periodic exploratory testing will help avoid "feature clash“

Key Agile development elements

• Shorter iterations This aims to produce smaller set of working features.

• Continuous integrationEnsuring regular testable builds, and enforcing unit testing as a default.

• Cross-functional teamMany skills make lighter workloads

• Daily stand-upsHighlighting impediments (albeit process or code), and general awareness of

everyone’s daily activity.

Example of making Agile work for you

• Implement Agile Business Strategy The business should lay out guidelines on how to initiate projects, and follow them

through. Define lines of communication and reporting methods to the business should be a standardised set of processes.

• Select methodology for project management This should be customised to be in keeping with company-wide Agile framework

(if there is one)

• Ensure that the team fulfils Agile assumptions Agile roles are there for a reason – they are key to success. • Relevant Product Owner• Scrummaster • The Team (development and testing)• QA Manager (not solely on one project)

• Continuous build and integration Every developer should be integrating their code daily, and running a quick build and

unit test. Every developer should take the latest code base in the morning, then everyone is working on the same page

A cautionary tale ...• Certified and experienced Scrummaster consultant.• Noted Agile testing consultant• Developers were coached and mentored.• Product Owner fully engaged in process• High budget

Why did it fail?The project was entirely misconceived as they were working on what was

essentially a set of shared web services. What they were trying to do was implement was what an SOA architecture

would have supplied, by using complex and ultimately unmanageable API’s.This type of work wasn’t in the development teams skillset.If Agile had been applied at business level downwards, this error would have

less likely occurred.

Tuning Development MethodologyAgile aims to avoid impact of feature implementations going wrong, and

impacting another feature. So ensuring an Agile development process is not optional.

• Take into account the type of project it is (greenfield, refactoring , etc ...)• Don’t assume development will work Agile automatically! • QA Manager can assist in decisions, though primarily Scrummaster task.• Don’t be afraid to change methodology – switching Agile development

methodologies has little impact outside “the team” .• Above all, don’t forget other project dependencies – they are part of the

Agile process.• The main reason these differing methodologies exist, is to tune Agile for

different approaches – not to fix Agile problem.

KanbanIdeal Usage: Brownfield (abandoned/underused)

• Designed to make Sprint planning more flexible, with no fixed Sprints.• Tighter management requirement, but leads to more optimal Sprints. • Helps avoid corner-cutting exercises, to complete Sprints backlog.• More project transparency

Challenges: • More daily testing work for the testers• Product Owner must be full-time• Difficult to sell “moving target” concept to the business

BDD (Behaviour Driven Development)

Ideal Usage: Greenfield (new)Similar to TDD, but with more focus on allowing Stakeholders, Product

Owner and testers to contribute to the application design. User story workshop approach. More time with analysis, less coding time.

Test Scripts are written directly from the User Stories and scenarios. There are tools that turn these into pseudo code – effectively a test script, code written in natural language.

This is more time-consuming process initially, but development happens much faster, as the focus of BDD is delivering features.

Challenges: Committed engagement from Stakeholder(s)/Product OwnerDependency on cohesive interaction between business and deveolopment.

Agile QA Summary• Process improvement QA should to be involved in every Agile process review.

• Exploratory testingExploratory testing extends the boundaries of testing scope beyond strict user stories and scenarios.

• Early reviews Testers can provide developers AND the business with early Sprint feedback – a

Sprint is a longer time than you think. If you are using kanban, this is essential.

• Regression testing This is where a QA “arc” can ensure periodically there is fuller evaluation of the

product progress with every iteration.