Hacker News Reader

Comment by tatersolid | Hacker News Reader

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.

View on HN

The 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-use...

>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.

Totally 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.

This is called Kanban I believe.

Yeah, Kanban is an implementation of this concept. But, you could do it without calling yourself kanban or using any kanban tools.

Kanban can support this, though it's not exclusively used for that. But the proposed approach is at a higher level of abstraction than Kanban.

In Japanese lean manufacturing, Kanban is an object. It's interesting to see how it's been adopted in software development as a methodology.

Yeah, 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.

Pretty 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

How 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.

You can't build something from scratch that way especially if there is a lot of research and unknowns involved.

> 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.

"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.

Interesting concept. But what if you start building from scratch?

It'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.

Then there is some minimal unit of functionality you want to deliver first.

Reply on news.ycombinator.com