
Ask HN: Best project management practices in 2018? - lambdadmitry
&quot;Agile&quot; and &quot;scrum&quot; were the hotness a few years back, but now it seems that the hype mostly subsided. It&#x27;s reasonable to assume that the Agile practices are put in context and incorporated into the mainstream now. Are there any recent works on project management that systematically present modern best practices? What have we been left with few years since the Agile revolution?
======
rishirishi
I have been through waterfall, agile, scrum, "agile", "scrum", kanban, to-do
lists. Yet, I cannot point to a single style of project management as a silver
bullet. However, I have come to realize the following conditions improve the
probability of success: small teams made up of scary-smart accountable people,
given a well-articulated objective (not solution) and are left alone without
distraction. Short of this, you almost always fall in the trap of micro-
management.

~~~
soneca
This is cool and fits well with the mindset that management is not only not
part of software development, but it is an inferior category of work. But it
is ultimately a useless answer. I am pretty sure the USA basketball Dream Team
didn't need any management process too to win the Olympics. How does this help
any other team ever?

I am myself for sure not a _" scary-smart"_ person, so it means that I
basically will never be on a successful team?

I prefer the answers to this question that apply to mortal developers.

~~~
matt_s
I think you're reading into the answer a little too much. The role of a scrum
master is really to shepherd the work through, not micro manage.

In software, a manager's job is to help plan work and shield the team. It is
critical that they can do this diplomatically with their peers. Planning
involves career guidance, budgets, meetings. If you don't have someone doing
those functions properly, the dev team is inundated with distractions.

Scary-smart is buzzwordy and really isn't needed for a team doing CRUD apps of
some kind. You need self-sufficient competent people not some "rock star" or
"scary smart" person. There's a reason why stereo-types are there indicating
those types are hard to work with.

------
JepZ
Agile is still the way to go and while many organizations have started
becoming more agile they are still far from _being_ agile.

In my opinion, Scrum is part of the problem and the worst of all agile
methods. Its strength is certainly that it is very well defined what you have
to implement to 'do' Scrum, but as the agile manifesto states, being agile
means to value

> Individuals and interactions over processes and tools [1]

So when you implement Scrum in an organization, you build processes to enforce
interaction. That is not wrong by itself, as that is how classical
organizations used to work, its just not very agile. The problem arises when
the management thinks 'We implemented Scrum so we are agile now', because in
reality they just started to become an agile organization.

I am not completely against Scrum as it is a reasonable first step to
transform a classical organization the an agile one. I think its just wrong to
see Scrum as the final goal and be done with agile as soon as you implemented
Scrum.

In the end, becoming agile means to change the culture of a company and as you
might have heard:

> Culture eats strategy for breakfast

So it will probably take some time.

[1]: [http://agilemanifesto.org](http://agilemanifesto.org)

------
lostcolony
The hype has subsided because so many organizations adopted the shell of an
agile methodology (oftentimes scrum, having meetings called standups and
things called stories), paid lip service to its tenets, but never actually
incorporated the core concepts in how they work.

So that said, I'd say modern best practices are still agile. The trick is
recognizing and convincing an organization they aren't actually practicing
agile, they're practicing cargo cult agile, and to get them on board with the
necessary changes.

That said, if anyone has any good resources on how to explain and affect that
change, convincing higher ups who believe that they're already agile that in
fact they're just cargo culting it, and to instead implement the scary changes
that are required to truly be agile, I'd be interested.

~~~
brlewis
Right now I'm at a place where agile is done well. But over the years as I've
seen management consultants come through different organizations, I've learned
how it's done: Rather than convince people that they never understood and
practiced the old concepts, you instead give the old concepts new names. Then
they don't have to say "we're finally doing what we talked about years ago",
and instead "we're adopting this exciting new thing!"

~~~
lostcolony
I've tried similar things, but any time it's been communicated upwards the
response has been (essentially) "That sounds scary. Where's the research that
says that'll improve things over this awesome agile thing we've been doing and
that all the marketing buzz says is awesome?"

I totally am in agreement that you have to treat it as some new thing (rather
than them just doing the old thing correctly, instead of incorrectly as they
have been), but even assuming they were on board to consider it, it gets
tricky. Do you just rebrand agile? Then they're going to screw it up the same
way. Do you take a more prescriptive approach, that this new 'eliga' (agile
spelled backwards) process means we do it -this- way? Because then you're not
really doing agile, and teams that need to operate differently are not going
to be as productive. Etc

------
deckard1
Read The Mythical Man-Month, internalize it, and realize nothing ever changes.

Organizations took up "Agile" because they wanted to _be_ "agile." But Agile
is not agile. Not even slightly. In most organizations, it devolves into
Painful Waterfall. Or Yelling At My Boss Waterfall. Or Product Yelling At Boss
Yelling At You Yelling At Each Other Waterfall. Not even joking here. Dead
serious.

Corporations pick up Agile because they want to chase their hopes and dreams
like the precious blossoming start-up they wish to be. It's a risk-averse way
to dabble in the shark-invested start-up waters. In almost every start-up I've
been in, I've had ssh access to production servers and modified production
databases. When your business is facing life or death, all niceties go out the
window. That unit test won't matter when your company goes under in a week.
Big corporations don't see that, though. They just see the scrappy start-up
eating their lunch.

~~~
CoolGuySteve
I mean who wouldn't want to be "agile". What's the opposite of agile?
Lethargic?

It's double-plus good.

Although now that I think about it, there's something to be said for lethargic
development. Move lazily and fix things.

~~~
matt_s
Brainstorming here about software projects you wouldn't want to be agile.
Agile being where you are shipping to production in short cadences.

\- Healthcare system software - not IT but like software on those blood
pressure monitor, drug dosing things hanging beside patients. You want to get
those types of things right.

\- Software for anything in the military involving weapon systems.

\- Nuclear power plant control software.

I honestly believe that 95% of software developers don't touch these types of
things but I would think these are cases where a waterfall approach with heavy
QA cycles is desired.

------
rdtsc
I like the WhatsApp approach:

* Hire smart people

* If a bug is found, investigate and fix it right there and then

* Have a 0 bugs backlog

* Minimal software footprint. Don't put your software you don't need in you stack

* No QA team, no waterfall, no kanbans, scrums

* Lots of small, simple deploys (no one big change the world updates)

Here is Jamshid Mahdavi talking about it.

[https://www.youtube.com/watch?v=tW49z8HqsNw&t=323](https://www.youtube.com/watch?v=tW49z8HqsNw&t=323)

FB teams apparently approached them asked what practices do you follow as they
were impressed by the reliability of the service, especially at their scale
and given the number of people they had.

~~~
bsvalley
From a product perspective it sounds awesome. As a user I won’t have to deal
with new user interfaces every month. Tiny increments while maintening a very
high quality. From a developer perspective though, it sounds pretty boring.
I’d not want to work in this type of environments.

~~~
rdtsc
> From a developer perspective though, it sounds pretty boring. I’d not want
> to work in this type of environments.

Completely understandable. You should find a company whose goals and practices
align with your own.

Now obviously WhatsApp does get new features, I am sure it didn't stay the
same since day one. But I think there is way to break up new features into
small bits and then deploy it very gradually and carefully.

I guess that's the bottom line with their approach "be careful". It's
mentioned right in the talk. If you're careful (and everyone else is) there is
less need for complicated processes.

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

~~~
tboyd47
This is called Kanban I believe.

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

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

------
JimDabell
> It's reasonable to assume that the Agile practices are put in context and
> incorporated into the mainstream now.

Not in the slightest. The ceremonies are widespread, but the principles you
need for them to be effective are not. Read the Agile Manifesto[0] and compare
that with, say, the horrors of SAFe[1] that "Agile" consultants tend to
inflict on organisations. They are essentially the opposite of one another.

[0] [http://agilemanifesto.org/](http://agilemanifesto.org/) [1]
[http://www.scaledagileframework.com/](http://www.scaledagileframework.com/)

~~~
feverdream
Can you elaborate on why you don't like SAFe? I'm really curious to hear your
thoughts.

~~~
JimDabell
It's difficult to explain succinctly. SAFe is the embodiment of the kind of
enterprise bureaucracy that agile was rejecting. Take a look at the principles
espoused by the Agile Manifesto:

* Individuals and interactions over processes and tools

* Working software over comprehensive documentation

* Customer collaboration over contract negotiation

* Responding to change over following a plan

Now imagine what the _exact opposite_ of this would look like, and then take a
look at SAFe.

------
ryanmarsh
Agile Coach here.

I took a break from engineering and leadership about 6 years ago to give Agile
Coaching a try. The prospect of solving the greatest problem in software
development intrigued me. The problem being: how we work together. I learned a
lot in the military about servant leadership, about pushing decisions down to
the lowest level, empowered teams, and reacting dynamically to a changing
environment.

“Agile” unfortunately is nothing more than a knee jerk reaction to the
problems in project management that came before it. There are no “first
principles”. I’ve been planning a conference talk on this for a while but I
don’t know where to give it.

Everything in Agile is anecdotal, secrets of success, dogma and religion (they
even call things ceremonies!). What I want, and what I think we deserve is a
first principles based approach to how work together. There are enough fields
of study surrounding how people work together to make software that I believe
we could uncover a set of laws or testable axioms. Just consider the following
areas of science that effect how people work together and build systems:
computer science, positive psychology, group psychology, semiotics,
information theory, complexity, human computer interaction… the list goes on.

What we need is more science, reason, and principles, less dogma, religion and
manifestos.

------
tootie
I think Agile and Scrum (and Kanban) are still in ascendance and I think that
as it percolates throughout enterpises, businesses are actually starting to
understand that going through the motions of Scrums doesn't make you agile.

I still push Scrum on new teams and I think it works well, but you can't just
push it down (on dev teams) and not also push it up (on stakeholders). They
need to understand the value of the iterative, quality-first approach and
having to accept some uncertainty on delivery timing. That's not even an agile
thing, that was made clear with the Project Management Triangle decades ago.
You want quality, you have to flex on scope or timing. Either set that
expectation first or your execution team is doomed. If you push a quality-
first approach but still have a fixed scope and timeline, you are now in death
march.

------
vemv
I'd go for a Kanban-like approach augmented by a tool that isn't as bare-bones
as Trello. Clubhouse is my personal favorite.

Also, a trend/mindset that should have taken over (but hasn't) is
[http://asyncmanifesto.org/](http://asyncmanifesto.org/) . Generally it is a
must if any % of your dev team is remote-based. Else at least one part will
suffer.

~~~
priyadarshy
We've been using Trello for a while and I've never thought of it as bare
bones. It seems quintessentially kanban, in your opinion what's missing or
simplified?

Do you have any opinions on "calendar kanban's" like Sunsama:
[https://medium.com/@landon_46280/scrum-with-sunsama-
ddb5e8e7...](https://medium.com/@landon_46280/scrum-with-sunsama-ddb5e8e76876)

------
zitterbewegung
Track what you have to do such as keeping a TODO list or a list of tickets or
a Kanban.

Communicate well and with others.

Write down things that you forget. Keep notes and keep a physical notebook.

Don't come into a discussion mad.

Treat people with respect.

------
dragonwriter
> "Agile" and "scrum" were the hotness a few years back, but now it seems that
> the hype mostly subsided. It's reasonable to assume that the Agile practices
> are put in context and incorporated into the mainstream now.

Well, “reasonable” perhaps, but AFAICT still wrong. Agile was defeated by the
same kind of cargo-cult, one-size-fits-all, consultant -pushed practices that
the Agile manifesto railed against.

Elements of Scrum, deployed in a decidedly non-Agile way, have become part of
the mainstream, though.

~~~
yesenadam
I couldn't help thinking of Jesus and Christianity here—although the analogy
has some ludicrous aspects. I guess this is a universal (anti-)pattern in
human affairs.

Christianity became at every point a near-opposite of anything Jesus stood for
- later Christianity has meant the 'gospel of success' and wordly prosperity,
priests in gold-encrusted palaces, polytheistic worship of Mary and the
saints, Greek-derived theology (heaven and eternal life is straight out of
Plato), angels etc.

H.L. Mencken on the subject:

 _Treatise on Right and Wrong_ , 1934, p254-5:

The mob, having heard Christ, turned against him, and applauded his
crucifixion. His theological ideas were too logical and too plausible for it,
and his ethical ideas were enormously too austere. What it yearned for was the
old comfortable balderdash under a new and gaudy name, and that is precisely
what Paul offered it.

 _Notes on Democracy_ , 1926, p66-7:

Christ, we are told, preached no complicated mysteries and demanded no
pedantic allegiance. He knew nothing of transubstantiation, or of reserved
sacraments, or of the adoration of the saints, or of the vestments
controversy. He was even somewhat vague about original sin. Alive today, could
He qualify as a bishop? He could not. Even the Salvation Army would put Him on
probation, at least until He had mastered the cornet. Even the Christian
Scientists would bar Him from their auctionblock, at least until He had got a
morning coat and paid cash for a copy of “Science and Health.” What would the
Congregatio Sancti Officii say of His theology? What would the Methodist Board
of Temperance, Prohibition and Public Morals say of His ethics? What would
Monsignor Manning say of His patriotism, or of His economic views, or of His
probable opinion of the great spiritual filling-station on Morningside
Heights? What these high authorities would say, I venture, would be a plenty.

------
no_identd
Taiichi Ohno - Workplace Management (1988).

BUT: Get the 2007 retranslation instead, the original translation is
responsible for every horrible management fad since the early 90s.

And then go read some W. Edwards Deming, and maybe some Davis Balestracci, if
you can afford the latter's ridiculously expensive book.

And start reading qualitydigest.com.

Any production process that doesn't focus exclusively on quality and quality
alone is doomed to failure. The problem is that most people have a horribly
naive understanding of the word "quality". (Go try figuring out it's etymology
if you don't know why I say that to get a start on figuring it out.)

------
dodgyb
Communication and risk management are the essence of project management, i.e.
those making a bet of a project need to know that there is a fair chance they
will get a return on their investment.

OKR's are good for outlining requirements, but the project needs to be viable
so start by validating the business case. This includes TCO - how much will it
cost to build and how much to maintain.

Project requirements come in many guises: building skyscrapers, changing
business processes, designing new tools, etc. etc., so choose the method to
suit the requirement and the environment.

Providing an environment where contributors can excel is key. Proscriptive
methods like scrum are useful when bringing teams together, but once they have
found their feet let them organise themselves. Good governance is crucial for
making this work - Cyranix's comment makes some good points on this.

The Manifesto for Async Software Development is a "21st century successor to
Agile" and has some useful tips for working with distributed teams, which
seems to be the way things are moving:

[http://asyncmanifesto.org/](http://asyncmanifesto.org/)

Both Cyranix and the Async Manifesto make a point of documentation. I would
add that all design decisions should be noted with details about the reasons
for the choice, and also the options considered and reasons why they were
discarded. This will help with learning from retrospectives.

------
jimnotgym
I wonder if this thread has fallen into the trap of talking about the
fashionable stuff instead of what is actually in use...in the same way a
newcomer to software on HN might be forgiven for thinking that the majority of
software is written in Node or Rust, and rather underrepresented the amount of
Java actually in use.

When I hear Agile, experience has taught me to suspect that these guys don't
spend enough time writing requirements. In the mid market web agencies Agile
is a synonym for 'we don't do project management.

I visited a software company recently who are still using a lot of VB6(!), and
they are having a big drive to modernize. But instead of finding a new GUI
framework they just employed a Scrum-master to re-arrange the deck chairs on
their Titanic and some ex-Oracle sales guys to paper over the cracks.

I suspect in the UK, if you are to be engaged on a project to implement a new
feature for an enterprise customer like a bank, or you are in a mixed
hardware/software environment you may see Kanban/Agile for little sub-teams,
but the actual project will be running under Prince2.

Prince2 is _how you do projects_ in UK enterprise/government, and if you are
writing software as part of an enterprise project you will be under Prince2 as
well. However Prince2 is pretty flexible about letting you run individual
tasks the way you want, don't expect to be able to reshape requirements on the
fly without having to justify how that affects the 'business case'

I would be interested to hear if that was not anyone else's experience?

~~~
firegrind
ITIL is common enough, as are less formal strategies adopted by project
delivery teams, departments and more lateral communities.

Without organisational support for agile adoption, from C-level down, agile is
very unlikely to be successfully implemented because at some point the team
who collectively contract to deliver a testable result in a sprint will
derail, or be derailed by a conflicting schedule.

I guess it's the same phenomenon that was observed when people noticed that
the waterfall software lifecycle was more of a spiral model, and started
exploring Rapid Application Development techniques. There's nothing new under
the sun.

------
maxxxxx
I think the Agile Manifesto is still valid and a great guidance. Also, the
principle that between features, delivery date and staffing you can plan for
two ahead only, but but not all three.

Unfortunately "Agile" as practiced is almost the opposite in most cases. With
traditional waterfall at least people thought about things upfront. With the
way a lot of companies do Agile there is no place left for thinking, it's more
like mini-step waterfall without upfront design.

------
SatvikBeri
I really like the theory of constraints, as espoused in books like _The Goal_
by Eliyahu Goldratt.

It's more of a philosophy than a set of tactics, but I've found that it
applies quite well to any process that involves projects having to pass
through multiple teams in order to become something valuable to the customer;
which includes most software.

------
jvagner
I found this, plus the ICE link, pretty close to processes I've had to develop
for a recent engagement:

[https://hackernoon.com/why-i-stopped-using-product-
roadmaps-...](https://hackernoon.com/why-i-stopped-using-product-roadmaps-and-
switched-to-gist-planning-3b7f54e271d1)

------
gnode
Can anybody suggest any management practises for single person projects? While
you could do Agile / Scrum, elements of them (the meetings) are certainly not
applicable. I've heard of Getting Things Done, which seems to have parallels
with agile.

~~~
cmmin
I have started practising GTD and have found it great so far. I recommend you
pick up David Allen's two books. Takes a weekend to cover them properly and
another few days to shift approaches.

------
tylertreat
Check out OKRs for tying back longer-term planning into shorter-term
deliverables: [https://blog.realkinetic.com/okr-
process-489891e6b6a8](https://blog.realkinetic.com/okr-process-489891e6b6a8)

~~~
dood
OKRs sound like a reasonable idea, but in my experience appear to be
prohibitively difficult to implement successfully, imposing a considerable
burden across the organization which isn't at all commensurate with the value
they deliver.

I've seen them done in a few places, each time they tend to be delivered late
and/or be constantly shifting, are constantly in conflict with important but
unstated objectives, are often hard to measure and inevitably used to judge
performance despite protestations to the contrary and so are subject to
gaming, are bad for morale, and for all those downsides seem to have somewhat
limited effects on output.

The primary benefits are aligning people, giving people clear goals to focus
on, and giving people a justification for not doing unnecessary work. All of
those things could be achieved at far lower implementation cost by ditching
the key results and just establishing clear goals at the top and allowing them
to semi-formally cascade with some kind of regular but very lightweight
process.

------
scarface74
Kanban.

Done correctly, it allows the product owner or manager, to rearrange
priorities dynamically as long as they aren't in progress, it surfaces where
resource or process issues are causing a bottleneck and there isn't as much
ceremony.

~~~
maxxxxx
Kanban is definitely much better than Scrum.

~~~
33W
My assumption is that Kanban has ongoing demos to the product owner as work is
completed. In that case, the consolidated demos in Scrum may work better when
you need to gather extended stakeholders (legal, compliance, design, etc).

~~~
scarface74
One of the steps in the Kanban process, before It goes to Production is UAT.
If the UAT WIP Limit gets above a defined threshold it's time to do a demo and
bug the people who have to do the final approval.

------
muzani
I think we still need better practices. Agile/scrum is better than no
management at all, but I find that the best teams I've worked with simply used
a giant to do list.

Agile works well in larger organizations where people are doing the work as a
way to earn money, and don't really think of it all day.

For some teams, it's a lifestyle. We talk about stuff that needs to be done
over and over again. At lunch, before bed, after showers, while waiting for
the bus, while driving to the movies. You don't really need stand up meetings
because everyone always knows where the project is and where it's going.

------
cyberlync
Agile and Scrum (big A/S) have faded into agile and scrum (little a/s). The
'One True and Holy Process' has faded into a set of processes that
organization iterates on. The process should be fit to the team/organization.
The team/organization should not be fit to the process. Personally, I have had
good luck with a mix of kanban, with multipart estimation and Monte-Carlo
simulations for projecting completion dates. So far its worked well and
managing change while being able to predict completion times.

------
stephenson
Go and read Marty Cagan's book on product management:
[https://www.amazon.co.uk/Inspired-Create-Tech-Products-
Custo...](https://www.amazon.co.uk/Inspired-Create-Tech-Products-
Customers/dp/1119387507/), I am also blogging a bit about how a successful
product team look here: [https://www.stephenson.dk/successful-product-
team/](https://www.stephenson.dk/successful-product-team/)

------
rhombocombus
Based on my experience (primarily enterprise level data development) Agile can
work if the product is ideally suited to it. By that I mean a reasonable
number of stakeholders, and documentation and the product are in a state that
can support rapid iteration. When management complexity and product complexity
increase I begin to lust for the dreaded waterfall, because it can become
onerous just defining requirements in an environment that is particularly
chaotic or troublesome.

~~~
NittLion78
For large efforts, I've always subscribed to "define waterfall, build agile".
If you don't really hammer away up-front on all the possible avenues
stakeholders want to explore in an end product and get those fully listed out
and vetted before even the first line of code is written, then the "agile"
portion should be simply changing directions on which of those things are
considered most critical to delivering a minimum viable product based on where
you currently are in the overall effort.

Too often real work begins to get something concrete for stakeholders to react
to (the general point of Scrum & Agile) while losing sight of the ultimate
goal because it was never really defined very well to begin with. That just
means more rework. Some rework is unavoidable, but so much of it is.

You can control which mountain you want to climb and you can and should select
which face of the mountain makes most sense to use as your path up it, but
have a way to move laterally to a safer path up if the weather goes south.

~~~
bahmboo
Product owner says build feature x this iteration by way of showing progress.
Customer has explicitly said they are only interested in y. Whole team knows
that x will have to be completely tossed out when building y. That's when
agile fails. If you know what you are building it's a good idea to take that
into account.

~~~
NittLion78
Agreed. That's the sort of rework that I think can be avoided by a good
partnership between the PO and the stakeholders in the nascent stages before
physical work begins.

I guess the reason why this happens is this weird psychological block in
people's minds that software is totally mutable and flexible and therefore can
change to whatever you want it to be, even after the fact. You'd never go into
that mindset when building a physical structure, but the amount of re-
architecture required to enact such changes in software can be just that
monumental.

~~~
bahmboo
I was able to break the impasse and build trust by getting PO to agree to
architectural deliverables in a sprint. He was skeptical but with some sort of
defined behavior for acceptance he was OK with it.

Saying "ima go build a framework for this, back in a couple months" is usually
a non-starter.

Also from reading this thread I am still convinced that you cannot jam process
down people's throats and there is no single solution. What you can do is
create a tone deaf hated ass-backwards process that make people quit the
company.

------
jarl-ragnar
I've worked across a spectrum of projects of differing sizes comprising teams
small and large, often spanning multiple contracting companies. The short
answer is: adjust your approach to suit the project conditions, but you need
to start with a clearly articulated objective.

Agile, in it's many flavours (scrum, kanban etc), is at it's heart simply
trying to minimise Work in Progress (WIP). This view gives the direct link
back to the Lean Manufacturing movement and the Toyota approach to Lean
processes and Continuous Improvement. Any WIP inherently accrues risk - the
risk you are building the wrong thing, or the right thing with the wrong
quality. Hence minimising WIP is about trying to identify the smallest amount
of work and drive it through to the finish so you can identify if it is indeed
the right thing. So Agile in a SAAS context is about shipping the feature into
production and using direct customer feedback to retire the risk that you may
have built the wrong thing. All good but it doesn't scale to a large contract
where you have pages of requirements written by the customer. That's why in
the "waterfall" world you have design reviews aimed at creating a
representation of the design that can be reviewed, critiqued and revised
before cutting any code.

Similarly as the team size increases you have to expend more effort
documenting the design such that you can apportion work to sub-teams and be
confident they will create the component you want.

If you view Project Management as Risk Management you can't go far wrong. Just
list out all of the assumptions you are making and turn those into your risks.
Then work through them in priority order.

------
dmitriid
My previous jobs:

What worked for X (200 people in engineering) didn’t work for Y (8 people in
eng) didn’t work for Z (1600 people in eng.)

What worked in isolated teams didn’t work in cross-functional teams didn’t
work in cross-domain teams etc.

You find what works for your specific setup, and stick to it. If it doesn’t
after a few iterations, you change it. Rinse, repeat.

Current setup that works for us:

\- Company-wide broad initiatives for the coming year, prioritized.

\- Quarterly planning for teams with goals and projects aligned with company
initiatives.

\- Our team has week-long sprints, with a retrospective every two weeks.
Issues are prioritized by technical and product leads of the team, so at the
beginning of the week we know what the most pressing issues are, and how many
of them we can take on (and complete within a week).

\- Once a month there’s an all-hands were all teams in our domain discuss
their progress on their projects/goals (because that may and will affect
dependent teams).

Is it perfect? No. Does it work for us? Yes. Do people question this? Yes, and
we make adjustments as we go along. Is it agile/scrum/kanban? I don’t know and
I don’t care :)

—————

tl;dr

\- Prioritize your shit on all levels (company, department, team)

\- Select whatever processes you want to go throught the prioritized list

\- If processes don’t work, adjust/change them

------
bsvalley
Project management at a low level (small/agile team) is pure micro management.
Why? Because devs end up reporting to a PM everyday. It depends on the company
and the setup, but I’d say most of the time a project within an organization
has more power than a team. So a PM can do a lot of damage. Projects are
created at a very high level, if you’re a manager you’d actually enjoy having
a PM. It’s a good way to know your reports are under “surveillance”. Which is
very bad, but I see a lot managers doing that. Though, project management at
high level is crutial for a company and a large project.

So to answer your question, I believe that the next evolution of project
management is no project management. At least at a small scale. A tech lead
could be a scrum master reporting to an engineering manager, hosting standups,
working closely with a Product Manager (not a project manager) who creates the
backlog and a timeline. The engineering manager updates the upper management.
I believe adding a PM in the mix would only add more micro management. No
project managemers is the future.

------
madhadron
Someone already posted The Mythical Man-Month, and has been upvoted to the
top. This is as it should be.

There's been some interesting noise around adaptive case management, which is
doesn't try to treat software as a manufacturing process but as something more
like handling an insurance claim where you gain information and replan as you
investigate.

------
maxreh
Here's an interesting take on the state of agile and a way for modern best
practices to be created and shared. Calling it the #RetroOnAgile.
[https://hackernoon.com/making-agile-open-source-
retroonagile...](https://hackernoon.com/making-agile-open-source-
retroonagile..).

------
osrec
Simple rearrangeable list with a completion status per task. That seems to
work for us at [https://usebx.com](https://usebx.com) , as long as we get the
granularity right (i.e. each task is assigned to exactly one person).

------
jozi9
I'd say for starters, Scrum because it gives you a framework. After you get
used to the Agile methods, just tailor it or switch to Kanban.

I jumped on the Scrum bandwagon in 2008. It was refreshing after so many years
of waterfall! I have introduced it in 3-5 companies during the years, but
sometimes it just feels rather restricting (after you get used to it) in
recent years we started leaning towards Kanban-style, but we are still using
methods like planning poker, checking velocity, and doing standups. And of
course if you're not remote, you still need a taskboard - shameless plug,
we're selling reusable storycards for this!

[http://www.storycards.co](http://www.storycards.co)

------
deepaffects
Over years, I have been on both the sides, management, and development, in
software companies. These methodologies are guidelines, and to be tweaked
based on the company culture, team dynamics etc. For me, successful
implementation of the methodology is when I looked beyond the planning &
reporting aspect of teams. Important questions are, Do you have distributed
teams vs collocated teams? The maturity of the team members, years of
experiences in IT, working together? current collaboration and communication
challenges between team members, intra teams and teams and management? If you
spend time in analyzing these questions, you have good chance of success.

------
lolsal
I think the best project management practice is: "Don't adopt entirely new
project management practices every year." The caveat being: do what works for
your organization. Iteration on process seems to be a good idea all the time.

------
oblib
Wow... this question and the responses really make me realize how little I
know about working with teams on projects.

I had to go find descriptions for "Agile", "Scrum", and "Cargo Cult".

I thought software project management would consist of outlining a feature
set, selecting the tools to implement it, designing an API, delegating who
builds what and the order they work on it, estimating time to delivery,
setting goals and monitoring progress, having scheduled meetings to discuss
problems and solutions, and an "It's Shipped Party" when the product has been
delivered.

No one's even mentioned a shipping "Party" :D

~~~
ewjordan
Oh, there's a ship party built into the Process, alright. It's called the
sprint restrospective, and everyone sits around and argues for an hour about
what went badly during the sprint.

Even more fun is the sprint retrospective retrospective, where everyone argues
for two hours about what went wrong in the sprint retrospective.

I wish I was making that up.

Edit: it's not that I don't get the point of retrospectives, I do...but I've
seen them taken to comically absurd levels, and in any sizable team it always
seems to be the three people that care the most about their particular flavor
of Scrum that sit around arguing about how much better it was the way they did
it at their last company, meanwhile everyone else just wants to leave and get
back to work. A small number of loud people will always have strong but
completely arbitrary and anecdotal opinions about process, and in _my_ opinion
it's not healthy to give them a regular spot on everyone's schedule to
complain about it.

~~~
dood
Wow, sprint retrospective retrospective sounds nightmarish. I've never worked
in a team nearly that dysfunctional, but I wonder if the blame is due to
agile, or perhaps that team would end making any process or system into a
horrorshow. It may even be that the agile process provides at least some
_bounds_ to the effects of the dysfunction, if it prevents such discussions
occurring otherwise in the workday.

------
night815
[https://m.signalvnoise.com/how-we-set-up-our-work-
cbce3d3d9c...](https://m.signalvnoise.com/how-we-set-up-our-work-cbce3d3d9cae)

------
maxaf
My personal favorite is: get sh_t done without burning yourself out or making
bad decisions along the way.

Of course, it's possible that I have entirely misunderstood your question.

~~~
GoToRO
Do something small everyday. I declare the day a success after that. This has
worked very well for me because:

1\. doing something, anything, will move the project forward.

2\. I do not feel guilty if I stop and do something else. In turn this allows
me to continue the next day (well rested and without any guilt for beeing
"lazy")

~~~
maxaf
You said it better than I did, but I meant the same thing. I work on three+
projects at any given time in order to give myself room to do something small
on each one of them every day. When I get stuck on one thing, I execute a
context switch to another project and stay productive there until I hit a wall
or need to think about some problem. Rinse, repeat. This yields remarkable
productivity and leaves boredom in the rearview mirror.

------
NumberCruncher
After following the principles of XP in the last 18 months and getting things
done on my own that lets our dev team look live a bunch of lazy noobs I
realised that someone with a T-shaped skill set can make a decent living
without being involved in so called "projects". I do not know the answer to
the OP's question but am happy to say "I can allow myself not to care".

------
chasd00
for projects as service ( like consulting ) use kanban but incorporate epics
and sprints where epics are communicated to the client as just "phases" and
sprints are internal to the developer team.

your PM should also be able to do at least some solutioning. The best projects
i've worked on where ones where the PM was also the Solution Architect.

Every projects gets a TL ( tech lead ). This is the PM/SAs right hand goto
person. The TL handles the design and implementation of the SAs vision. They
also manage task delegation to the dev team, and acts as their escalation
point. The TL must be able to get up in front of the client and explain
technical jargon in a way the client understands it.

process = Kanban + epics/sprints Staff = 1 PM/SA, 1 TL, Dev Team

I've seen the above work very well in consulting for projects in the $2-3M
budget range.

------
toastking
This maybe isn't a project management "best practice" but one of the things my
team does that is great is that we insert JIRA ticket links into changelogs.
We also put revision numbers as well, it makes it really easy to cross-
reference stuff and let people know when something is fixed.

~~~
dcow
That's great! It's also been happening forever (:

------
sheepmullet
As an industry we have wasted an inordinate amount of time chasing
methodologies that add little value.

In many ways we have gone backwards - I used to be able to hire a promising
graduate and reliably turn them into a senior/lead in 3 years.

------
sputknick
tl;dr Agile is still becoming the "hotness", it just takes time.

In the enterprise space Agile is still going through it's growing pains. I was
in an org a few years ago which was __technically __implementing Agile, but
what they were really doing was what I would call "micro-waterfalls". It will
probably be 10-20 years until enterprises have something that resembles what
was normal in smaller organizations in 2015. The real challenge will be the
lack of formality around documentation and decision making. That is not
natural for large organizations.

------
amriksohata
Not really a practice but a lot of companies have adopted Netflix's HR policy,
here are some famous slides they published on how they work and hire, one
includes don't hire brilliant jerks

------
tboyd47
The original agile manifesto is still the best thing to go by, IMO

~~~
sidlls
The original manifesto is a litany of aphorisms and position statements with
little or no practical utility, and what to me appears to be a bias for what
is essentially spec work at an agency.

~~~
foopod
I am glad we are on the same page.

The problem is that these don't translate well when we turn them into
practical frameworks.

So how do we teach mindset?

~~~
tboyd47
The original manifesto makes the correct mindset super-obvious. It's very
succinct and still relevant to today.

Just take the first line, "Individuals and interactions over processes and
tools." Interesting how most "Agile (tm)" is just selling processes and tools
and pushing people into cookie-cutter roles.

Even better is what I consider "line zero": "We are uncovering better ways of
developing software _by doing it_ and helping others do it," (emphasis mine).
The lesson there being that the best people to teach you how to develop
software are, in fact, developers (not managers, execs, consultants...).

------
foopod
I still find it hard to believe that people still struggle to grasp the
concept of Agile.

It is not a solution to Project Management, it is an alternative.

I see a lot of other comments that struggle to see the concept put into
practice building a new product from scratch. Sure it doesn't make sense to go
straight into development. Use other "agile" practices like design thinking
and lean to build up to that point. Incremental can mean a lot of things, not
just a horizontal or vertical slice, but an iteration on an idea, on
architecture, on design or on planning. And there is no reason for a
development team to be absent from any of this process.

------
Cyranix
A lot of comments here seem to be focusing on project management as "how do
you sequence the day-in, day-out, never-ending pile of work". I would
encourage people to also consider a project as, y'know, a non-trivial discrete
set of work items that have a coherent aim. (For some people this is analogous
to an epic, but it doesn't have to be the case.)

If you think about projects that way, a few of my recommendations are:

0) Set up clear organizational guidance for project artifacts. Where will all
of the docs and spreadsheets go? How will you keep track of which issues are
relevant in your issue tracker? How can stakeholders get self-service updates
on the project? Keep labels and naming as consistent as possible across the
various services you use. For more formal situations, you might also need to
set up RACI or similar communication structures.

1) Define measurable outcomes as success criteria from the very start. Do you
want to increase customer lifetime value, or get more daily active users, or
decrease AWS spend, or...? You need at least one, and probably no more than
five if you want to stay sane, and they all need a target number. Measure your
starting number, and document how you calculated it, because you're going to
need to use the same method again later. (It really helps if at least one of
your measurable outcomes has a non-zero starting point.)

2) Conduct a pre-mortem. Everyone on the project (or representatives of each
role, if somehow your team is too big) gets together and imagines that the
project is complete but ended up going less-than-well. Brainstorm every
failure mode you can think of, then brainstorm ways to prevent or mitigate
each failure mode. Some failure modes are unavoidable, and it's good to
recognize that too. Create tasks to follow up on each preventative measure.

3) Set milestones to gauge progress. This can be lightweight and still be
useful. Each milestone allows you to evaluate the impact of unforeseen
challenges, whether the quality of work is high enough, whether scope or time
needs to be adjusted, and even whether to pull the plug early. Iteration
boundaries are fine milestones.

4) Conduct a retrospective when the project is complete and enough time has
passed to collect the appropriate metrics. Check the outcomes using the
calculations from step 1. Celebrate successes, assess shortcomings, and
brainstorm ways to improve the way that projects are run. It's surprisingly
important to be explicit about learning from past mistakes. Now you're ready
to rinse and repeat.

These principles are orthogonal to, or perhaps operating on a higher level
than, kanban or agile or what-have-you. None of the above ideas force you into
a waterfall methodology, but they may require you to think a bit harder up
front. It's also not incompatible with continuous deployment or other similar
development practices.

------
fbonawiede
[https://www.delibr.com](https://www.delibr.com)

------
joaofiliperocha
Agile requires discipline and that's hard to implement.

