Ask HN: Best project management practices in 2018?
"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. 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?
112 comments
[ 4.4 ms ] story [ 172 ms ] threadOf course, it's possible that I have entirely misunderstood your question.
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")
I do consider that an environmental 'code smell' though.
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.
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.
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.
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.
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.
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
That's why you have to throw down a Tranquility/Jokulhaups combo every few years; get a fresh start.
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.
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.
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.
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.
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.
If Agile ceremonies don't achieve this or otherwise excessively waste time, they're just a form of cargo-culting.
The problem is that these don't translate well when we turn them into practical frameworks.
So how do we teach mindset?
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...).
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.
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.
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.
https://hackernoon.com/why-i-stopped-using-product-roadmaps-...
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.
Also, a trend/mindset that should have taken over (but hasn't) is http://asyncmanifesto.org/ . Generally it is a must if any % of your dev team is remote-based. Else at least one part will suffer.
Do you have any opinions on "calendar kanban's" like Sunsama: https://medium.com/@landon_46280/scrum-with-sunsama-ddb5e8e7...
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/ [1] http://www.scaledagileframework.com/
Current company, we literally just implemented SAFe and now that I'm learning the ins and outs of that ... Org A was either SAFe before SAFe was cool or even existed or they are the Satoshi for SAFe. The similarities between what I see preached in SAFe versus Org A are scarily similar and when implemented - highly successful.
* 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.
For example, a scrum master is supposed to ensure a team follows agreed processes, in direct contradiction with one of the four values of the agile manifesto:
Individuals and interactions over processes and tools
A scrum master is someone running around dictating that everyone stick to processes. Usually that were "agreed" by management (i.e. dictated)[1]. This is also in direct contradiction to several of the principles.
I also love how the customer is shoved in the top right of the diagram, as far, far, far away from the developers as possible. Agile value 3:
Customer collaboration over contract negotiation
[1] Scrum itself is so far from agile and in direct contradiction of the principles I have no idea how they managed to convince everyone it's an agile methodology.
Ok.
> in direct contradiction with one of the four values of the agile manifesto:
> Individuals and interactions over processes and tools
But its not in contradiction. Agreed processes are the outcome of individuals and interactions, not dictates from authority external to the team. The individuals and interactions are superior to, and directing, the processes and tools; that is consistent with the line quoted from the Agile Manifesto, especially when considered with the line everyone forgets that immediately follows the "X over Y" statements: "That is, while there is value in the items on the right, we value the items on the left more."
The Manifesto is not calling for rejecting clear, well-defined processes in favor of chaos. Its calling for making process serve the team rather than vice versa.
The principles make it even clearer.
What's especially damning about Scrum is that there's courses, and prescribed tools, and prescribed processes. Exactly the opposite of what the values and the principles argue for.
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.
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
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.
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
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.
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.
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.