An Alternative for 'Less Relevant' Agile: the Studio Model (forbes.com) 92
Last week Forbes ran an article by writer/data scientist Kurt Cagle arguing that Agile software development "was becoming less and less relevant." Within five days it had racked up 300,000 hits, and "I'm still digging out from the deluge of email, Tweets and Linked In messages," he wrote this week.
But in a new follow-up, Cagle looks back over his 40 years of programming, remembering successful six-month development cycles in the 1990s that used "a home-grown methodology which I've since dubbed the Studio Model, because it reflected the way that you create movies, television programs, orchestrated concerts, video games, and to be honest, most intellectual property." He then attempts a 12-point manifesto for this Agile alternative, which emphasizes things like a clear vision, good design, redundancy, flexibility, and remembering that as a project moves forward changes become "exponentially expensive". All too often, proponents of certain methodologies want to claim that their methodologies are the reason for success, when in reality, the deciding factor was the skill and tenaciousness of the people involved, the presence of a clearly articulated vision that could be changed as needed but that was not written in jello, and on recognizing the distinction between providing flexibility and fueling failures.
Agile is not, by itself, a methodology. The Agile Manifesto is a wish-list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed. I cheered when I first read it... Agile legitimized the idea that all stakeholders must be involved in the process of shaping the product's constraints and parameters (something that even now is still more preached than practiced). It gave a voice to developers and (some) others in the production process who up until then often had little say, and its message to managers in particular about the need to trust in the competence of the people they manage is one that cannot be stressed loudly enough. Its emphasis on change management has spurred a lot of thought about the nature of change, experimentation and development costs in the field. And for all that I think that certain Agile tools are a bit on the cheesy size, the idea of formalizing the process of development in such a way as to give creatives both the opportunities and the tools to shape and push back on design decisions is invaluable.
Yet, there are two key sets of problems that the Agile community faces. The first, and foremost, is that it decentralizes responsibility too much -- it essentially punts on the whole issue of governance or editorial guidance. This is that whole vision thing all over again... Agile empowers autonomous teams, but those teams still need to be able to pull together towards a common set of goals, and this means sacrificing some autonomy for cohesiveness. Agile also does not (ironically) distribute very well for precisely that same reason...
Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used -- as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.
But in a new follow-up, Cagle looks back over his 40 years of programming, remembering successful six-month development cycles in the 1990s that used "a home-grown methodology which I've since dubbed the Studio Model, because it reflected the way that you create movies, television programs, orchestrated concerts, video games, and to be honest, most intellectual property." He then attempts a 12-point manifesto for this Agile alternative, which emphasizes things like a clear vision, good design, redundancy, flexibility, and remembering that as a project moves forward changes become "exponentially expensive". All too often, proponents of certain methodologies want to claim that their methodologies are the reason for success, when in reality, the deciding factor was the skill and tenaciousness of the people involved, the presence of a clearly articulated vision that could be changed as needed but that was not written in jello, and on recognizing the distinction between providing flexibility and fueling failures.
Agile is not, by itself, a methodology. The Agile Manifesto is a wish-list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed. I cheered when I first read it... Agile legitimized the idea that all stakeholders must be involved in the process of shaping the product's constraints and parameters (something that even now is still more preached than practiced). It gave a voice to developers and (some) others in the production process who up until then often had little say, and its message to managers in particular about the need to trust in the competence of the people they manage is one that cannot be stressed loudly enough. Its emphasis on change management has spurred a lot of thought about the nature of change, experimentation and development costs in the field. And for all that I think that certain Agile tools are a bit on the cheesy size, the idea of formalizing the process of development in such a way as to give creatives both the opportunities and the tools to shape and push back on design decisions is invaluable.
Yet, there are two key sets of problems that the Agile community faces. The first, and foremost, is that it decentralizes responsibility too much -- it essentially punts on the whole issue of governance or editorial guidance. This is that whole vision thing all over again... Agile empowers autonomous teams, but those teams still need to be able to pull together towards a common set of goals, and this means sacrificing some autonomy for cohesiveness. Agile also does not (ironically) distribute very well for precisely that same reason...
Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used -- as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.
Is this some kind of racket . . . ? (Score:5, Insightful)
Declare the current software development process as obsolete.
Hash up some new kind of process.
Convince top management that without this, they will die.
Sell education services to teach this newfangled process.
Profit!
Repeat in a few years . . . the process that you sold a few years ago is totally too old.
Re: (Score:2)
Not sure if the process outlined here has much opportunity for consulting - you would need to create a methedology around it (like scrum did for agile). It seems Scrum in particular is a divisive topic for developers, so I don't think you need any conspiracy theories to understand why it's being declared dead by some.
Re: (Score:3)
Re: (Score:1)
How can it be dead when all the top companies are practicing scrum rituals?
Which top companies are those? I have literally never worked in a place that used Scrum, and many of the people I've worked with would probably run away if management suggested it.
Re:Is this some kind of racket . . . ? (Score:5, Informative)
Just because the matching words are being used to describe something doesn't mean that it is really what advocates would have wanted.
For example, most recently I have seen a company pull in Agile consultants to train up some 'Agile' coaches. The Agile coaches then took the material, and walked back much that isn't compatible with the corporate vision (offshoring is desired so face to face is out the door. Srum Masters and Product Owners are project managers and they should be the only non-fungible roles, project managers are the *only* ones allowed to create or schedule stories), That diluted training was given but still included a few things (e.g. that teams should be more autonomous, welcome late requirements, and that the various things like story points and estimation were a tool within a small team that cannot be interpreted outside the team).
Then there was a post-meeting meeting where managers "amended" that training to say that late requirements are not OK, story points were to be mapped exactly to X number of hours and each sprint should consist of exactly X story points and all teams should have identical looking burndown charts.
Anyone who *thinks* they have a new shiny methodology to fix the ills of the predecessor either needs to realize that any vision is going to be polluted by the same mistakes that lead an organization shopping for a methodology or the creators of a new methodolgy are a scam artist seeking money.
Re: (Score:2)
Where I work we have a mix. When I first joined, we had daily stand ups with the 5 of us and 3 week sprints, but the sprint was really defined as "what we are currently working on" and things would move from this sprint to the next sprint and carry on without releases. Additionally, code would be published from our test system to our production system twice per week, when the dev working on a particular work item said it was done and created a publishing request. Our issue tracker (Jazz from IBM) is/was
Re: (Score:2)
It isn't dead. I just said many people are ready to declare it so because they hate it.
On the other hand, this whole kerfuffle and string of articles started because apparently Scrum has fallen out of grace at the 'top' companies. It seems mostly the mid and low companies are using it.
Re: (Score:3)
Re: (Score:3)
That 95% needsa lot fo citations. I've been programing for decades and all the stuff we made worked, and we were a lot quicker about it than we are today with all the faux-agile rituals supposedly making things better.
And yet CGI is still what web development is all about - you send some data to the server, a process runs some binary logic, and sends saome data back to the client. We may have improved the wrappings around that ancient perl CGI server (well, some of us, /. seems ot work OK with it) but the
Re: (Score:2)
That 95% needsa lot fo citations. I've been programing for decades and all the stuff we made worked, and we were a lot quicker about it than we are today with all the faux-agile rituals supposedly making things better. ...
If you had studied computer science in an university and especially the topic "software engineering" you would have been hammered with those citations.
Now it is obviously left to you to find some on your own
The number in the late 1980s of _complete failures_ as in project got canceled at s
Re: (Score:2)
I've been programing for decades and all the stuff we made worked, and we were a lot quicker about it than we are today with all the faux-agile rituals supposedly making things better.
You were able to do that because you are skilled. The question is how do you get people to do meaningful work when they lack skills? The answer is to get them a PM and a PM and use the carrot/stick of scrum to keep them on task.
Re: (Score:2)
That's still not 68% of projects fail.
That article says 68% of companies will have a project that fails. When you think about how many projects a company has going on, that's a reasonable stat, but in no way suggests that failure rates for projects are anything like as high.
If it was anything else, the whole software industry would have failed already.
But the article then goes on to say the way to succeed is... to write down what you want up front (though they do say iterate the requirements phase until you
Re: Is this some kind of racket . . . ? (Score:2)
Re: (Score:2)
Jesus, you fail your own post.
https://www.failory.com/blog/s... [failory.com]
63% of "information industry" startups fail. And a ton of those in the IT space are "social media" startups, so dreamers that have already failed.
Re: (Score:2)
Re: (Score:2)
Here you go [blogspot.com], you search-engineless man. I seriously doubt you've ever been part of a succeeding project.
I disagree. With such a positive attitude, how could they not fail? :P
Re: Is this some kind of racket . . . ? (Score:2)
Re: (Score:2)
And yet CGI is still what web development is all about - you send some data to the server, a process runs some binary logic, and sends saome data back to the client. We may have improved the wrappings around that ancient perl CGI server (well, some of us, /. seems ot work OK with it) but the idea that writing your entire application in javascript on the client is progess is laughable.
I understand the OSI model and underlying technology. I can read packets in hex in a packet sniffer. That has nothing to do with delivering functionality. Do you post all your slashdot posts by writing programs in ASM with a hand-crafted NIC driver to communicate with the HTTP server by raw sockets? I doubt it. If you do though, you certainly are a masochist and enjoy wasting a lot of time. I prefer to use my time wisely.
Re: (Score:2)
But did agile fix that? There are still death marches with agile. If you say that's because Agile was done wrong, then you may as well say that waterfall was done wrong too.
Re: (Score:2)
Re: (Score:2)
Most Agile methods cost next to nothing.
Neither XP nor Scrum is particular expensive, compared with a Java or C++ course.
So claiming people hype stuff to earn money with teaching is for many teachers an insult, especially when they are good at the topic and good at teaching.
If you 'don't like "agile" ' then do something else. Can't be so hard leaving other people alone. I find baseball too quite boring and not really self explaining in its rules, but I don't run around ditching baseball fans or players.
Re: (Score:2)
Most Agile methods cost next to nothing.
There are corporate level consultants that do make a lot of money, and do so with very little potential for downside.
If you 'don't like "agile" ' then do something else. Can't be so hard leaving other people alone
People who complain about "Agile" are people that would love to have been left alone by "Agile". If it was just something people decide to do for themselves, then no one would care to object. Of course, if "Agile" is being mandated by executives, it's probably nothing like what the writers of the manifesto would have wanted.
By extension, if "Studio" catches on, it will be the same deal. It c
Re: (Score:2)
Any change gets some developers upset. Such as a change to please create documentation first before you start coding, or please get a code review before checking anything in, or please give me an estimate about how long this task might take.
Re: Is this some kind of racket . . . ? (Score:1)
Re: (Score:3)
It _is_ some kind of racket. Also, most people forget the first line of the Agile Manifesto completely: "people over processes". If you miss out on that, Agile is pretty much worthless. If you see it and act according to it, the rest of the Agile stuff is nice, but you already have 90% of the benefits with this line alone.
Re: (Score:2)
I never liked the "people over process" idea. It sounds like something driven by the developers rather than being driven by the company. Usually, engineering is not a charitable organization, and it is almost never a democracy, and instead the bottom line is important, getting stuff done is important. I know it's annoying, I've been there, but processes are there for a reason.
If all the developers think that code reviews are a waste of time, for example, that's not a valid reason for the company to abandon
It's always about the quality of the team (Score:5, Insightful)
I've been in software development, in one capacity or another, for nearly 40 years. I've seen all sorts of methodologies. Every few years, something new and shiny comes along that is going to solve all problems. What's the buzzword of the day?
It all doesn't matter. Any methodology can work, any methodology can fail. In the end, it's all about the quality of your team.
Some projects require lots of customer feedback and a highly iterative approach. Back in the days of waterfall projects, if you had a project that needed feedback from the customer during development - and your project team was good enough to realize this - you effectively had an agile process, before that term had been invented. Today, you can Scrum all you want, but if you have a crappy team, your project will fail. In fact, I just recently witnessed a catastrophic failure, because a Scrum team basically spent a year ignoring what their customer was telling them.
For other projects, continuous customer interactions and tiny iterations just waste everybody's time. If the requirements are clear, just do the damned project. One of the best projects I ever worked on: We laid down the requirements in a couple of weeks of of intense work at the start. Then: bye bye customer, see you when we're done. Sure, within the development process there were iterations, but there was no need for the customer, or a product owner, or whatever. Just months of pure development work. That was by far the most efficient project I've ever worked on, and the customer was very happy with the result.
Re:It's always about the quality of the team (Score:5, Interesting)
The quality of the team is at the top of the list, but it is not the only thing on the list of what makes a work effort succeed.
I don't have a link handy, but the bi-annual Chaos Report by the Standish groups shows (last I checked) that Agile methods have 3x the success rate of waterfall methods. Interestingly, that doesn't get Agile over the 50% success margin! But waterfall had abysmal success rates.
Agile is not a silver bullet. But, it turns out that getting a high-quality team is a lot harder to do in advance (to do intentionally), than to use an Agile methodology. High-quality teams are rare, and they aren't just a simple collection of people with big brains or big resumes.
In fact, from a business perspective, Agile methods are a good bet: low cost to implement (compared to trying to get a good team), and a very high multiple for success. In other words, good ROI.
Re: (Score:3, Insightful)
Re: It's always about the quality of the team (Score:2)
We do the same thing. Anything that becomes hairy during planning get "waterfalled".
Re: (Score:2)
Maybe if something does not actually become hairy during planning is something that's simplistic enough that any process would work? And anything that's going to take longer than a year before shipping is almost certainly going to be hairy.
Re: (Score:3)
I wish I had mod points today.
I very much doubt the projects are comparable at all.
Consider a transaction processing system for banks. There are so many components that must work together that you don't just start without carefully thinking through all the data flows and error modes. Requirement don't change often or easily and the system doesn't "work" at all until the last piece is in place.
Web pages, "apps" etc are different. Just build something basic that works and let the demand of the customers guide
Re: (Score:2)
Correlation is not causation. Seriously.
Re: (Score:2)
However, Agile and Waterfall aren't the only two choices out there. I suspect the majority of companies have an ad-hoc method that's a mixture of Agile, waterfall, and seat-of-the-pants. Having a deadline or schedule is not the same as waterfall.
If you're making a real device and you've got hardware and manufacturing involved (and maybe a protocols or science group) then you've got to have a style that's similar to waterfall or it's all going to fall apart. You can't get manufacturing up and going on a ne
Re: It's always about the quality of the team (Score:1)
Re: (Score:3)
A somewhat quality team is obviously a requirement. However, so is competent management (Product Owner, Product Management, Project Management, Customer Representative, other stakeholders). Agile provides a bit more of a framework than traditional methods to slightly lower the chances of the latter bunch being the problem.
Re: (Score:2)
Actually, what we all probably need is a methodology that works for crappy teams. Because those are in the majority. I'll be honest, I don't know if I've ever worked on a team in 30+ years that wasn't crappy in some regard or that didn't have a couple of lead weights attached to the team that would offset the couple of geniuses. Some of the smartest developers I've known were terrible in a team environment, and some of the best developers were rather mediocre at programming.
Although it may not matter, in
Re: It's always about the quality of the team (Score:1)
Re: (Score:2)
Re: (Score:2)
I'm sure they have, but I've seen the same phenomenon under "Agile" as well.
There's a certain business reality that needs to be fixed in those shops and a new methodology doesn't fix that.
Re: (Score:2)
Re: (Score:3)
Today, you can Scrum all you want, but if you have a crappy team, your project will fail.
Yes.
And it will fail with any other process/method, too.
Wow, that was so easy again.
But with Scrum you know after 3 sprints that they will fail. And with a traditional process after 2 or 3 milestones ... pick the amount of money/time you want to sink.
Re: (Score:2)
Exactly this. The model you use is basically immaterial as long as it does not stand in your way too much. What is important is understanding the problem you want to solve and what the interaction model with the customer is. And that can only be done by insight and experience.
Of course, there are a lot of mediocre to abysmally bad coders out there and they are always looking for the one true model and the one true language that finally will make them and their code not suck. That model and that language doe
Re: (Score:2)
It all doesn't matter. Any methodology can work, any methodology can fail. In the end, it's all about the quality of your team.
This is a simplistic statement that is extremely easy to falsify. I worked in an excellent team at a large corporation that used to be very successful at a time. We worked for 1.5 years on a product for a large customer. After 1.5 years the customer told us we're not working on what they really need. The problem was the product management and the fact we didn't communicate with the customer in iteration. In fact, we didn't work in iterations because the project manager didn't believe in "this agile crap".
Re: (Score:2)
A quality team almost by definition is one that's adaptable to circumstance. What works for a game studio wouldn't necessarily work for an in-house IT development shop or a small consultancy juggling several projects for different clients.
Now I've definitely worked in a few situations where a relatively pure Agile approach fits pretty well, but ironically it was because Agile gave us a way to limit our responsiveness to managers and clients. In those cases I've found Agile to be a pretty useful "manage f
Too much focus on process (Score:3)
1) To understand what everyone on your team is working on. There are a dozen ways to do this (look at code reviews, standups, daily emails, whatever).
2) You need to get requirements so you can figure out what to build in some way. There are a bunch of ways to do this, also.
Those are the crucial points. Maybe in addition your team will enjoy games, or motivational techniques, or silly chants (we do that at my current team), or lots of meetings to facilitate communication and make the workday pass faster. These are all fine, but it's important to pay attention to the core of what you are trying to do. The rest is just syntactic sugar.
Re: (Score:2)
You don't need the first - I worked plenty of places, even agile ones, where we have the standups and I tune out when some colleagues are speaking about their work - nobody cares.
The architect or product manager guy (or whatever you call the chap who's supposed to make sure it all has a coherent design) knows, and that's good enough, the rest of us can do our thing and then ask for another thing. If the interfaces are defined, or not rode-roughshod over by some dick who thinks it all needs refactoring becau
Re: (Score:2)
1a) you need a way to refocus the team if they're working on the wrong thing. This does happen a lot. Agile supposedly is supposed to help with this, but it can't help if there's no higher level of oversight/management/whatever that can determine that the team is on track or not. I'm surprised sometimes when I run across a team that's been spinning wheels for months or working on low priority side projects and no one has noticed.
Re: Too much focus on process (Score:2)
Convenient for the bean counters (Score:5, Interesting)
I originally thought that the whole Agile thing had the effect of eliminating the hidden costs of maintaining technical debt, by bringing them to light.
Sadly, this is not the case. The way it is used in practice is to allow the managers and the bean counters to fill in spreadsheets and "itemize" the work of the developers.
The hidden costs stay hidden and developers have to stay after hours to work on problems that managers do not want to hear about.
Alan Perlis famously said: "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it."
It is incomplete however. This has to be added: "And the upper management imposes it."
Re: (Score:1)
Boeing's, new motto: “MAX the only airplane guaranteed to get you back on the ground”
Re: (Score:2)
Sorry to hammer it into you: you are doing it wrong!
Sadly, this is not the case. The way it is used in practice is to allow the managers and the bean counters to fill in spreadsheets and "itemize" the work of the developers.
That is a thing that does not exist in an agile development environment.
The hidden costs stay hidden and developers have to stay after hours to work on problems that managers do not want to hear about.
The core mantra of agile is: extra hours are verboten!!
I can not get that it is not sel
Re:Convenient for the bean counters (Score:5, Insightful)
> The core mantra of agile is: extra hours are verboten!!
Nice thing, in theory. I would like to see it put in practice, though.
The thing about no extra hours I saw used in only one way: The upper management will plaster it on your face if you dare to mention to them that you have to stay after hours due to their incompetence.
We don't do extra hours, as we are agile, so you did not stay until 10 PM yesterday to do work we don't want to hear about. Don't worry, you won't be paid for the extra time.
I would like to see that work place where they do stick to the principles of Agile and the upper management admits that problems do exist even if they don't like those problems.
So far I only saw the Agile manifesto used as a smoke screen to deny the existence of inconvenient problems.
Whenever you mention a problem they just stick the Agile manifesto in your face and tell you to go away.
As for me doing it wrong, sorry, but I was not the one making the decision. Waterfall was working just fine, but the beancounters wanted the work to be more "itemizable".
Re: (Score:3)
Because you probably work in an environment where shoving "Don't worry, you won't be paid for the extra time." is easy for management.
In Europe that is not the case. Not paying extra hours is even illegal (in most cases).
Re: (Score:2)
If only everywhere was Europe. All things would be perfection!
Re: (Score:2)
Sorry to say that it does. We "point" work so we can determine "velocity" so we figure out how much work we can cram into a "sprint", and to which each team member must "commit" getting done.
Which leads to bean counter questions like, "Why did your team fail to meet your commitments for this sprint?" And, "Why isn't your velocity increasing?" And, "Team X is completing 5.4% more points/sprint than team Y. What's the problem with team Y?"
IMHO what started out as a manifesto morphed into Agile "management" to
Re: (Score:2)
Which leads to bean counter questions like, "Why did your team fail to meet your commitments for this sprint?" And, "Why isn't your velocity increasing?" And, "Team X is completing 5.4% more points/sprint than team Y. What's the problem with team Y?"
If that is the case, then I have to hammer into you as well: you are doing it wrong!!
Can't be so hard to not realize that yourself.
Hint: 'statistically', what percentage of sprints would/should you 'fail'?
Hint: bean counters don't even are supposed to see sprint
Re: (Score:2)
Tell that to management. I just work here....
Re: Convenient for the bean counters (Score:2)
You're STILL holding it wrong!
Re: (Score:2)
Indeed.
Works for me... (Score:3)
I work for a company that produces software for the motion picture industries, so we get to work with the studios that are being used as an example. Here, we have a process made of people, and people don't fit into processes. Or rather, there are some people that will have an exact niche, but you can't always fit the others around them. But the whole thing has ti come together somehow. All management models are wrong: some management models are useful.
Here, I would pick out "having a vision" is key, where the vision is often something that the customer does not know they want until the see it. The exponential cost of change is important to recognise, but there isn't a lot you can do about that beyond being occasionally prepared to rip out something central because it is holding you back. The changing nature of the job again is important, as the project evolves from the people working o their separate bits, to something with a regular build and smoke test 'heartbeat', but there isn't a lot you can do about that either.
Re: (Score:3)
Here, we have a process made of people, and people don't fit into processes.
We are working on fixing that with CRISPR.
People genetically engineered to fit into processes!
Re: (Score:2)
Point 7 isn't exactly a new insight, nor unique to his model or even others: "The Customer Is Not The Visionary". Yes, the customer often does not know exactly what they want, and it can be di
Bias and Exponential Cost of Change (Score:5, Interesting)
Logically, Cagle's argument mostly rests on anecdote. The one part that needs to be addressed is his claim for the exponential growth of cost of change in software (and other creative) work. As a professional programmer myself, I believed in this cost of change curve for the first 3 years of my professional life. Then I learned about test-driven development, refactoring, and a few other less-well-known technical practices and my experience changed.
Changing software is not actually hard. Instead, designers and developers make it hard. Then, because of two strong biases, the sunk cost fallacy (also known as throwing good money after bad), and confirmation bias (ignoring disconfirming evidence), we experience growing psychological effort in making change that makes the cost of change grow exponentially. In other words, the exponential growth in the cost of change isn't inherent in the creative work itself... that cost of change is a consequence of our psychology. As we build more and more stuff, we want to change it less and less. We resist change and that resistance shows up in a myriad of ways including:
- plain procrastination (but our hours are still counted!)
- narrowing of solution options to those which are compatible with what we have already built
- arguments about solutions instead of just trying solutions
- a desire to keep one's previous solutions even if they aren't good anymore and therefore building overly-complex accommodations to those solutions
A good Agile development environment actually creates the psychological environment to reduce or eliminate most of these biases. How? By giving a team practical technical, process and teamwork practices that reduce and flatten the cost of change curve.
FWIW, I'm an Agile consultant and trainer. I don't believe that Agile is for everything... but I do wish that more of these "Agile is dead" arguments would actually address the bias problems systematically. A good starting place is to read "Thinking, Fast and Slow" by Daniel Kahneman.
Re: (Score:3)
His point about vision and having an overall architect is valid. In fact all too often the process focuses on defining epics that span stories that create tasks that are pointed and pushed into sprints. Developers pick up those teeny-tiny tasks and start work on their little pieces of the puzzle.
The problem is that all too often the piece that you're doing now is only part of the big picture and you have no idea that at some later point your current piece will also have to do B and C and integrate with X. S
so.. Fred (Score:2)
Isn't this just reinventing the whole surgeon team model Fred Brooks described 30 years ago?
Re: (Score:2)
Isn't the studio model the prevailing model? Only with inept directors.
Re: (Score:2)
Re: (Score:2)
And it gets away from what I think is the worst fault of Agile. As has been said long ago:
My experience is that Agile gives altogether too much room for ego--"I need to put in my two cents, no matter whether they are contradictory to having a unified vision."
Re: (Score:1)
Suddenly that team has to work on lots of new content.
Re: (Score:2)
Brooks described what works. Brooks also said to get the best people for the job you can. In fact, the best people will very likely save you a lot of money, no matter how expensive they are. (My observation, but likely said somewhere by Brooks as well....)
What is happening is that Brooks described a lot of inconvenient truths and hence his spot-on observations and recommendations are routinely ignored.
Re: so.. Fred (Score:2)
People love to quote little snippets from Brooks; but alas hardly anyone actually bothers to read his whole book.
Re: (Score:2)
That punting has another effect (Score:2)
Re: (Score:2)
Everyone stop and vote because God forbid that a senior engineer just hammer out a patch, align it with a new 1pter in Jira and announce "that problem we all noticed? Solved per PR here:...."
If that happens in your agile teams, then I have to repeat the old mantra and hammer it into you: you are not doing it right.
Cant't be so hard to realize that by yourself.
(P.S. bugs don't get points ... the points are already in the feature/task/story where the "bug was produced")
Re: (Score:2)
So when bugs come back in 6 months later and need to be worked you don't point/t-shirt them as to level of complexity?
They're going on the board to be worked, regardless. If they're not sized how do you determine how much "work" can be done by the team in the current sprint?
Re: Yup (Score:2)
Um bugs donâ(TM)t get points because they are waste, not value. Working on defects is supposed to reduce your velocity metric, not contribute to it.
Re: (Score:2)
So when bugs come back in 6 months later and need to be worked you don't point/t-shirt them as to level of complexity?
No, they don't.
How would you even know how complex a bug is?
Bugs are neither estimated in points (Stories) nor in work hours (tasks) .... because you don't know how much it takes in either metric.
And see the other answer, I allow myself to quote it: Um bugs don't get points because they are waste, not value. Working on defects is supposed to reduce your velocity metric, not contribute to it.
Re: (Score:2)
"How would you even know how complex a bug is?"
Because I've been dong this for awhile now? There's a difference between something typographic, something misplaced in the UI, maybe a validation problem, and a totally random Crashlytics issue.
".... because you don't know how much it takes in either metric."
Going off the above, that's likely a few minutes, an hour or so, a couple of hours, and maybe a two-hour spike to determine just how serious the problem is, maybe pin down the cause, and at the least come u
Re: (Score:2)
There is a difference in planning a sprint where you DON'T estimate bugs.
Or giving feedback to a customer who has to decide which bug to fix first.
However in both cases, if I was your customer, I most likely had switched to a different development company long ago :D
UI issues are not really bugs in my eyes, and probably can be estimated as "change request" or "new feature" ... a bug is something "unknown" ... you neither know where it is nor how to fix it. You probably have a vague idea because something
Re: (Score:2)
The most toxic team I've ever worked on loved agile because it gave everyone a chance to discuss their feelings, play politics and ensure that no one with a stronger work ethic showed up others. Bug shows up that's stopping people from getting stuff done? Everyone stop and vote because God forbid that a senior engineer just hammer out a patch, align it with a new 1pter in Jira and announce "that problem we all noticed? Solved per PR here:...."
Those are also the teams where anybody competent will try to leave as fast as possible.
Oh goodie another development type (Score:2)
The most amazing thing about agile (Score:2, Troll)
The Agile Manifesto is a wish-list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed
If you know that it's just amazing how management has turned those ideas into a way to often micromanage people worse that waterfall. I guess agile should just go with the acronym WTWF
Hey look everybody, management!!!! (Score:2)
What works (Score:1)
What is it with The Software Dev Model? (Score:3)
.
I've worked in software engineering departments (as a developer and as a manager) in many companies. One of the things that is prominent for me is the various companies all have differing dynamics.
Why the effort to force all those different dynamics into one process style? Shouldn't the process style morph to meet the needs of the company, instead of vice versa?
Re: (Score:2)
Simple: Same problem with the search for the "best" language. The fact of the matter is that most coders and most managers are pretty bad at what they do. And it is because of their personal limitations, so the only real fix would be to have them do something else. But because these people think that, of course, the problem is not them (refer to the "Dunning-Kruger Effect" for why they think that) it must be the tools! Hence they believe the thing that makes their code suck and their projects fail is for su
Reality (Score:1)
No PM style works 100% not even close (Score:1)
They are all dependent on everyone buying into them. Not just the Devs.
I've worked with just about all of them by now. Maybe one of them works great in some instances. Maybe another works great in others. All can fail in many.
I see the worst abuses in businesses that claim to be Agile. (I know... they're using it wrong. that's not agile. but that's the way it happens. Hence "claim to be")
I watch "scrums" that are a recap of what people are doing. No scoring new tasks at all. Management of a fixed
The Quest For A Silver Bullet ... (Score:2)
All these methodologies, new programming languages, the 'cloud', ...etc. are just all a facet of the same thing: non-technical managers seeking a magical 'thing' that would cut down the effort, time and cost of developing software.
Fred Brooks, in his No Silver Bullet [worrydream.com] paper says that all the old hurdles have been overcome, and what remains are the essential ones. He gives advice on these (buy if you can, rather than build, rapid prototyping, and so on), emphasizes that there is, well, no silver bullet.
A clas