Re: Roll Your Own Agile?

Face -> Palm

On Monday, February 1, 2016, [email protected] [SCRUMDEVELOPMENT] <
[email protected]> wrote:

>
>
> [ 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
> accomplished this by the following practices and some others:
>
> 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.
>
> How can a Scrum Team work together, here's my often posted example:
> 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
> accomplished by:
>
> 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.
>
> 
>