Wasn't pair programming a part of "extreme programming" say 10 years ago? Anyhow this Dilbert strip seems to think so:
Amen!!! Preach it! I love this quote: "Agile has the smell of death on it. If you go to an “agile” event you will see few people under the age of 40 and many over 50." That is so true! This blog post made my morning.
I'm sorry if I offended people with the comment about older people going to agile events. I'm 49 years old, and still programming actively, as are many of our senior people. I"m not trying to make a value judgement about what people are doing in any age group. I think it's interesting that demographically, older people are more involved with "agile". It changes the whole perception of the effort.
I don't make a conjecture about the reason that agile events skew to an older crowd because I really, really don't know why it is true. I do know that it changes the whole perception of the effort. So, I have to be careful when I use the word "agile". It's got a demographic implication that isn't positive, isn't "us" for many younger people. You can argue about the wisdom of my saying it this way, but the word has a real demographic and emotional association. This article is a chance to express my doubts about the word "agile". It's done. I'll be more positive from here on out.
thanks for sharing your thoughts on Agile. I can emphasize with a lot of what you've written. I'd like to know what you think about the 'Lean' movement compared to Agile. For me even though it has the same challenges as Agile (and any other buzzword, HTML5, web2.0, cloud, …), Lean feels less detached from reality and from my point of view describes the current best practices in software development quite well.
Yes, I agree. We like both Lean and Agile. I try to not be abstract when I talk about Lean. In a software context, I think that "lean" it means that you don't want to waste time on tasks you don't finish (wasted inventory). Specifically, you want to limit the number of tasks that you are working on so that you don't abandon tasks, and move to new ones, before you finish. That's an important part of the way we try to work here. We found that recommendations from Kanban (both lean and agile) actually do help us to get this effect.
I disagree with your disparagement of shared values, for small teams that must work in close collaboration.
If you are loosely coupled, then yeah, values don't matter. All you need are contract terms. Agile isn't a tool for outsourcing or supply-chain management.
But if your work is tightly coupled, then things like punctuality, communication style, conflict resolution methods, team decision process, working hours making matter a lot. These are values, and its helpful to make them explicit and to have an environment where people can discuss these issues.
Actually, to be fair, business statistics state that the over-50 crowd actually start more successful businesses than the under-30 crowd. So, those people you are stereotyping, might just be leaders in those "hot" new startups you love.
Yes, shared values make working in a small team much easier and more rewarding. I want that, plus all of the agile manifesto stuff, for my teams too. I think they start to become a negative obsession in bigger groups, and they pose logistical and even logical problems. What if your value is that people should think for themselves, and they don't want to?
Yes, it's completely possible that the reason that agile skews older is that the older people have a better idea about what will make them successful. The statistics might prove that. That's a very fair hypothesis. I'll be happy if I get more successful on the day (very soon) when I turn 50. Probably not, since I'll be the same guy with a few more scars, but I might have learned something.
That doesn't change implied and emotional and emotional relationship between "agile" and old.
I have attended two events in which Agile was discussed. The first was the first Scotland on Rails conference in Edinburgh in 2008, I think. It's what first introduced me to Agile, Scrum and TDD. The focus was mostly Ruby on Rails but a large part of the day was on Agile, and I found those aspects of the two days the most exciting. The audience was very young.
The second event was a very expensive training workshop in London specifically about Agile. I found it very disappointing. I spoke to quite a few of the delegates, most of whom were much older than me. The chap next to me told me that he was there reluctantly because his firm told him that he needed to get up to speed with this Agile thing. A few others I spoke with were in a similar situation.
It seemed to me, from these two events, that the younger people were already out there doing Agile. The older folks were playing catch-up and reluctantly so; it is, after all, a hard thing to change.
Thanks for the amusing post; the thing about the stench of death made me laugh out loud/ (not that LOL BS). Unfortunately I'm old, though I wasn't in 1999 when I started doing agile-sorts-of-things. At the time, it made a boatload more sense than the heavy process crud that was prevalent.
It's 12 years+ after 1999, so it *is* time for a new generation of what works. Some of the better teams out there meld good ideas from agile, lean manufacturing/lean software development, and the lean startup movement, and they learn how to adapt them to their culture and circumstance. These are the teams that will usually outperform the no-process teams, who simply hack out bad code as fast as they can.
Most other agile teams aren't succeeding (though they succeed in slightly highly numbers on average than non-agile projects, and it's partly because most of them think they can get there by following a bunch of buzzwords. The teams that succeed understand and follow the principles behind the values (which are mostly motherhood and apple pie), such as the need to continually reflect & adapt.
As far as imposing values: The teams that succeed most over time are the ones who have agreed how they want to work together--not the ones where everyone just does their own thing. Hiding in your code and slamming out code works for the short term, but I've been there, and it always produces a steaming mound of crappy, difficult, costly-to-maintain code. I honestly don't care what the values system is, agile or not, but it's more useful to have team standards (that can and should change) than not.
I believe you're right about the time wasted estimation. Fortunately it's getting greatly de-emphasized nowadays by some folks promoting agile.
Pairing works great for some teams, and isn't a good choice for many others. I enjoy it as a developer, and get a lot out of it (and it doesn't cost 2x), and I can also live without it. But most after-the-fact review is a big waste of time (been there done that, in many different ways).
> If you go to an “agile” event you will see few people under the age of 40 and many over 50.
Quite the opposite. I am 47 and I hate "agile". However, all the Facebook wannabe companies that I worked for only want twenty-to-thirty year old programmers who thing agile is their new religion.
I learned to hate agile from the moment I stepped into a company that does it. My biggest complaint is the waste of time, that agile is supposedly trying to get rid of. It is a waste of time. The day of planning and retrospective -- thats a bullshit day. Planning should be done by team lead alone, and delivered to the developer, with an email. When developers have questions, they can talk to each other, without any meetings. The estimation and graphs are even more ridiculous. It gives people an excuse to do for 3 weeks something that should take 3 days.
The only system that works is the one where:
- the developer receives tasks,
- the team is balanced so that all developers are about the same strength.
- all developers respect each other, and don't screw each other by making one do the work of others
- developers don't have to be in the office, but can come and go whenever they please, work from home, or just take days off completely, without any pre-approval.
Finally, thanks to the original poster Andy. Heres a bitcookie
for you, number 8635 (look it up).
Maybe this is obvious, but any time fresh new ideas get accepted and go mainstream, they tend to get enshrined, stale, co-opted, distorted. At least partially it's the price of success. So we need to keep looking, paying attention, working at it. It's fun. Thanks for the cheeky and sincere prod. Ha ha, and yes I'm in my 50s.
Wow - to discount 40 or 50 year old people with decades of experience is certainly a broad brush. Some day you will have the "stink of death" on you. By then you may actually have more valid opinions.
If you don't estimate for projects of significant size, it's not business - its either a hobby, R&D or some kind of dysfunctional project waiting to fail.
Amusing, in a jaded sort of way. I think the problem is that agility is not just about technical changes. It's about organizational change, but it looks like it would work most effectively in a bottom up approach, where technical folks are highly respected. In organizations where technical people are the hands, and their management and business stakeholders are the brains, it becomes an exercise in frustration. Perhaps the younger crowd that would be interested enough to go to a conference has different expectations about the kind of company they want to do technical work for and don't bother with that bastion of mediocrity known as the corporation. If I had it to do all over again, I'd avoid it like the plague.
8) Write requirements on post-it notes, then throw them away when the project is complete. Seriously, WTF?
The best use of Agile I have seen is forcing end-users to become more involved and give feedback during the development process. At the end of development when the final release is sent to the end-users they do not say "why did you do x and not y?" The notes from the sprint review can be rolled up and used to poke them in the eye and you can respond "because on this date you told us to pursue that solution".
A company already has "scalable agile" and it's not very pretty: http://scaledagileframework.com/
"If you go to an “agile” event you will see few people under the age of 40 and many over 50. These attendees are on average much older than the average age of programmers, and often older than the people running today’s hot software companies. Why aren’t more younger people grasping at agile straws?"
This is explained by simple sampling bias. If you go to almost any programming "event", you will see most people over 40. Ever been to a computer graphics conference? Old people! Artificial intelligence? Old people! Haptics? Old people galore!
Yes, in all of these cases, much older than average. That's because programming encompasses a huge spectrum of abilities and tasks, and the long tail is exceptionally long. The "average" programmer today is probably a 17-year-old with a homepage written in PHP. Clearly, anyone with the motivation and resources to attend a conference is going to be far older (and richer) than average.
If you want to compare agile against other methodologies (or "no methodology at all") then it might be interesting to look at conferences for SEMA or Six Sigma or whatever. In my experience, Agile has younger participants than these. Agile might have few people under 40, but have you met anyone under 50 doing SEMA, ever?
We are a hard-core Agile shop, and I (and probably most of my co-workers would) agree with you on several of these points. We don't find much value in Scrum. Many of our teams are starting to abandon estimation when possible. And the term "Agile" is definitely being diluted by a lot of non-Agile companies.
But I've seen a lot of benefits from Agile when it's done well.
The reason you see older folks at Agile events is that they're the ones with the most experience, so they're more likely to have learned better ways to work and to have the ability to attend events.
I get your point about values, but I think that if you're writing software for someone, you SHOULD have a shared value that producing quality useful software is what you should be doing.
I find pair programming to be productive, for a few reasons. First, the 2 people keep each other focused on the tasks at hand. Second, talking about things before doing them helps ensure a good plan and design. The way I explain this is with an analogy of the times when you go ask someone a question and answer it as soon as you verbalize it -- the process of verbalizing a problem helps you get it much clearer in your head, often enough to see the solution. Third, you get immediate code reviews. Fourth, you learn a lot from each other very quickly. Finally, with good pair switching, everyone gets to learn about almost the entire code base.
I find that pairing program done well (basically both members stay engaged) usually accomplishes about twice as much as an individual -- especially when you factor in the amount of time getting stuck on something, fixing bugs, or re-designing.
I think the big part of Agile that you're missing is that it's adaptable. Teams have the ability to change what they're doing, to improve the way they work. So if the team finds pairing to be an improvement, they can do it. If it doesn't work for their team, it's "less Agile", but they shouldn't do it if they're not getting any benefit.
Much of what you hate about Agile are about specific ways that someone has chosen to implement what they think of as Agile. Scrum is one of these ways, and plenty of people hate Scrum but still like (and do) Agile. Same thing goes for Pair Programming, Estimating, etc.
Anyone that tells you that you must do a particular process in a particular way is breaking the first part of the Agile manifesto: "Value Individuals and Interactions over Processes and Tools". I've taught a few 'Agile training' things and instead of a set agenda or pile of powerpoint slides, I show up with the 12 Agile principles and ask participants what they are doing that they don't like or isn't effective and we go from there.
we proudly call ourselves Agile because we firmly believe that it's the way to deliver the most value to our customers, and can present a convincing argument for each of the Agile principles.
We estimate, but only with 'points' on a very coarse scale (0,1,2,3) and only so that we can gauge relative progress and future progress. This takes maybe 30 seconds for each story, so a few minutes a week are spend on estimation. We do pair programming, but only when it makes sense to either solve something tricky or to bring someone new up to speed on a project.
The average age of our developers in probably around 25, and none of them came to work for us because we are 'Agile', and none of our clients came to us because we are 'Agile'. Everyone comes together to be happy and build great software, or to quickly get a web application built to meet a business need.
If you're doing Agile right, you're not doing anything that you're not getting value from. For you, it sounds like I'd stop going to those Agile events first :)
Perhaps one reason for old folks is that we old guys can't leave when folks bring in crazy methodologies. Try finding jobs if you're over 50 and not in Silicon Valley. Try forming a company when you can't buy health insurance.
In my decades of programming, one thing has held constant: small groups of motivated, focused capable people far out-perform any other organization or "methodology."
In my organization, agile seems to be popular with management because it creates the illusion that planning is possible, and that progress can be measured at any time with a few button clicks. Hey.. .look at the burn-down... look at the estimates... wow, we actually know what we're doing.
Of course, the real world is less rosy, and many times these things (like planning a few week iteration into maximum four hour tasks) result in lots of gaming of the system.
It's folly, but it's how managers (and I've been one a few times) want things.
It's a lifecycle thing. There will be another 'Agile' along soon with another name with the same underlying 'values' (getting things done, and apparently done well) with a slightly different emphasis. There will always be three key points, another three 'obvious' points, and the final few nice to haves. Folk keep changing their minds about what is most important and so the merry go round moves on[around?].
It's the life cycle of a silver bullet [Sarah Sheard] citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.177.8379
I felt the emotion and passion in what you said. I recognized the experience in your words. I identified.
I was a little upset by the over 40 thing, but pointing out the differences between the 20 somethings and the older crowd is a common theme in programming. I think that the older guys don't feel we get the deference from the "kids" that we deserve for our experience, and the younger guys think that they know better. I figure that this is just normal human nature. I remember thinking that my dad and his friends just didn't get it. I don't know anyone who didn't feel that way when they were younger.
As for Agile or any of the 20K different customizations that people use or promote, one solution does not solve all problems. If someone needs an estimation then get good at estimating. If someone needs 10 pages of paperwork filled out for the project manual, then get good at writing documentation. Do what it takes to get the job done, and find ways to improve along the way. Enjoy the improvement.
Those are my old words, but I have found them to serve me well.
The best way to get code out fast is to lock up the coder in a small room with enough suplly of pizza and cola.
It is called the 'quick and dirty' way and it worked quit well for the last 40 years.
Anytime a 'team' is programming it ends up with a a lot of compromises.
I think the preponderance of 50+ programmers you see at conferences relates to a couple of things:
1. They are more senior in their organizations and more likely to be tech leads/lower level management;
2. They have lived through too many projects where the requirements and ship date have been delivered from "on-high" and neither can be flexed. Thus the third leg of the triangle (quality) gets bent out of shape. These guys are trying to find some tools (any tools) to convince the higher-ups to stop doing this. [The kids on the payroll haven't had this experience yet or have not grown sick of it.];
3. They make a better pitch to management that this is training to help the company and that they can be a "change agent". In short they promise to make their manager look better.
Agile? Fragile. In a long career you discover there is no method that substitutes from knowing your stuff and a habit of staying at the desk until the work is done. OTW, code, compile, fix bugs. Repeat.
As an over 50 califiying relic who has spent days cleaning up code written by slick scruffy kids who learned the tool but not the technology being applied, YMMV By Values. They valued the long flirt, short skirt and the fast promotion for the long weekend of fixing everything they didn't fix the first time. I valued the code that compiles, doesn't corrupt the data and getting out the door by 4pm.
Priorities: the greek philosopher who said one thing should come after another.
I agree! Just like in America itself, we need to get old people out of the way so we can move forward. New technology comes from young people. You don't see Facebook hiring fogies do you. If they're old enough to be your parents they're old enough to stay out of the way!
I completely agree with this comment: "I think the big part of Agile that you're missing is that it's adaptable. Teams have the ability to change what they're doing, to improve the way they work."
Good teams make their own way of working, and "Agile" encourages them to do it.
I also see the value of age and experience in working through the options for the team, since THAT'S WHAT I GET PAID FOR as an old guy myself. I'm just pointing out that this creates an association between the word "Agile" and the older crowd. In the minds of younger people, it becomes an emotional part of the word. I could have said this in a less colorful (more boring) way, and maybe I should have titled this article "7 things I hate about the word Agile."
You sound like a frustrated, angry, old man.
You argue that the value of ideas correlate with the age of people you see at conferences you participate to? Come on...
You argue about the wording in the agile manifesto and not about what's behind it? Come on...
You completely ignore that the value of estimates can be the conversation and insights that happen when estimating? Come on...
You rant against pair programming and blame "agile" for it? Seriously?
You completely mixed up "agile", "Scrum" and the big consulting industry behind it. There is probably a lot to discuss and improve in agile, lean, <whateveryoulike> and you probably want to reconsider if shouting out "you people are all shit" really helps. Well, other than increasing the page views of your blog.
Yes, I think the word "Agile" is very closely related to scrum and the consulting industry behind it. That's the point. If you want to use the word in a different way, you have to do something to shake it up.
I'm not arguing about the wording of the Agile Manifesto. I actually think it's not correct even in principle. Mos of us would like to work in teams with those values. However, in reality, you see people focusing on getting a type of groupthink around values. That's really happening, and it's sort of evil. They should focus on the output. The values will follow, with less peer coercion.
So what's the alternative? I'm a team of one programmer with a db guy on the side for a company, and while estimation may seem like a waste of time due to what you quoted, keeping track of user stories as requirements and their associated tasks keeps me focused on what I need to do to achieve the goal (Kanban is pretty useful too). It also keeps mgmt off my back when I can show progress, accurate or not. I'm glad I never worked in a full blown agile shop...lol. Sounds like it sucks ballz...
Estimation is absolutely essential - but not because it provides predictability. It's because unless you can visualize the work to be done in sufficient detail to support estimation, you're certainly going to encounter gaps in the goals that are going to throw the development off track.
This leads to unnecessary rework and just plain-old wasted effort.
When I say "visualize", I really mean it. Imagine starting the IDE, browsing the web, page layout, which code files you're going to create or modify, etc., etc. In any non-trivial project, you're going to find a lot of indistinct intervals between the imagined start and product delivery that reflect critical uncertainties to be resolved.
I'm not going to assert that this is bullet-proof. I find myself getting tripped up all the time - particularly when the complexity of a project is such that I can't visualize how all the components tie together until I've got some of them built. But I have far greater success when I estimate in this way than when I don't.
mmm, thoughtful piece.... however a couple of minor bones to pick...
Old folk go for agile, why don't the young... well, young people go and do and don't do lots of things, mainly because they haven't been around long enough to learn what does and doesn't do any good. Some societies still revere the elderly - and that is because all of us old farts have been around long enough that we've made - and learned - from the mistakes the young are still making.
Stagnation, not actually a bad thing you know, if it works you don't need to fix it. There is constant churn in a lot of areas where there are problems, there are a lot of people reinventing the wheel - and usually making it worse (good example with the current digital tv and digital radios, they are so damned slow to start my valve tv and valve radio out performs them, my transistor tv and radio are nearly instant). Agile (done right), especially 'scrum', does work - and no I don't say you have to do it exactly as the book says, not all books are right, but the basics DO work.
Imposing values, here you are right, the people you describe don't share values. And not every culture is able to create and sustain self organising teams because their values expect a heavy handed and detailed management, this doesn't mean that the scrum system doesn't work in Europe and America. It also doesn't mean that you can't work with teams some in scrum and some in more management driven - you have to know about cultural differences and setup horses for courses.
Scrum masters vs technical leads. Scrum masters are there to sort out problems to allow the technical bods to get on with their work. This means they HAVE to understand the technical details just the same as technical leads, if they don't understand the details they can't fix the problems. They have a real job, and many do mix some technical work in with the scrum mastering,
Estimating. This would be a valid point if any project anywhere had ever managed to estimate correctly. Frankly a task breakdown is no use when they project changes regularly, if the project doesn't change you produce something out of date or unwanted. I do agree that scrum FAILS badly in not being able to accommodate the basic business requirement to have at least a vague idea of the cost so we can work out whether to do the job, buy it or do something else. However that doesn't mean scrum isn't a valid way of getting the job done once you have decided to do it.
Pair programming is an attempt to get the code reviewed before it is submitted. It is heavy handed, inefficient and I don't agree with it. However it isn't part of scrum and isn't really an 'agile' methodology. Test driven development is also not an agile methodology and actually works better than pair programming.
Agree with the last bit - scrum teams do NOT need to be colocated - I am an advocate of home working as I don't believe we really need development offices anyway. However agile DOES work with teams spread out. Self contained teams are important and work. No one will ever get zero bug software, and teams do shuffle. But agile attempts to help with both - in that respect it is certainly no worse than any other technique and better than many.
Ok so some subset of the people you're talking about are over 40/over 50. So what? I don't think it "changes the perception of the effort" at all, as you are claiming. Ageism is rampant in the world and it should be here in the world of programming least of all. We're all coders. Age is completely irrelevant and really shouldn't be in the discussion. (I'm in my 20s ftr, not that it matters).
I agree with the comment about estimating. I have this theory that most people estimate correctly for the things they think of and understand. For example, programmers will correctly estimate the cost of coding. However, they basically assign zero estimates to all of the other tasks that they don't think of or understand. With this algorithm, estimates are always low. So, the way to get a good estimate is to do a really detailed component and process breakdown, so you leave fewer things out.
the reason the people over 50 like agile is because they lived thru the "waterfall" era and agile beats the hell out of that. but software development is still in it's infancy and newer ideas that use the best parts of the older ideas are still flowing. i learned a lot of good things from agile but i never signed the manifesto or took the pledge ;)
Agile development is a philosophy! "Agile development isn't a specific process you can follow. No team practices the Agile Method. There's no such thing."
Dev Teams should implement the right "method" or "process" that is best suited for the company...enter DevOPs
. Collaboration is key!
Agile methods should be tailored-made and constantly refined to embrace change! There is no silver bullet for software development. "Agile Development focuses on achieving personal, technical and organizational success"
There are no young people in the crowd of the "Agile Conventions" because we already know how to be agile!
The new generation of developers (born >1978) are born into a fully-loaded technological world...which is constantly 'changing'.
After reading your post, it is clear that not everyone can be successful in remolding their mind to learn new processes.
This fear naturally comes with age after you have reached your cognitive capacity.
[Warning to Readers: Agile Development is not for everyone
... if done incorrectly, it will make you bitter and grumpy]
Quotes: The Art of Agile Development by Shore & Warden | O'Reilly
The Assembla blog has proven very interesting over the years, as it describes the efforts of a distributed, small(ish) software team focused on software development productivity. But the latest post is just another example of a trend I've observed of confusing an individual's lack of performance with a more systemic one.
Show me a system/process/methodology that works and at least one person who's passionate about sharing their success in the hope of benefiting others and I'll show you a group of people that don't make the effort to understand why it works yet feel entitled to adopt it in name only and then use it as an excuse for their own lack of performance.
I don't agree with your take on "the smell of death" -- I see a lot of younger developers doing Agile and I find that very encouraging. I recently had a chance to visit with another group in the company I work for and they had a very vibrant Agile practice. Most of the developers were in their 20s and only a handful who were our age (late 40s and more). As for the job of Scrum Master, they have one of the most important jobs: to keep the team honest and to remove obstacles, whatever those may be; that includes getting developers a massage once in a while, if that's what's keeping them from working as well as they could. Overall, your criticisms make me think that you have either not done Agile or Scrum at all or you have tried it but didn't do it very well. Agile and Scrum are not perfect and it's not very hard to point out something "wrong" about it if that's the mindset that you have coming into it. That's not the right mindset to have when you do Agile though and if it is, then you've already failed.
I'm no big fan of Agile.
But you do go on quite a bit about its lack of freshness.
Typing hasn't changed in 40 years either, but I still do it because it achieves the goal of entering data into my computer.
Newer does not necessarily mean better.
I won't even start to comment on the rest of the post since others have already pointed out the problems with it. But the whole 'old people' thing fascinates me.
Certainly when I was a baby dev I generally didn't bother with conferences and suchlike either since (1) I couldn't afford it, (2) my employers wouldn't send me since I already had a reputation for rocking the boat, and (3) I knew it all anyway - why should I listen to a bunch of Old People tell me about things that I knew everything about and then some?
However, as I learned, I realised that all my silver bullets were duds, and that all my golden hammers were made of glass. I needed
those Old People to guide me around the pitfalls and traps that I was rediscovering the hard way. I needed to stand on their shoulders, not on their toes. Between us, we homed in on a better way of working by cooperation, discussion and experimentation.
But I don't expect you to believe this yet. After all, it's advice from someone I suspect you would consider to be an "Old Person". After all, what do I know after over 20 years of experience? And I suspect you still have a lot of bludgeoning through before you realise that there might be a better way. Enjoy.
The problem as I see it is most places are playing at Agile. Too many times I have seen where they are producing documentation to show they are doing it (I assume to keep someone up stairs happy) while not actually following the sprit at all. For example spending 3 days estimating vaguely defined features to find we are WAY over on the hours we need to complete the tasks. Answer revise the estimates! Then just move anything that does not get done to the next sprint. Kind of reminds me of the whole ISO-9000 mess. (Yeah I’m that old.) Great idea almost that never implemented as anything more that increased documentation. Essentially both (and pretty much all the variants in between) come down to the same feedback loop idea and basic time management:
First you should know what needs done. Process docs and good requirements. Good luck on that one in the real world.
Once you figure out what needs to be done break that down into tasks that take less time than your sprint length. Better yet less than a week. This includes research tasks to get requirements or data for estimates. Often ½ the time spent on a feature is finding enough info to do a realistic estimate. One method I’ve seen used maps estimates onto Fibonacci numbers with the idea that the larger the number the further off it will be. To me that kind of says it all about estimates. Do them for real or don’t bother. (Be sure to put time in those estimates for writing tests and updating docs.)
Commit to what each of you will do this sprint. Assuming you have realistic estimates of course otherwise this is also a complete waste of time and usefully only for giving the customer false hope.
At minimum you should add at least 1 happy path test for each bit of logic you add or change. Whether that is a unit test or an integration test depends on what is being tested but SOMETHING. The idea here is if someone decides to do a refactor they can be reasonable sure they did not break your code if your tests still pass. Every defect should have a test written BEFORE a fix is coded so show the defect.
When you check in, some sort of continuous integration should be done which runs all the afore mentioned tests to make sure nothing fell through the cracks and deploys the build to a demo server so everyone has a reference of the current code to compare to.
Lastly you need to routinely look back and where things went wrong, figure out if there is a way to do better and demo functional changes to the app. While most places seem to think this means showing it to the team, in most cases that is useless. The people writing the code should be working with the app every day and or looking at the deployed build. They should not need a demo. The Agile intent is to show it to the customer or their agent (like project manager) to get them to sign off as you go instead of them letting it get to the end and claim you did the wrong thing.
What is not from in the above? Mainly meetings. I like to say meetings are like brakes on a car. Every time you touch them it costs you MPG so use them as little as possible. And brakes like meetings people tend to use them by default instead of thinking ahead.
I think Agile feels so dated is because more and more it seems to be used to justify getting people into the office earlier and motivating them by making them come up with status for all the meetings. This is a very old style manager point of view. Today’s buzz is all about moving everything to the cloud. Being able to work from anywhere. But lazy types try to use Agile to make quantifying what their developers are getting done by the hours past 5pm they are at their desks. And empire building types try to use the “face-to-face” tenants to help keep their budgets bloated with unneeded office space. Today we have phones that do teleconferencing and all kinds of online meeting tools. There really is no reason to waste time bringing people to a place for either a meeting or to type. I tell people if your process does not support distributed development then you will not be able to compete for long. (See Justin Case above) Office space is too expensive to waste on people that could be working from home. Not to mention relocation costs, all the time wasted in just getting to and from the office or the health and safety issues. Plus there is NO WAY to call yourself a green company and still expect your employees to drive in to sit in front of a computer all day. Software developers tend to be out there on the edge. They are writing these cloud based apps. You are not going to motivate them with pre internet thinking.
There are good reasons for Agile development:
1. Nobody can fully visualize full potential of a system, so build your best guess and get some feedback.
2. Nobody knows where will the market or marketing take your product next. So your product needs to be agile, whether you call yourself Agile or not. Adapt or die.
3. Documentation is useless at best and outright dangerous when it gets out of sych with the code. How do you find out what the other guys are doing? Round em up for a quick chat.
4. You have tried all the other crap, you have designed yourself into a corner too many times, your APIs were never used the way everybody agreed during countless design meetings and the product visionaries were mostly blind. You are too old for this shard. Just make the sharded thing work.
Some other less important reasons:
* Pair programming: she is soooooo cute!
* Standups: stretching after the morning run... can't do it sitting down. Also, faster exit after the BS is over.
* N-weeks iterations: hello! That is a no-brainer. Who can wait for that release party the next sharded year? Man needs beer.
* Tickets tracking system: your boss can't shave her sharded neck beard and you want to believe that she will remember what she told you to do? Really! Really? You need to use protection! Write it down what was that unicorn you were suppose to catch.
Why do old gasser-gissers go to Agile...Big Data...No SQL... ML... meet ups. Ahm, beside the usual 3 Bs beer, bitches and BBQ? Who knows, maybe they don't like bingo?
I never liked agile. There's value in each and every agile technique - but hey, all those techniques were in fact there before the agile term was even coined.
My take on agile: all the right things to do when developing software were actually invented/discovered before agile came along. However, once programming became a well established corporate activity, all those right things were replaced by bureaucracy. At some point, a few people got fed up with bureaucracy ruining projects, coined the term agile, and claimed ownership of all the right things that corporate programming had thrown away.
What's happening now is the same thing. Agile is the new corporate name for bureaucracy. Potentially, younger people have come to the conclusion that the only way of breaking this cycle is not to give a name to what's the right thing to do, but instead just do it.
Just remove the first point from this post and it will be just awesome. I think that our industry lacks "old" people who are still programming. Those are exactly the kind of people that usually don't fall for latest new fashions like "story points" in agile estimations.
As every method, from waterfall to agile, don't take it too strict and use what you can use and leave what isn't applicable or significant to you.
This post has generated quite a bit of discussion, both pro and con. That in itself suggests it says things that need to be said. The post struck me as a very good summary of the so-called "agile backlash."
Andy hits the nail on the head in most respects. The two minor errors (the age thing and the pair programming thing) are probably a result of his preference to avoid "agile" methods and events. He knows enough about "agile" to know he doesn't like it. His misconceptions about details are irrelevant to that point.
I suspect the readers who have posted comments that seek to "teach" him what "agile" is supposed to mean are missing the point. Are those readers tuned in to hear this message at all? Do they really believe "to know agile is to love it," or something along those lines?
Many people have grown tired of people labeling anything and everything "good" with the word "agile." When a word means anything you want it to mean, then in effect the word means nothing. The A word has been so overused and abused that it has been squeezed dry of any meaning at all. It's time we, as an industry and as a profession, take what lessons we can from the "agile" movement and move on. Maybe it's past
time we did so.
I hope we won't merely substitute some other buzzword and continue behaving (collectively) in the same way.
Overall this reads like just like the complaints of any new dev joining one of my teams who are doing what I need them to do, challenge authority and resist stupidity. There are answers to the legitimate questions posted here.
* Estimates of software tasks are inherently unreliable.
-- taken literally, of course they're unreliable, that's why they're called "estimates". The value is that over time estimates yield a standard error that trends very, very reliably, just like story points. Never take estimates literally, as in an hour estimate takes an hour duration.
* The benefits of estimates are outweighed by the time required to make them.
-- seems true given the points listed here show the author has never seen estimates used correctly.
* Most developers won’t take the time to enter actual hours.
-- true in this case because no one has demonstrated how to trend estimates as the key predictor of when things will be 'done'.
* Measuring people against estimates sends the wrong signals and will distract people from being flexible and innovating.
-- Amen - this is evil, evil, evil and certainly not agile. Attributing it to agile is wrong.
* Measuring people based on estimates causes them to game the system.
-- Absolutely. smart people should actively tear down stupid things. Also not agile, but again demonstrates lack of understanding of those polled, and the pollster.
Pairing: I would bet to outperform a 2person team of circa the same skill level that go by your pair review format by minimum 20% of output by ca. -50% of a bugrate in the final product with a 2 man team pairing. This is what the research implies and my experience.
Interesting Blog, but we thinks this was written to drive traffic to your site, well done
I suspect this article was more about positioning than anything else. Old people use the other guys product, young hip “successful” people use ours. I think that will end up biting you in the ass but kudo’s for having the balls for trying it out.
Your statement that most “Hot” startups are not using X and instead are going with Y is not a predictor of success or failure. Amazon is pretty successful and they seem to love Scum, therefor I guess Scrum made them successful? ( I don’t love Scrum, and I think it has issues just like you, not the point )
These things tend to be more important after you start to scale and become successful and things start to get harder to control, but they don’t predict or insure success, and I am pretty sure that you won’t find a single honest entrepreneur that says “The secret to my success was using brand X process model/practices/toolset!”
In general startups (regardless of their hotness) fail, not because of the flavor of the process framework or best practices they have applied, but because they built something no one cares about or that they have no revenue model for.
I would rather be building the right product with the wrong “process” than the other way around. This is something “Old guys” like Steve Blank tend to think more about.
Successful practice always trumps theory, and sadly for all of us, the old death stinking types, you tend to age while that happens.
The fact that you are at your near 50 stage teaching the young guys how to think about process frameworks because they recognize the value that the old and infirm just can’t seem to grasp is kind of ironic don’t you think?
Of course tool vendors always try to convince you that their tools are the golden bullet, older guys usually laugh at this because they realize that golden bullets are fairy tales.
About "smell of death"
I am 58 years old and I hate Agile. Age prejudice doesn't help get to the right conclusions.
I am 57, I have been a programmer for most of my working life and I hate Agile. It ignores the reality nof how good software is developed. SO far as I can see it is just a way for people with no programming ability mand no management skills to make money out of the IT world.
When you get old enough you view all these "latest and greatest" "new" developments with the skepticism they deserve.
Demographics at Agile events is nothing related to the actual Agile methodologies. Seeing the "older" crowd, in fact, tells that it may also be more about job-security rather than improving development practices.
Agile approaches have business value as much as the people who actually understand and practice them.
Agile ideas perhaps are more attractive to younger developers, but naturally they have more career time ahead of them. On the other hand, the "seniors" in current market conditions sit in a really shaky chairs, on all levels from execs to team-leads. So the "agile" is being used as a collective floating cushion from top-to-bottom.
Unsurprisingly, this leads to dogmatic adoption for the sake of self-preservation. Count how many former project managers are now cast into ScrumMaster roles [full-time].
Many Agile events are geared towards larger companies which can validate the registration fees, so startups or freelancers may instead turn to other ways to communicate.
The bottom line: it's not the ideas, it's the people and ourselves included!
You don't like it because it's not exciting. You'd rather put out fires, work 80 hour weeks and think you're super cool because you're so "free".
Meanwhile, I'm hanging out with my family for dinner every night and NOT working weekends because I did things right. Oh... and we did it on time, under budget without racking up future technical debt. There won't be guys looking at my code in the future thinking "what an IDIOT" for being too busy to do my job right.
As far as estimating goes, I bet you have never measured a doorway before you bought a dryer to make sure it will fit through. Yeah.. COMPLETE waste of time there.
Good points, tratwork. There are many benefits to good planning. In my opinion, it's worth stepping back and looking at the effectiveness of each planning effort, and making sure that the planning work you are doing actually qualifies as "good planning."
Just throwing my 2c in. Yes, Agile, DevOps, and all that crap is just a load of bullshit designed to sell books and keep middle managers alive instead of in the hobo rubbish piles begging where they belong.
Rapid Prototyping is the only
method that has ever worked. No, as in EVER. There IS nothing else.