As a documentation starter:
- The phab:T124022 ticket has been announced by Quim Gil on wikimedia-l
- That post links to WMF product development process
The WMF product development process very much looks like a waterfall process or method. Is that intentional or inevatible? Isn't that at odds with agile / scrum software development?
Thanks for your question. Had you already read the topic "Sounds like waterfall"?
Quim has pointed to that long discussion on the phab ticket discussion. I've seen it :)
I wonder whether agile is too – I'm not sure how to explain this. With a large project, in agile, you're really doing everything at once. When you are releasing part 1, you're also building part 2, designing part 3, planning part 4 – and also re-building part 1, re-designing part 1, re-planning how to integrate the changes from part 1 into your current plans for parts 2, 3, and 4, etc.
And it's kind of hard to explain this "do everything at once" as a "process" to someone who is thinking in terms of, say, the process used by a factory line or the process used in a court of law.
Would it make more sense to present it as several interconnected, simultaneous focus areas, rather than anything in a line? (For example, six blobs with lines between them rather than six lists in a row.)
At least when it comes to the conversations with our communities, Understand and Plan come before Release and Maintain, and not vice versa. There is a sequence. The purpose of the checkpoints for every stage is to check whether a project is fit enough for a next stage.
Another example. Once a project is in Develop, they can go back to Understand, Plan, etc as often as they wish, but still they cannot jump into Release without going through the related checkpoint. Again, there is a sequence for new products and new big features requiring community checks.
We probably agree, but your brief explanation here sounds rather "waterfall-y". Perhaps VisualEditor is an example: "Release" and "Maintain" citations came before "Understand" and "Plan" table editing. Therefore, "Release and Maintain" (something) actually did come before "Understand" and "Plan" (something else). From the communities' perspectives, all of these things happened at the same time.
We probably agree indeed. From the point of view of the communities, they want to know about features like "VE citations" or "VE table editing", and some people might be interested in A but not in B. Each feature follows more or less that sequence (at least ideally).
I think this topic will be less of a problem when we move from one draft in a wiki page to some real action.
I think it would be helpful for this discussion to have clear definitions into what is waterfall and what is agile from a person on TPG.
Also, we have drawn this process as a line, and really it is more of a circle. There are places in the process that do not neatly check off boxes and then move to the next stage without going back and forth for a while. For example when building citations in VE, there were several concepts built and tested, and iterated, and tested (several circles, back and forths between parts of the process) until people were able to use it (it was usability tested and people were able to accomplish creating a citation without difficulty, considering all the details and edge cases), there were no bugs (this was a combo of QA and usability testing - which are different), then, it was released to production.
It might help to explain this process in a more visually representative way, showing that it really is a circle (we may some day decide to add functionality or remove functionality to the product called citations) that sometimes has circles (iterative testing until ready for release) within each part of the process. Drawn as a straight line with not back and forth between parts of the process (iteration), it communicates a less iterative process that does not reflect the reality of product development inclusive of the necessary activities to create usable, bug free, quality software. I think it is important to call out the back and forth between stages with arrows pointing backwards in the, at this point, unidirectional flow. Perhaps a visual designer could help us with creating a more representative visual to describe this concept.
