|
Everything you are talking about is why this book is so fantastic.
The author takes the history of software development back to the publication of the seminal management theory book from 1911 (Principles of Scientific Management by Frederick Winslow Taylor). His point is that companies are still managing people and processes by that guide written over 100 years ago.
Quote: It was not lost on the people doing the work (the programmers) that the way things were going was not sustainable. Throughout the 1990s, professionals across the software industry would meet periodically and share ideas. What do some of these emerging ways of thinking have in common? What are ways that we can improve the way software is written? People recognized that things needed to change, but the ideas had yet to coalesce in a meaningful way.
Quote: As a result, top-down, fixed strategies—however well executed—no longer predictably yield the results we expect.
From the perspective of the incumbent accustomed to doing business in a more predictable world, this type of business environment may seem chaotic. Only by adjusting and learning better, faster, and more economically than their peers can companies gain an “agile advantage.”
To start embracing a new way of operating, it is necessary to think beyond the simplifications useful in a more predictable context defined by early thinkers such as Frederick Taylor. As the world has changed to become more complex, the way we approach business strategy needs to reflect a more adaptive view of the world.
|
|
|
|
|
From a consumer point of view.
I use DAW software. It's used to be 600+ bucks or less for current users with new releases once a year predictably in each fall. The features and fixes we all opined for all year on the user forum were either in the release notes or not. There was little or no access to the Indians within the company to try to lobby your pet stuff with. This was normal in the world.
Then they changed and announced features would be released when they were deemed ready and bugs fixed too which resulted in new toys for us roughly every month. Inexplicably, the updates are free to us now - we don't know why but we don't push it. 
btw it's Cakewalk by Bandlab
|
|
|
|
|
I may not have said it directly enough but I really like the things you said in your post.
Especially the following because I completely agree with you...
Dean Roddey wrote: Can anyone think of any truly amazing or original or game changing software that wasn't created by a smallish team of people who were mostly left alone (or ignored because they were in a company so big no one upstairs know what they were doing?)
Now as I've continued further into the book I came across this...
Quote: This takes us back to Professor Watts’s initial observation: what is it about cities that make them so robust and virtually indestructible, compared to companies? Dr. Watts theorized that the way cities are managed helps them embrace uncertainty in a way that allows them to benefit, rather than suffer, from unexpected events. By creating boundaries within which people can work together toward a common goal, the cities’ leaders can influence—rather than control—an outcome, while allowing for creativity, collaboration, and serendipity to naturally happen.
When companies want to get more innovative, we typically hear of chief innovation officers and special initiatives in which employees are directed to submit ideas and vote for interesting concepts. People are rewarded nominal prizes if their ideas are selected, and a nice article in the company newsletter is written. This sounds nice enough; the only problem is that it does not work. Internal innovation programs are notoriously ineffective. An MIT study found that 80% of innovation is a result of coincidence and chance. You simply can’t “force” innovation.
|
|
|
|
|
raddevus wrote: The signatories were primarily interested in finding ways to create environments for writing better software while the profession found itself in a crisis.
Define "crisis." Another word that has become cliche. I'd actually like to know what "a profession in crisis" looks like. 
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
I'll send you a selfie...
Explorans limites defectum
|
|
|
|
|
I'm fairly sure this guy could tell you exactly what a crisis is ==> Refactoring the soul[^] 
I think that situation is a lot of what those Agile signatories were talking about.
|
|
|
|
|
raddevus wrote: I'm fairly sure this guy could tell you exactly what a crisis is
Hey, I resemble that remarc. 
Latest Article - Azure Function - Compute Pi Stress Test
Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny
Artificial intelligence is the only remedy for natural stupidity. - CDP1802
|
|
|
|
|
IMHO - two things.
1 - In my experience (in multiple companies), the implementation of agile has led to a bureaucratic layer of project managers and business analysts with no proficiency at software engineering nor the software development lifecycle. The end result are projects that take too long, lean towards mediocrity, and cause the customer (internal or external) to blame the developers, whose hands were tied by the aforementioned project managers and business analysts.
2 - I went back to the original Agile Manifesto, and this article explains how I see those principles could be applied effectively today, at least in my own country. https://www.linkedin.com/pulse/agile-principles-from-traditional-american-view-jeff-jones/[^]
I understand if others disagree, which is why the first four letters in this post are "IMHO".
|
|
|
|
|
MSBassSinger wrote: 1 - In my experience (in multiple companies), the implementation of agile has led to a bureaucratic layer of project managers and business analysts with no proficiency at software engineering nor the software development lifecycle. The end result are projects that take too long, lean towards mediocrity, and cause the customer (internal or external) to blame the developers, whose hands were tied by the aforementioned project managers and business analysts.
Yes, that sounds like most projects everywhere, most of the time.
That is because that the old "We manager-types will tell you how long things should take and the functionality that should be in there, even though we have no idea about either one and have not even attempted to gather data about either one."
That is the old-school management theory that the author of Unlocking Enterprise Agility is attempting to open everyone's eyes to. It is based on principles from 1911 with a study of how people are like machines so we should just determine how many movements they should make to build a product. Then we can just set the schedule and have the minions crank out the widgets.
But, of course, if you call the thing Agile but all the principles still follow the old-school pattern then you do not have Agile.
2- I'll read the article. It looks quite interesting.
|
|
|
|
|
Thanks. I agree. I am a bit dumbfounded as to how thinking professionals see software development as essentially assembly line workers (developers and testers) on a predictable assembly line, instead of professional engineers (not PE, but generically) creating value from thin air.
|
|
|
|
|
Yeh, I mean, I've said it time and time again... how many of us, when starting a new project, are doing something that we have done just like that before, with the same tools, the same techniques, and the same constraints, and of course with the same team (known quantities)? It's probably never happened to any of us even once.
Every significant undertaking is new. You can't predict results without repeatable conditions, and no one even WANTS repeatable conditions for the most part because that would mean not taking advantage of lots of new things that will have become available within the lifespan of the previous project (if it was of any size.)
It's like most space projects. NASA and ESO have some of the best engineers in the world, but they almost never bring in anything under budget and on time, and all too often make massive blunders, because they are never doing the same thing twice. No matter how much process analysis experience you have, if you haven't done it almost exactly like that before, then you are to one extent or another throwing darts at a board.
Explorans limites defectum
|
|
|
|
|
I agree with you MSBassSinger. I worked for an company back in the late 80s that hired its software manager from a well-known accounting firm. He believed that software production is the same as an assembly line. People like him are extremely lacking information.
For example, workers on an assembly line have blueprints (or exact instructions) on how to build the product, which part goes where, how to put the part into the product, and how to inspect and test the product. Those plans even include an inventory of parts needed and the company stocks the needed parts.
Where are those instructions for the software developers? Although, the parts are endless, what parts will I need and how many? Should I use an array or linked list for an operation? A simple sort or a quick sort? Which would be best if the software changes at a later date? Is the performance of my new algorithm fast enough or do I need to add something more to it?
Even the hardware engineers create a breadboard to test their ideas when creating a new product. Do I use a 40 ohm or 80-ohm resister? There are no instructions of how to build it before it is conceived.
Does someone think that a customer’s or marketing’s request and requirements (even if detailed) is enough instructions to build a product? Can the customer or marketing give us the detailed specifications about the internal processes. If we refer back to the old days of software engineering (looking back to IBM in the 60s and 70s), there were processes in place to conceive of the breakdown, product boundaries, design, testing, implementation, deployment, and maintenance.
Any manager who doesn’t have software experience should be handled with care. Time needs to be taken to educate that manager, so he knows what he is working with.
|
|
|
|
|
|
That’s exactly how the process goes. 
|
|
|
|
|
|
These learned gentlemen would be contemporaries of Pink Floyd? That sort of education?
|
|
|
|
|
FYI, "Learned gentlemen" are barristers or solicitors (lawyers to you USians). These are Peers of The Realm.
Lord Ashton of Hyde was born in 1958, Lord Geddes was born in 1937, and Pink Floyd was founded in 1965. This makes Pink Floyd too early for one, and too late for the other.
Until comprehensive education was largely replaced in the UK with Comprehensive education, it was possible to get an education well-grounded both in Classics and in Science. The idea of getting a comprehensive education has sadly been relegated to the dustpan of History.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: The idea of getting a comprehensive education has sadly been relegated to the dustpan of History.
FTFY 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Daniel Pfeffer wrote: The idea of getting an comprehensive education has sadly been relegated to the dustpan of History.
FTFFY
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
My point, I believe! 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I was referring to Pink Floyd as a child, as in the movie.
|
|
|
|
|
Daniel Pfeffer wrote: Until comprehensive education was largely replaced in the UK with Comprehensive education, ...
The italics are mine.
Somehow, I feel as if I am missing something...
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
In brief, there used to be two types of secondary education in Britain. Pupils took an exam known popularly as the "eleven plus" (no prizes for the age at which it was given). Those who passed it went to an academic school, possibly on to University. Those who failed were sent to trade schools.
This separation was mostly abandoned in the 1960's, and replaced by Comprehensive schools. As everyone went to the same type of school, academic standards necessarily dropped.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I remember taking the "eleven plus" exam in 1969. I was 10 at the time.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
Slate wrote: One could possibly quibble that this doesn’t quite capture the term’s contemporary popular usage as a stand-in for software programs that issue rankings, recommendations, or decisions, as in “the YouTube algorithm.”
One could, just as one can use the word without knowing the meaning. Doesn't mean you're right.
You can quibble all you want, but it still is exactly what it was ages ago.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
