4 ms·
Don’t do “projects” at all. Instead, Everything is either an “enhancement” or a “defect” broken down into the smallest deployable chunk. These can have themes
by tatersolid 9y ago
Don’t do “projects” at all.
Instead, Everything is either an “enhancement” or a “defect” broken down into the smallest deployable chunk. These can have themes (epics), labels, and dependencies.
Prioritize in consultation with the business, but don’t plan more than a few months ahead.
This actually seems to be working for us in SaaS product management, infrastructure management, even managing packaged internal-facing “crapplications” like financials.
The budgeting, funding, and measurement practices surrounding “projects” is so broken in most orgs that you almost have to do this.
- baxtr 9y agoInteresting concept. But what if you start building from scratch?
- jaredhansen 9y agoIt's the same thing. You start by talking to customers to get an idea of what to build, then you create a mockup of what you'll build and then show that to customers and iterate until there's demand - now you have your first set of Things to Build, and they'll all be "Enhancements" at this point, since you haven't built anything yet. Once you've done that, you get that first draft in front of customers, collect feedback, and you'll find the feedback is a mix of "x is broken" and "wouldn't y be cool". And you're off to the races.
- deleted 9y ago[deleted]
- dragonwriter 9y agoThen there is some minimal unit of functionality you want to deliver first.
- tboyd47 9y agoThis is called Kanban I believe.
- alistairSH 9y agoYeah, Kanban is an implementation of this concept. But, you could do it without calling yourself kanban or using any kanban tools.
- dragonwriter 9y agoKanban can support this, though it's not exclusively used for that. But the proposed approach is at a higher level of abstraction than Kanban.
- nextos 9y agoIn Japanese lean manufacturing, Kanban is an object. It's interesting to see how it's been adopted in software development as a methodology.
- alistairSH 9y agoYeah, the software process was developed from the Japanese manufacturing processes (which use kanban cards as singals in their inventory systems). The basic concept is the same - minimize wasteful work in progress. In manufacturing, this is excess inventory at any point in the production pipeline. In software, this is excess tasks in a state of partial completion.
- tatersolid 9y agoPretty much. The product managers and architects have to show the discipline to prioritize the enhancements needed to complete a major theme or epic. The reality of “projects” is that they are always interrupted by other high-priority items, and months later everyone asks why it’s late and over budget. So just embrace the chaos and make continual prioritization your “project” discipline
- aytekin 9y agoThe problem with that approach is that your product becomes cluttered and looks old as years go by with only small enchantments and fixes. Here is a middle ground: continuous improvement with yearly strategic planning. https://medium.com/swlh/how-we-develop-products-for-3-2m-users-f5ec8895ee47 https://medium.com/swlh/how-we-develop-products-for-3-2m-use...
- jpfed 9y ago>The problem with that approach is that your product becomes cluttered and looks old as years go by with only small enchantments and fixes That's why you have to throw down a Tranquility/Jokulhaups combo every few years; get a fresh start.
- tatersolid 9y agoTotally untrue, we actually rebuilt several complex services this way, and did a front-end refresh as well. So long as you prioritize the starting “enhancements” of a theme or epic it can work. These early tasks usually produce architecture diagrams, API signatures, wire frames, or demo code.
- OnlyRepliesToBS 9y agoLooks old? It's called MATURE SOFTWARE. The BEST kind of code is the kind that IS JUST FINE by itself. Today it's more about looking busy.
- maxxxxx 9y agoYou can't build something from scratch that way especially if there is a lot of research and unknowns involved.
- dragonwriter 9y ago> You can't build something from scratch that way Yes, you can. Especially a from scratch automated system to enhance an existing business process, but also a from-scratch process and system together. > especially if there is a lot of research and unknowns involved. The research part is distinct, but as it produces results and those are feed into a “what do we want to do” decision making process, it absolutely can feed exactly the kind of incremental development process described, which can even operate in parallel with much of the research.
- maxxxxx 9y ago"The research part is distinct, but as it produces results and those are feed into a “what do we want to do” decision making process, it absolutely can feed exactly the kind of incremental development process described, which can even operate in parallel with much of the research." I work on stuff where you often have to scrap three months of work and try something else. You can't do this incrementally. But I agree, once you have a rough idea where things are going you can switch to incremental mode.
- ecaradec 9y agoHow do you manage not having multiple people working on the same thing ? Do you have some way of distributing work ? Just talking informally without a central written document often ended up with people starting working on the same thing simultaneously in my company. Kanban did solved this for us.