From Inception to Release

Product Development Process
1

Exploring our collective process for full software lifecycle

It’s rather a tall order, all this collaborative working that we do. We all have features we’d like to see. We all have ideas that we’d like to see implemented. But between having an idea and seeing it on OFN there lies a long journey. How can we do this collaboratively, yet efficiently and viably?

Stage One: Idea Sharing
This is done through discourse. If there is a feature anyone in the community would like to see, they are free to add it to discourse and tag people (see below) to comment on the feature.

Try to make comments constructive and useful. Talk in as much detail and specificity as you can about what you’d like the feature to do. Talk about the specific requests of users and the problem this feature is trying to solve. If you don’t feel confident speaking in a technical language, don’t. Just use language that is as clear as possible. Include images, screenshots, diagrams, wireframes, anything you can to make your descriptions as clear as you can.

Be clear if there are parts of your description that are ‘nice to have’ and parts that are ‘must haves’. If you couldn’t use the feature at all without a specific functionality, be clear about this. This will help the technical team in working out the MVP.

People who would like to be tagged to comment on the process of new feature development…

Please add your names here
@lin_d_hop

If there is a clear time limit on this stage, as the feature has been requested and funded by a user/instance this will be made clear on the original post.

Stage Two: Confirming a Specification
Currently this stage is generally led by the team that is funding the majority of the development. This stage takes the broad set of ideas and goals and begins to develop a clear specification for the work. A clear specification should answer all of the developers questions, and thus cannot be created without developer input.

To develop and finalise the requirements spec one or more meetings will be required. Limiting to a smaller set of people at this stage, including ‘head developers’, developers that are likely to work on the issue and ‘product owners’. During this stage the team that will work on this project will also be decided.

A requirements specification will likely include things like:

  • High level requirements
  • Any assumptions that need to be made
  • Use cases and user journeys
  • DB Changes required
  • Ideas for the UX
  • Implementation steps. Include review, test and merge here.

Once developed the requirements specification should be made available for the whole community. If there is a deadline for comments/feedback, or if no further comments/feedback can be made by the community at this stage due to timescales, this will be noted in the document.

It seems sensible, at this stage, to also designate a project lead that will drive the project forward.

The requirements specification document should be linked from the original discourse post.

Stage Three: Estimation

After a specification is agreed the development, implementation and testing will need to be estimated.

Estimations will be made based on the estimated time required for each of the implementation steps in the spec, including review, test, merge and user guide updates.

These estimations can then be translated into project cost, which will in part be indicated by the people that are likely to work on the project and their day rates (which differ from country to country based on differences in living costs).

A breakdown of project costs can be linked to the discourse for transparency.

Stage Four: Funding

Once a budget for the project has been decided the project can be added to co-budget.
Find the description of how to do this here:

Stage Five: Development

Once a co-budget project has been fully funded development can begin. Firstly the implementation tasks are added as Github Issues. These issues should be added under a new Project so that the issues can be tracked.

More insights into creating Github issues can be found here:

While development is ongoing it is important for devs to track their time such that budgets can be monitored.

During this stage it is a good idea to merge code in smaller chunks as you go, to save big conflicts and merges as the project starts to wind up.

There will likely be a few iterations of development as features are tested, either internally or by the community, issues are found, fixed and retested.

Development phase is complete when developers, testers and product owners are happy that it meets the spec for this phase of the project. Note that this might not be the project in it’s entity… and might not satisfy all the needs of all the users. In that case it’s back to Stage One to work out what to include in the next round.

Stage Six: Merge and Release

Once the new feature has been signed off by developers, testers and product owners it is ready for release. At this stage descriptions of how to use the new feature should be added to the user guide.

What’s Missing:

  • As yet there’s no guide as to how to fund the initial scoping and speccing work. Some of this work is done by the community and some needs high level technical skill that should be remunerated.
  • How do dev track their time while working on project issues such that budgets can be monitored as we go?

@danielle @MyriamBoure @Kirsten @serenity @NickWeir @jveilleux @pierredelacroix @CynthiaReynolds @tschumilas @sreeharsha @oeoeaio @maikel @sstead @iris

Probably @ the whole community on this one… who else?

2

This is excellent groundwork.

I’d like to suggest that you adopt a SOP (standard operating procedure) that each specific project have a number of standard documents that go along with the discourse thread on that project and that one of those projects includes a spreadsheet with the links to all of the places where the project is discussed.

As I’ve plowed through the community forum (discourse), I’ve found is challenging to find all the discussion points for specific topics and am quite sure I haven’t found them all yet. And even when I have, there’s not much structure to the discussion. (This is not a criticism; it’s the natural result of an evolving process.) Every newcomer to the project is going to have similar or greater challenges as the corpus of discussion grows.

I would suggest creating a template (form) for the spreadsheet and perhaps also one for the inevitable google doc that contains the narrative on the project. You could use the tabs functionality in sheets to include the project plan and dependencies, as well as the list of who’s responsible for what. You could even use one tab to keep track of developers time.

As a starter, I drafted these: https://docs.google.com/a/virtuallogger.com/spreadsheets/d/1sgDwabTVG92XD_NKyx2IvA98AwOjGXA22yB2EoL_GMw/edit?usp=sharing

This is only a “trial balloon”. I’m willing to spend more time fleshing these out if you feel it’s useful. Because I’m still a newbie, I’m really feeling my way through how you do things. And don’t worry about my feelings. I’m 60 years old and my skin is as thick as a rhino. So if you think it’s garbage, say so.

I also think you need a commonly accepted wireframing tool. Some of you suggested Pencil, which I think is very good, but is desktop-oriented. I would offer you a slot on my balsamiq account, if you like (www.balsamiq.com). Balsamiq provides unlimited users and is designed for collaboration. Unfortunately, I can only offer you 1 or 2 projects (my subscription level is limited to 10) so individual projects would have to be lumped into a single project within balsamiq, unless you wanted to get your own subscription. (You can transfer your projects later to your own account, I believe.)

I’ve created an “OpenFoodNetwork” project in my balsamiq account and only need to know if you’d like to have access to it. I have to “invite” you to the project and don’t want to send you a useless email if you have no interest. (Note that I’ve used the screens I’m working on form my instance, so it won’t match the OFN version 100%. But I’m willing to have someone create duplicates of the existing OFN screens to make it easier to work from what you have now (I’ll fund that.)

There are plenty of other wireframing tools and also ones that can generate interactive screens. I’ve played with a handful and would be glad to help with selection if you want to be more selective. You can even just use the drawing tool in google docs, although you won’t be able to create clickable links and your choice of images is much more limited.

Thanks.

3

I would suggest that the Discourse post would be the place from which all documents are linked. Mostly because thus far it has been working well for the community, particularly in relation to spreadsheets.

4

To me, the most important thing is consistency, rather than the form. So I’m OK with using the Discourse post if it can be structured. As a new user, I haven’t figured out the organizational structure. But maybe it’s just me.

5

@lin_d_hop would suggest adding a couple of tasks pre-development where there is an allocation of who is going to work on it, and then a kick off where those people gather and discuss scope and the devs decide how they’re going to approach it together/who does what.

Given the ‘Product Owners’ are part of the definition of done for the phase I’d suggest further up you need a step to determine who the Product Owners are for the work.

Perhaps we could have a scoping budget for anything new? Kind of like what we did with multilingual, where we got Maikel to estimate how much time he needed to design and estimate a solution. I wonder whether we can get a view on how much it cost to scope multilingual, or maybe better the embeddable shops or the bulk upload stuff and then try to come up with an average cost to scope? Not sure, maybe it’s more along the lines of the ‘estimate to estimate’ process where for each feature to be bitten off we get the lead dev to quote on how much time they’d need to do a solution design, and then add to that time x number of hours for the others who join in on the speccing meetings?

7

Oh, one more thing in relation to what @jveilleux noted on having a template. I really like the idea that they have in this article, about transmissions. It’s a really simple way of way of describing to everyone regardless of technical ability just what is being built, the problem it’s solving, and how we know it works (success criteria).

The scope section could be dot point line items (that are then turned into the stories that are put into GitHub?), and then the technical design could follow on from there. Including who is playing specific roles in this is also needed as this will change per piece of work.

Taking it up a level though, thinking about our information/communication needs across this process:

Initial idea development = Discourse discussion within ‘wishlist’ category

Scoping (speccing) = slack, google hangout/mumble session/s, more comments on discourse.

Summation of this into a concise view of what we want to build = Discourse wiki page within ‘development’ category shaped into something like a Transmission template, linked to the original wishlist item

High level solution design view = ?

Solution stories and tasks = a GitHub Project with issues, epics, etc.

Development pipe = slack channel, global-virtual-standup, GitHub Project moving across a board to done.

Community testing = slack channel to communicate how, as well as the original Transmission Discourse page that outlines scope.

Project spend/hours tracking = ?
Issues tracking = ?

Additional thought: I wonder whether we could embed the github stories onto discourse page so that non-github users can see scope broken down that way…?

1 Like
8

I am glad to see this line of thinking (although I don’t totally understand it) But one of the things I struggled to figure out initially is how new features get proposed, developed, released, and how I (if I) take part in that. So this is a great help for newbies. There is one specific ‘step’ that I still struggle with and I invite feedback. I often do feelancing/consulting on local food assessment kind of projects. In this work there is never any kind of costing for the specifications. So I was surprised at the idea of ‘estimates to do an estimate’. It feels like a chicken and egg conundrum to me - you can’t commit time to do detailed estimates without funding. In my world of proposal writing - no one ever funds the time to write the proposal. I’m not saying we shouldn’t find a way to fund the estimate work - I think we should (I wish funders would fund my proposal development work.) But - how to do this? I wonder if there isn’t some type of a fund that we try to build that is not project specific. Instead it pays for detailed estimates? Feedback from those of you more familiar with how this all works in the development freelancer community is appreciated.

9

Hey there @tschumilas great to have you in on this conversation!

Working in digital consulting or hiring agencies to do work we’ve always paid or asked to have paid the scoping and specification part of the work. One agency I used charged $5000 + tax to run an inception that defined scope, designed the solution, and created a project charter with costings and timings etc. The software development company I worked for offered a day’s worth of time from the presales team to “scope” the work to be done before a high level proposal was written that included a proper inception period to lock this down. The only part of this proposal that had fixed cost was the inception, the rest of the quote was to be firmed up post-inception.

What you find is that freelancers within the software industry don’t necessarily do presales work to get a gig. They are hired as part of a team and scoping/solution design is part of the work they’re paid to do. Or they’re within an agency and the cost that they charge to customers includes coverage of presales and proposal overheads. Which means that regardless of who is paying for the speccing (the agency as a presales task or the customer as a fixed price inception cost) the people doing the speccing work get paid.

10

I appreciate this - Thanks. It helps me explain how OFN does development work to food enterprises. Its helpful to know a bit more about the culture of digital consulting.

11

Moving relevant parts from an email chain so that all can participate . .

Lynne laid out a proposed process for how we improve this [transparency, clarity, spec and contributions] for new projects going forward (this thread) - I think we probably need to continue working on that to get it clear. I am also unsure the extent to which we have this happening for more recent projects like bulk upload, multi-lingual etc. I think there is a balance of transparency and overhead of written specs where one dev is just working on something (e.g. Matt on embeddable shopfront), but getting through review/merge and testing it is always going to be useful to know what something is meant to do.

Also, I believe that @enricostn @lin_d_hop @MyriamBoure @CynthiaReynolds had conversations at Ouishare about global product strategy and need for some process around this. I am eagerly anticipating the notes from this discussion, and hoping that we can make use of Lynne and Enrico’s visits to Aus in December to have some extreme quality face-to-face work on this!! Perhaps this would be a priority discussion at the next global hangout? Would one of you be willing to lead that?

12

I have put this on the agenda for 12th Sept and unless we get a more competent volunteer I will open the discussion