1

The Question:

What are the distinct advantages and/or disadvantages of a Digital (excel or dedicated PM software) approach to Sprint management as it relates to documenting the development process for the purpose of satisfying ISO 9001 (or other similar sanctioning bodies) compliance requirements?


Answers should follow these guidelines :)


Background:

We’re an ISO 9001 regulated company. As such, we are required to generate and maintain records which show evidence of:

  • Risk based thinking (identification and acting upon opportunities and identifying and acting upon chances for defects)
  • Process based approach (evidence of having a system and following that system)
  • Plan-do-check-act cycle (plan what you will do, do it, analyze the outcome, act on opportunities to improve based upon your outcome)

This stuff is all inherently built into the Scrum process YAY! but showing evidence of it is where the digital tools seem to have the advantage.

Excel, and most of the dedicated Scrum software I've seen, does this handsomely by documenting the product backlog, user stories, the sprint backlog, tracking progress, etc., etc.

However, I have mixed feelings about the value of these tools in that regard vs. their alignment to the Agile principles.

Specifically I have concerns about the following:

  • Working [processes] over comprehensive documentation.
  • Working [product] is the primary measure of progress.
  • Simplicity--the art of maximizing the amount of work not done--is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The requirements for evidence are pretty open ended, and do not preclude analog tools.

For example, I can satisfy the requirements for evidence of Risk-based thinking and PDCA by taking pictures of the product backlog boards and sprint boards before/after grooming, sprint planning, and sprint completion, etc. We're already tracking retrsopective minutes with OneNote, while using an analog approach, which works fine.

Being new to Scrum, I'm not sure what is the right approach, and was hoping to get inputs from more experienced Scrum teams who may have some experiential insights to offer :)

  • 2
    After such a lot of time and effort you took here, which is to be applauded, I have to say this doesn't look like an on-topic question. In reality you are presenting your opinions, asking who agrees with you and canvassing for individuals' experience and opinions and a list of pros and cons. – Marv Mills May 4 '16 at 14:22
  • 1
    Hi Marv, I don't think it's off-topic based on the help article. I'm not asking for a specific tool recommendation; my question relates to general pros and cons of an approach, and asks for evidence in support of success or failure based on experience. This is inline with many other top rated questions on this site - like this, and that, and even the highest rated question on this site. This site is still Beta; maybe the good question article could use some refinement? – CBRF23 May 4 '16 at 14:48
  • 1
    That said, I will edit the question to make it more precise (less open-ended or chatty) as I think that could be part of the problem :) – CBRF23 May 4 '16 at 14:50
  • 1
    The first and last example are asking specific questions ('How do I do this thing', and 'Why is this method better than that method') and I would argue the middle one was off topic as Opinion-based anyway. Yours is not seeking an answer to a specific question, it is asking for a comparison of two different methods, a list of pros and cons for two options and asks each correspondent to provide their own evidence. This kind of question is not a good fit for a Q&A site in my opinion. Sorry – Marv Mills May 4 '16 at 15:13
  • 1
    Hi Marv, I noticed the same things, which is why I did revise the question to be more precise in both what I'm asking and what I'm asking for. And you can always edit my question if you think it can be improved :) – CBRF23 May 4 '16 at 15:14
2

Seemed more appropriate to split this into an answer, to be voted on/commented on/edited and generally considered by the community separate from the question.

Recommendation:

*Perhaps the ideal approach for this particular situation would involve using OneNote as a Digital Whiteboard. *

A touch capacitive whiteboard running OneNote (or some similar software) provides most of the same advantages of the analog approach, while offering may of the advantages of the digital tools - including the distinct advantage of persistence for providing evidence of ISO compliance.

It also offers the advantage of being able to easily copy/paste data to do tracking in excel other software programs, and the convenience of being able to add pages related to a Story to document the research done and risk considerations, decision making, etc. OneNote also offers the ability to link or embed attachments, making it a good central repository for all the work being done.


Summary: Digital vs Analog

The digital approach offers distinct advantages in the form of more complete and persistent documentation, better data aggregation and analytics, better meta-data analysis (long term velocity tracking, similar projects evaluation, etc.) and ease of searching for and finding information relating to the work done and considerations on feature integration/refusal, etc.

However, Excel and most (all that I've seen) Scrum based tools require much work to setup and get working right, and require diligence in entering information in the expected (rigid) format. These trade-offs are not well aligned to the Agile values and principles.

The analog approach is better aligned to the values and principles of Agile, offering great flexibility and freedom to adapt, change, and refine the approach, but everything is temporary (with each Sprint, the board is reset, and aside from taking pictures, there is no evidence inherently generated on the work done in prior Sprints). Taking pictures of the board at various states requires extra effort, and is a weak link in the process that is easily defeated by forgetfulness or simple human factors.


Agile Alignment

  • Working process > documentation
    • There is not much to break with a whiteboard (maybe a sticky falls off? or someone drags it out in a windstorm) but there is much that can (and usually will) go wrong with custom software. Also, every where I've worked people manage to break excel files constantly. Lastly, as we attempt to refine and continually adjust our process, will the rigid framework of these tools become a barrier to our experimentation?
  • Working product is the primary measure of progress.
    • We already have the one KPI needed. What is the real value of all that extra tracking, and does it outweigh the compromises to the other values?
  • Maximize the work not done.
    • How much time is spent making the process fit the tool? What about finding, reporting, and fixing bugs or broken references? Making adjustments to the framework when we want to try something new? Is this work that needs to be done, or is it more work that does not need to be done?
  • Best architectures, etc. come from self-organizing teams.
    • I believe this speaks as much to the product being developed as the development process itself. Many Agile and Scrum processes evolved this way too. When following a rigid and existing framework, will it stimey the team's ability to develop it's own framework/process?
  • ...Reflects...on becom[ing] more effective...tunes and adjusts...
    • How much wasted time and energy will go into tuning and adjusting spreadsheets or software tools? Will that detract from tuning and adjusting the process? Will the rigidity of the tools get in the way of experimentation in our process? These things were mentioned in my earlier points, but worth reiterating here.

My Experience

Not much.

I've been researching Scrum for about 9 months, and we've been doing it for about 2.

I have my own beliefs on what matters, but I don't have the experience to recognize holes in my thought process or know what has/hasn't been done, or compare approaches first hand.


Pros & Cons

With limited experience, this seems my best method to approach the topic analytically.

I weighted the Pros (+) and Cons (-) of each item on a scale of 1 to 3 for impact/value. (e.g. + has less value/impact than +++)

Analog

+++ Flexible
+++ Collaborative
+++ Constant Visibility
++ Easily reconfigured
++ No intrinsic constraints/limitations on data entry or formatting + Handwriting allows us to draw pictures, create emphasis, etc
- - Creating evidence requires additional effort (e.g. take pictures of Scrum board and add to project folder, add up points completed track velocity, etc.)
- - Tracking takes additional effort, and can easily be forgotten or done incompletely.
- - Archived stickies and photos of whiteboards are not text searchable
- - Requires extra effort/discipline to identify the story associated with a task, so when tasks are complete their value is added to the story - and for figuring out how much effort was really required, vs estimated.
- Not very green (paper and markers are environmental waste)

Digital, via EXCEL

+++ Tracking is automatic and gives instantaneous feedback
++ Easy to save historic evidence
++ Lends well to data aggregation & analysis
++ Text searchable
++ Remote accessibility (if shared via google docs or similar) - - Tracking systems need to be developed up front (e.g. formulas, macros, data-entry format, etc)
- - - Rigid format; data must be entered consistently to use advanced tracking abilities.
- - - Doing more non-essential work. This is the big one for me. We're not a software company - we don't have programmers on staff, and building excel templates and macros and whatnot doesn't directly add value to the product. Can I program? Yes. In a couple languages now. Can I build an excel sheet (with formulas and pivot tables and arrays) that would offer advanced tracking? You bet. Can I download a template from the web and use it as a starting point to save some time? Sure! Is there still time, money, and resources that must be spent developing and maintaining these types of things? Yes, absolutely. Is that work primary to achieving the Sprint goals? I don't believe it is - - - Inflexible. The added structure and added complications of changing worksheet layouts, formats, formulas, macros, etc. seems like it would be a barrier to changing the process (continuous improvement). - - Not an information radiator (must have computer available with excel to log in and be able to view).

Digital, via Dedicated Software

+++ Tracking is automatic and gives instantaneous feedback
++ Easy to save historic evidence
++ Lends well to data aggregation & analysis
+ Searchable
++ Remote accessibility (for some software - cloud based). - - What to track needs to be developed up front. Are we tracking right things? What benefit does the data provide?
- - - Rigid format (for data entry, for information presentation, etc.)
- - - Inflexible. The added structure inability to make changes to that structure on our own seems like it would be a barrier to changing our process when needed (a key agile value).
- - - Inability to change. What if we want to do something that isn't currently offered by the software? Maybe we need a new feature, or want to change the way we do something, or want to track something differently, or maybe we want to switch to t-shirt sizes instead of story points, or some other off-the-wall rating system, or a myriad of other things that might not be offered by the software currently. Since we do not control the design/development (unless open-source, but then see multiply my concerns with complications from Excel by 100x if we're modifying and maintaining our own software) which seems like a huge barrier to change and subsequently to continuous improvement.
- - Not an information radiator (must have computer, log in to computer and open software to view. With cloud based software, must have computerr and internet connection to view. )

  • 1
    This is an excellent answer and I agree with you. However, as much as I really dislike Microsoft's Team Foundation Services, it's new incarnation in the cloud (Visual Studio Online) is really a very flexible and maturing product. There are a lot of ISO compliance benefits of being able to tie story cards to code to manually run tests. Of course, we're aiming at a manufacturing ISO cert, not the 9001, so YMMV. At the end of the day, I very much find the ISO standards to be at odds with the Agile Manifesto. – RubberDuck May 5 '16 at 22:50
  • Agile and iso standards are not in conflict at all -- in fact, I think that they are complimentary. The only real difference is a need to archive the documents produced during the projects, which agile tends not to need but is actually agnostic about. BTW: Use Jira for this. Everyone of merit uses Jira because it's the best tool for the job. Every other suggestion is wrong. – Engineer Dollery May 9 '16 at 20:48
  • @EngineerDollery - would you care to expand upon why Jira is so great? – CBRF23 May 9 '16 at 21:18
  • @RubberDuck actually, it is ISO 9001 we work to, but you are correct, the benefits of tying code to story cards in TFS wouldn't be much use to us :) I find Agile and ISO to be very well aligned as well. SCRUM, as my answer attempted to point out, satisfies ISO completely - it's just a matter of showing it :) Also, the tie-in between LEAN manufacturing and Agile/SCRUM is ridiculously well-aligned. All this stuff was actually part of my presentation about why we needed to bring SCRUM into our process :D – CBRF23 May 9 '16 at 21:31
  • Like I said @CBRF23, we're in medical device manuf, so it's a different set of ISO standards. For us, it's important to tie a code change to a requirement to a test case. I honestly know next to nothing about 9001. – RubberDuck May 9 '16 at 22:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.