Hi,
At my organisation, Wikimedia Sverige, we’re planning to adopt Shape Up for our development. We know that one of the very first things we’re likely to work with is to improve a Python library for a API. The API currently has capabilities that the library is not yet taking advantage of.
So, my question:
Does anyone have experiences or suggestions for how to best shape developments that don’t have GUIs?
Cheers,
David
I’m also using Shape Up for work that doesn’t have a GUI. The process really doesn’t change IMO.
That said, before you try shaping work, I’d consider interviewing devs “jobs to be done” style and find the measurable progress the product team actually wants to make. Is it better performance for end users? Access to new features? Increase dev speed? Reduce manual labor/time spent debugging?
I believe it’ll be easier to shape the work with a desired outcome in mind. “Improve a Python library” might well be the answer but the team may also benefit from exploring alternatives to achieve that outcome as well.
But, this is just a guess from a person who has only been doing Shape Up for 3 cycles and still very much learning. =) Best of luck!
The idea is just to stay high-level and not get too detailed (the developers/designer/architect team will decide the specifics). So, just work incrementally. What kinds of data do clients need from the API?
If it’s a Shipping Rates API, instead of defining the specific endpoints, parameters, and return values and pagination model (offset), you can just paint with a broader brush:
The API should require validation, it should return shipping rates given an address and package dimensions (size and weight).
Potential rabbit hole: “Printed-Matter” rates are only available for books, so there should be some day to determine whether the package contents is books-and-only-books.
Note: insurance should be optional and the cost depends on the package value (see “insurance table” attached)
Then let the developers sort out the specifics…
Hey David
We’ve not done too many projects that are 100% just backend API changes but the one piece of advise I would try to give is to beware of grab bags.
https://basecamp.com/shapeup/1.2-chapter-03#watch-out-for-grab-bags
I’ve found projects work best when there is a clear problem to be solved, else the scope can too easily expand endlessly and it doesn’t feel like anything gets done. Try to identify what the goal of the work is. Could it be improved performance? Improved developer experience? Then the question becomes how much by? How will we know when we are done?
Hope that helps!
Josh
Thanks!
The “jobs to be done”-angle is a good one! And I had certainly planned to break down “Improve the Python library” into something more concrete but not a full tech spec.
I guess you could actually see Jobs to be done as a shaping of sorts. That was really what I wanted to learn from others as the examples in the ShapeUp! book is centred around sketching and storyboarding GUIs at the right fidelity: what is the right fidelity for a sketch and storyboard for something that doesn’t have GUI?
Hi Josh,
And thanks!
Yes, absolutely. “Improve the Python library” was more of a shorthand than anything else. Do you perhaps have any examples you could share of what a shaped pitch for a piece of API-development?
Cheers,
David
Hi Max,
And thanks! Yes, someone much more a software developer than me should take the lead in shaping API-pitches esp. the “non-functional” improvements.
Do you perhaps have any shaped pitches for API-related developments that you could share? Looking for examples of pitches that don’t involve GUI-devlopments.
Cheers,
David
Not from scratch, unfortunately. We started building our API over a year ago, so now it’s usually just small changes.
Maybe just start with a mind-map. Here’s a partial mind-map of a system we built. Mind-mapping can be a good way to start thinking and communicating about the various entities and the Jobs-To-Be-Done (JTBD)
