|
Ahh, the competent, those who are:
0. Spenting their time holding coffee mug and roaming around in the office.
1. False process story tellers wasting corporate money.
2. Sprint secrectories...
|
|
|
|
|
I've always felt agile was most effective in smaller shops, where you can have that free communication and ability to think and act outside the box.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Never been a fan of Mr. Martin.
After all, the reason for:
> value safety, consistency, command-and-control, and plan execution
is specifically to counter the chaos of:
> risk-taking, rapid-feedback, intense, high-bandwidth communication between people that ignores barriers and command structures.
Granted, middle-management structures are not the solution but tend to become necessary as the product develops from a two person garage shop (or dorm room) implementation into a company that employs thousands of people, many of which have nothing directly to do with software development (legal team, help desk, sales and marketing, etc) but are very necessary. And it is those groups that start driving the requirements that get fed to the actual developers, not the other way around.
IMHO, the problem with Agile (well, one of many) is that it's a concept intended to maintain the illusion that the developers are in control of the product, when in reality they are not.
|
|
|
|
|
Those are all very good points.
It also reminds me of the
Two Distinct Parts of Business
1. building
2. selling
Its also the two distinct types of workers
1. builders (Wozniak)
2. sellers (Jobs)
You can't have one with the other.
Agile tends to be focused on The Builders.
It's a great method for getting Builders to drive the thing.
The Sellers really should drive the product to where it is supposed to be and _SHOULD_ own the product.
Marc Clifton wrote: the problem with Agile (well, one of many) is that it's a concept intended to maintain the illusion that the developers are in control of the product, when in reality they are not.
Product Owner
This should be the part of the Product Owner. The Product Owner simply "contracts" devs to get the shtuff done. The developers shouldn't own the product. The Product Owner should be a person who is as motivated as Jobs to "Get it right!!!" and "Don't build crap!"
But the Seller must also KNOW EXACTLY what the product MUST be.
But, have you ever seen that in a company? Very rare!
So, the devs end up making the lion's share of final decisions.
They are way down the pipe and only seeing one part of the elephant and thinking it is one thing or the other: no overall vision.
And, as you said, it all falls apart.
modified 8-Aug-19 14:04pm.
|
|
|
|
|
Marc Clifton wrote: Never been a fan of Mr. Martin.
...and just what have I done to p1ss you off this time?
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
I work in an agile organization of 400 devs. At my company, agile isn't a bolt-on thrust onto the R&D team - it's how the entire company operates. Clearly, I'm in the minority.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: I work in an agile organization of 400 devs. At my company, agile isn't a bolt-on thrust onto the R&D team - it's how the entire company operates.
That must be a very solid company that is running well.
It's a 1 in a million to find a company with a strong process in place. 
|
|
|
|
|
raddevus wrote: That must be a very solid company that is running well.
Yes, it is (IMHO).
We started as a 25 person shop ten years ago and IPO'd last year on both the NYSE and TSX (we were the largest tech IPO in Canadian history). Although we now have 400 devs, we still think and execute (in many respects) like an early-stage company. I believe we are who we are because of our company culture. Almost all our dev managers and several C-level folk started out as devs and have an innate understanding of what it takes to build a software product. Our CEO values the people who make up the company and it shows. I'm grateful to work with bright people, and learn from them every single day.
/ravi
|
|
|
|
|
Great and inspiring story about your company.
Mine is very similar due to our CTO who has that same kind of vision.
|
|
|
|
|
Awesome!
/ravi
|
|
|
|
|
You are definitively an exception (and I am officially jealous)
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Which company is that?
A humble Googler would like to know
|
|
|
|
|
Quote: Which company is that?
Bollywood 
|
|
|
|
|
Aside from corporate values, structure and culture, I think Agile works better in some types of projects more than others and in some phases of a product than other. For example, a project with a lot of customer engagement is easier to acquire valuable feedback. A project with a single client is much easier to direct than a commercial product with many unknown users.
As for phases, the early phases of development involve a lot of infrastructure and architecture that benefits from planning for a longer view than just looking at the immediate requirements. Later phases involving mainly adding new features fit more naturally with an Agile process.
Web products, with their ability to immediately deploy, are better candidates for Agile than client applications or embedded systems that must be installed by its users.
|
|
|
|
|
Agile is failing? Ohh no. We're going to miss our Bollywood Story Tellers, JIRA Board assistance. So sad! 
|
|
|
|
|
This is all well and true.
But waterfall is worse.
So Agile fails... less...
|
|
|
|
|
Super Lloyd wrote: But waterfall is worse.
So true!! Very good point.
|
|
|
|
|
I experienced this exact thing decribed by Robert C. Martin in one of my last companies (1000+ employees). The SCRUM masters always had to defend SCRUM's integrity against the managers and their traditional hierarchical superstructure. The SCRUM masters did a good job fighting this war, yet they had to make a couple of concessions, which were so essential that SCRUM turned into something not-actually-SCRUM-any-more. These concessions were:
- effort estimations in hours/Euros instead of Poker points
- SCRUM team members have to stay disposable for their non-SCRUM legacy projects
It didn't work out.
|
|
|
|
|
Yeah, it's too bad that Agile gets interrupted like this.
If it could go the way it is supposed to, it can be a very good process (probably the best possible) --- if it can go the way it is supposed to.
|
|
|
|
|
Although I would like to add that SCRUM isn't necessarily good in my opinion. The more innovative the project and the larger the team is, the more SCRUM becomes the only way to ensure proper communication and project management. Anyway, if team communication and project management still work properly without SCRUM, I don't see the need to introduce it. It adds a lot of overhead and tends to break the developer's concentration several times a day every day.
|
|
|
|
|
I have actually seen this transformation happening in my previous workplace. And it happened just what most organizations struggle with, which is getting rid of middle management.
Many people left anticipating the movement, others were fired and others relocated to more agile positions like product owners and scrum masters.
What I also realized was that it takes certain very specific profiles and characteristics to make a successful agile team. Scrum masters need to be very dynamic, pro-active and communicative, or else they won't fit the new mindset. To me, getting the right people as SM's (or related) and PO's is the real challenge. The team also needs to respect and believe in them for this to function correctly, which is no easy feat by itself. The SM and PO also need to have the right mindset. Having a SM that feels like a manager also makes thing go wrong, because in agile role is more important than hierarchy.
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
Our heads are round so our thoughts can change direction - Francis Picabia
|
|
|
|
|
Fabio Franco wrote: ...which is getting rid of middle management.
...Many people left anticipating the movement, others were fired
Yes, it looks as if the best thing for transformation happened in your company.
It is said, "It is easier to give birth than raise the dead." And in your company's case there was a new birth because the right people left and the new people were added which created a new thing.
However, many companies fail and try to build a group by using the same people who are against change and the new process in the first place. It's quite a challenge.
|
|
|
|
|
In my experience, the main problem with agile software development, the whole ordeal with fast feedback/iteration-cycles is that software simply doesn't work that way. I've been doing a fair share of refactoring in my time simply because it's bloody hard to integrate features added by the customer ad-hoc later if the foundation of the whole thing doesn't support the required data flows. Creating a foundation that supports everything under the sun however quickly leads to the inner-platform-effect where it can easily take a couple years to get a somewhat-working prototype.
|
|
|
|
|
The recent CP news article (2019-08-06) 'why-agile-often-fails-no-agreed-metrics' [^] has a similar sentiment but claims that at least some do manage (or maybe that's that they started out right and held the course).
It also shows that getting the right metrics is hard if they are to reflect the organisation's goals rather than the technical folk's ideas of 'goals'.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
