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.

> given a well-articulated objective (not solution)

And a clear idea of why the objective is important, or the access to inquire about that. Without the ability to know why a business goal needs to be accomplished, its too easy to start sliding back into asking for solutions rather than objectives.

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.

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.

> given a well-articulated objective (not solution)

100% this.

Developer empowerment.

Always has been. Always will be.

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

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.

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

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

That's brilliant. Sadly, in some sense, but the logic checks out. It highlights how multi-dimensional the problem of persuasion can be.

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.

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.

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.

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

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.

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.

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

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.

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.

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.

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

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

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.

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.

> 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/ [1] http://www.scaledagileframework.com/

I've seen that SAFe for Lean Enterprises image before, honestly thought it was satire.

Along with the Afghanistan Strategy image: http://msnbcmedia.msn.com/i/MSNBC/Components/Photo/2009/Dece...

SAFe both directly incorporated process evaluation and improvement and recognizes that the process starting point appropriate to different orgs in different tasks is different, and even in its framework doesn't dictate low-level team process though it describes what process combinations are common, so it seems to, as much as a canned starting-point process can be, be a fairly robust concrete implementation of Agile Manifesto values (it's arguably, though, more Lean than Agile, though I'd argue Lean’s focus on well-defined processes with continuous, team-involved evaluation and improvement is the best operationalization of the Agile Manifesto’s “individual and interactions over processes and tools” (remembering that the Manifesto’s “over” statements are explicitly about priority, not one thing instead of the other.)

Most of the concepts in that diagram are in direct contradiction of the agile manifesto.

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.

> For example, a scrum master is supposed to ensure a team follows agreed processes

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.

Well, that's an impressively convoluted way of justifying doing the exact opposite of what the phrase says.

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.

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

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.

I'm interested as well. 2012/2013ish I was a consultant at Org A that deemed themselves "agile" - in reality a very highly functional agile organization. I've yet to see anything quite like what that org had going for them.

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.

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.

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.

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/ . Generally it is a must if any % of your dev team is remote-based. Else at least one part will suffer.

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

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.

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

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.

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

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/

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.

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?

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.

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.

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.

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

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.

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.

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

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.

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.

The primary purpose of Agile ceremonies (if done correctly) is to provide a structured way to surface and resolve resource and process issues (as well as prioritize) in a way that allows team-members to otherwise get on with their work as they see fit - without the constant threat of distraction by product/delivery managers' concerns about resources, processes and ever-shifting priorities.

If Agile ceremonies don't achieve this or otherwise excessively waste time, they're just a form of cargo-culting.

Kanban is definitely much better than Scrum.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

What do you mean by "chaotic" and "troublesome" environment. Also I would be interested in how waterfall is helpful in those cases.

Not OP, but I read that as the codebase is compartmentalized poorly. Agile works best when you can dip in, fix something small, and move on. If you need to change half the codebase to do a small thing; it may make sense to combine multiple small changes together. "While you're in there...".

I do consider that an environmental 'code smell' though.

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.

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

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.

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.

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

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

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

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.

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.

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

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.

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.

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.

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

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.

That works on an IC level for sure. However, a bit more structure is needed on the interface between developers and the rest of a company (especially if the company is not in a software business).

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

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.

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.

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

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.

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.

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

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

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.

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?

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

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.

Agile requires discipline and that's hard to implement.