No. Process is important; it's necessary. There are at least two prongs to this problem: one is you can't manage what you don't measure, and process gives you a way of tracking functionality implemented, defects, defects resolved, etc. There's nothing inherent to programming that gives your manager or your team any sort of knowledge about how far along you are, or just as importantly, when you will be done. You can hack all you like and -- even if your code is visible to all -- there's no way of guessing how far along you are, or if that needs-to-be-fixed-yesterday bug is close to resolution.
The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.
And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.
Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.
No, it's even worse. You can't manage what you can't measure. And so far no one has found a metric to measure creative output like painting, writing poetry or writing software. Whatever metric you choose to measure and evaluate your team, and esp. what ever metric you reward is going to lead your team optimizing their performance for that metric.
You want to measure LOC, programmers WILL write more lines. Want to measure and reward less defects, programmers WILL create less defects etc. But will your software be sexy, appealing to users, creative, innovative, trend setting solution to old/new problem?
> And so far no one has found a metric to measure ... writing software
How about ...
* Number of new features delivered per week (and size of said features)
* Number of new users per week
* Number of page views per day
They're fuzzy metrics at best, but saying "writing software can't be measured" is just defeatism. It's not fine art, it's not a Jackson Pollock painting, it's a craft. It has utility. We can get a grasp on that. Even the pretty bits are ultimately there to make it more useful to people.
That's even more nebulous. Yes, those things are perfectly measurable, but how do you translate x number of new users per week into code?
Isn't that what software development is all about. It's about collapsing this cloud of uncertainty into concrete deterministic expression a.k.a code, which only solves the problem as you understand it.
If software development were that measurable, software developers would be as well paid as CEOs or sales people. But we are not. Because there is no way to demonstrate almost any relationship between what we do on daily basis (stare at screen and type on the keyboard as management often sees it) and sales and revenue. Some places go as far as to think of their development organization as overhead, a cost center.
Measuring something in order to manage it does not automatically mean that the management consists of incentives or punishment - and if you don't do those things, people have no reason to game your measurements.
There most definitely are useful software metrics that can provide important information to management, mostly in the form of identifying problems and risks, which can then be adressed before they become urgent.
> how do you translate x number of new users per week into code
You talked about turning code into metrics, now you want to turn metrics into code?
It's the other way around. Scrum translates delivered code into metrics. You track history. You would say "last week we delivered 4 new features and signed up x new users. That's above our average." It's not entirely nebulous.
Is Agile (big A) really as "proven" as proponents make it out to be?
I'd love to see some citations in the form of "Product XYZ that you know and love is developed using Agile" as opposed to the usual "My cousin's friend's brother's girlfriend used Agile for an internal CRUD tool and it went totally great".
In the real world, the few times I've worked at places that attempted Agile (Scrum both times) I've only seen Agile fail miserably.
I would like to add one thing to that: Process is necessary, but it should never be the solution.
This is where people tend to wrong at the very start. Any attempt to implement Agile (or any other method) with the illusion that process can solve the problem will always go horrible wrong.
The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.
And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.
Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.