Slashdot Mirror
Is Agile Development a Failing Concept?
Nerval's Lobster writes: Many development teams have embraced Agile as the ideal method for software development, relying on cross-functional teams and adaptive planning to see their product through to the finish line. Agile has its roots in the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods. And now one of those developers, Andy Hunt, has taken to his blog to argue that Agile has some serious issues. Specifically, Hunt thinks a lot of developers out there simply aren't adaptable and curious enough to enact Agile in its ideal form. 'Agile methods ask practitioners to think, and frankly, that's a hard sell,' Hunt wrote. 'It is far more comfortable to simply follow what rules are given and claim you're 'doing it by the book.'' The blog posting offers a way to power out of the rut, however, and it centers on a method that Hunt refers to as GROWS, or Growing Real-World Oriented Working Systems. In broad strokes, GROWS sounds a lot like Agile in its most fundamental form; presumably Hunt's future postings, which promise to go into more detail, will show how it differs. If Hunt wants the new model to catch on, he may face something of an uphill battle, given Agile's popularity.
No.
DNRTFA, but I think this will be a fun thread.
Regardless of what Agile really is (a true scotsman?) the abuses perpetrated in the name of agile are appaling. I think a lot of people think agile means something like:
make bad developers good by not bothering to organise things properly
Which is really amazingly appealing if completely bogus.
SJW n. One who posts facts.
Like so many other things, it's very difficult to take an ideal theory and put it into practice in the real world. If your team really understands the ideas behind Agile and you have a good process in place to make it happen, you can have a great deal of success.
Unfortunately, like so many other things in life, most teams don't get it right and they end up failing to some degree or another.
It is hard to take someone seriously when the argument seems to be 'my idea is brilliant! but most people are not good enough to implement it!' rather than 'hrm, maybe my idea is not the universal solution and one needs to fit the methodology to the requirements and resources involved?'
No, it's just no longer selling as many books and consulting hours as it once did--so it's time to invent a new scam.
Sales / Management are on strict Waterfall and dev is on Agile
Until those concepts align in a company they will always be at odds with each other
Agile, done right, has been a game changer here. Yes, we had to let some of our developers go - the ones who couldn't actually think. We're better off for it.
There is no way to optimize the development process for software. Inserting terms such as "Agile" or "Waterfall" really just create bloat and waste time. The best software development process is to have no process and work in the way that fits you best. For instance when I write large software projects, I just start coding, I pick a place to start at and go. I wait until I have large testable blocks completed and then debug and integrate them. I don't follow and form of standard development process and yet have never been held up via a deadline of meeting request.
When developers try and add those stupid terms, they're basically saying that they can't self manage and instead of taking responsibility, they're going to throw silly management methods around in an attempt to streamline a task which is unique to each individual developer and situation.
The only things you need to write good code are the right language, the right platform and proper requirements. Once you have those, you can just start and work to completion.
Our development and project management groups (~ 50 people) moved from waterfall to scrum/agile 2 years ago. Since then, we have seen a significant increase in quality and velocity. It is also more comfortable for the devs on the teams because they know exactly what the PM process will be and what is expected. I don't know that Scrum/Agile is the best practice out there but in our case, it has brought increased productivity, higher product quality, less worry and overall comfort with all our processes.
Error reading device 'Signature'. (A)bort, (R)etry, (F)ail?
Agile started failing pretty much as soon as it met the real world. I disagree with Andy Hunt's explanation of why, though. It's not because "thinking is hard", it's mostly because of two things: management not allowing agile to be done correctly, and (from the developer's point of view) it drains software engineering of the things that make it a satisfying and enjoyable activity, turning it into the software equivalent of grunt factory work.
New books to be written and sold, new training programs, new seminars. That's the reason there has to be a new methodology every decade.
Agile is great in theory and if you can get everyone involved to understand it then it's great in practice, too. The reason I say agile is a failing concept is because those of us in the industry understand it but are remarkably terrible at selling it to the non-technical people we need to have involved in order for our projects to be successful. What good Agile methodology really drives at is an effective amount of involvement from all parties -- customer, analyst, technical team, testers, operations, etc. Most businesses want to fire things at their IT department and then go off and do other things while the project is underway. This is clearly more conducive to the "waterfall" model (which we all know is terrible) and it prevents them from ever seeing and effective agile development implementation.
So, yes, Agile is a failing concept. Not because the idea bad, but because it's so incredibly difficult to implement fully, and it's not very valuable when partially implemented (you basically just turn it into mini-waterfalls).
I foresee DevOps ending up with a similar problem.
That's not even close to enough time for a major cultural change to take place. The Agile Manifesto describes a culture of work that is so fundamentally different from how work was (and still is) performed, that I expect it will take another 15 to 30 years for organizations to really "get it". This is the same thing that happened with Lean manufacturing. Toyota developed it, other manufacturers adopted it as a fad over the course of about 15 years, and then it declined in popularity... but it never died out because it was "correct" and "good". Now, 40 years later, most manufacturers are still learning to be lean, but lean has fundamentally changed the culture of manufacturing. I have clients that will probably be working to adopt Agile methods over a 10 to 20 year period. Agile hasn't failed... Andy Hunt's patience has failed.
Helping with organizational effectiveness is our job.
I'll dub thee DevOps
Is Agile Development a Failing Concept?
No. It's just that people suck at doing quality work. People released shit when using procedural/modular programming. But that's people, not procedural/modular programming. Then OOP came, and people did more shit with it. But that's not on OOP, but on people.
I can say that with confidence because I know teams and companies that have delivered quality work using either any (or all) of these paradigms.
Same with processes. People have done good work with waterfall, and bad work with waterfall. Good work with spiral/iterative process, and bad work as well. Same with RAD, RUP, all flavors of agile, XP, Scrum, Kanban, etc.
It is people. It is organizations. A group of engineers that do good work with one reference process is very likely to do good work with most other processes, newer or older than the reference process by which they are currently being measured.
Newer processes are typically better than older ones when applied to general cases. Better as in helping ameliorate cost or increase delivery, or pretty much optimize some type of software development KPI. But that neither implies older methods are bad or that newer methods guarantee better deliveries.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
It's never the tool, but the wielder.
This is bullshit. Tools can be poorly made.
I second the management thing. None of the managers want to change the way they manage things (I need a schedule for your work for the next 6 months!) in away that prevents any of the advantages of Agile from being fully realized.
I've worked on agile teams that accomplished little more than completing the required checklists, and I've worked on agile teams that were very productive. It all depends on the skills of the scrum master and the product owner; of course the same could be said for any development process - good people can make it work, incompetent people will make it fail.
You don't need to create a new one, just use DevOps!
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Then you haven't been in software development for very long or how little ability to discern a good tool from a bad one. Shitty tools are foisted upon software developers all the time in the form of buggy and/or poorly documented frameworks, databases, IDEs, etc.
or *have* little ability, that is.
Nah - that one won't get as far - it usually requires that people prove their ability as both a sysadmin *and* as a developer (or at least as a member of a dev team). Most applicants choke hard on one or the other in the interview, and I'm not seeing a credible 'certification' yet that can paper over that deficiency.
Quo usque tandem abutere, Nimbus, patientia nostra?
The articles to which TFS links point have more than a few links and references to other articles, blogs and books (yes, "see my article/book") written by Andy and the "gang of 17". Not exactly astroturfing, but certainly rather self-promotional. "Agile" is one methodology, appropriate for some situations, but certainly not the "one ring to rule them all." (if I recall, wearing that ring had some negative effects...) Now he wants us to move on to: "The GROWS (TM) Method."
All this probably benefits someone, not sure it's always us.
It must have been something you assimilated. . . .
As a system admin, I admire agile for the rapid proto-typing. Because as we all know, business users seldom know what they really want, but they all know what they don't like. However, I hate agile for being the universal excuse for turning project management into an exercise for "let's make it up as we go along", because then everyone expects me to work like that too. They don't want to acknowledge, let alone understand, that being a good system admin is about being organized and informed and having a more than 5 minute attention span.
Agile doesn't make a crappy team good.
An excellent team is good with or without Agile.
Too much effort is spent on methodology compared to construction of teams which work really well.
Usually, people just end up in a team. "Here's Steve, he starts today. Hi Steve!".
Setting up an excellent team is usually very hard, and take a lot of skill. I.e. it requires excellent leadership.
I've seen it once in 20 years, and fortunately, that time is now. I'm happy to go to work, despite crappy
customers, budget constraints, slow hardware. The people are awesome and make the best of it.
So true. When we help an organization "go Agile" it is critical that the managers also use Agile and that they stick with it. But this doesn't mean exactly "by the book" since, for example, Scrum might not be the best approach for a management team. Kanban, OpenAgile, Crystal or other Agile methods or techniques might work better for any given team (including a management team). Long term success of Agile methods in an organization requires that management become Agile too.
Helping with organizational effectiveness is our job.
Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).
"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.
I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.
This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.
One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".
For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.
There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
Totally agree- I am certified scrum master and most of the attempts I have seen at organizations being 'agile' have been atrocious.
love is just extroverted narcissism
The problem isn't that many programmers don't know how to use Agile methods. The problem is that many programmers don't know how to think critically.
If you have a terrible HR process that allows morons into your company, then no investment, no snappy buzzwords, not nothing is going to make them change how they fundamentally approach problems. By time you graduate college, 99% of people are already set in their ways, and within the first few years of working, the rest have.
It's like my Differential Equations 2 teacher in college said. "This is not the class to learn fundamentals of problem solving. If you've come this far and still haven't learned to solve problems, there's nothing I can do in this last semester to fix you."
I've been watching the idea since the early 00's. I've been on teams that have adapted the processes to work for the team and have been very successful doing so. I've seen a team get a cadence going and become extremely accurate at estimating new work for a product the same 5 people worked on for 5 years. During that time they also dramatically improved the quality of the code, reducing crashes that required weekend coverage to almost 0. Every once in a while they'd adjust their processes if things weren't working smoothly. Teams can work very effectively in an agile environment, if they're actually allowed to.
If you follow the evolution of agile, you see a lot of key concepts that get repeated over and over. The guys who wrote it understood that code is never perfect and never really correct the first time you write it. It pushes unit testing as a core component of the process. As with other things, making mistakes and correct them teaches you something about the problem, and so the whole process is designed around uncovering those mistakes quickly, throwing code away and rewriting it and constantly improving quality. The philosophy of most companies is that the developers should just crap something out that kind of works and then move on.
What it basically comes down to is just because your team is agile doesn't mean you can hire chimpanzees to write your code. Or manage the team. If you're looking for a silver bullet that will fix what's wrong with your company, agile isn't it. It enforces much more discipline than whatever crappy process you were using before that, but you really have to understand what it's about, and most people don't.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It's a good article, but the pattern is an old one. Twenty (20) years ago, I wrote much the same thing about object-oriented technology. Since then, I've found that the same issues, the same pitfalls, pretty much apply to any new technology or methodology; here are some more generalized pitfalls (based on ones from the 1995 book) that I wrote up nearly a decade ago (2008):
-- Adopting a new technology or methodology for the wrong reason
-- Thinking a new technology or methodology comes for free
-- Thinking a new technology or methodology will solve all your problems
-- Betting the company on a given technology or methodology
-- Getting religious about the technology or methodology
-- Adopting a technology or methodology without well-defined objectives
-- Overselling the technology or methodology
These all apply to Agile -- but they also apply to just about every other 'silver bullet' technology or methodology that's come along. ..bruce..
Bruce F. Webster (brucefwebster.com)
The problem is Agile is fundamentally incompatible with the way most businesses are run. Top down command and control organization, blind adherence to process, lack of discipline / peer accountability, lack of team autonomy, etc will all create a disaster out of Agile. Blame corporate culture, not the person pointing out the inconvenient truth that "Hey, software is hard and I'm not arrogant enough to sit in a room and design everything upfront and pretend here at the beginning of the project when I have the least amount of information over the problem that half of my decisions are going to be right."
it's management. When you get a good project manager its like a breath of fresh air. The best PM I ever worked for was a guy that used to be a developer and just didn't understand object based programming, after an honest assessment, so he decided to go into project management. He shielded us from all the corporate BS and just let us code.
Most of the other PM's I have worked for have no background in programming. Some of them claimed to and didn't, which is much worse than someone that just tells you they don't. They would insist on idiotic exchanges like the following:
PM: How long will it take to code this?
Me: I'm not sure until I get all of the requirements
PM: Can you give it a guess?
Me: Sure but what's the point? It won't be a very good guess.
PM: That's OK I just need something to put on the project plan
Me: *Bullshit radar is now on full alert* So you just want me to pull something out of my ass so that you can finish up your project plan? Is that it?
PM: Umm, well, no...it's not like that
Me: OK, fine. I'll give you numbers but they are going to be grossly inflated to account for the unknowns. It covers my ass. Kind of like what you are doing, no?
PM: *Grunts and walks away*
Most of these people look at project management as if we were building widgets on an assembly line. As if we know exactly how long each task is going to take. Well, software development is not not like that. Not in the least. The ones that understand that - the ones that are truly "Agile" as it were - are the successful ones. The successful ones understand that any number of things can go wrong and plan accordingly.
In the correct application, it can be a miracle. Misapplied it does nothing, or worse kills the patient. I've seen it misapplied many times.
Inapplicable (or should be). There is no "standard" here. It is a collection of related, mutually supporting practices and tools. People who try to make it into "name brand" all-or-nothing methodologies can create that impression though.
Starships were meant to fly, Hands up and touch the sky - Nicky Minaj
I do systems engineering work for a professional services/software company. Development is fully Agile with a capital A, whether or not it makes sense for a particular project. On the systems side of the house, we have another particular religion called ITIL which lots of companies have jumped into with both feet. The problem with both of these concepts is that they are adhered to, almost to a comical level, even if it's painfully obvious that parts of it don't fit.
Adhering to all of ITIL, for example, is a really good way to ensure your production systems almost never change. The number of people and sheer volume of paperwork, tickets and meetings to get anything even scheduled for a change in a "true ITIL" system is beyond insane. The same goes for incident management -- we have so many single-task focused "resolver groups" that I have no idea how anyone knows how any of our systems operate end-to-end. ITIL is great for mainframe systems, safety sensitive stuff, and networks which never change.
"True Agile" and "True Waterfall" are opposite ends of the spectrum. Agile gets you very fast development, at the expense of pinning down any sort of architecture in the beginning. Waterfall often results in software you have to throw away because the requirements change out from under you. However, there are some things that require at least some discipline, both in systems and development. No systems guy would ever advocate just logging in and making random changes on a production system to see what happens. No smart developer/architect charged with writing something that underpins tons and tons of other things would advocate swapping out the core components without at least some backward compatibility thrown in. The prpblem is that "gurus" make their money selling management on these methods. In the case of both Agile and ITIL, it's a manager's dream -- everyone becomes a replaceable unit and business requests can get promoted to production in one Sprint.
Do you even measure "quality and velocity", let alone "increased productivity"? Do you control for confounding variables? I bet the answer to all of that is "no". For all you know it might be hurting all those metrics, but you feel good about yourselves because you do "stand up meetings" every day and talk about how you couldn't get anything done the day before, but today you will definitely be able to do it.
My experience for most of these development methods and problems almost always comes back to requirements gathering. People typically want to jump on what ever solution they seize on or what is being asked of them instead of taking the time to truly understand the problem space and only then designing their solution. Often your Customer has no idea how a software implementation will change their work so I have watched agile being the blind leading the blind a lot. Rapid iteration is good, but to be successful in the end it requires an upfront understanding of the domain, thinking, and how it might change with different solutions.
...uses Agile.
not some subproject of a subproject, but a real project.
AFAIK no such thing exists, but if it did it could be analysed.
Frankly every time I down load a project I don't see any unit tests for examples. Code is written by one person.
I consider Agile a major failure, not in that it was a bad failure, but it took up all the oxygen from other iterative processes like RUP, and has reduced the progress of design overall.
Why would anyone take something seriously that was created and peddled by consulting outfits at $700-per-hour bill rates? I had the misfortune of being incarcerated at Pivotal Labs for a month by a misguided boss who thought their bizarre religion was the answer to all of life's ills. Boy, was that eye-opening.
As many people rightly point out, that doesn't mean we can't pick up some new ideas from it - my company now does short daily meetings and have a chart with everyone's daily tasking on it, and those have proven very effective. But the other 99% of what the Snowbird 17 vomited forth upon our industry is empty zealotry and jingoism. It was like Scientology right in our codebases, and worked about as well. And no, for god's sake, it wasn't because we just weren't doing it well enough.
We do have shockingly dramatic quality issues in the software industry, but they will never be addressed by the next dumb-ass management fad. We need to sit down and re-think the ways that we learn to code, get serious about "Software Engineering" degrees in our colleges, and let go of fetishized code patterns as the primary unit of engineering ability. In my own experience, we know plenty enough design patterns, but almost no one understands how to exercise coding judgment in the context of a team or long-term project.
It's never the tool, but the wielder.
This is bullshit. Tools can be poorly made.
Which is true. But here we are talking about tools, concepts and processes that are known to produce good results when used intelligently (or that should be known by anyone worth his/her salt in this industry.)
The context should have been apparent, but I guess we needed to go Barney Style with it.
What if the straws are melted down into a hardened composite? (ducks)
I am very small, utmostly microscopic.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Good luck hammering nails with a hammer made out of plastic straws. And when you can't get it to work, it must have been your own fault not that of a bad tool.
Why would you use a hammer made out of plastic straws? What is the use of that tool? What is the purpose? What is the context? These are obviously rhetorical questions used to highlight the stupidity of your counter example.
For that matter, why don't you go and say "good luck hammering nails with a bar of soap, a saw, or a roll of toilet paper"?
Which is true. But here we are talking about tools, concepts and processes that are known to produce good results when used intelligently (or that should be known by anyone worth his/her salt in this industry.)
No, we have a process that is full of "no true scotsman" defenders who do no introspection on why the methodology has numerous notable failures beyond blaming everyone but themselves. And I say that as someone who does like many aspects of Agile, but it is far oversold on what it can offer by its true believer priests.
Agile is nothing but an admission by clueless marketing/business development folks that they're terrible at their jobs. They have no idea how to do market research, they have no idea how to interact with actual or potential customers, they have no idea what a company's products actually do and what solutions they provide, they have no idea how to do the analytical side of their job, and have no vision at all for their industry. So instead they shove all the responsibility onto the development team: hack a small iteration together quick, show it to a customer (or more likely, show it to a cross-function representation of development groups within the company, none of which is trained in market analysis), and repeat until someone in upper management says "hey, this was supposed to be released this quarter". Then marketing will swoop in and offer to put together some glossies.
Obviously for situations like with a small start-up, you aren't going to have a well-rounded business development unit, and you'll be forced into having developers and other non-specialists pick up the business development slack. That's when agile makes sense: when you have no other option. But big companies with full business development and analysis teams pushing agile on its developers is nothing but welfare for idiot marketers.
The biggest failing of Agile seems to be the interpretation that no one has to care about the big picture. Planning and preparation are too narrowly scoped to specific functionality. Even in that there's a tendency to be lazy. Implementation often degenerates into hack and paste.
There's nothing horribly wrong with Agile development in theory. The chosen Agile method (yes I'm looking at you Extreme Programming), and especially the tendency to laziness sabotage development efforts.
Two of my imaginary friends reproduced once
Agile means: Completely loosing the big picture, allowing people to write code without knowing what the scope is they are doing it in. It also means: If something is too big to fit in a scrum sprint, you have to split it up in pieces which will not be scheduled in adjacent sprints because of -wheee Agile- higher priority stuff. Which means the pieces might easily go to different teams, or the second half might not be executed in the near future at all. It also means, if something requires more than a sprint to do, it will never be properly finished, so you better not start it. Agile is nice if everyone has the same knowledge about your project. Which means it is a small project for which Agile is completely over the top or you don't have any specialists -correction- you ignore the fact that each human being has his own areas of interest, areas of specialisation and capabilities.
Why would you use a hammer made out of plastic straws?
Why wouldn't I? You've proclaimed that every tool is perfect and it's only the user that is at fault when it doesn't work.
Which is true.
Can't be possible. Your original claim was pretty adamant that all issues are the fault of user and to quote you "it's never the tool". If a tool is poorly-made then it means that it is not the fault of the wielder if they can't get the job done using a faulty tool.
There is no one methodology that works for everyone. Usually the purest form of any of the major concepts is fundamentally flawed in that in general you will not get what you want with Waterfall, you will never have a finished product, or even know the feature set for the next iteration in a pure Agile development.
What you need to do is look at the work you are doing and borrow from the main two, and any other, methodologies to come up with what works for your group for the type of software you are developing.
I have been in a group where the Waterfall with added iterations worked really well. We were working on embedded office automation controllers.
I have been in a group where we were making a tourism web site and a more Agile approach of faster iterations and showing the customer was more appropriate
I say Agile is a failed concept, because all the concepts are failed. You just need to take from them what is appropriate and modify it if things don't work, or the nature of the work changes.
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
It can't fail cause all of the critics are doing it wrong.
Why would you use a hammer made out of plastic straws?
Why wouldn't I? You've proclaimed that every tool is perfect and it's only the user that is at fault when it doesn't work.
I didn't say every tool is perfect. I said that every tool has a function, has a context, and that works in that context. But hey, I guess I have to go Barney Style in these realms.
It's never the tool, but the wielder. Give a process to a good engineer, and he will find a way to get things to work. Give any process to a code monkey, and you are just going to get a lot of shit flinging irregardless of the process of choice.
Then you haven't been in software development for very long or how little ability to discern a good tool from a bad one. Shitty tools are foisted upon software developers all the time in the form of buggy and/or poorly documented frameworks, databases, IDEs, etc.
Been in this business for 20 years, 9 different companies in various industries, doing application and system/embedded development. But whatever. If you want to play my lightsaber is bigger than yours, by all means, knock yourself out, you win.
We are obviously talking about processes in general. But if we want to talk about shitty IDEs, languages and coding-level artifacts, let's do it. Yes, there are shitty IDEs, bad languages and such. They make work difficult, if not painfully insane, but none of that stop good workers from delivering good work (or at least avoid the number of sophomoric WTFs from piling up.)
Back in 1994, I once had the disgrace of having to do support report generating programs on PICK systems, using nothing but ed (not even vi for ${DEITY:-FSM} sake), using a bastardized language that mixed sh-based constructs with SQL-like statements for multi-column databases and PICKBasic.
That last thing, PICK Basic, utter crap that made GW-BASIC look like Haskell. At least GW-BASIC supported named labels for your GOTOs. PICK Basic oth only supported numeric labels. Imagine that if you can. You can have named labels in most assembly languages, but not in PICK Basic. Wrap your head around that if you can.
Anyways, the existing programs were a monstrosity we inherited were a monstrosity. We started fixing that by establishing standards and procedures for creating new programs (or introducing changes in new ones). We established a hierarchy of numeric labels - labels in the 1000-1999 range for initialization, 2000-2999, 3000-3999 for general computation, 4000-4999 for reporting/output and 5000+ for error handling and abnormal termination.
Those are the tools we had for that specific job, and as ugly as they were, we found ways to deal with them, to increase value for our employer while minimizing the number of WTFs that had been piling up for years by incompetent code monkeys.
There is no question in my mind that PICK systems were pure crap because they required us to put significantly more attention to detail to avoid introducing WTFs. Thank God that was just one job I had to do, and that I have never had to deal with that ever since.
And I've experience deja-vu moments like that, in Java, Visual Basic, C/C++, FoxPro, you name it. There is no language or IDE out there that does not have some unbelievable collection of WTFs.
But none of them cause people to unavoidably fuck it up again and again and again. Wielder, not tool.
When we had our choice to pick, we try to pick the best tools we can get.
But more often than not, we do not. And when that happens, what do you do? Do you go on auto-pilot and let the tool WTFquery imbue themselves into WTFs in your own code?
No. Not at all. You use your skills and find ways to make that shit work, to put some structure, some standards, some sane mechanisms and patterns and practices to maintain some quality in your work.
It can be done. Actually, it is done, and it has been done. Wielder, not tool. Always.
At its inception, the Agile manifesto was simple. Four priority/value statements and then a list of simple principles. The goal? Merely to say that delivering value to the customer, collaborating with customers, frequent delivery and feedback, and team empowerment are the way to deliver software. Focus on delivering value. Don't focus on delivering things that aren't valuable. Very simple.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc), you all of a sudden had a bunch of consulting companies and community meetups appear that all but destroyed the perception of Agile. For these companies and community groups, it's all about the process. They will teach you how to "do agile". They will provide you with bodies/contractors who can "do agile". They will sell you certifications which show you "do agile". They will sell you seminars and training on how to "do agile". They will sell you software which "does agile". Agile has went from a basic set of values to becoming a fundamentalist religion.
So my statement to "Agile Process Improvement" firms is this: You are all just scammers and profiteers. You are software development Pharisees. It is amazing that you focus on profiting from creating processes, enforcing processes, teaching processes, and writing process software... for a methodology where the first value statement is "Individuals and interactions over processes and tools". Why don't you guys teach REAL agile? Why don't you teach companies how to better define value and deliver it to customers instead of selling new processes, fundamentalism, and bodies?
For the rest of you, if you want to be "Agile". Read the Agile manifesto. Create your own process that suits your team and your business. Work continuously with your customers to understand what is valuable to them. Deliver good value to them often and get their feedback. Allow your team to learn and grow and understand the needs of the customer. THAT is Agile. THAT is all you need to do.
No, you said and I quote: "It It's never the tool, but the wielder". This statement could only be true in a world in which every tool is perfect.
I always find it funny for something named Agile and aimed at being responsive to needs that people are so "by the book" about it. I find it oxymoronic that there's "one true way" to do something called Agile.
Some employers are so by the book that they have to have a physical whiteboard with postits even though they also have to have jira and keep both those in sync. The purist agile says no remoting- face to face only, which I think is incorrect- I think "some kind of verbal or visual chat" is sufficient, but the key is communication beyond say hipchat and jira and email.
Some employers claim to be really purist about it and yet depart in significant ways. I think a lot of employers also use Agile as a way to squeeze long hours out of devs at the end of every sprint even though "purist" agile says 40 hour work week.
I generally like agile and it took a while for me to understand that MVP doesn't mean do the bare minimum for the sake of doing the bare minimum but with the idea you get it to the customer for feedback sooner and you iterate.
Management push-back is a tough one and understandable. They want to know where the company is going in a quarter, two quarters, next year. That means big plans, and it means estimating the size of things way in advance. That's something that Agile is specifically designed to avoid - unnecessary advance planning. I think this conflict exists (or should exist) even in the best Agile development shops. The alternative is the ultimate in management short-sightedness - no plan for the future, just get through the quarter. On our team the compromise is doing some one quarter rough-grooming and having our engineering team manager (who was a team member before being promoted) flesh out the more distant epic level grooming with our PM.
Let us live so that when we come to die, even the undertaker will be sorry -- Mark Twain
From my experience, Agile works really well when you or your manager can define "mini projects" that are completed within 1-2 days. Yet, if you are slow and such projects take 1-2 weeks, it doesn't work as well.
From this perspective, the best Agile teams should have several super fast developers who would interact on such development every morning and keep the good speed of going forward.
Agile works cheaply for software which is a relative island onto itself; facebook, google stuff, etc - where you have to meet a standard for a web client, but where otherwise you can publish API versions and allow people to continue to use previous versions, but that nothing is really built /on/ your product. It works horribly for anything which has to work with anything else which might change (yes, standards change....slowly). Operating systems, libraries, etc - when a core principle is to ignore documentation or any group other than the engineers themselves (including clients) then yeah - works well for islands, not things which are parts to a larger puzzle.
To me the biggest risk in any product is not getting the right product out. Quality comes second. Iterating rapidly allows you to get to the right product. The impact on quality that comes from not having enough time to think through design, code and test, in theory, could be compensated for by "smarts". To the extent Agile helps iterate to get to the right product it is valuable. The specific mechanics of it are not "nature laws" and hence should and must be changed by smart people to see if it fits their purpose.
"agile team lead themselves". We tried that. Gave outline. And the agile developer used that to explain them being much slower than estimated because the spec are not deep detailed enough. And then test were dropped in favor of coding. Yeah sure. Excuse are invented to be used. Too much micromanagement. not enough micromanagement. So yeah. You'll excuse me if I see I am skeptical.
C. Sagan : A demon haunted world:
http://www.amazon.com/gp/product/0345409469/
visit randi.org
it drains software engineering of the things that make it a satisfying and enjoyable activity, turning it into the software equivalent of grunt factory work
I'm confused. The satisfaction and joy of software engineering is turning a problem into a working solution.
The agile methods I followed let me realise that joy multiple times a day - checking in working code, and see it pass the automated test bed on the build server.
What is it that you perceive to be satisfying and enjoyable, and how are you losing that?
If you want to do it semi-scientifically, then test a given methodology for at least 7 years on actual projects for multiple project and organization types.
Why is it methodologies start spreading before being properly field tested? It appears to be hypsters jumping the gun in order to get rich selling hype (books, training, & consulting), but I'm open to other explanations.
Table-ized A.I.
I made enough money with agile, its caught on and I can't make money anymore.
Look at that shine! Use GROWS and you too can look like me! Ka-chow!
If Agile is failing despite voluminous developer output, that's where the rubber hits the road.
In real world development, you are going to have acceptance criteria written to your PMs level of understanding of the product. Most businesses don't understand product managers, they understand *project managers*, and since project managers are just bookkeepers, organizers, and communication traffic facilitators, meant to be fungible across many types of projects, it just all goes to shit.
The experts who know the system can't be bothered to write the stories, and the project manager has no fucking clue what they are typing up.
Here's the stupidest thing ever: a company that develops with Agile, yet still has Subject Matter Experts communicating through the project managers. Of course you have to have a project manager, because it isn't a single team, or even all Agile teams, and the teams need to coordinate their efforts. And of course those SME's are too busy answering everyone's questions to be bothered to write out the specs properly.
Agile is like most high school physics: it works *perfectly* in low-friction environments.
Now, the pro-Agile people are going to say you aren't doing it right, etc. etc. You people are like communists: it works if you do it right! No, it doesn't, because it doesn't take into account corruption, greed, politics, propaganda, and deliberate mis-control of information for the benefit of a few. And those things are going to exist in any large-enough group of people.
Agile will not fix your organizational problems. It only shines a spotlight on them. Usually, when you point this out, everyone will nod their heads. They will all agree it needs to change. The problem is that no one with the power to actually fix the issue is in the room.
I would be very reluctant to blame the incompetence of your co-workers on Agile. It seems like that they were incompetent before Agile came along.
Fanatically anti-fanatical
It works because it forces developers meet regularly, track progress, discuss problems, pay attention to requirements, be aware of the schedule and what everyone else is doing, The rest is theology, more or less.
Please do not read this sig. Thank you.
Once Agile values started to become embraced and a couple of new development processes came along (SCRUM, etc)
That's a nice thought, but SCRUM actually predates Agile by half a decade. SCRUM was introduced ~1995, and Agile ~2001.
Though the actual Agile techniques are much, much older. Reading the Mythical Man Month can convince you of that.
"First they came for the slanderers and i said nothing."
Agile probably fails because it is the next Management Buzzword that somebody heard somewhere. Then try to use it, because it is the new best thing.
Like anything, it likely has it's place and time, probably mostly dependent on size and type of project being worked on. Having it misapplied because Management thinks it is a swell idea, then having people just try to make it work because they have to, well it might work, but if you are trying to fit a square peg into a round hole it may be difficult not to fail.
From what I have read, for small to medium sized project Agile can work quite well. However once you get to the large and gargantuan size projects it starts running into some fundamental problems. Sure you might be able to break it down into smaller projects, but that is not always reasonable or makes sense, or then you are adjusting requirements simply to fit your development process. Also those pieces need to be able to work together in a seamless and coordinated way, which requires some higher level planning...
Anyway when I hear about a very large system being done in an Agile manner, the first thing I think of is, enjoy that incomprehensible pile of garbage that is going to be the result unless you are very careful.
I think some like it for infinite job security, as you will just be constantly going back over and redoing and readjusting things for that application forever just to keep it limping along and running like some Quasimodo. Though in this example, perhaps Frankenstein might be a more apt analogy where you are trying to take a bunch of badly related pieces and building a single system out of it, zapping it with lightning and hoping for the best... The result? Fire and Mobs... Fire and Mobs...
You can theoretically hammer nails with a saw. :)
I'm seeing posts from people saying things like, "Agile isn't working for my team, I just spent my whole daily standup reading this thread" or, "I get a lot of work done during my retrospectives". Of course agile sucks for these people! Agile will get limited—but still useful—results when the team has this attitude.
But if they have a different mindset where they actually try during the daily standup or retrospective, it works so much better.
Look, every really good developer I've worked with has had good opinions and ideas about how the project should be run. When they spend the entire standup or retrospective looking at on their phones, the team doesn't get the benefit of those opinions and ideas. But when they use the meeting to actually share those ideas, and maybe even engage in a good discussion (or even argue for them!) with the rest of the team, the whole project benefits. But that only works if they care about doing a good job with the standup or the retrospective the way they care about doing a good job with their code.
I'm plugging my book, Learning Agile, now. I hope you don't mod me down too much for that. But I think we did a pretty good job arguing this point in the first few pages the first chapter. You can read the first chapter for free [PDF].
Building Better Software
Waterfall is a straw man. It only continues to be mentioned because it is an easy target. Claims that X is better than waterfall are a waste of time; they tell us nothing about whether X is actually effective.
The origin of agile and scrum (and the use of rugby as a metaphore) is "The Knowledge Creating Company" by prof Nonaka and Takeuchi. When you read that book, you realize that Scrum as it is practised today, in nothing resembles the ideas of Nonaka and Takeuchi. So, my answer is "yes". Even the scrum metaphore is wrong: the book uses team play in rugby as an example. Scrum is not team play and agile, it's standing still.
no, I don't have a sig
Agile works for many teams or projects, but Scrum only works for some.
Agile has received a bad name due to real-world implementations: The real-world implementation of an agile project philosophy is often done via Scrum, which is a very strict and prescriptive process. There are others, but Scrum is the most popular one. Scrum doesn't work for all organizations and projects, though! Shoe-horning unsuitable teams and projects into the Scrum process can lead to lots of problems and disillusionment with Agile, even though it wasn't really Agile's fault in that case.
It's a bit like how Socialism gets a bad name from the (totally failed) real-world 'implementations', such as what we've seen in the Soviet Union or East Germany, even though the theoretical ideas of Socialism may actually offer some good points. The "agile" (lower case) aspects of "Agile" (upper case) are quite good, so it's worth to see if you may be able to adopt some of them.
If you are interested in a less prescriptive and much more flexible approach to Agile, may I recommend you have a look at Kanban? It starts by just watching how you do things now and then can be used to slowly add a few processes here and there to strengthen the good things and reduce the bad things in your process. Especially large, established organizations can benefit greatly from that.
Unlike other methods (and I'm strechting the term "method" here), agile methods rely on excellent optimised and product oriented software production pipelines. This is how you should do it anyway, agile or not. But in my experience roughly 1 in 20 software shops implement even the flakiest of standardised production. Most of the time you still have to explain to people why they should use versioning.
The decision makers, sales people and IT strategists also usually have a very hard time commiting to a product and produktion pipeline. They want to sell whatever goes and have the devs sort it out, understaffed, ill-equipped and with extra weekends.
There are a few companies that have sales and technology and perhaps even industrial design/user experience all on par (Apple for example), but most companies that offer software development have no decision makers that understand even the faintest about software development.
Agile methods such as Scrum are the ones that expose the fastest wether you actually are doing professional development or if your crew is just a bunch of people faking it with poor gouvernment, bad organsiation and a sales and production team that don't communicate professionally with each other. IT mostly is a second and third afterthought with most companies and in such environments the best method won't improve development, no matter what.
If a PM can't tell a client from a server or Java from JavaScript and couldn't be bothered to understand why it is important to make a call and a final decision about tabs or spaces Agile will show how shitty your environment is in an instant. Waterfall (i.e. we don't know what we're doing but we're doing it anyway) will disguise that indefinitely, because there's no fixed model for accountability built in.
Bottom line: Until IT stops being the cellar child of the company no method in the world will professionalise development as it is desperately needed. We're still like medicine in the 16th century in that regard.
We suffer more in our imagination than in reality. - Seneca
http://programming-motherfucker.com/
Left MS Windows for Linux Mint and never looked back!
Vote for Bernie in 2016!
Maybe off topic, but is there good money in DevOps? I've always thought it would be something I excel at, and I usually ending up filling that roll anyways at the small shops I've worked at anyways. Are there fun and interesting problems to solve in that position, or is it mostly an admin task? How does it compare to something like systems design / architecture as a career path?
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
So the argument is "the methodology is perfect, it's the people that are failing". Just like "waterfall is perfect, it's the people that are failing". Accept that "agile" has some good stuff and some stuff that doesn't work, applies in some cases and not in others. Take some good stuff from it, and move on.
Though my career; I've been a developer and also have been in an operational roles. I also been on a DevOps team and my perspective is that operations suffers and it's not development either. The past few companies that I have worked at had a DevOps teams and the end result is that development is running operations without the operational knowledge and with no real IT department within the company. I decided to get another job with an actual title and wouldn't want another DevOps role.
I'd argue the opposite. As a consultant, when we're brought in for a 1.0 type project, we're more successful with an Agile approach because requirements are less solidified in detail but the high-level stories are fairly well known. Each sprint, we can take a story, detail it out and implement it. The customers see progress and enjoy the feedback loop.
Projects that are more focused on enhancements (smaller scale, not a "major upgrade") tend to have issues in an Agile fashion because everything needs to be done "right now" because it's "affecting such and such group" and the prioritized backlog turns into a big mess of conflicting priorities.
That being said, my main complaint about Agile is that the typical implementation of it is too short-sighted. Sure, Agile allows for refactoring phases, but if you are only focused on what's in the current sprint, you might make a sub-optimal decision in Sprint 2 for a feature that isn't even considered until Sprint 6......but the decision you made in Sprint 2 locked you in to a bad approach and refactoring will take almost a full Sprint.....had you known about the Sprint 6 feature, you could have implemented the Sprint 2 feature in a way that the Sprint 6 feature could be implemented in a matter of days.
"By definition, if can't fit into a single Sprint, then you cannot do it"
That's right.
But it works both ways: if there are things that cannot be fitted into a sprint, your sprints are too short.
Nobody is telling that a sprint have to be two weeks long. Sprints should be as long or short as to be able to accomodate a significant result. Sometimes this means one week, sometimes three months, sometimes this needs to change from sprint to sprint or at least to product-livecycle phase to phase. The only requirement is for the sprint's duration to be fixed beforehand.
"The report is required to be done by Dec 1"
That's an OK bussiness need -at least, when it really is a bussiness need and not just a date to add pressure to your team, but one that some if not most of agile *methodologies* (no a problem with agilism by itself) can cope with.
This only means that most probably this single request needs to be handed in a custom way: if the feature set is clear and fixed (and it probably is) even the charicaturesque version of waterfall-as-an-antipattern can perfectly work: you get the requirements, design the solution, asign a team for the expected time, test and deliver. I don't see what the problem can be with that -except, maybe, that the team needs to come from somewhere, probably the same team doing everything else, which would mean, say, no sprints for the next month, or a negotiation to push forward stories that don't requiere to be delivered by the people now reassigned to the report and if that's really the problem you are again failing on agilism, since one of its tenets is "Customer collaboration over contract negotiation": obviously, putting people to do "this" makes it impossible for that people doing "that" at the same time, so the customer needs to make up his priorities, or the team to be expanded at the risk of falling in "the mithycal man-month" trap.
"Our board has directed that we are required to do Agile, and the certified scrum master they hired wouldn't let us start on the report."
You see, "scrum" is not "agile" but an "agile methodology". Your "scrum master" looks to me more of a "scumbag master" than anything else, since he failed twofold:
1) Within scrum, "The Scrum Master serves as a facilitator for both the Product Owner and the team", which he obviously failed to be.
2) In the overall context of agilism: being scrum an *agile* methodology is naturally driven by agilism first, and that means "Working software" as well as "Responding to change" and he failed in both fields.
In my first encounter with Agile back in 2001, our management decided to follow Scrum.
We did the daily meetings, of course. Then we divided our project into sprints:
Sprint 1: Design
Sprint 2: Coding
Sprint 3: Debug
Sprint 4: QA
Sprint 5: Release
Needless to say, it didn't work out too well. Since then, I've seen agile done a lot of ways, some worked, some did not. Frankly, most waterfall proponents simply don't get Agile. Managers who DO get agile are able to deliver far better quality, in far less time, than any waterfall model.
Firstly, criticism does not mean failure- it means things can be improved, which is part of being agile...
I'm a big fan of Agile. In a team of intelligent, talented, motivated developers and managers who trust each other it can be fantastic. Sadly, once it got a label, people tried to codify it. Then they started following processes and ignored one of the tenets of the Agile Manifesto - People before processes. That's when it started to go wrong.
My team tried Scrum, it didn't work. Rather than give up (or keep plowing on), we looked at why and decided to give Kanban a go. It worked, mostly. Where it didn't, we tweaked it. As the team grew in size we did more tweaking.
One of the most important things we do is to bring up any issues in our retrospective - if something isn't quite right we try to fix it. We criticize our process. Sometimes managers do it, sometimes devs. We talk, we trust each other. All in all it works pretty well.
The problem is not with Agile, but with people who believe in magic potions.
Nothing in this world ever solves all problems. Nothing in this world ever fits everyone. Agile is no exception. It might be good or bad, depending on circumstances such as your team, your culture, your project and a dozen more.
The best you can do as a leader (manager, lead dev, CTO, whatever) is to pick and choose and come up with a system that works for your company, your people. It might be Agile, or Agile with something else mixed in or something else with some Agile mixed in, or no Agile at all. It depends.
If you believe you can take something that someone else cooked up without knowing your situation, and just apply it by the book and that's it, then you are not doing your job.
Assorted stuff I do sometimes: Lemuria.org
"the Agile Manifesto, the product of 17 software developers coming together in 2001 to talk over development methods."
So they figured it all out for the rest of us devs. Awesome! Works for everything!!!
I agree with this. Most of the "agile" teams I've been part of just pretend that all it takes is sprints + scrum meetings to be agile. They throw any pretense at engineering out the window and rely largely on hacking in its most pejorative sense to get things done, which usually means ignoring quality and putting in a lot more hours.
Most teams I've been stuck in have also been more obsessed with who owns what and how many hours and story points everyone's working than on how much functionality they're implementing, and at the same time largely ignoring even any pretext at there being a team involved.
Actually, it pays hella good money - My salary has almost doubled over the past 4 years. I still get recruiters bugging me at least 1-2 times a week (and I don't mean the bullshit Indian-run far-flung contract ones, I mean local recruiting companies in PDX that I know quite well.) Once a month or so I get emails from the really big name folks wanting to know if I want to move to Seattle, SanFran, etc. It's damn hard to find someone who keeps the title for more than 6 months, and I've been doing this since 2011 or so, back when it was just called "Systems Engineering", and you were at the mercy of numerous external teams.
There is one trick, though, and it may just be my own bias showing, but you have to approach it with a heavy leaning towards operations. You don't want to get in a position where you're writing product code or doing QA, but instead acting more in an SCM/automation role in the dev teams. You do have to know enough about development to work well within the teams, but at the same time, you have to know enough about the IT side to know what you're asking them to do for you (or often to build it yourself), and to keep uptime at maximum.
Here's where company size comes in, though, because company size usually determines what you do.:
I work for a largish (1500-3,000 employee) company, which is, believe it or not, the least stressful way to do it (you have enough resources on either side that all you have to do is help make it all go smoothly.) In the larger companies, you are an advocate for Ops/NOC while you're within the dev teams, but you are an advocate for the teams when you deal with Ops and the NOCs. Meanwhile, you're building the automation (usually viz Puppet and a good ENC like Foreman if you're lucky), and doing your level best to make sure it all runs smooth. I usually find myself as a combination of right-hand-man and devil's advocate to the product owners and PMs, making sure that both of them understand fully what I'm up to, and what they're trying to navigate on their way to release (unless you're lucky enough to have good CI/CD in place, in which case everyone builds towards that). I find myself talking just as much as I am typing.
( One big caveat, though... some companies this size are murder to work under... especially if they're too into using H1-Bs to do the bulk of their dev work. )
In a smaller company (say, 300-400 employees total), it's way different. In this environment, you're a little bit of everything, doing a bit of everything, and sometimes you get dragged in to help debug, help out QA, etc. Other times, you're troubleshooting issues on the load balancers. Other times still, you're helping the DBA hammer out a bad query into a good one. On the plus side, you get a lot more leeway as to what tools get used, what processes you want to have in place, etc. Just be prepared to bust-ass and put in a lot of long hours... I didn't mind working for a company like this, but the one time I did it, the Systems Architect and I didn't get along very well, to put it mildly. I think it was because I wasn't quite hipster/bleeding-edge enough when it came to how I approached production systems...
I once did it all by myself with one dev team, for two small products, in a small company who inherited the project/team from a small acquisition they made. It actually was a lot less work, at least once I put the CI/CD process in place (the dev team and two QA guys didn't care - they just want it out and working). At that size it's just maintenance and scaling for growth ('course, that can go many ways, depending).
Quo usque tandem abutere, Nimbus, patientia nostra?
That is why we went to three month sprints that fit neatly between our quarterly releases. We also ditched Scrum for a lose Kanban approach, no longer do retrospectives where we were asked to tell how we felt the sprint went (and if you speak your mind your boss tears you a new one), and stopped estimating. We never have enough info to even give a good estimate and there is no value in estimating 2 weeks when it takes 4 weeks in the end. Plus, being in QA, Agile is nothing else than mini waterfalls with the difference that I now have no clue what the business wants until stuff is coded and changed a dozen times. Without acceptance criteria all that is left to do is craft test cases that pass based on what was coded....ass backwards! Oh, and we do standup twice a week tops. Scrum is the worst of all Agile methods anyway, it was invented by the office supply industry because the consumption of post its and Sharpie pens is mindboggling. With Scrum we spent endless hours trying to split tasks into mini tasks, just to find out that some stuff takes longer than the arbitrary time box of 3 weeks. But then we were reprimanded for having nothing to demo when sprint was over and all that was done was database design. Folks don't dig ERDs and they are not impressed when all that changed was a check box. Agile is the hardest on QA. Agile is the free for all to not commit to anything and constantly change your mind. If you cannot tell me what you want I cannot tell you if it was implemented correctly. And since devs consider a story done as soon as code compiles it is especially tricky to get bugs fixed or testing done before equally arbitrarily set release dates. Agile is the death to quality. Ever wondered why software quality is in the toilet? Shipping features is more important than doing things right the first time...because it all has to get done in 3 weeks.
Hey, thanks. This really helps a lot!
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
The three minutes standup
Manager: (looks at Dev 2) Kanban board says you moved Blah task to done yesterday and pulled in foo task today.
Dev 1: Yes.
Manager: Good work. Need anything from me or the team.
Dev 1: No
Manager: (looks at Dev 2) Kanban board says you moved Oober1 task to done yesterday and pulled in Gobblygook task today.
Kanban board says you moved blah task to done yesterday and pulled in foo task today.
Dev 2: Yes.
Manager: Need anything from me or the team.
Dev 2: Yes, I need help from Dev 1 to do Gobblygook.
Manager: (looks at Dev 1) Dev 1, can you talk to Dev 2 about gobblygook after standup.
Dev 1: Yes
Manager: (looks at Dev 3) Kanban board says you moved Whatsit task to done yesterday and pulled in WrongWork task today.
Dev 3: Oops. Yes, I finished Whatsit yesteday, but I pulled in the wrong story. I am working on RightWork.
Manager: Fix the Kanban board mistake. Need anything from me or the team on RightWork.
Dev 3: Nope
Manager: (Looks at Tester) Kanban board says you finished tests for oober1 and you are working on testing Blah.
Tester: Yes, there was one bug, I verbally told Dev 2, he fixed it. I retested an now all tests pass. I am testing Blah now.
Manager: Good work.Need anything from me or the team.
Tester: I'll maybe need to speek to Dev 1 about Blah sometime after lunch.
Manager: Great job team. Keep up the good work.
Stand up ends.
Agile development in the more pure form such as XP is doing just fine where I see it being used. But the management/certification/terminology/paid courses version of Agile should be taken out behind the woodshed and shot. Basically when I hear a company has SCRUM masters then I add it to the dead pool of tech companies that my friends and I bet chocolate bars on. I have a long list of these sort of silver bullets that can claim to turn shitty programming teams into productive machines. Six Sigma would be another pet peeve.
I am partial though to some parts of the PMI PMBOK type stuff but some care needs to be taken distinguishing between certification and ability. At least half of managing people is being a people person.
But to me agile seems to be mostly adopted by really really shitty programmers who aspire to management so as to cover up their complete inability to get anything done. Also many Agile people tend to use the guise of agile to ram their shitty programming style down everyone's throat as some kind best practice. People who like ++i or have insane commenting styles.
So, there's a brilliant programmer or programmers who can and do create and negotiate their own path by constantly juggling the requirements, the current state of the project, the gap between where it is and where it wants to be, within their heads at all times, while keeping the code clean and readable. And you want to convert your organization from reliance on one or a group of these talented programmers, so that you'd have to quit the business if anything happened to them, into one where the talents and knowledge and wisdom and good habits and skills and styles and diligence are all built into the processes so that mediocre programmers can do good work by just adhering to processes; and good programmers will find these processes are in accord with what they're doing anyway and not be hindered. Ha! Welcome to the dilemma of every organization, ever; making the leap from a bunch of talented people pooling their talents into an organization where the talent is built into the structure/function of the organization. If 5% organizations make the leap successfully, I'll be surprised.
Star Trek transporters are just 3d printers.
Yes.
Again a case of "methodology X" failing at delivering the expected but shinning at surfacing your company's misfunctions.
Agile, being about "Individuals and interactions over processes and tools" is specially good at that.
The paradox is that sane companies would react at all that revealed insanity and would take the chance to correct themselves, which the only thing it's impossible to be done in the companies that show this kind of insanity.
After reading some of the comments about how Agile is being done elsewhere, I'm pretty pleased with how well it's going where I work. I do wonder why the difference, though.
Standups are 15 minutes (officially) but went longer because we had two scrum teams (called "pods", which name no longer irritates me) working on a project that affected both. We needed the expertise and the resources.
We don't spend a lot of time on backlog grooming, in part because we don't have to split many of our user stories. Things were pretty well broken-down into manageable size when we laid out our work, up front. (Somewhat waterfall-ish, but it has worked out OK.)
Another reason is we have a separate meeting (which we call a "champion meeting" for some reason) where a subset of the whole team identifies uncertainties and determines things that were TBD, if they have to be before the user story can be sized. User stories normally are sized at that time.
We used to use "planning poker" cards, but now people are comfortable singing out their estimates or doubts about the estimates of others, and working to a consensus. If we can't come to a consensus, we'll go with the higher of point estimates.
Teams are small, 5 or 6. (Except for our duo-Pod team, during that project.) About half our people are in St. Louis, the other half are contractors in India. Almost always a St. Louis QA tests what a St. Louis Dev produced, and an India QA tests what an India Dev produced. One BA/scrummaster for the team. (Two, during the duo-Pod project.) Only St. Louis folks attend the "champion meeting", but all attend the daily standup and a weekly coordination meeting (at the end of the India day and the start of the St. Louis day).
Much of the above applies all Pods, some only to the the duo-Pod team, which is breaking up now. Next week, some are going half-time on the duo-Pod work, and then it's just going to be one of the pods.
We've not been slavish in following Agile rules, or our own. The "champion meeting" was added a few months back. And with the end of the duo-Pod, we'll no doubt have to make more changes. We've already started on that.
Why has it gone so well? A couple explanations.
Management had a strong commitment to it, and for the most part hasn't micromanaged it, or even come close. All pods are now on 2-week sprints, and are synchronized, with a 6-2-1 at the end of each quarter. Initially we had a requirement to maintain a somewhat even velocity. If the points accomplished per sprint weren't sufficiently consistent over time, we got "dinged". Now we have to commit to calendar dates for big chunks of functionality, instead, but we get to choose our commitments. (We can't be silly about it, of course.)
We got some training, pretty much from the get-go. Some general Agile training initially, and when we were ready or almost ready for it, more detailed training, like on user story splitting.
Another part is the company culture. There's more of a "fix the problem, not the blame" when things go awry, and the concept of technical debt is understood pretty well, even in the business. (We're about 2 weeks away from removing the last of the Visual FoxPro code from production -- in our Pod's code. We're not quite the first Pod, and won't be the last. So, they know what happens when important-but-not-urgent work is deferred too long.)
There's no time like the present. Well, the past used to be.
Don't fill up pages and pages of Slashdot arguing about which methodology fad is best...
An engineer who ran for Congress. http://herbrobinson.us
I can see how that happens. It takes a lot of initiative and push on your part to make it happen the way you want it to... you cannot rely on either the Dev teams or Ops to do it for you. On my part, I am fully independent from either side of the house. Because I came into it from the operations side of things, I treat the dev teams as my customers, and the ops/IT teams as my resources. I will happily abuse or appease both as needed to get the job done, but overall, that's usually how I handle it.
Thing is, you bring up a really good point: If you let either team take prominence, they will dominate your schedule, and eventually they will use you to own the other side of the fence. This is scarily common in both startups and huge corps alike, with only the actors changing. I'll explain who.how in a moment...
It goes bad either way: Either you wind up with bleeding-edge eternal-beta product that constantly breaks because the dev teams (and marketing!) demand release über alles!, or you get stuck with a calcified slow-moving product roadmap because Ops (and the bean-counters) really hate change.
In your case, the codemonkeys won the battle (which is, again, *very* common in startups and small companies.) If you worked for a large corp, it would be the opposite - a fight to keep the Ops guys from dominating things.
Anyone who has worked in/as a competent SCM manager is (or at least damned well should be) familiar with how this works; DevOps just takes the SCM role and expands the hell out of it.
DevOps also introduces one thing that the average code/server-monkey has never had to deal with: Inter-departmental politics. It's now up to you to keep The Force in balance, as it were, while at the same time putting in sane frameworks that not only scale up, but makes sure that everybody gets what they wants w/o unnecessary expense.
Quo usque tandem abutere, Nimbus, patientia nostra?
From what ya'll are saying, it sounds like big beauracracy all over again! Only the names have been changed, to "protect the guilty".
Note that using new words, does not guarantee a new outcome...
Tired of endless meetings, circling back, and rehashing specifications no one has reviewed? Running out of corporate buzzword bingo cards? I'm working on a new paradigm which I think I'll name: Git-r-dun. Your thoughts?