What experiences should we work by? I think most, if not all, of us have worked in, around or through those SCRUM projects either
- Where a company or department has just adopted Agile
- Claim that previous releases, defects, infrastructure and current change is ok and needs to happen simultaneously;
They are very serious about keeping important processes moving with frequent fire drills. No matters what the cost of these overnight sessions are, all hands are on the deck via Skype or Messenger all across the globe as long as a ‘believed’ shippable package is ready for production in a 2-5 week sprint.
This is one example that I’ve lived through over and over again with a charter to introduce 1 new agile improvement technique per sprint before I joined Apexon. On top of that, this was deemed and touted as a ‘world-class’ organization with wise and brilliant leaders. There’s no question the latter was true but something seemed to get in the way of the ‘world class’ part.
What are the agile accelerators? Agile accelerators are those which:
(1) Meet the user needs created by an agile team that could synthesize functional and non-functional features effectively, under pressure, especially being humble enough to tackle two things that did not work well in a previous iteration.
(2) Be shippable quality and aligned to quorum of shared knowledge between end users, product management/biz analysts, development, test and operations.
(3) Be created per and only by acceptance criteria and as a side-effect of Automated Test Driven Development (ATDD).
(4) Flow through the life cycle smoothly even if changed, delayed or added by management or affected by resourcing through Fibonacci based point system and worthwhile 2-4 hour exhaustive planning sessions.
(5) Survive onslaught of heavy numbers of client facing defect fixes.
(6) Struggle between product management and testing or operations around handling backlogs and project roles.
(7) Which metrics are most helpful, ‘agile’ and beneficial?
I suggest these as warning signs in your project, if agile accelerators like the following:
(i) are not welcomed,
(ii) if introduced, not adopted
(iii) are considered not agile enough criticized for being ‘too waterfall’
Somehow to consider a development life cycle practice in agile SCRUM and still have management as part of the core team and have inflexible rules of engagement, may be worse than a team focused on AGILE practice operating stagnantly.
Agile accelerators to turn a failed SCRUM-like project into a successful SCRUM or AGILE project:
1) Master test strategy document stressing consistent user story card point velocity from sprint to sprint or iteration to iteration sometimes considered un-agile because we favor people and their skills over documentation from the agile manifesto.
2) The MTS sets the ground rules, directly, concisely esp. around agile iterations, acceptance criteria, roles, responsibilities, life cycle (# of construction iterations, # release/system test iterations) and most importantly, the feature sets and criteria that make the package releasable at the end of the sprint cycle.
3) Test environments planned, setup, data requested and managed
4) Tests created and stored in test management tool for iteration test and system test
5) Bidirectional traceability between story card — test case pass and acceptance criteria incorporated
6) Tester collaborates with analyst & developer ‘The 3 Amigos!!’ to prepare acceptance criteria
7) Functional tests are created during Iteration test and failures are fixed ‘in place’ according to acceptance criteria
8) System tests are created for end to end scenarios per MTS
9) Usability testing is performed where needed during iteration testing
10) Triage process defined for customer facing issues/emergency with fixes in current release
11) Issue found after iteration test are entered as defects and tracked