James, Thanks. I have a follow up question regarding project management in general. When the length of time for development and testing are unbounded so that product quality is the principal goal, how do you forecast needs for human resources and financial resources? Thanks, Pine On Jul 27, 2015 12:07 PM, "James Forrester" <jforrester(a)wikimedia.org> wrote:

James, Thanks, that's an interesting answer. Lots of fields other than software struggle with similar issues. For example, I can't remember the last time a major aerospace manufacturer managed to design and build one of their flagship products on schedule, and major public transportation projects in the U.S. seem to fall behind schedule and over budget on a regular basis If it wouldn't be a distraction from other priorities, I'm wondering if project management could be the subject of a Tech Talk sometime. (Cc'ing Rachel who I believe coordinates Tech Talks.) Thanks, Pine On Mon, Jul 27, 2015 at 3:16 PM, James Forrester <jforrester(a)wikimedia.org> wrote:

That Kanban talk assumes some familiarity with Scrum or other agile software development models, so might not be helpful for everyone. For those who are new to that space, agile development[1] takes a radically different approach than traditional (non-software) project management, or from traditional software project management (often referred to as "waterfall"). Agile encompasses both Scrum and Kanban, as well as a dozen more methodologies. Agile is a way of thinking, being, and doing, rather than a specific set of practices[2]. Note that agile is not fully adopted within the foundation, but I believe many/most teams are either agile or "agile-adjacent". Most open source projects are agile (or agile-ish) even if they don't realize it. Within our Wikimedia context, I might describe "agile" development like this: We probably can't know how long it will take to develop X, because as we work, we will learn. So even if we did deliver exactly X, by then we would realize that X is no longer exactly what is desired. That's in addition to the normal uncertainty around programming, which is inherently a creative process[3]. However, we will have some X in mind as a long-term destination, realizing that we're unlikely to end up exactly there. It's kind of like planning a road trip "up the coast", without knowing exactly what campsite you'll end up in. To get started, we will figure out some small portion of X, and code and deliver it. That will give us feedback to figure out the next part of X, which we will code and deliver. We'll repeat this over and over, constantly refining our direction based on feedback. At some point, we will have delivered "enough" and will stop. That could be at 30% of X, or perhaps 80% of X but also with 40% of Y and 10% of Z. Throughout the process, the Product Manager, developers, and users will be having conversations to refine everyone's understanding of the goal(s). At any point in time, the Product Manager will decide what the team should work on, using heuristics like: - Stuff that allows users to actually start using the product for real work - Stuff that has a very high benefit-to-cost ratio - Stuff we are absolutely certain we need over stuff we think we probably want - (Sometimes) Risky stuff first, to get it out of the way Compared to other industries, software development has a couple huge advantages: First, once we design and build something, it can be replicated infinitely at almost zero cost. Second, our medium is highly malleable. That is, we can build the equivalent of a 30-story tower, and then replace the first floor with something completely different. Or we can start off thinking we're building an airplane, but halfway through decide that we actually want a cruise ship. For those reasons (and others), it can be difficult to translate project management practices directly between software and non-software fields. [1] https://en.wikipedia.org/wiki/Agile_software_development [2] http://agilemanifesto.org/ [3] https://en.wikipedia.org/wiki/Software_craftsmanship Kevin Smith Agile Coach Wikimedia Foundation *Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.* On Mon, Jul 27, 2015 at 5:48 PM, Brian Wolff <bawolff(a)gmail.com> wrote: