Post by ***@juno.com [SCRUMDEVELOPMENT][ The Feature Blitz as an alternative to meetings like Planning Poker Parties. ]
I participated in an agile-scrum group that implemented much from the lean
methodologies. This department was able to double programmer productivity
almost immediatelyâbut there was some temporary stress increase as the
change from waterfall to agile was madeâthey were able to produce a Userâs
Guide for each feature while the programming and QA was happening, and they
were able to release features most needed by customers in a truly agile and
quick manner. They were able to accurately estimate four 8-month projects
and deliver them on time while outperforming competing companies by a
factor of 4 times their speed, something I haven't seen since. They
An analyst prepares some ideas for a projectâs features and then schedules
a meeting (Feature Blitz) where all the development team [domain expert(s),
programmer, code reviewer, SQA engineer, the analyst, and any manager that
really wanted to attend] decide the features needed, their specs, their
implementation, the proposed order they will be coded and list of
dependencies, breaks them into iteration-sized mini-projects, and at the
end of the meeting assigns people to each of the above roles for each
mini-project. The specs are the notes and digital photos from this meeting.
Next each member of the team enters estimates of hours for them to finish
their roleâs work for each iteration or mini-project. The managers, in
Iteration Planning, then swap around any resources or mini-project to
maximize the use of everyoneâs time, keeping in mind that changes may
require the new team member to meet with the analyst or others to get
up-to-speed on what happened at the Feature Blitz and that the new team
member may not be able to do the roleâs work as fast as the one who helped
decide the particular implementation in the Feature Blitz. Next there is a
commitment meeting where the development team (the four roles besides
domain expert) commits to their deadlines even if they have to do overtime,
which rarely happened because people became good at estimating their work
ability. Simultaneously during an iteration, the analyst writes the Userâs
Guide, the QA engineer wrote a test suite with corner cases and exceptions
that programming may not have thought about, the programmer and code
reviewer discuss the details of the implementation and do the coding.
Obstacles and progress were discussed frequently among the whole team and
communicated to management and other stakeholders. QA tested each code drop
so a programming path that wasnât going to work was caught quickly and
little code had to be thrown out. QA had enough time to do their job
properly and checked how the feature functioned with other features.
Analysts, QA, programmers, and domain experts generated other enhancement
ideas not only for the project, but for other projects as there was more
time for exploratory testing, prototyping, and thinking about the entire
product/program. At the end of the iteration, the released product was more
closely bug-free than the waterfall methodology. Lastly, QA had test suites
that could be assigned in the future to other QA members or customer
support for re-testing prior to each product/program release.
Not only did we use this for estimating a single story, but we did an
estimate on the entire product, [Cardiology software that was a patient
record, drug-drug interaction, prescription sender, billing, ECG and other
device integration, etc., etc., that is, a big product]. We did not do any
planning poker game or variation ever, but had ACCURATE estimates by using
the Feature Blitz as our method, meaning the one who was going to program
the feature gave their estimate after domain experts and others (QA &
Analysts) all mentioned ramifications of the code changes.
In two and a half years (including when we first started our
scrum-agile-lean hybrid), we were only later than âa single dayâ on one
sprint and less than a day late on three sprints (once was due to hardware
load testing that uncovered a need for a hardware change). All other
sprints were fully completed on time, with most sprints having work from
the subsequent sprint started. (Our sprints were 2 weeks.)
---maximum L exceeded so shortened---
The answer to the question sometimes depends on how the company works.
But for an Agile/Scrum Team, the Team, the Department Head, & any Product
Owners may all have valuable insights in how QA can continuously improve.
Our department was able to double programmer productivity almost
immediately; they were able to produce a Userâs Guide for each feature
while the programming & QA was happening, & they were able to release
features most needed by customers in a truly agile & quick manner. This was
An analyst prepares ideas for a projectâs features & then schedules a
meeting (Feature Blitz) where all the development team--domain expert(s),
programmer, code reviewer, SQA engineer, the analyst, & any manager that
really wanted to attend--decide the features needed, their specs, their
implementation, the proposed order they will be coded & list of
dependencies, breaks them into iteration-sized mini-projects, & at the end
of the meeting assigns people to each of the above roles for each
mini-project. The specs are the notes & digital photos from this meeting.
Next each member of the team enters estimates of hours for them to finish
their roleâs work for each iteration or mini-project. The managers, in
Iteration Planning, then swap around any resources or mini-project to
maximize the use of everyoneâs time. Next there is a commitment meeting
where the development team (the four roles besides domain expert) commits
to their deadlines even if they have to do overtime, which rarely happened
because people became good at estimating their work ability. Simultaneously
during an iteration, the analyst writes the Userâs Guide, the QA engineer
wrote a test suite with corner cases & exceptions that programming may not
have thought about, the programmer & code reviewer discuss the details of
the implementation & do the coding. Obstacles & progress were discussed
frequently among the whole team & communicated to management & other
stakeholders. QA tested each code drop so a programming path that wasnât
going to work was caught quickly & little code had to be thrown out. QA had
enough time to do their job properly & checked how the feature functioned
with other features. Analysts, QA, programmers, & domain experts generated
other enhancement ideas not only for the project, but for other projects as
there was more time for exploratory testing, prototyping, & thinking about
the entire product/program. At the end of the iteration, the released
product was more closely bug-free than the waterfall methodology. Lastly,
QA had test suites that could be assigned in the future to other QA members
or customer support for re-testing prior to each product/program release.
Not only did we use this for estimating a single story, but we did an
estimate on the entire product, [Cardiology software that was a patient
record, drug-drug interaction, prescription sender, billing, ECG & other
device integration, etc., etc., that is, a big product]. We did not do any
planning poker game or variation ever, but had ACCURATE estimates by using
the Feature Blitz as our method, meaning the one who was going to program
the feature gave their estimate after domain experts & others (QA &
Analysts) all mentioned ramifications of the code changes.
In two & a half years (including when we first started our
scrum-agile-lean hybrid), we were only later than âa single dayâ on one
sprint & less than a day late on three sprints (once was due to hardware
load testing that uncovered a need for a hardware change). All other
sprints were fully completed on time, with most sprints having work from
the subsequent sprint started. (Our sprints were 2 weeks.)
<Sorry I was too lazy to retype, so I just pasted from another site I had
posted it on. Other comments next.>
What to work on was whatever percolated to the top when stuck in this
massive spreadsheet inspired by six sigma. The spreadsheet had the same
tasks that we estimated accurately as mentioned above.
Programs were for medical specialties like Cardiology and included ECG
device integration and the like into the Electronic Health Record.