Should Executives Be Embracing Agile Principles Too? (forbes.com) 116
Steve Denning was director of knowledge management at the World Bank from 1996 to 2000, and now consults with organizations around the world on management and innovation. And in 2018 he wrote the book The Age of Agile. Now he's arguing in Forbes that "As the global coronavirus crisis is forcing many organizations to act with unaccustomed speed, organizational agility has suddenly become a necessity.
"The crisis is also making obvious that institutional agility means much more than having lots of agile teams scattered around the organization." "To create a truly agile enterprise," as the article, "The Agile C-Suite", by Bain consultants Darrell K. Rigby, Sarah Elk, and Steve Berez in the May-June 2020 issue of Harvard Business Review (HBR) points out, "the top officers — most, if not all, of the C-suite — must embrace agile principles too." Agility of course isn't new. What's new is to see the C-suite embracing it.
The contrast in stock market performance between firms that have been embracing Agile principles at the senior level for a number of years — such as Microsoft and Amazon — and two firms that have spurned Agile principles at the senior level — such as GE and IBM — is dramatic...
It is important that Harvard Business Review is highlighting the role of the C-suite in business agility. Wall Street has already got the message. Although the U.S. economy shrank at a 4.8% annual rate in the first quarter and suffered from 30 million unemployment claims, the stock market finished its best month in years. Why? The answer to the paradox is simple. After a devastating collapse the previous month, investors poured into the "chosen few." Firms that have demonstrated business agility by taking advantage of technological possibility — Amazon, Apple, Facebook, Google and Microsoft — have become the largest and fastest growing organizations in the world, while many others struggle.
"The crisis is also making obvious that institutional agility means much more than having lots of agile teams scattered around the organization." "To create a truly agile enterprise," as the article, "The Agile C-Suite", by Bain consultants Darrell K. Rigby, Sarah Elk, and Steve Berez in the May-June 2020 issue of Harvard Business Review (HBR) points out, "the top officers — most, if not all, of the C-suite — must embrace agile principles too." Agility of course isn't new. What's new is to see the C-suite embracing it.
The contrast in stock market performance between firms that have been embracing Agile principles at the senior level for a number of years — such as Microsoft and Amazon — and two firms that have spurned Agile principles at the senior level — such as GE and IBM — is dramatic...
It is important that Harvard Business Review is highlighting the role of the C-suite in business agility. Wall Street has already got the message. Although the U.S. economy shrank at a 4.8% annual rate in the first quarter and suffered from 30 million unemployment claims, the stock market finished its best month in years. Why? The answer to the paradox is simple. After a devastating collapse the previous month, investors poured into the "chosen few." Firms that have demonstrated business agility by taking advantage of technological possibility — Amazon, Apple, Facebook, Google and Microsoft — have become the largest and fastest growing organizations in the world, while many others struggle.
well if it just means that they know what's going (Score:5, Insightful)
well if it just means that they know what's going on then sure.
like if they were up to speed on to which subcontractors the mid level execs are building golden beds to jump into from the large corporation.
no need to call it agile though. it's just called normal competent leadership, which can be hard to find of course when top level execs have learned to hide from all responsibility and executive decisions while still money from the company regardless of the companys performance.
(the faut for all of this is at the shareholders and the board, of course, because they hire people with such high salaries that they don't actually need to care about if they succeed in their job or not because they're set for life after 1 years salaries and bonuses regardless)
Re: (Score:3, Informative)
Agile for me have just been slowing down things - now everything shall be broken down into "sprints" and only a certain number of issues are permitted to be handled during a sprint - no flexibility to adapt to reality.
The administrative overhead has increased instead of decreased while at the same time the traceability to why changes and new development is made is completely lost.
In addition to this there are no longer any "checkpoints" that allows things to be in a stable state so that everything ties toge
Re: (Score:2)
Agile for me have just been slowing down things - now everything shall be broken down into "sprints" and A) only a certain number of issues are permitted to be handled during a sprint - B)no flexibility to adapt to reality.
That is nonsense.
A) when you are done with the allocated items, you do others. Hint: you planned your sprint wrong. That is. a lesson to learn!!! Obviously you do not learn.
B) wrong again. Agility - hence the word - is all about flexibility.
No idea were - and why - you learned such nonsen
Re: (Score:2)
This is all from the experience I have had at one workplace, especially when it comes to cross-team functionality.
Some of this is basically caused by not understanding that each team have to coordinate their efforts to create a solution.
Even worse is that the teams haven't completed their "paperwork" at the end of task assigned so that when it's pointed out that the documentation isn't consistent then they always come back and say "we don't have time for that".
Re: (Score:2)
so that when it's pointed out that the documentation isn't consistent then they always come back and say "we don't have time for that". ... again.
Has nothing to do with agile or not
Or would they have time to do the documentation in a waterfall process?
Re: (Score:2)
That is nonsense.
A) when you are done with the allocated items, you do others. Hint: you planned your sprint wrong. That is. a lesson to learn!!! Obviously you do not learn.
B) wrong again. Agility - hence the word - is all about flexibility.
No idea were - and why - you learned such nonsense when it is common sense that it is opposite around.
And most of all the "Not My F-ing Problem" mentality did arise at the same time to unseen levels.
Then your team sucks. Has nothing to do with agile or not.
I'm surprised everyone has not already become sufficiently tired of this bullshit that anyone still feels they can get away peddling tired and lame "YOU'RE DOING IT WRONG" excuses.
Agile itself is an anti-pattern. Something only competitors and coding sweat shops should partake in. Those who care about succeed don't waste their time with abstract ideology. They create processes tailored to success of individual missions.
Re: (Score:2)
They create processes tailored to success of individual missions.
Correct. And how is that called?
Hint: it is called "agile", oops.
Re: well if it just means that they know what's go (Score:1)
Agile is the problem. The solution is MOAR AGILE!!
Re: (Score:2)
They create processes tailored to success of individual missions.
Correct. And how is that called?
Hint: it is called "agile", oops.
It's called using your brain rather than subscribing to ideology.
Re: (Score:3)
Agile is a massively mixed bag and it really does depend on the expertise and experience of the project manager.
If you have a shit project manager, agile just turns the shit into agile shit. If you have an excellent project manager, agile can really help to clarify processes and give coders a bit of a better chance to code properly.
For me the big insight I've gotten is that it isnt REALLY about getting the process right, but rather having a process at all, and frigging sticking to it. But its got to be the
Re: (Score:2)
Yep. My conspiracy theory: agile basically gets endorsed by management when they get jealous that devs only have meetings 1-2 times a week. If you go with sprints and retros, planning meetings etc then all the devs get 11 or so meetings biweekly one if them the majority of a day. The senior guys at least get the backlog grooming and the majority of the prep work for meetings. End of the day you go from spending 5% of your time to 30% of your time in meetings. Then everyone has an excuse why development has
Re: well if it just means that they know what's go (Score:5, Insightful)
Fake agile.
Why should I call anything Real Agile (is this starting to sound familiar)?
Because everyone seems to have their claim, "well, you weren't agiling right." Okay. Then who is? What are their names, and day-to-day physical actions? What are the things a person can physically perform to be agile?
If you can't take some set of actions and quantify their correlation and causation to and of an outcome, you've got nothing but cargo cult dead chicken voodoo.
Re: (Score:2)
cargo cult dead chicken voodoo
Oh, so you're familiar with my bestselling book, How To Be An Unleashed Agile Dummy in 21 Days! Buy it now on Amazon!
Re: (Score:2)
Oh, so you're familiar with my bestselling book, How To Be An Unleashed Agile Dummy in 21 Days! Buy it now on Amazon!
That one was a classic! Right up there with, Sam's Teach Yourself Ted-Driven [dilbert.com] Development in 24 Hours.
Re: well if it just means that they know what's g (Score:2)
What are the things a person can physically perform to be agile?
You're supposed to pay a bunch of money and then they'll tell you that during the Certification Training.
Re: well if it just means that they know what's (Score:2)
Otherwise you're not doing agile right.
Re: (Score:2)
What are the things a person can physically perform to be agile? ... see above.
Adapt to changing requirements.
Adapt when you realize you planned wrong (aka to many or to few items in the sprint).
Adapt to failure: you made mistakes? Realize the reasons, fine remedies, implement them, take measure to avoid the same failure.
Adapt to wasted time, realize what is taking you wasting time
Plain and simple standard way of life engineering tactics.
Point is: you are doing it wrong and fail on mostly anything (in Tim,
Re: well if it just means that they know what's go (Score:4, Insightful)
Exactly I feel people get too stuck on the scrum meetings and sprints process. However they miss the real problem affecting nimble development.
1. Requirements are always changing. Business School incorrectly teaches the idea that a proper project plan we have all the requirements on hand before we start. Getting requirements out of peoples head is impossible. What they say isn't what they wanted, and often they don't know what they want until they see it.
2. Being that as things progress with partial or not properly explained requirement. When they requirements get revised then the project plan will need to be changed. Dropping some things and creating new ones.
3. Remember the Multiply by 6 rule. Take the time you think it will take, multiply it by 6 for the actual time.
Also never expect a perfect system. We look at all the crap programs out there and go Yea I can program this much better than this POS system. However in reality you probably couldn't, being faced with the same sets of changing requirements, limited time, and workarounds to get things out.
Re: (Score:2)
Adapt to changing requirements. ... see above.
Adapt when you realize you planned wrong (aka to many or to few items in the sprint).
Adapt to failure: you made mistakes? Realize the reasons, fine remedies, implement them, take measure to avoid the same failure.
Adapt to wasted time, realize what is taking you wasting time
Company A spends their time adapting.
Company B spends their time anticipating.
Company A fails and goes out of business. This failure is always excused away as "you are doing it wrong" when in reality the problem is Agile itself promotes process over results. It rewards short term deliverables and iteration over results.
The reason Company A failed is that Agile is only useful for sweat shops and managing fools. It doesn't provide optimal outcomes for anything else.
Re: (Score:2)
While anticipating is better than adapting it requires the same agile mindset, actually: more agility.
No idea why you are bashing it and mention sweat shops and managing fools.
And competition is not between your examples A) and B). The competition is with C) the companies which rarely make software successfully because they are stuck in a water fall world.
Re: (Score:2)
While anticipating is better than adapting it requires the same agile mindset, actually: more agility.
Agile actively promotes adaption and actively discourages prediction.
No idea why you are bashing it and mention sweat shops and managing fools.
These are the only things Agile has ever been good for.
And competition is not between your examples A) and B). The competition is
No, A and B are polar opposites in their implications. You can't just draw an Agile box around everything and call it Agile any more than a priest can draw a God box around everything and explain it away by invoking God.
with C) the companies which rarely make software successfully because they are stuck in a water fall world.
All you are doing is peddling ideology. No different than preaching for or against socialism or capitalism. No single ideology provides optimal results. For that yo
Re: well if it just means that they know what's g (Score:1)
Re: (Score:3)
SpaceX seems to be doing alright with it more or less.
I truly doubt any company that has a successful workflow has fully implemented any project management framework. They all suck and none of them are really flexible enough for the real world. Rather, the ones who make it work have adopted core ideas that are consistent with the framework and then adapt the actual implementation of it to their own needs.
I've seen a lot of Six Sigma bullshit in my time for example. I have yet to see anyone successfully impl
Re: well if it just means that they know what's go (Score:5, Insightful)
This is the crux of the problem with Agile and in fact with any theoretical 'methodology'.
Even with the best intentions, things vary between vague blatantly obvious things (e.g. the Agile manifesto makes sense, but is blatantly obvious and vague). The various stakeholders already believe they are acting consistently toward those goals and its always everybody else's fault that things are falling short of those ambitions.
However all that vague, yet good gets picked up by a whole industry of consultants and tool vendors to 'help' companies be Agile. Particularly ironic since one of the manifesto lines was that tools were less important, but inevitably tools are 'key' to implementing Agile when there's money to be made selling those tools. In practice, Agile training is used by management/project managers to justify their authority and go full on micromanaging every little work item, whether they understand or not. They create multiple daily meetings to better inject themselves and slow everything down by making technical consensus that used to happen naturally have to proceed at an agonizing pace as the project manager now has to feel comfortable they understand every little technical decision, despite lacking skills and experience to ever suggest an alternative.
Then when things do fall apart and become a bureaucratic nightmare, proponents break out the no true Scotsman fallacy to wave it away.
The reality is that a methodology isn't the answer to dysfunction. It's a behavior of your team. Management wants to believe they can take they have (generally the cheapest developers they thought they could get away with) and apply methodology to transform that into a good team, rather than evaluating whether they can get a team or if they are just in a hopeless situation.
Re: (Score:2)
Re: (Score:2)
At my company, Agile leadership means that whatever shiny thing the boss sees becomes the new highest priority. His thought processes are a wonder to behold.
We go from "Not a feature that our customers care about" to "My ideas are unquestionably true - I'm a businessman" in the span of not more than an hour.
Even less time if there is a YouTube video involved. Bonus points if it's a video from a failed company doing related work. In that case, it's still the boss's idea, and we're innovating by trying to
Re: (Score:3)
... if it just means that they know what's going on then sure.
To me that's the essence of Agility; that Senior Leadership has established a clear goal and direction that is openly communicated to employees at all levels.
If the C-level people don't have that understanding, and if they aren't working with their Directors to help their organizations see the overall goal and how they can contribute to achieve that goal, then Agile is nothing more than "yet another cargo-cult."
Re: (Score:2)
The problem is often management thinks they have to be involved in decision making.
Companies try to hire the best and brightest that they can afford. Only to second guess their opinions and do thing the way that they had done it before.
For some reason there is this expectation that the Boss knows more than the employees. This isn't the case, good bosses know that their employees know more than they do, if they don't they will still pretend that the employee knows more.
Lets use a software development shop
Isn't this what Elon (SpaceX / Tesla) does? (Score:2)
That seems to work rather well, assuming that's what this article is about. :)
(Note to self: RTFA!
Re: Isn't this what Elon (SpaceX / Tesla) does? (Score:3)
Musk at SpaceX: stay out of the way of real scientists and engineers because there's no silly consumer tech involved. Space ship does not use dog mode or automated windshield wipers. Space is unforgiving of bul
In my experience... agile usually waterfall (Score:5, Insightful)
Agile usually collapses to waterfall.
The Goal.... isn't clearly defined. Attempts to get a clear goal are resisted by management.
The Time... is abused. Sprints are extended because "an important feature needs to be in this sprint".
Responsibility... every team member is responsible for their actions-- and all the extra actions assigned to them... and trying to help meet the Time which is being abused. And they dont give estimates-- the estimates are dictated to them by management and the sales force.
Cooperation and Transparency... is usually there tho. This part seems to work and should be used.
---
In my opinion- as a retired manager for a fortune 100 company that lived thru failed agile and failed SAP $100 million plus projects...
a) people were overworked.
b) deadlines were dictated.
c) sprints or iterations were not time boxed.
d) too much low risk construction work was done early
e) stakeholders were *ignored* (and I'm talking multi-million dollar customers who finally started leaving which lead to the project failures-- the customers would *NOT* go to the new products.)
I prefer Rational.
1) FINISH *ALL* high risk work before allowing anyone to start on a single line of low risk construction work.
2) Feature focus contract.
3) But you still need management support for time boxing (we had it)
4) GOOD built in documentation
And I prefer "pattern" based documents. Much more concise and less ambiguous.
https://www.ibm.com/us-en/mark... [ibm.com]
https://en.wikipedia.org/wiki/... [wikipedia.org]
It was much lower risk. You didn't spend $80 million on a project that would *never*work.
Every month you had a working copy for the actual users to test.
But- seriously- do the high risk stuff (new tech, communications, database and network I/O bandwidth) whether you are in AGILE or Rational or even waterfall. That way, you only sink $500,000 before finding out what you want to do is impossible.
(and I'm no fan of IBM. They are really abusive of their employees IMHO. I would *never* work there. But they were not as abusive
as deloitte and douche.)
Re: (Score:3)
Oh yes.
If you don’t do the high risk stuff first, you can easily run into a showstopper. You must kill the dragons before proceeding with the quest!
Proofs of concept for each of the high risk items is indeed crucial. Pretty can come later. Pretty isn’t easy, nor quick, but it can always be done.
In my experience, agile tends to collapse into institutionalised micromanaging, which is beyond horrible.
Re: (Score:2)
Aye and the problem is the sunk cost fallacy. "We've spent $100 million and you said this project was 80% complete! We can't cancel it now!" But you finally got the actual key product from the vendor-- and it doesn't work as advertised. the project shouldn't have even *started* until that product was available to test.
Re: (Score:2)
The point of Agile is to be able to deliver, measure, refine, and then re-run the cycle.
It has taken (is taking) years for the engineering disicplines to get their head around the benefits of this.
The benefits of this cycle *to business* should be even more obvious to the "Executives" in terms of generating a business product that can be adapted to changing business needs.
But it doesn't get treated with respect because big business still reports to shareholders on quarterly and annual results - and the shar
Re: (Score:2)
Agile principles are not in and of themselves, to blame, we'll agree. Instead, one needs to look at Microsoft and others that have employed them and ask the real questions of: Do you want to be a bullying monopoly, largely impregnable, even by the courts, making dreck but selling it quickly and for high margins, while putting velcro around new product development?
Money making machines, and especially self-perpetuating ones, seems a lofty goal. The problem with this idea, and all the oil-well-in-the-basement
Re: (Score:2)
Agree. Anything taking longer than a sprint length to do gets thrown out. Need two weeks to research a new tool which you might not even end up using? Sorry that's 2 sprints. We can break it up but then you are making bs documents like "research report part 1" as deliverable so you can deliver "customer value".
Sometimes things are just chores that have to be done that may or may not ever land in anything a customer will see. Engineering isn't science since it is more formally a way to build stuff for the mo
Re: (Score:2)
Re: (Score:1)
Another problem we saw was that very powerful executives can (for a short time) literally redefine reality, success criteria, and terms.
For example... for the SAP project- everyone *knows* if you want to succeed, you remake your business to fit SAP and you *DO* *NOT* customize SAP.
So instead of "customizations" we had over 1,000 "gap fills". Some of them *literally* re-implemented built in SAP features.
The executives thought they were clever since they hadn't customized code- only filled gaps. Total fail
Re:In my experience... agile usually waterfall (Score:4, Interesting)
And some things just can't be broken into sprints; Some things are so interrelated you can't break them up that way. Some things involve matter-bashing, so you can't make pieces of the thing and have a functional product that slowly improves over time - you either have the product or you don't.
Some things have to have an entire design and analysis complete before you can start implementation.
Re: (Score:2)
Yes modern successful products depend on evolution. But that's evolving over several "models" of a product - not over the development cycle for a single model.
If you try to evolve during development of a single model, that product will never be completed. Or you have redefined "model" to be something that term did not historically mean.
Re: (Score:2)
We use Scaled Agile ... SAFe . Yes, if you don't have your work actually developer ready,,, If there are unknowns treat them as spikes until the they are known.. If you fail either of these, it turns into waterfall with daily scrums and two week iterations into oblivion! Not sure how this would translate into a room of PHB's ( pointy haired bosses).
Re: (Score:3)
Why is management always so resistant to setting firm goals?
To me it always reads like a willingness to escape consequences of their choices, combined with some lack of willingness to devote limited resources to choosing rational or achievable goals.
The unwillingness of management to commit to anything and accept responsibility for it has long been one my biggest frustrations, especially when they abuse the ambiguity of their commitments to punish workers for actions they took without much clarity of guidan
Re: In my experience... agile usually waterfall (Score:2)
Re: (Score:2)
Why is management always so resistant to setting firm goals?
The primary reason is quarterly report goals. Execs are wedded to having good news every quarter so they can be assured their bonus remuneration is safe.
Re: (Score:2)
The Time... is abused. Sprints are extended because "an important feature needs to be in this sprint".
I like to explain this way: You can get an aribitrary number of features in an arbitrary amount of time by just coding away and hoping for the best. But for practical project management you want to fix one or the other, you either pick a set of features you want and let the schedule vary or you pick a time box and let the scope vary. If you keep changing back and forth then neither the schedule nor scope is predictable, because you're not going to get rid of the uncertainty either way. The point of time box
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Thanks - this is the kind of comment that keeps me returning to Slashdot.
And I prefer "pattern" based documents. Much more concise and less ambiguous.
What would you say are good examples of this, or of these writing guidelines?
Re: (Score:1)
It's been a while since I retired but here are a few random web sites on the idea.
https://code.tutsplus.com/arti... [tutsplus.com]
https://medium.com/educative/t... [medium.com]
https://en.wikipedia.org/wiki/... [wikipedia.org]
Here's a cheap course from the above site.
https://www.educative.io/cours... [educative.io]
Re: (Score:2)
Cool, I think I've stumbled on some of these before but now it's quarantine reading time :)
Thanks a lot.
Scrum is a subset of agile. (Score:2)
Never heard of "Rational", but that looks like an agile way of doing things.
Re: (Score:1)
The primary differences are enforced documentation by the tool and high value set on identifying and then resolving all known risks before beginning *any* safe "construction" work.
Re: (Score:2)
Agile requires a lot of things to go right at the same time. It's not forgiving of bad apples and dysfunctional managers or organizations. Check-lists and reminder memos are often not enough to fix riff-raff. Therefore whether it works at a given org is a crap-shoot.
Successful C-Suite has always been "agile" (Score:1)
Successful C-Suite executives have always been "agile".
The term "agile" however has now been co-opted by technical people who prefer not to plan and instead figure "we can just replace it all in the next release".
So, no, competent C-Suite executives still don't replace long term planning with a two week sprint and whatever the last user asked for.
However, a competent (and most are not) C-Suite executive can and will make a multi billion dollar decision in response to rapidly changing conditions without exte
Re: Successful C-Suite has always been "agile" (Score:1)
Re: (Score:2)
It sounds to me like selection and confirmation bias.
Develop new management strategy.
Use case studies of existing successful enterprises to point how many were actually using elements of the new strategy. Ergo, new strategy is already proven successful because successful companies have been engaging in it already.
Seldom, if ever, are failed companies studied for presence of these "new strategy" components and whether they contributed to the company's failures. Even if they are, they are prone to be cherry
What's New? (Score:2)
Re: (Score:2)
As far as anyone else can tell, Agile is synonymous with, "fuck requirements, just build stuff the customer wants," where, "what the customer wants," is synonymous with "idea the PHB themselves had in the shower while drunk,"...
And you are never going to an actual set of requirements--just a bunch of flak because what they dreamed up isn't even internally consistent, let alone useful. But the vague notion sounded really, really Awesome and Next Level.
Customer requests get totally ignored.
Yeah, they should a
Re: What's New? (Score:1)
What does this really mean? (Score:2)
The author's book, on Agile crap, was published a couple of years ago. I can't tell whether he's trying
Link to the book, and reviews (Score:3)
1-star review: Just plain wrong! [amazon.com]
2-stars review: Wanders a long way off topic. [amazon.com]
3 stars: Not too solid; vague arguments bad examples [amazon.com]
5 stars: This Is A MUST Read Book For EVERYONE, Independent Of Industry Or Vocation!!! [amazon.com] Quote: "If someone does read this book and does not understand a concept being discussed consider asking for help from others..."
Agile: People claiming to be smarter? (Score:3)
I agree! The writing about Agile seems to be people claiming to be smarter than everyone else, without giving solid evidence.
Re: Agile: People claiming to be smarter? (Score:4, Funny)
Pro Tip: Using "Agile" as a nown ... (Score:3)
... is a very good indicator that you are near or smack center in bullshit territory.
Disclaimer: Scrum Master speaking here, so I know a thing or two about orgaising work in such a way as to optimise agility. Duh.
To clarify: You can't embrace "Agile".
You can "embrace agility", if you must say it so poetically.
You can *be* agile. And being a CEO pretty much means being agile in many ways.
That's why most CEOs have entire offices dedicated to organizing their work they need to do most effectively.
This, of course, means that CEOs are basically agile by default.
So I don't really get your question.
Amazon is Agile? Depends how you define Agile (Score:2)
"firms that have been embracing Agile principles at the senior level for a number of years â" such as Microsoft and Amazon"
Really? What about Jeff Bezos' autocratic memo of 2002 [dcc.ufmg.br], in which he states,
All teams will henceforth expose their data and functionality through service interfaces...Anyone who doesn't do this will be fired.
The Agile Manifesto has great ideas in it. But the Agile community went nuts in the early 2000s, and advocates extreme practices that don't work at scale. What works is havin
Re: (Score:2)
I also think that perhaps there's just a false correlation here.
The natural cycle of a company is to grow and shrink. IBM and GE are the Old Money, and MS/FANG are the New Money.
what agile? (Score:2)
agile makes a lot of sense from a sw craftmanship perspective (*). in the sw business sense the whole agile fad is more like a sponge. executives should rather embrace a rock. a heavy one. in the open sea.
(*) many of the original techniques in the agile umbrella (pair programming, test driven and incremental development, etc ...) are excellent principles to produce high quality, highly fitting and reliable software, particularly in projects with huge scope and/or uncertainty. this has nothing to do with the
Re: (Score:2)
If they won't voluntarily embrace the rock, can we tie it around their necks?
Nothing to do with Agile (Score:2)
"The answer to the paradox is simple. After a devastating collapse the previous month, investors poured into the "chosen few." Firms that have demonstrated business agility by taking advantage of technological possibility â" Amazon, Apple, Facebook, Google and Microsoft"
Wrong. People are mostly stuck inside and reliant on the products and services from these companies, as are many businesses with remote workers, in the case of O365.
They already are (Score:2)
At least the one with the "clueless" model of developer, where agile just means no rational strategy, getting bogged down in details, always reporting bullshit about the state of the project and not documenting anything as to why things were done. Also no after-the-fact analysis of failures.
Re: (Score:2)
This is the daily, behind-the-scenes life of a sockpuppet.
It's almost like this crap is pervasive.
Agile: Agility Training (Score:1)
Our local dog park has an agility training course.
The ramps and the hanging tire to leap through.... etc.
Chop chop, now, fad follower. Get agile!
What executives need (Score:1)
Re: (Score:2)
And as usual with executives, an elaborate and needlessly costly plan when a cheap bullet could accomplish the same goal.
Re: (Score:2)
Are you sure 10 tons is big enough? Don't forget they're mostly full of hot air.
Stupid idea (Score:2)
Large corporations should not be agile. High agility means high uncertainty for shareholders. I want to invest in a solid factory, not some hipster concern that may tomorrow be serving cappuccino instead. It would not be compatible with worker rights if entire divisions can be changed overnight. People want stability and predictability. If you do agile in wall street, you end up with an economy like China.
What does this article even mean?? (Score:5, Insightful)
Depends on what "Agile Principles" means... (Score:5, Insightful)
If the article is asserting that C-suite execs should adopt the values from the original Agile Manifesto (https://www.agilemanifesto.org), then absolutely "YES".
However, if the article is asserting that C-suite execs should employ the services of a bunch of blood-sucking, business process improvement consultants to learn a new process and charge tens of thousands of dollars in training services.... then "NO". Process improvement consultants single-handedly killed Agile culture adoption by bilking companies with tools, software, and books... which is completely antithetical to the Agile values themselves.
C-suite execs shouldn't worry about a bunch of useless books, a bunch of useless processes, or a bunch of useless tools. Just read the values and adopt them. Practice them. The four values are simple. Do those things and you are Agile. That is all you need to do.
Re: (Score:2)
Sometimes Slashdot really needs a level 6 score for "the perfect answer".
Re: (Score:2)
But if they can't buy useless books and write useless processes, they'd have to change something! Or, worse, change their values and be subjected to those ridiculous things themselves.
That's madness. Madness, I tells you!
Re: Depends on what "Agile Principles" means... (Score:3)
But then I don't do software, am an engineer by training and work in production... Far away from agile, and rightly so.
Re: (Score:2)
"The way I read the manifesto, there are 8 values. 4 of those are lifted above the 4 others. "
The value is not "this" or that" (two) but "this over that" (one).
Now, count again.
Re: Depends on what "Agile Principles" means... (Score:3)
Considering the items on the right, if you truly don't value any of those at all, I don't ever want to be near your code nor work with you. I a
Re: (Score:2)
C-suite execs shouldn't worry about a bunch of useless books
It's getting to the point where soon C-suite executives are going to have to start worrying about peasants with torches and pitchforks.
Yes (Score:2)
Business Agility is essentially nothing more than open communication and effective feedback on a consistent basis.
If that doesn't start at the highest levels of an organization, then the "Agile Transformation" is doomed.
Not if they want a working business (Score:2)
If they're talking about "software Agile" then it will make short-sightedness even worse. Companies need a direction to steer in, even if it's kind of waffle-y...a 1 year plan, 2 year plan, maybe even a 5 year plan. Software Agile from my perspective can be translated to "we don't like planning, planning is for oldsters, if we're wrong we'll just fix it in the next sprint." IT and development don't do middle-ground solutions well...it's either no-plan Agile or this-is-the-only-plan Waterfall when realistica
People are forgetting good human work (Score:3)
Of course they should (Score:3)
God no (Score:5, Insightful)
I thought the Agile fad was over? I have never seen a process so in love with itself.
Re: (Score:2, Insightful)
Cargo cult development (Score:2)
And if you aren't more productive or if your points estimates go up and down like a yo-yo then it cannot possibly be because it's all a bunch of bullshit ceremony and mystical thinking. No, you're clearly doing the incantations wrong! So send your acolytes on expensive training cours
Re: (Score:2)
More like "No True Scotsman", or socialism/communism - if it didn't work out (which it never does), "you didn't do it right". No one ever questions the premise, just the execution.
Re: (Score:2)
Hey, capitalism works great that way! If it doesn't work for you, then you're doing it wrong!
most agile isn't (Score:2)
Stupid buzzwords. Even the Department of Defense realizes that most people are either just faking it, or just plain stupid:
https://media.defense.gov/2018... [defense.gov]
Heaven forbid corporate executives ever let an engineer actually engineer, or a developer develop... that would incur too much risk.
Agile sucks. But so does everything else. (Score:2)
The issue is with management.
Management doesn't want to make any decisions that might bite them in the ass. And since *every* decision has the potential to bite them in the ass, they don't make any decisions. Instead, they simply say "That's not what I wanted". They will never tell you *what they want*, only that they don't want what you gave them.
Put another way: Management only wants to take CREDIT. They never want to take BLAME.
Bunch of cowards. Which would be fine, if they stayed out of the way of the p
So the rest of the company (Score:1)
Sure (Score:2)
Why should only those who are working suffer?
Agile versus agile (Score:2)
Harvard Business Review publishes many articles about "agile business practices." You can read the articles, and see that they talk about "following agile principles" pretty often.
No where do they ever talk about the Agile Principles and the more fundamental Agile values as laid out by the Agile Manifesto.
The idea that there are written values and principles is part of "software Agile" but is not "business agile." That concept comes from "principle based business" which is its own way of organizing a comp
which "agile" do you mean? (Score:2)
"Agile" is one of those buzzwords that 78.3% of the people who use it don't actually understand and/or have conflicting but never expressed definitions of in their heads.
The Agile Manifesto is a nice aphorism devoid of practicle content. It's a mission statement, but not a mission. What it actually means and how to implement it, that's a different animal and that's also where things are suddenly not so simple anymore.
On the management level, it's a buzzword. I've had so many managers use the word and so oft
Re: (Score:2)
Yes, and the sooner management notices that, the sooner we can get rid of it. That works best when they suffer from it themselves.