Agile is a Sham(williamedwardscoder.tumblr.com)
williamedwardscoder.tumblr.com
Agile is a Sham
http://williamedwardscoder.tumblr.com/post/20054342100/agile-is-a-sham
45 comments
True, the article is basically a rant, but I tend to agree. I've felt like the agile train left my station long ago and it wasn't for trying. After being invited to attend a free 'workshop' from one of the holiest purveyors of agile out there, I left with the feeling that it definitely was all for those who did not know how to actually 'do the work'.
The trends I've been seeing and trying to do are as follows:
* full stack responsibility. You own the task front (js/html) to back (db), including testing.
* no f-ing standups. Communicate normally with your colleagues, no prescribed check in with them.
* no iterations. Release whenever; it may sound crazy but kanban style release whenever you're ready to push features out, in my mind, is the way to go.
* engineers, again, run the company. This in my mind is the biggest thing - having those 'with power' also be engineers and the product being the most important product.
All the above are the opposite of what I've seen with the agile movement. Keep teams small, keep them close and your product will reflect that.
Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong. You're making a tech company but you don't understand the basics of how the product is made.. So, you own a furniture making company and you don't understand what glue, oak, and lathes are..? Fail.
That's my real life experience and opinions regarding agile. I've tossed away all the agile stuff for a new project I'm doing and like the poster says, it's all based on common sense. You can run your company or project any way you want. I have friends that have millions in revenue every year with their small shops and they don't do any agile stuff. Yet they're one of the leaders in their space and when my friend, the engineer ceo, told me "we have no iterations or deadlines except when it has to be done by", that was a big wakeup. I was thinking "THAT'S how I want to do things".
So, it can be done. Good luck. :)
The trends I've been seeing and trying to do are as follows:
* full stack responsibility. You own the task front (js/html) to back (db), including testing.
* no f-ing standups. Communicate normally with your colleagues, no prescribed check in with them.
* no iterations. Release whenever; it may sound crazy but kanban style release whenever you're ready to push features out, in my mind, is the way to go.
* engineers, again, run the company. This in my mind is the biggest thing - having those 'with power' also be engineers and the product being the most important product.
All the above are the opposite of what I've seen with the agile movement. Keep teams small, keep them close and your product will reflect that.
Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong. You're making a tech company but you don't understand the basics of how the product is made.. So, you own a furniture making company and you don't understand what glue, oak, and lathes are..? Fail.
That's my real life experience and opinions regarding agile. I've tossed away all the agile stuff for a new project I'm doing and like the poster says, it's all based on common sense. You can run your company or project any way you want. I have friends that have millions in revenue every year with their small shops and they don't do any agile stuff. Yet they're one of the leaders in their space and when my friend, the engineer ceo, told me "we have no iterations or deadlines except when it has to be done by", that was a big wakeup. I was thinking "THAT'S how I want to do things".
So, it can be done. Good luck. :)
> full stack responsibility. You own the task front (js/html) to back (db), including testing.
Unless you are 1337 with all of those you end up with silos instead of properly defined layers and reusable code.
> Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong.
Awesome, I'll get around to telling my boss that, the very same one that hired me.
Unless you are 1337 with all of those you end up with silos instead of properly defined layers and reusable code.
> Another huge, HUGE thing is to get the fucking mba management types out of the office. Can't stress this enough: if you can't code, you don't belong.
Awesome, I'll get around to telling my boss that, the very same one that hired me.
"* no iterations. Release whenever; it may sound crazy but kanban style release whenever you're ready to push features out, in my mind, is the way to go."
I am not a programmer. I have been involved in user training and in documentation for end users. How does your project handle the situation where there is a non-trivial change in the user interface?
I am not a programmer. I have been involved in user training and in documentation for end users. How does your project handle the situation where there is a non-trivial change in the user interface?
The ranking on HN can be explained because there are apparently a lot of people here that share your sentiment.
I don't really have a problem with the tenets of Agile, but the Church of Agile, its high priests, and its associated industries are bullshit.
I don't really have a problem with the tenets of Agile, but the Church of Agile, its high priests, and its associated industries are bullshit.
That's it, the marketing people take a very simple concept, put a lot of marketing bullshit around it, make it seem A LOT MORE difficult than it needs to be and you then have to take a million courses to understand what the hell is going on. The best "agile" managers I have worked with "just got it", just like the best developers. There is none of this spoon feeding a baby crap.
True, agile is a collection of "very small nuggets of common sense wisdom". But one thing that often gets missed is that common sense is often very hard to implement properly; this is where a good agile trainer will help.
I can think of dozens of changes I should make to my every day life based on common sense (don't get stressed, spend more time with firends and familly, save for the future etc). Why don't I do them? Because it's difficult to align these "simlple" truths with the overall complexity of my environment and competing pressures. There's always complexity in the system, agile just simplifies one part and moves complexity into other areas e.g. having a highly trained and skilled team.
I can think of dozens of changes I should make to my every day life based on common sense (don't get stressed, spend more time with firends and familly, save for the future etc). Why don't I do them? Because it's difficult to align these "simlple" truths with the overall complexity of my environment and competing pressures. There's always complexity in the system, agile just simplifies one part and moves complexity into other areas e.g. having a highly trained and skilled team.
Don't confuse "what you should do", with "how you should do it".
For example the what is "do not get stressed", the how might be to plan your day better, keep your life simple, etc.
These small nuggets usually talk bout the how, but a lot of people either think they know better, or have resigned themselves to the fact that it really is that hard.
For example the what is "do not get stressed", the how might be to plan your day better, keep your life simple, etc.
These small nuggets usually talk bout the how, but a lot of people either think they know better, or have resigned themselves to the fact that it really is that hard.
I'm surprised no one has brought up Steve Yegge's Good Agile, Bad Agile [1], which speaks well to both Google culture and scaling (good) Agile. One of the comments on that post mentions it. It's worth reading (and being Yegge, that'll take awhile).
Agile is like anything else: some well-meaning (and arguably useful) principles that get warped by bad managers and bad companies. The natural evolution for any such idea is to turn it into an industry and there are any number of people who are willing to sell you training, lectures, books and programs for Agile (with a capital-A). You need to separate the industry from the idea.
[1]: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
Agile is like anything else: some well-meaning (and arguably useful) principles that get warped by bad managers and bad companies. The natural evolution for any such idea is to turn it into an industry and there are any number of people who are willing to sell you training, lectures, books and programs for Agile (with a capital-A). You need to separate the industry from the idea.
[1]: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile...
Exactly. And note the date: 6 years ago. I think the collective wisdom has been acquired. The IT community needs to name it in a way that makes these lessons learned common enough that the next time someone is burned by Bad Agile, they won't rewrite one more iteration of this same post.
It's useful to distinguish big-A and small-A agile.
Big-A Agile is a management buzzword, something you can become certified in and certainly a scam.
Small-a agile is a number of mostly common sense principles on how to approach process. It is emphatically not the process itself. While it cannot be meaningfully certified, it can be taught and learned.
Someone else linked to the agile manifesto. I'm just gonna go out on a limb and paste the punchline:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Big-A Agile is a management buzzword, something you can become certified in and certainly a scam.
Small-a agile is a number of mostly common sense principles on how to approach process. It is emphatically not the process itself. While it cannot be meaningfully certified, it can be taught and learned.
Someone else linked to the agile manifesto. I'm just gonna go out on a limb and paste the punchline:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This is fair.
Furthermore, I think it's best to consider Agile in its proper historical perspective. When it first emerged, its principles -- as you've enumerated from the manifesto -- were uncommon enough to be novel and insightful. In this context, the Agile philosophy was a legitimate reaction to the problems of its day. Whether or not it's been an effective remedy to those problems is a matter of hotly contested argument. But one is, perhaps, inclined to be more charitable to Agile when fixing it into historical place.
In principle, I don't think it's fair to call Agile -- the core, original theory -- a "sham." Rather, the "sham" is all the rigidity, trappings, and liturgy that have grown up around Agile since it reached its saturation point. At some point, Agile started to ossify into a shadow-image of everything it was intended to fix. But I think that failing reflects the nature of its practitioners more than it does the core philosophy.
Furthermore, I think it's best to consider Agile in its proper historical perspective. When it first emerged, its principles -- as you've enumerated from the manifesto -- were uncommon enough to be novel and insightful. In this context, the Agile philosophy was a legitimate reaction to the problems of its day. Whether or not it's been an effective remedy to those problems is a matter of hotly contested argument. But one is, perhaps, inclined to be more charitable to Agile when fixing it into historical place.
In principle, I don't think it's fair to call Agile -- the core, original theory -- a "sham." Rather, the "sham" is all the rigidity, trappings, and liturgy that have grown up around Agile since it reached its saturation point. At some point, Agile started to ossify into a shadow-image of everything it was intended to fix. But I think that failing reflects the nature of its practitioners more than it does the core philosophy.
I haven't heard that argument before. Interesting.
For me, big-A Agile refers to the Agile Manifesto for Software Development, and is the Agile that people are talking about in posts like this. It may be a software development buzzword, and yes there are certifications and they are scams, but I find the values and principles in the Agile Manifesto to be fairly sound and relevant within the context they were first produced in, as basically a reaction to waterfall in larger companies developing business software with average developers.
Small a agile is an English word meaning quick or flexible or something.
I am not saying I am right and you are wrong, just that is how I have usually thought about it.
For me, big-A Agile refers to the Agile Manifesto for Software Development, and is the Agile that people are talking about in posts like this. It may be a software development buzzword, and yes there are certifications and they are scams, but I find the values and principles in the Agile Manifesto to be fairly sound and relevant within the context they were first produced in, as basically a reaction to waterfall in larger companies developing business software with average developers.
Small a agile is an English word meaning quick or flexible or something.
I am not saying I am right and you are wrong, just that is how I have usually thought about it.
You can't "be" big-A Agile, it's a tool set or a check-list - but you can (and should what to) be small-a agile as a development organisation.
The reason I make the distinction is that big-A is the quantifiable bit, but you can tick all the boxes and still essentially do waterfall. Conversely, you can be small-a agile without ticking the boxes - agile isn't, and can't be, prescriptive.
If the team feels they don't need daily stand-ups, or if they want to sit down (the horror!), there is nothing about being agile that should keep them from doing that. Same goes for tests: You can worship the test coverage number obsessively, but if your assertions are pointless or missing, you won't reap the benefits. Conversely, an agile team can decide to forego tests if that's the right thing.
The reason I make the distinction is that big-A is the quantifiable bit, but you can tick all the boxes and still essentially do waterfall. Conversely, you can be small-a agile without ticking the boxes - agile isn't, and can't be, prescriptive.
If the team feels they don't need daily stand-ups, or if they want to sit down (the horror!), there is nothing about being agile that should keep them from doing that. Same goes for tests: You can worship the test coverage number obsessively, but if your assertions are pointless or missing, you won't reap the benefits. Conversely, an agile team can decide to forego tests if that's the right thing.
The problem with these "only good programmers will create good products so stop with the Scrum already" rants is that in real life we have more than enough mediocre engineers and we just have to come up with best possible products with those.
I work as a quality assurance consultant. Usually companies buy my services when everything is messed up. Now if I try to solve their problems by saying "hire better engineers", nothing gets fixed. Nothing gets fixed because there is only so many good engineers available and the company usually don't have enough money to hire him/her.
But if I teach them to follow Scrum, it is really easy to add code reviews, testing (unit and functional), planned releases, etc.
It could be argued that one does not need Scrum to get those done or that it does not matter since team of better engineers will at some point do better job. But have problems in our hands right now and those must be fixed yesterday. So until some other methodology than Scrum get popular enough, we'll use that.
So in real life Scrum makes getting the best out of normal team so much easier. Sure there are always rockstars who don't need any process, but in reality you, me and most of us, are all pretty dumb and just have to live with the fact.
I work as a quality assurance consultant. Usually companies buy my services when everything is messed up. Now if I try to solve their problems by saying "hire better engineers", nothing gets fixed. Nothing gets fixed because there is only so many good engineers available and the company usually don't have enough money to hire him/her.
But if I teach them to follow Scrum, it is really easy to add code reviews, testing (unit and functional), planned releases, etc.
It could be argued that one does not need Scrum to get those done or that it does not matter since team of better engineers will at some point do better job. But have problems in our hands right now and those must be fixed yesterday. So until some other methodology than Scrum get popular enough, we'll use that.
So in real life Scrum makes getting the best out of normal team so much easier. Sure there are always rockstars who don't need any process, but in reality you, me and most of us, are all pretty dumb and just have to live with the fact.
The other problem is that the people who write those rants are probably not half as good as they think they are.
In the last few companies I have worked for, Agile was not lightweight, and became a significant hindrance to productivity. In fact, there was an "Agile consultant" brought in to make us more agile at one company I worked for. He ended up making our process 3-4x more convoluted and process intensive. He also succeeded in making the work not fun anymore. In my last job, "Scrum" meetings could take 30 minutes or more on many occasions, and our "sprints" would regularly change scope or be canceled mid way through.
I know that isnt Agile, but the problem is that many managers(and apparently consultants) think that is the way to do it. In my opinion, work getting done is not because you implement a process or methodology. Work gets done when you have a good team in place and trust them to do their job. Many companies seem to think that they can promote a non technical person to manage a development team. The problem with this is that they have no idea how software is built so implementing a methodology that promises consistent results no matter what the inputs are seems reasonable to them.
I am by no means representative of anyone other than myself, but I find I am most productive when a) I know the problem domain inside and out b) I am given some leeway with architecture and design c) I am not bogged down in process.
As projects get larger, its not as easy to allow for those conditions, so getting smart people on board is imperative. Agile should allow for managers to get some transparency and a view into the process, but little more...
I know that isnt Agile, but the problem is that many managers(and apparently consultants) think that is the way to do it. In my opinion, work getting done is not because you implement a process or methodology. Work gets done when you have a good team in place and trust them to do their job. Many companies seem to think that they can promote a non technical person to manage a development team. The problem with this is that they have no idea how software is built so implementing a methodology that promises consistent results no matter what the inputs are seems reasonable to them.
I am by no means representative of anyone other than myself, but I find I am most productive when a) I know the problem domain inside and out b) I am given some leeway with architecture and design c) I am not bogged down in process.
As projects get larger, its not as easy to allow for those conditions, so getting smart people on board is imperative. Agile should allow for managers to get some transparency and a view into the process, but little more...
Agile and Scrum have some good things going for them.
They teach developers that building things is always an iterative process. A well designed product will still require incremental on-the-fly improvements to get it right just as code does. Sometimes a design will require a refactor just as code does. Needing a 'complete' design doc before building a product is a fallacy.
They teach project managers that if they just let the designers and developers get on with it they can usually self-organise and manage their time better than if done top-down by a non-technical outsider.
They teach producers and 'product owners' that constant interference can be detrimental to a production process. Developers should be allowed to develop.
Best of all if done right they allow everyone scope to make mistakes yet still fix them and good mistakes that they can try out and keep.
However, there are downsides: scrum has no role for designers in the day-to-day production. Either they are pushed to the role of product manager or they have to work independently a sprint ahead. An ideal system would put the designers into the heart of the scrum team.
Top-down scrum is where it all goes badly wrong: producers and managers insisting that designs are complete before a line of code is created, managers taking the role of scrum-master, sprints being nothing more than waterfall milestones etc.
They teach developers that building things is always an iterative process. A well designed product will still require incremental on-the-fly improvements to get it right just as code does. Sometimes a design will require a refactor just as code does. Needing a 'complete' design doc before building a product is a fallacy.
They teach project managers that if they just let the designers and developers get on with it they can usually self-organise and manage their time better than if done top-down by a non-technical outsider.
They teach producers and 'product owners' that constant interference can be detrimental to a production process. Developers should be allowed to develop.
Best of all if done right they allow everyone scope to make mistakes yet still fix them and good mistakes that they can try out and keep.
However, there are downsides: scrum has no role for designers in the day-to-day production. Either they are pushed to the role of product manager or they have to work independently a sprint ahead. An ideal system would put the designers into the heart of the scrum team.
Top-down scrum is where it all goes badly wrong: producers and managers insisting that designs are complete before a line of code is created, managers taking the role of scrum-master, sprints being nothing more than waterfall milestones etc.
Let me say this. I have found scrum in particular to be used as a management tool (report back tool), and not a developer tool. It doesn't matter where i go. It starts with the greatest of intentions, and ends up where management are sticking there fingers in the pie half way through. And by that I mean they don't use priorities on the backlog to manage the process. They use the standup meetings as a moan session when things don't go there way. To me scrum in its purest form is where the developer drives the process. Most projects will perform better if they just let them do that.
Agile is a management tool. It helps manage developer time, feature bloat, organizational blocks, communication overheads and user expectations. It also helps you measure performance and identify bottlenecks in your own process. Like other comment said, it helps getting a couple things done instead of having a huge pile of stuff half done.
Look at what Agile is promising to fix. The development process not the management process. Semantics aside, I like everything you said, except to say that either the line manager is doing those things, or 'it' (scrum) is doing those things.
I disagree. I've met a LOT of developers who believe they know more than the customer, the QA team, the UX team and the DBAs. And they are, most often, wrong.
I think it takes a special sort of programmer to run a project to be honest. They are out there, but they are hard to find!
I think it takes a special sort of programmer to run a project to be honest. They are out there, but they are hard to find!
Just to be clear, I meant the developers should drive the STORY, and not the PROJECT. Is is after all something advocated by scrum.
This kind of somewhat understandable but ultimately clueless ranting just tells me one thing: no way in hell I'm ever going to trust a programmer who cannot (or can not be bothered to) distinguish between marketing bullshit and the real thing.
This kind of attitude will show up in other matters, most importantly understanding what actually needs to be developed, what the priorities are and why they are important.
I'm surprised how many people here seem to be ignorant of Agile. Take for instance the certification scam accusation that is liberally thrown about: only Scrum has certification, and even that has always been controversial. As far as I know, no other Agile flavor tries to sell certification. But even so, Red Hat sells certification, does that make Red Hat Linux a scam?
There are scammers and greedy consultants in every area of IT. None of that has fuck all to do with Agile in particular. So why are people so hell bent on using this against Agile?
This kind of attitude will show up in other matters, most importantly understanding what actually needs to be developed, what the priorities are and why they are important.
I'm surprised how many people here seem to be ignorant of Agile. Take for instance the certification scam accusation that is liberally thrown about: only Scrum has certification, and even that has always been controversial. As far as I know, no other Agile flavor tries to sell certification. But even so, Red Hat sells certification, does that make Red Hat Linux a scam?
There are scammers and greedy consultants in every area of IT. None of that has fuck all to do with Agile in particular. So why are people so hell bent on using this against Agile?
How well a team works together depends on far more than how smart the component engineers are. One clever engineer may be sufficient for a Suduku problem, but it is a matter of scale.
This fellow is basically arguing that we don't need government because people get along just fine on their own. Which is absolutely true on an individual scale, and not at all true as soon as two people live next door to one another.
In my experience 90% of software problems are social problems. He seems to care only about technical problems, and assumes those are solved by the magic of intelligence. I believe that if you can not explain to someone else how to do what you do, you aren't actually a master of your craft. Appeals to hire smarter coders sound incredibly hollow unless they are accompanied by techniques to make the average coder smarter.
There are much better critiques of Agile out there, mostly having to do with how it has been sold. I'm not sure what he thinks he is contributing to the discussion.
Any process can be harmful. It can also be incredibly useful, and the lack of process is at least as harmful as process applied badly. I recommend the book "The Checklist Manifestos" for examples. It proposes that the goal of process is to handle routine complexity and make cooperation routine, leaving human attention and effort free to focus on the actual hard problems.
In my experience 90% of software problems are social problems. He seems to care only about technical problems, and assumes those are solved by the magic of intelligence. I believe that if you can not explain to someone else how to do what you do, you aren't actually a master of your craft. Appeals to hire smarter coders sound incredibly hollow unless they are accompanied by techniques to make the average coder smarter.
There are much better critiques of Agile out there, mostly having to do with how it has been sold. I'm not sure what he thinks he is contributing to the discussion.
Any process can be harmful. It can also be incredibly useful, and the lack of process is at least as harmful as process applied badly. I recommend the book "The Checklist Manifestos" for examples. It proposes that the goal of process is to handle routine complexity and make cooperation routine, leaving human attention and effort free to focus on the actual hard problems.
No. Process is important; it's necessary. There are at least two prongs to this problem: one is you can't manage what you don't measure, and process gives you a way of tracking functionality implemented, defects, defects resolved, etc. There's nothing inherent to programming that gives your manager or your team any sort of knowledge about how far along you are, or just as importantly, when you will be done. You can hack all you like and -- even if your code is visible to all -- there's no way of guessing how far along you are, or if that needs-to-be-fixed-yesterday bug is close to resolution.
The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.
And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.
Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.
The other prong to this problem is you can't remember what you don't record. Well, you may have an eidetic memory, but unless the company generates deliverables besides code that explain what the code does or is supposed to do, a change in team X years down the line may mean the company forgets why Joe wrote the widget wrangler in the way that he did, and accordingly the widget wrangling module becomes an unmaintainable black box. Generating these deliverables is a part of the software process, whether Agile or otherwise.
And there will always be a process. This arises simply as a consequence of the fact that management needs to know how well you're doing, and if you're performing in a cost-effective manner, to many decimal places of precision. And if the process isn't agile, it could be something far less pleasant.
Agile Processes (big A) may sound scammy to you, like their proponents are trying to sell back to you shit you already know. But you only know that shit because you're a software developer. Management can't do what you do, and they're the target audience of Agile Processes like Scrum and XP. It gives them a ready-made Industry Best Practice that they can decide with confidence to adopt company-wide, with little perceived risk because it's so proven and widespread. Compare and contrast with the success of the "open source" meme in convincing companies to adopt, and participate in, free software.
No, it's even worse. You can't manage what you can't measure. And so far no one has found a metric to measure creative output like painting, writing poetry or writing software. Whatever metric you choose to measure and evaluate your team, and esp. what ever metric you reward is going to lead your team optimizing their performance for that metric.
You want to measure LOC, programmers WILL write more lines. Want to measure and reward less defects, programmers WILL create less defects etc. But will your software be sexy, appealing to users, creative, innovative, trend setting solution to old/new problem?
You want to measure LOC, programmers WILL write more lines. Want to measure and reward less defects, programmers WILL create less defects etc. But will your software be sexy, appealing to users, creative, innovative, trend setting solution to old/new problem?
> And so far no one has found a metric to measure ... writing software
How about ...
* Number of new features delivered per week (and size of said features)
* Number of new users per week
* Number of page views per day
They're fuzzy metrics at best, but saying "writing software can't be measured" is just defeatism. It's not fine art, it's not a Jackson Pollock painting, it's a craft. It has utility. We can get a grasp on that. Even the pretty bits are ultimately there to make it more useful to people.
How about ...
* Number of new features delivered per week (and size of said features)
* Number of new users per week
* Number of page views per day
They're fuzzy metrics at best, but saying "writing software can't be measured" is just defeatism. It's not fine art, it's not a Jackson Pollock painting, it's a craft. It has utility. We can get a grasp on that. Even the pretty bits are ultimately there to make it more useful to people.
That's even more nebulous. Yes, those things are perfectly measurable, but how do you translate x number of new users per week into code?
Isn't that what software development is all about. It's about collapsing this cloud of uncertainty into concrete deterministic expression a.k.a code, which only solves the problem as you understand it.
If software development were that measurable, software developers would be as well paid as CEOs or sales people. But we are not. Because there is no way to demonstrate almost any relationship between what we do on daily basis (stare at screen and type on the keyboard as management often sees it) and sales and revenue. Some places go as far as to think of their development organization as overhead, a cost center.
Isn't that what software development is all about. It's about collapsing this cloud of uncertainty into concrete deterministic expression a.k.a code, which only solves the problem as you understand it.
If software development were that measurable, software developers would be as well paid as CEOs or sales people. But we are not. Because there is no way to demonstrate almost any relationship between what we do on daily basis (stare at screen and type on the keyboard as management often sees it) and sales and revenue. Some places go as far as to think of their development organization as overhead, a cost center.
Measuring something in order to manage it does not automatically mean that the management consists of incentives or punishment - and if you don't do those things, people have no reason to game your measurements.
There most definitely are useful software metrics that can provide important information to management, mostly in the form of identifying problems and risks, which can then be adressed before they become urgent.
There most definitely are useful software metrics that can provide important information to management, mostly in the form of identifying problems and risks, which can then be adressed before they become urgent.
> how do you translate x number of new users per week into code
You talked about turning code into metrics, now you want to turn metrics into code?
It's the other way around. Scrum translates delivered code into metrics. You track history. You would say "last week we delivered 4 new features and signed up x new users. That's above our average." It's not entirely nebulous.
You talked about turning code into metrics, now you want to turn metrics into code?
It's the other way around. Scrum translates delivered code into metrics. You track history. You would say "last week we delivered 4 new features and signed up x new users. That's above our average." It's not entirely nebulous.
Is Agile (big A) really as "proven" as proponents make it out to be?
I'd love to see some citations in the form of "Product XYZ that you know and love is developed using Agile" as opposed to the usual "My cousin's friend's brother's girlfriend used Agile for an internal CRUD tool and it went totally great".
In the real world, the few times I've worked at places that attempted Agile (Scrum both times) I've only seen Agile fail miserably.
I'd love to see some citations in the form of "Product XYZ that you know and love is developed using Agile" as opposed to the usual "My cousin's friend's brother's girlfriend used Agile for an internal CRUD tool and it went totally great".
In the real world, the few times I've worked at places that attempted Agile (Scrum both times) I've only seen Agile fail miserably.
I would like to add one thing to that: Process is necessary, but it should never be the solution.
This is where people tend to wrong at the very start. Any attempt to implement Agile (or any other method) with the illusion that process can solve the problem will always go horrible wrong.
This is where people tend to wrong at the very start. Any attempt to implement Agile (or any other method) with the illusion that process can solve the problem will always go horrible wrong.
Process is, actually, just tax. If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
Discipline is just a tax. If you need to structure and test your code, then you're a mediocre coder at best, and so is your work and project. Just write whatever you feel like, it'll turn out ok. You're awesome, how could you possibly code anything less than exactly what the client wants?
Nonsense. Agile is a discipline, just like properly structuring your code and testing it. It's discipline at a macro scale, on the team, rather than the individual programmer. You might argue over whether its specific practices are better or worse than other methods, but arguing against any development process at all is absurd.
Discipline is just a tax. If you need to structure and test your code, then you're a mediocre coder at best, and so is your work and project. Just write whatever you feel like, it'll turn out ok. You're awesome, how could you possibly code anything less than exactly what the client wants?
Nonsense. Agile is a discipline, just like properly structuring your code and testing it. It's discipline at a macro scale, on the team, rather than the individual programmer. You might argue over whether its specific practices are better or worse than other methods, but arguing against any development process at all is absurd.
The problem with Agile development is the same problem that has affected many modern revolutions: The revolution against the current ruling class gets co-opted by the current ruling class[1]. The revolution then ends up changing nothing more meaningful than the colors on the flag.
Agile was supposed to help developers escape the obstacles of poor management and poor managers. It's really about developers owning the development of the software, and being given more creative authority. Non-developers play a support role, if they're present at all. That part is all fine and dandy, and it's The Good Part® of agile. Let the guys who make software be responsible for making software. Brilliant!
Managers, of course, don't want to get marginalized. If they see a movement towards Agile, they would rather bring it in themselves, so that they can control how it's implemented. And they implement it in a way that a) fits their existing biases about software development b) doesn't marginalize themselves[2]. Both of those goals are met by taking the agile process, and turning into The Agile Process (engraved on stone tablets, up on a pedestal).
Agile should be less process, but when the transition is implemented by process guys, it just ends up being different process rather than less. And naturally, the one role in agile that ex-managers can step into (aforementioned support role) is more important in this set-up, because it's about owning and managing the process. So the revolution happens, and nothing changes. Instead of developers having more freedom, the old managers just have a new title. That title still comes with the authority to make developers fall in line, except that "in line" now refers to a different set-in-stone collection of steps and rules.
tl;dr Meet the new boss, same as the old boss.
[1] I'd rather not derail this thread into history and politics so I'm avoiding details.
[2] b) is actually a subset of a). One of management's existing biases is that management and process is an important part of software development.
This isn't a knock of managers; everyone thinks the same about themselves. Hell, Agile itself basically originates from developers having the same bias. They just happen to be more correct ;).
Agile was supposed to help developers escape the obstacles of poor management and poor managers. It's really about developers owning the development of the software, and being given more creative authority. Non-developers play a support role, if they're present at all. That part is all fine and dandy, and it's The Good Part® of agile. Let the guys who make software be responsible for making software. Brilliant!
Managers, of course, don't want to get marginalized. If they see a movement towards Agile, they would rather bring it in themselves, so that they can control how it's implemented. And they implement it in a way that a) fits their existing biases about software development b) doesn't marginalize themselves[2]. Both of those goals are met by taking the agile process, and turning into The Agile Process (engraved on stone tablets, up on a pedestal).
Agile should be less process, but when the transition is implemented by process guys, it just ends up being different process rather than less. And naturally, the one role in agile that ex-managers can step into (aforementioned support role) is more important in this set-up, because it's about owning and managing the process. So the revolution happens, and nothing changes. Instead of developers having more freedom, the old managers just have a new title. That title still comes with the authority to make developers fall in line, except that "in line" now refers to a different set-in-stone collection of steps and rules.
tl;dr Meet the new boss, same as the old boss.
[1] I'd rather not derail this thread into history and politics so I'm avoiding details.
[2] b) is actually a subset of a). One of management's existing biases is that management and process is an important part of software development.
This isn't a knock of managers; everyone thinks the same about themselves. Hell, Agile itself basically originates from developers having the same bias. They just happen to be more correct ;).
"Agile is not a silver bullet" is more to the point, and applying it dogmatically can counterproductive.
But regular communication, short, well defined sprints and a prioritized backlog available to all can do wonders in terms of getting a small amount of stuff done rather than a large amount half done.
But regular communication, short, well defined sprints and a prioritized backlog available to all can do wonders in terms of getting a small amount of stuff done rather than a large amount half done.
Agree with this 100%. Transparency and communication are key when you have more than one or two people on a team.
Well, agile and TDD (not necessarily together) are good for two kinds of projects.
(1) If you're building simple web apps for small town clients in a framework like RoR, you can break things into little tasks and estimate with laser-like accuracy. This fits in great with an agile methodology
(2) If you're writing security-sensitive string parsing code or any algorithms with tricky components, TDD is a big win. When I was in grad school I converted a very slow program for solving a quantum system (worked for N=5) into a very fast program (worked for N=64) by building very detailed test scaffolding. I don't know if I could have built the fast but complicated app without the tests.
Now, I've got another app where I almost want to use TDD but I'd wind up building a whole Potempkin village of mock objects and I just can't bear the line count I'd need to first write it all, find bugs in, and then maintain.
(1) If you're building simple web apps for small town clients in a framework like RoR, you can break things into little tasks and estimate with laser-like accuracy. This fits in great with an agile methodology
(2) If you're writing security-sensitive string parsing code or any algorithms with tricky components, TDD is a big win. When I was in grad school I converted a very slow program for solving a quantum system (worked for N=5) into a very fast program (worked for N=64) by building very detailed test scaffolding. I don't know if I could have built the fast but complicated app without the tests.
Now, I've got another app where I almost want to use TDD but I'd wind up building a whole Potempkin village of mock objects and I just can't bear the line count I'd need to first write it all, find bugs in, and then maintain.
You're wrong on both accounts:
(1) Being able to estimate with laser-like accuracy is not part of what's agile. Estimation is not part of the agile manifesto at all - Kanban for example can be done without a single estimate. It just limits the number of tasks that you have in parallel. Scrum on the other hand does deal with estimates, but it mainly postulates that you can't estimate large chunks of work at all and small chunks not necessarily correct. So there are all kinds of observed correction metrics built in that help you to get a better estimate - no one vouches for a correct one though.
(2) If you can't use TDD because you have to build a whole set of mock object you might have a tightly coupled system. Writing a test is not dead line count, it helps to formulate boundary conditions and expected behavior. It's certainly not useful for all kinds of project but it's certainly not limited to security sensitive or tricky algorithms. If the behavior is simple, then the test is simple as well. If the behavior is complicated, then the test will be as well - but at least you'll think about how it is supposed to be.
(1) Being able to estimate with laser-like accuracy is not part of what's agile. Estimation is not part of the agile manifesto at all - Kanban for example can be done without a single estimate. It just limits the number of tasks that you have in parallel. Scrum on the other hand does deal with estimates, but it mainly postulates that you can't estimate large chunks of work at all and small chunks not necessarily correct. So there are all kinds of observed correction metrics built in that help you to get a better estimate - no one vouches for a correct one though.
(2) If you can't use TDD because you have to build a whole set of mock object you might have a tightly coupled system. Writing a test is not dead line count, it helps to formulate boundary conditions and expected behavior. It's certainly not useful for all kinds of project but it's certainly not limited to security sensitive or tricky algorithms. If the behavior is simple, then the test is simple as well. If the behavior is complicated, then the test will be as well - but at least you'll think about how it is supposed to be.
My own "agile" process for certain kinds of development involves breaking down all tasks to less than an hour and estimating time to 10 minute granularity and planning on weekly releases.
For boring web apps built on the right framework I find this keeps everybody very happy. Devs aren't chasing their tails, you can make and keep promises to the client, etc.
Of course you've got to be building the kind of app where there aren't surprises, but those exist.
As for the other project, the whole thing is a machine where you put a 600 million fact knowledge base in one end and it manufactures 'potempkin villages' (little knowledge bubbles about particular domains w.r.t a point of view) on the other end. Once it's done, I could use it to generate micro test cases for the rest of the system, but in the short term that doesn't bring in revenue or delight customers.
For boring web apps built on the right framework I find this keeps everybody very happy. Devs aren't chasing their tails, you can make and keep promises to the client, etc.
Of course you've got to be building the kind of app where there aren't surprises, but those exist.
As for the other project, the whole thing is a machine where you put a 600 million fact knowledge base in one end and it manufactures 'potempkin villages' (little knowledge bubbles about particular domains w.r.t a point of view) on the other end. Once it's done, I could use it to generate micro test cases for the rest of the system, but in the short term that doesn't bring in revenue or delight customers.
I dunno. In a way I think he is right in some ways in that most of the times people say they are doing agile or scrum it is a sham and they are not really doing agile and also it generally doesn't tell you much about how well they work.
Also I think that process can very easily get in the way. I was actually thinking maybe things would work better for small teams if you just handled everything in a group chat room with a history like campfire.
But I still have hope that someday I'm actually going to use TDD for a project and then have way fewer regressions to deal with. Still haven't had the discipline I guess to really learn and apply TDD after all these years although I have sort of done it a little a few times.
And also a few other things like short iterations and getting the simplest useful software going which I always thought were part of agile, those things help. Although it has always been a battle for me to get managers or even users to stop adding features and do an initial release so I haven't been very successful in that aspect.
I don't know if the quality the individuals on the team is everything but it is a good point that it is probably more important than anything.
I also would really like to believe that having a real QA team as part of the process would improve things, although I have never had that luxury either so it may be a false hope. But that would be something in the process category.
Also I think that process can very easily get in the way. I was actually thinking maybe things would work better for small teams if you just handled everything in a group chat room with a history like campfire.
But I still have hope that someday I'm actually going to use TDD for a project and then have way fewer regressions to deal with. Still haven't had the discipline I guess to really learn and apply TDD after all these years although I have sort of done it a little a few times.
And also a few other things like short iterations and getting the simplest useful software going which I always thought were part of agile, those things help. Although it has always been a battle for me to get managers or even users to stop adding features and do an initial release so I haven't been very successful in that aspect.
I don't know if the quality the individuals on the team is everything but it is a good point that it is probably more important than anything.
I also would really like to believe that having a real QA team as part of the process would improve things, although I have never had that luxury either so it may be a false hope. But that would be something in the process category.
An agile process isn't just there to manage the developers, it's there to engage and manage the customer as well.
In my experience, customers rarely know exactly what they want out of a software project, large or small. Complicated documents, produced up front get ignored because of TL;DR and projects start on faulty specifications that describe a solution to illusory requirements. So, inevitably, there will be a disparity between documented requirements and the desired outcome.
Iterative delivery - a key feature of agile as I have experienced it - gives the customer multiple chances to try-out and feedback on working software along the way. Furthermore, by making the customer part of the solution early they are as instrumental as the implementers in ensuring the validity of the software and - therefore - the success of the project.
Incidentally, I think this is why many customers (internal and external) are suspicious of and hesitant to engage in a truly agile process. That is, they would become equally liable for the success of the project because of the decisions they are required to make. They are part of the solution and therefore potentially party to the blame for any failures. It's much safer for them to be more likely to fail and avoid the blame than it is to risk complicity in a failure, however less likely that failure might be as a result of the process.
What agile does that the author missed (or at least declined to mention) is that it gives a name to and formalises an approach that attempts to manage the customer as well as the implementers. It compensates for the fact that customers can't always be expected to fully understand their own requirements and for the inevitability that they change their minds.
In my experience, customers rarely know exactly what they want out of a software project, large or small. Complicated documents, produced up front get ignored because of TL;DR and projects start on faulty specifications that describe a solution to illusory requirements. So, inevitably, there will be a disparity between documented requirements and the desired outcome.
Iterative delivery - a key feature of agile as I have experienced it - gives the customer multiple chances to try-out and feedback on working software along the way. Furthermore, by making the customer part of the solution early they are as instrumental as the implementers in ensuring the validity of the software and - therefore - the success of the project.
Incidentally, I think this is why many customers (internal and external) are suspicious of and hesitant to engage in a truly agile process. That is, they would become equally liable for the success of the project because of the decisions they are required to make. They are part of the solution and therefore potentially party to the blame for any failures. It's much safer for them to be more likely to fail and avoid the blame than it is to risk complicity in a failure, however less likely that failure might be as a result of the process.
What agile does that the author missed (or at least declined to mention) is that it gives a name to and formalises an approach that attempts to manage the customer as well as the implementers. It compensates for the fact that customers can't always be expected to fully understand their own requirements and for the inevitability that they change their minds.
[Obligatory plug and disclaimer: Agile professional who wrote an earlier rant "Agile Ruined my Life" http://www.whattofix.com/blog/archives/2010/09/agile-ruined-... Also I am writing some practical how-to Agile e-books trying to undo some of the damage: http://tiny-giant-books.com/scrummaster.htm ]
Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely.
Agile is best practices around iterative and incremental development. Period. Yes, there's a manifesto and there's Scrum and all sorts of other things, but at the end of the day Agile is a marketing term. A place to go find out what people are trying in order to get better.
Two secrets here. One, team success is about 90% dependent on who is on the team. Good teams do well. Bad teams do poorly. But if you're going to have more than one team, you need some way to measure and talk about what they are doing, so you have to have something.
Agile -- when done correctly -- is just the minimum amount of something you need to get your work done. It is the minimum amount of process. After all, it's not like you can have no process at all. Whatever you're doing already is a process.
I've seen hundreds of teams struggle with Agile, and to me the problem is that we do a really bad job of balancing the difference between "here's a best practice that worked awesome for about 80% of the teams that tried it" and "These are the rules. You must do this." In many shops, Agile is just another way of micro-managing teams, sadly.
I can't help that. I also can't help the fact that lots of folks are out to make a buck on certifications and such. I don't think that makes Agile bad. Heck, I'm not even against certifications, although I'd never get one. I just think we take things too far.
I like the idea of having a marketing blurb "Agile" where I can go to find out what kinds of new stuff is being done. It helps me pick better reading material.
The second secret is that most teams, frankly, are not that good. So you need some kind of way to demonstrate that as well. Making things incrementally and in small iterations lets you see how bad teams are early on. You fail early and often. Then at least you have a bit of a shot at trying to help.
But believe me, I feel your pain. Sounds to me like you are a lot more upset at modern marketing and management attitudes than Agile. Remember that we technical folks have a way of over-doing whatever we get into, as I was writing in my blog before your post appeared! (It's still very strange to me watching HN how the same topic comes from multiple writers at the same time) http://tiny-giant-books.com/blog/agile-means-stop-focusing-o...
Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely.
Agile is best practices around iterative and incremental development. Period. Yes, there's a manifesto and there's Scrum and all sorts of other things, but at the end of the day Agile is a marketing term. A place to go find out what people are trying in order to get better.
Two secrets here. One, team success is about 90% dependent on who is on the team. Good teams do well. Bad teams do poorly. But if you're going to have more than one team, you need some way to measure and talk about what they are doing, so you have to have something.
Agile -- when done correctly -- is just the minimum amount of something you need to get your work done. It is the minimum amount of process. After all, it's not like you can have no process at all. Whatever you're doing already is a process.
I've seen hundreds of teams struggle with Agile, and to me the problem is that we do a really bad job of balancing the difference between "here's a best practice that worked awesome for about 80% of the teams that tried it" and "These are the rules. You must do this." In many shops, Agile is just another way of micro-managing teams, sadly.
I can't help that. I also can't help the fact that lots of folks are out to make a buck on certifications and such. I don't think that makes Agile bad. Heck, I'm not even against certifications, although I'd never get one. I just think we take things too far.
I like the idea of having a marketing blurb "Agile" where I can go to find out what kinds of new stuff is being done. It helps me pick better reading material.
The second secret is that most teams, frankly, are not that good. So you need some kind of way to demonstrate that as well. Making things incrementally and in small iterations lets you see how bad teams are early on. You fail early and often. Then at least you have a bit of a shot at trying to help.
But believe me, I feel your pain. Sounds to me like you are a lot more upset at modern marketing and management attitudes than Agile. Remember that we technical folks have a way of over-doing whatever we get into, as I was writing in my blog before your post appeared! (It's still very strange to me watching HN how the same topic comes from multiple writers at the same time) http://tiny-giant-books.com/blog/agile-means-stop-focusing-o...
Exactly. And this shit makes me furious.
I got involved with this stuff before the term "Agile" existed. At the beginning, it was a bunch of professionals (mostly developers) sincerely trying to find better ways of working. Extreme Programming, for example, came to be because the developers were really interested to experiment with how their team got stuff done.
It breaks my heart that in the ensuing decade it has turned into exactly the kind of bullshit, top-down, PHB-fluffing idiocy that early agilists were trying to get away from. If you look at the Agile Manifesto, the focus is supposed to be on a) people, b) shipping working software, c) collaboration, and d) being adaptable. That is sure not what it has become.
In my view, we made a crucial mistake: we didn't think about money and power enough. Now the Agile industry is 98% selling idiotic certifications and homeopathic doses of process improvement to organizations that don't really want to change anything at all.
Mad. It makes me mad. Sorry we screwed it up, everybody.
I got involved with this stuff before the term "Agile" existed. At the beginning, it was a bunch of professionals (mostly developers) sincerely trying to find better ways of working. Extreme Programming, for example, came to be because the developers were really interested to experiment with how their team got stuff done.
It breaks my heart that in the ensuing decade it has turned into exactly the kind of bullshit, top-down, PHB-fluffing idiocy that early agilists were trying to get away from. If you look at the Agile Manifesto, the focus is supposed to be on a) people, b) shipping working software, c) collaboration, and d) being adaptable. That is sure not what it has become.
In my view, we made a crucial mistake: we didn't think about money and power enough. Now the Agile industry is 98% selling idiotic certifications and homeopathic doses of process improvement to organizations that don't really want to change anything at all.
Mad. It makes me mad. Sorry we screwed it up, everybody.
The only people that screwed it up are the ones that monetized it. They made it
a) rigid based on their definition b) defined themselves as experts in making teams agile based on their rigid definition c) charged for it
PS. These same guys, once they couldn't squeeze anymore blood out of the Agile stone, moved onto a new marketing term, "craftsmanship". They now charge the same clients, even more money, to teach them this "new way of doing it ..... right".
Plus, they make a mint on the books they hastily write and push out.
I eagerly anticipate that successor to Craftsmanship.
a) rigid based on their definition b) defined themselves as experts in making teams agile based on their rigid definition c) charged for it
PS. These same guys, once they couldn't squeeze anymore blood out of the Agile stone, moved onto a new marketing term, "craftsmanship". They now charge the same clients, even more money, to teach them this "new way of doing it ..... right".
Plus, they make a mint on the books they hastily write and push out.
I eagerly anticipate that successor to Craftsmanship.
I disagree that craftsmanship is a replacement for agile. To me, being a software craftsman is more about how you write and structure code. Agile is about figuring out what the end product should be and how you get there.
I don't mean to imply they are the same.
I'm reflecting on how the same "agile experts that sell/sold their services" quickly abandoned selling that and moved onto selling "craftsmanship" once their Agile well dried up.
cough Bob Martin cough cough Object Mentor cough
I'm reflecting on how the same "agile experts that sell/sold their services" quickly abandoned selling that and moved onto selling "craftsmanship" once their Agile well dried up.
cough Bob Martin cough cough Object Mentor cough
Depends on who you're talking about here. Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better. I'm not sure about who's cropped up lately, though.
Also, it's very, very rare for somebody to make a mint on a software book. I've talked with a number of authors, and their universal view is that writing code pays much better than writing a book. You do it because you have something to say, not because you want to get rich.
Also, it's very, very rare for somebody to make a mint on a software book. I've talked with a number of authors, and their universal view is that writing code pays much better than writing a book. You do it because you have something to say, not because you want to get rich.
> Bob Martin one of the craftsmanship people, is very sincere in his desire to make the field better.
Unfortunately, you can be totally sincere in your good intentions, and yet still repeatedly be wrong. When you are a high profile figure who presumes to advise others on the best ways to do their job, that makes you a liability.
It's a shame. Some of Bob Martin's earlier work exploring OO and the SOLID principles was quite decent stuff. But I think it's obvious at this point that he and several of his colleagues at Object Mentor have collectively lost the plot.
Unfortunately, you can be totally sincere in your good intentions, and yet still repeatedly be wrong. When you are a high profile figure who presumes to advise others on the best ways to do their job, that makes you a liability.
It's a shame. Some of Bob Martin's earlier work exploring OO and the SOLID principles was quite decent stuff. But I think it's obvious at this point that he and several of his colleagues at Object Mentor have collectively lost the plot.
Could be. I guess I'm not aware of the repeated wrongness on ObjectMentor's part. Got links?
The big problems I saw, though, came from people who weren't particularly sincere. They were happy to sell whatever large companies were buying. E.g., two-day "Scrum Master" courses and a splash of Agile holy water to bless whatever top-down idiocy a company was already engaging in.
The big problems I saw, though, came from people who weren't particularly sincere. They were happy to sell whatever large companies were buying. E.g., two-day "Scrum Master" courses and a splash of Agile holy water to bless whatever top-down idiocy a company was already engaging in.
At this point, a comprehensive critique of Object Mentor would be more a case of writing a book than posting a few links. However, in the interests of not attacking them completely without justification:
- Object Mentor are big advocates of XP. The fundamental principle of XP is that a certain practice is good, then doing more of it must be better. There is no logic in that position at all, and it doesn't stand up to even cursory criticism. Moreover, if XP is as superior to other processes as the typical advocacy quotes and statistics imply, how come organisations using XP aren't consistently reporting dramatically better measurable results and how come so few software development groups have chosen to adopt it? Sooner or later, people notice that the emperor has no clothes. (I suspect this is why we now have Software Craftsmanship: it's a new positive-sounding but conveniently meaningless marketing term to pitch to clients.)
- Bob Martin has repeatedly stated that anyone who doesn't do TDD is unprofessional. Safety-critical software is typically not developed using TDD; in fact, formal methods, BUFD, and other very much not Agile processes are often used in such fields.
- Michael Feathers redefined the term "legacy code" in terms of unit tests. There are decades of research studying what actually causes a project to decay to the point that it is difficult to maintain and update. To my knowledge, a lack of unit tests has not yet been cited as a causal factor by any paper on the subject. (FWIW, I do think Feathers' book on the subject offered some interesting and worthwhile ideas, I just don't accept his premise that having unit tests is what defines whether code is legacy or not for practical maintenance/project management purposes. I think when you try to co-opt an ill-defined but commonly understood term and give it a formal definition that is very different to the mainstream concept, you lose some credibility.)
- Brett Schuchert, a man writing a book on C++, managed to make "Hello, world" take five source files and a makefile totalling nearly 100 lines, using TDD of course.
- Ron Jeffries. Sudoku. Probably enough said. TDD is not an alternative to understanding the problem and how you're going to solve it.
- From a post on the Object Mentor blog, Brett Schuchert apparently advocates pair programming based on a 1975 study of something involving two-person teams, a ten-year-old study of university students, and a couple of links to secondary sources. The original research for almost every one of the primary sources he appeals to either directly or indirectly is no longer available at the cited links less than 18 months later.
- Bob Martin thinks there are no more new kinds of programming language left to find. That's roughly on par with equating Haskell and Brainfuck because they're both Turing complete, and shows a complete lack of awareness of the state of the art.
- When it comes to the amount of up-front design and formal architecture that makes sense for a project, the amount of retconning in recent comments from the TDD guys is laughable. There was a particular interview featuring Bob Martin and Jim Coplien a couple of years back that was almost painful to watch.
I could go on, but if that lot doesn't paint a clear enough picture for anyone reading this, I don't have a powerful enough Kool-Aid antidote to help them.
I do agree with you about the insincerity. That's worse in theory, but unfortunately it's probably no less damaging in practice.
Edit: Here are few links to support some of the points above.
http://www.infoq.com/interviews/coplien-martin-tdd
http://skillsmatter.com/podcast/agile-testing/bobs-last-lang...
http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku...
http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp
http://blog.objectmentor.com/articles/2010/11/09/info-please...
- Object Mentor are big advocates of XP. The fundamental principle of XP is that a certain practice is good, then doing more of it must be better. There is no logic in that position at all, and it doesn't stand up to even cursory criticism. Moreover, if XP is as superior to other processes as the typical advocacy quotes and statistics imply, how come organisations using XP aren't consistently reporting dramatically better measurable results and how come so few software development groups have chosen to adopt it? Sooner or later, people notice that the emperor has no clothes. (I suspect this is why we now have Software Craftsmanship: it's a new positive-sounding but conveniently meaningless marketing term to pitch to clients.)
- Bob Martin has repeatedly stated that anyone who doesn't do TDD is unprofessional. Safety-critical software is typically not developed using TDD; in fact, formal methods, BUFD, and other very much not Agile processes are often used in such fields.
- Michael Feathers redefined the term "legacy code" in terms of unit tests. There are decades of research studying what actually causes a project to decay to the point that it is difficult to maintain and update. To my knowledge, a lack of unit tests has not yet been cited as a causal factor by any paper on the subject. (FWIW, I do think Feathers' book on the subject offered some interesting and worthwhile ideas, I just don't accept his premise that having unit tests is what defines whether code is legacy or not for practical maintenance/project management purposes. I think when you try to co-opt an ill-defined but commonly understood term and give it a formal definition that is very different to the mainstream concept, you lose some credibility.)
- Brett Schuchert, a man writing a book on C++, managed to make "Hello, world" take five source files and a makefile totalling nearly 100 lines, using TDD of course.
- Ron Jeffries. Sudoku. Probably enough said. TDD is not an alternative to understanding the problem and how you're going to solve it.
- From a post on the Object Mentor blog, Brett Schuchert apparently advocates pair programming based on a 1975 study of something involving two-person teams, a ten-year-old study of university students, and a couple of links to secondary sources. The original research for almost every one of the primary sources he appeals to either directly or indirectly is no longer available at the cited links less than 18 months later.
- Bob Martin thinks there are no more new kinds of programming language left to find. That's roughly on par with equating Haskell and Brainfuck because they're both Turing complete, and shows a complete lack of awareness of the state of the art.
- When it comes to the amount of up-front design and formal architecture that makes sense for a project, the amount of retconning in recent comments from the TDD guys is laughable. There was a particular interview featuring Bob Martin and Jim Coplien a couple of years back that was almost painful to watch.
I could go on, but if that lot doesn't paint a clear enough picture for anyone reading this, I don't have a powerful enough Kool-Aid antidote to help them.
I do agree with you about the insincerity. That's worse in theory, but unfortunately it's probably no less damaging in practice.
Edit: Here are few links to support some of the points above.
http://www.infoq.com/interviews/coplien-martin-tdd
http://skillsmatter.com/podcast/agile-testing/bobs-last-lang...
http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku...
http://schuchert.wikispaces.com/Tdd.HelloWorld.Cpp
http://blog.objectmentor.com/articles/2010/11/09/info-please...
You start out with a giant misunderstanding, which makes it hard for me to take the rest of your complaints seriously. Extreme Programming is not an arbitrary desire to turn all the knobs you can find to 11. It started as a question: what happens if we take certain practices that are good and do them more intensely? E.g. if some testing is good, what if we test pretty much everything?
That team found that they really liked turning particular practices way up. But you can't turn all the knobs up, so you are implicitly turning others down. E.g., if you turn up iteration speed, then you are turning down the sort of heavyweight waterfall requirements process ubiquitous at the time.
So the "extreme" was a way to explore the space of possible processes, not any sort of fundamental principle. Teams trying XP are explicitly encouraged to experiment similarly. I sure have; the process we use is derived from XP but departs from it in a number of areas.
I think a lot of the rest of your points are similar misunderstandings along with some cherry picking. E.g., the OM blog post on pairing. He said that people sometimes asked him for basic background materials, so he posted some links. To go from that to "Brett Schuchert apparently advocates pair programming based on.." is either very poor reading comprehension or the act of somebody with an axe to grind.
As to not doing TDD being unprofessional, I'd generally agree. I tried TDD first in 2001, and have worked on a number of code bases since. For any significant code base that's meant to last and be maintainable, I think it's irresponsible to not have a good unit test suite. I also think there's no more efficient way to get a solid suite than TDD.
If you (or anybody) wants to discuss this further, probably better to email me; that's easy to find from my profile.
That team found that they really liked turning particular practices way up. But you can't turn all the knobs up, so you are implicitly turning others down. E.g., if you turn up iteration speed, then you are turning down the sort of heavyweight waterfall requirements process ubiquitous at the time.
So the "extreme" was a way to explore the space of possible processes, not any sort of fundamental principle. Teams trying XP are explicitly encouraged to experiment similarly. I sure have; the process we use is derived from XP but departs from it in a number of areas.
I think a lot of the rest of your points are similar misunderstandings along with some cherry picking. E.g., the OM blog post on pairing. He said that people sometimes asked him for basic background materials, so he posted some links. To go from that to "Brett Schuchert apparently advocates pair programming based on.." is either very poor reading comprehension or the act of somebody with an axe to grind.
As to not doing TDD being unprofessional, I'd generally agree. I tried TDD first in 2001, and have worked on a number of code bases since. For any significant code base that's meant to last and be maintainable, I think it's irresponsible to not have a good unit test suite. I also think there's no more efficient way to get a solid suite than TDD.
If you (or anybody) wants to discuss this further, probably better to email me; that's easy to find from my profile.
Extreme Programming is not an arbitrary desire to turn all the knobs you can find to 11. It started as a question: what happens if we take certain practices that are good and do them more intensely? E.g. if some testing is good, what if we test pretty much everything? That team found that they really liked turning particular practices way up.
Well, of course they're entitled to their opinion, but that's all it is: an opinion. An argument that if some testing is good then test-driving everything must be better, or that if code review is good then full-time review via pair programming must be better, has no basis in logic. And those kinds of arguments go right back to the original book by Kent Beck, and they have been propagated by the XP consultancy crowd from the top right on down ever since.
IMHO, if a trainer is going to go around telling people that if they don't program a certain way then they are unprofessional, then that trainer had better have rock solid empirical data to back up his position. Maybe as you say, I do have a giant misunderstanding, and in fact Object Mentor do make their case based on robust evidence rather than the sort of illogical arguments I've mentioned. In that case, I assume you can cite plenty of examples of this evidence-based approach in their published work, so we can all see it for ourselves. Go ahead; I'll wait.
I think a lot of the rest of your points are similar misunderstandings along with some cherry picking. E.g., the OM blog post on pairing. He said that people sometimes asked him for basic background materials, so he posted some links. To go from that to "Brett Schuchert apparently advocates pair programming based on.." is either very poor reading comprehension or the act of somebody with an axe to grind.
This is a consultant who presumes to tell others how to do their job, openly posting asking for any source material from others to back up his predetermined position, and then claiming in almost the very next sentence to favour material based on research or experience. He says that the links he gave (the ones where much of the original research is either clearly based on flawed-at-best methodologies or simply not there at all any more) are things he often cites. And he gives no indication, either in that post or anywhere else that I have seen, of having any library of other links to reports of properly conducted studies that support his position. I don't think criticism based on this kind of post is cherry-picking at all, but of course if it is then again you should have no difficulty citing lots of other material from the same consultant that is of better quality and supported by more robust evidence, to demonstrate how the post I picked on was an outlier.
The same goes for any of my other points. If you think I'm cherry-picking, all you have to do to prove it is give a few other examples that refute my point and show that the case I picked on was the exception and not the rule. If you can't do that -- and whether or not you choose to continue the debate here, you know whether you can do that -- then I think you have to accept that I'm not really cherry-picking at all.
As to not doing TDD being unprofessional, I'd generally agree. I tried TDD first in 2001, and have worked on a number of code bases since. For any significant code base that's meant to last and be maintainable, I think it's irresponsible to not have a good unit test suite. I also think there's no more efficient way to get a solid suite than TDD.
Please note that I'm not disputing that an automated unit test suite can be a useful tool. On the contrary, in many contexts I think unit testing is valuable, and I have seen plenty of research that support such a conclusion more widely than my inevitably limited personal experience.
On the other hand, I don't accept your premise about TDD. For one thing, TDD implies a lot more than merely the creation of unit tests. Among other things, I've worked on projects where bugs really could result in very bad things happening. You don't build that sort of software by trial and error. You have a very clear statement of requirements before you start, and you have a rigorous change request process if those requirements need to be updated over time. You might have formal models of your entire system, in which case you analyse your requirements and determine how to meet them at that level before you even start writing code. At the very least, you probably have your data structures and algorithms worked out in advance, and you get them peer reviewed, possibly by several reviewers looking from different perspectives. Your quality processes probably do involve some sort of formal code review and/or active walkthrough after the code is done, too.
If you came into an environment like that, and claimed that the only "professional" thing to do was to skip all that formal specification and up-front design and systematic modelling and structured peer review, and instead to make up a few test cases as you went along and trust that your code was OK as long as it passed them all, you would be laughed out of the building five minutes later. If you suggested that working in real time with one other developer was a substitute for independent peer review at a distance, they'd just chuck you right out the window to save time.
TDD is not an alternative to understanding the underlying problem you're trying to solve and knowing how to solve it. A test suite is not a substitute for a specification. Pair programming is not a substitute for formal peer review. They never have been, and they never can be.
I haven't gone into it here, but of course there are other areas where TDD simply doesn't work either. Unit testing is at its best when you're working with pure code and discrete inputs and outputs. It's much harder to TDD an algorithm with a continuous input and/or output space. Tell me, how would you test-drive a medical rendering system, which accepts data from a scanner and is required to display a 3D visualisation of parts of a human body based on the readings? Even if this particular example weren't potentially safety-critical, how would you even start to test-drive code where the input consists of thousands of data points, the processing consists of running complex algorithms to compute many more pieces of data, and the observable output is a visualisation of that computed data that varies in real time as the operator moves their "camera" around?
If you (or anybody) wants to discuss this further, probably better to email me; that's easy to find from my profile.
I appreciate the offer, but I prefer to keep debates that start on a public forum out in the open. That way everyone reading can examine any evidence provided for themselves and draw their own conclusions about which positions stand up to scrutiny.
Well, of course they're entitled to their opinion, but that's all it is: an opinion. An argument that if some testing is good then test-driving everything must be better, or that if code review is good then full-time review via pair programming must be better, has no basis in logic. And those kinds of arguments go right back to the original book by Kent Beck, and they have been propagated by the XP consultancy crowd from the top right on down ever since.
IMHO, if a trainer is going to go around telling people that if they don't program a certain way then they are unprofessional, then that trainer had better have rock solid empirical data to back up his position. Maybe as you say, I do have a giant misunderstanding, and in fact Object Mentor do make their case based on robust evidence rather than the sort of illogical arguments I've mentioned. In that case, I assume you can cite plenty of examples of this evidence-based approach in their published work, so we can all see it for ourselves. Go ahead; I'll wait.
I think a lot of the rest of your points are similar misunderstandings along with some cherry picking. E.g., the OM blog post on pairing. He said that people sometimes asked him for basic background materials, so he posted some links. To go from that to "Brett Schuchert apparently advocates pair programming based on.." is either very poor reading comprehension or the act of somebody with an axe to grind.
This is a consultant who presumes to tell others how to do their job, openly posting asking for any source material from others to back up his predetermined position, and then claiming in almost the very next sentence to favour material based on research or experience. He says that the links he gave (the ones where much of the original research is either clearly based on flawed-at-best methodologies or simply not there at all any more) are things he often cites. And he gives no indication, either in that post or anywhere else that I have seen, of having any library of other links to reports of properly conducted studies that support his position. I don't think criticism based on this kind of post is cherry-picking at all, but of course if it is then again you should have no difficulty citing lots of other material from the same consultant that is of better quality and supported by more robust evidence, to demonstrate how the post I picked on was an outlier.
The same goes for any of my other points. If you think I'm cherry-picking, all you have to do to prove it is give a few other examples that refute my point and show that the case I picked on was the exception and not the rule. If you can't do that -- and whether or not you choose to continue the debate here, you know whether you can do that -- then I think you have to accept that I'm not really cherry-picking at all.
As to not doing TDD being unprofessional, I'd generally agree. I tried TDD first in 2001, and have worked on a number of code bases since. For any significant code base that's meant to last and be maintainable, I think it's irresponsible to not have a good unit test suite. I also think there's no more efficient way to get a solid suite than TDD.
Please note that I'm not disputing that an automated unit test suite can be a useful tool. On the contrary, in many contexts I think unit testing is valuable, and I have seen plenty of research that support such a conclusion more widely than my inevitably limited personal experience.
On the other hand, I don't accept your premise about TDD. For one thing, TDD implies a lot more than merely the creation of unit tests. Among other things, I've worked on projects where bugs really could result in very bad things happening. You don't build that sort of software by trial and error. You have a very clear statement of requirements before you start, and you have a rigorous change request process if those requirements need to be updated over time. You might have formal models of your entire system, in which case you analyse your requirements and determine how to meet them at that level before you even start writing code. At the very least, you probably have your data structures and algorithms worked out in advance, and you get them peer reviewed, possibly by several reviewers looking from different perspectives. Your quality processes probably do involve some sort of formal code review and/or active walkthrough after the code is done, too.
If you came into an environment like that, and claimed that the only "professional" thing to do was to skip all that formal specification and up-front design and systematic modelling and structured peer review, and instead to make up a few test cases as you went along and trust that your code was OK as long as it passed them all, you would be laughed out of the building five minutes later. If you suggested that working in real time with one other developer was a substitute for independent peer review at a distance, they'd just chuck you right out the window to save time.
TDD is not an alternative to understanding the underlying problem you're trying to solve and knowing how to solve it. A test suite is not a substitute for a specification. Pair programming is not a substitute for formal peer review. They never have been, and they never can be.
I haven't gone into it here, but of course there are other areas where TDD simply doesn't work either. Unit testing is at its best when you're working with pure code and discrete inputs and outputs. It's much harder to TDD an algorithm with a continuous input and/or output space. Tell me, how would you test-drive a medical rendering system, which accepts data from a scanner and is required to display a 3D visualisation of parts of a human body based on the readings? Even if this particular example weren't potentially safety-critical, how would you even start to test-drive code where the input consists of thousands of data points, the processing consists of running complex algorithms to compute many more pieces of data, and the observable output is a visualisation of that computed data that varies in real time as the operator moves their "camera" around?
If you (or anybody) wants to discuss this further, probably better to email me; that's easy to find from my profile.
I appreciate the offer, but I prefer to keep debates that start on a public forum out in the open. That way everyone reading can examine any evidence provided for themselves and draw their own conclusions about which positions stand up to scrutiny.
An argument that if some testing is good then test-driving everything must be better, or that if code review is good then full-time review via pair programming must be better, has no basis in logic.
That's not the argument at all. That is, as I just said, the reason they decided to try that. Their reasons for continuing to do it and further to recommend it are entirely different.
[...] better have rock solid empirical data [...]
You do realize that almost everything that goes on in the industry is not based on rock-solid empirical evidence, right? And also, that you're privileging an arbitrary historical accident by saying that new thing X has to have evidence when the common practice doesn't?
If you came into an environment like that, and only "professional" thing to do was to [...] make up a few test cases as you went along and trust that your code was OK [...]
That is not something I have ever heard any Object Mentor person say, and it's not something I said. It's so far from what I've ever heard somebody like Bob Martin or Kent Beck say that your misunderstanding is so dramatic that I have a hard time believing it's not willful.
I prefer to keep debates that start on a public forum out in the open.
Well, I'm not trying to have a debate. If you'd like to have one, you'll have to do it without me.
That's not the argument at all. That is, as I just said, the reason they decided to try that. Their reasons for continuing to do it and further to recommend it are entirely different.
[...] better have rock solid empirical data [...]
You do realize that almost everything that goes on in the industry is not based on rock-solid empirical evidence, right? And also, that you're privileging an arbitrary historical accident by saying that new thing X has to have evidence when the common practice doesn't?
If you came into an environment like that, and only "professional" thing to do was to [...] make up a few test cases as you went along and trust that your code was OK [...]
That is not something I have ever heard any Object Mentor person say, and it's not something I said. It's so far from what I've ever heard somebody like Bob Martin or Kent Beck say that your misunderstanding is so dramatic that I have a hard time believing it's not willful.
I prefer to keep debates that start on a public forum out in the open.
Well, I'm not trying to have a debate. If you'd like to have one, you'll have to do it without me.
Their reasons for continuing to do it and further to recommend it are entirely different.
So you keep saying. The problem is, almost everything Object Mentor advocate does seem to be based on some combination of their personal experience and pure faith. I object to someone telling me that my colleagues and I are "unprofessional" because we happen to believe differently, particularly when we do have measurable data that shows our performance is significantly better than the industry average.
You do realize that almost everything that goes on in the industry is not based on rock-solid empirical evidence, right?
That may be so, but most people in the industry aren't telling me how to do my job, and insulting me for not believing the same things they do.
That is not something I have ever heard any Object Mentor person say, and it's not something I said.
Good for you. XP consultants have been making essentially that argument, in public, for many years. TDD without any planning ahead is inherently a trial-and-error approach, which fails spectacularly in the absence of understanding as Jeffries so wonderfully demonstrated. Plenty of consultants -- including some of those from Object Mentor -- have given various arbitrary amounts of time they think you should spend on forward planning before you dive into TDD and writing real code, and often those periods have been as short as half an hour. You may choose not to believe that if you wish. I'm not sure even they really believe it any more, as they've backpeddled and weasel-worded and retconned that whole issue repeatedly in their recent work. But I've read the articles and watched the videos and sat in the conference presentations and heard them make an argument with literally no more substance than what I wrote there.
You keep saying that I'm misunderstanding or cherry-picking evidence. Perhaps that is so and I really am missing something important in this whole discussion. However, as far as I can see, throughout this entire thread you haven't actually provided a single counterexample or alternative interpretation of the advice that consultants like those at Object Mentor routinely and publicly give. You're just saying I'm wrong, because, and there's not really anything I can say to answer that.
So you keep saying. The problem is, almost everything Object Mentor advocate does seem to be based on some combination of their personal experience and pure faith. I object to someone telling me that my colleagues and I are "unprofessional" because we happen to believe differently, particularly when we do have measurable data that shows our performance is significantly better than the industry average.
You do realize that almost everything that goes on in the industry is not based on rock-solid empirical evidence, right?
That may be so, but most people in the industry aren't telling me how to do my job, and insulting me for not believing the same things they do.
That is not something I have ever heard any Object Mentor person say, and it's not something I said.
Good for you. XP consultants have been making essentially that argument, in public, for many years. TDD without any planning ahead is inherently a trial-and-error approach, which fails spectacularly in the absence of understanding as Jeffries so wonderfully demonstrated. Plenty of consultants -- including some of those from Object Mentor -- have given various arbitrary amounts of time they think you should spend on forward planning before you dive into TDD and writing real code, and often those periods have been as short as half an hour. You may choose not to believe that if you wish. I'm not sure even they really believe it any more, as they've backpeddled and weasel-worded and retconned that whole issue repeatedly in their recent work. But I've read the articles and watched the videos and sat in the conference presentations and heard them make an argument with literally no more substance than what I wrote there.
You keep saying that I'm misunderstanding or cherry-picking evidence. Perhaps that is so and I really am missing something important in this whole discussion. However, as far as I can see, throughout this entire thread you haven't actually provided a single counterexample or alternative interpretation of the advice that consultants like those at Object Mentor routinely and publicly give. You're just saying I'm wrong, because, and there's not really anything I can say to answer that.
That's because you're trying to have a debate with the Object Mentor guys rather than a discussion with me. Your problem with them isn't my problem, and neither are your misunderstandings. It is not my job to argue you into a better understanding of something you clearly can't stand.
Thx for putting the effort into this long reply, I've enjoyed reading it
Definitely matches my experience.
And let me just leave this here... http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.htm...
And let me just leave this here... http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.htm...
Would you have the same opinion about the PMI and the ecosystem built to support PMP certifications?
More so, even.
I could not possibly agree more.
Like many early Agile adopters I have been shocked and saddened by what it has become. I think the problem is that brainfucked corporate IT programmers (Java, .NET, whatever) have jumped on the bandwagon and driven it into the sea.
I was recently smacked around the head by this in a meeting about how a team was going to implement Jira ticketing to help improve their development process. I am not sure entirely what I was expecting, but I was totally, totally unprepared for the mind-stunning crap that I got - an endless series of slides of things called "workflows" which apparently document the life-cycle of a ticket and need to be mapped out in excruciating gory detail. I decided to raise my hand and ask a simple question "how do I just raise a ticket and assign it to someone" - the presenter gave me this kind of stunned "why would you want to do that??" look and explained that it doesn't work that way, first you need to assign everyone into teams and roles (like tester, developer etc), and then the workflow will decide where the ticket goes based on the kind of ticket and it's status. Mind blown. I could almost appreciate how such system might be of use on a really large project where you don't know and interact with most project members directly - they had a team of 8 people including testers and analysts. And in their minds they were doing Agile.
In another case I was arguing for the use of the Jira Fisheye plugin to enable meaningful access to VC to enable things like code review and release diffs and the like. The so called "Agile practitioners" had a different idea however - they were keen on a different plugin called Greenhopper which apparently does Agile process management and the like. I knew something was wrong when it was mentioned that it does nice Gantt charts. I probed a little deeper into why they didn't see the value in Fisheye and found that their actual VC practices were a joke - ludicrously large commits with minimal comment just before a release, no consistent release tags, broken commit history (they seemed to be deleting and re-creating their trunk after every release...what I don't even...). Advanced process/project management techniques over getting the basics like VC right? That doesn't sound like Agile in any universe I am familiar with.
I really struggle to think of any other examples where a worthy movement has been so thoroughly corrupted and debased into something almost diametrically opposed to it's original vision. Fuck Agile programming and what it has become. I think I'll stick with being a Pragmatic programmer.
Like many early Agile adopters I have been shocked and saddened by what it has become. I think the problem is that brainfucked corporate IT programmers (Java, .NET, whatever) have jumped on the bandwagon and driven it into the sea.
I was recently smacked around the head by this in a meeting about how a team was going to implement Jira ticketing to help improve their development process. I am not sure entirely what I was expecting, but I was totally, totally unprepared for the mind-stunning crap that I got - an endless series of slides of things called "workflows" which apparently document the life-cycle of a ticket and need to be mapped out in excruciating gory detail. I decided to raise my hand and ask a simple question "how do I just raise a ticket and assign it to someone" - the presenter gave me this kind of stunned "why would you want to do that??" look and explained that it doesn't work that way, first you need to assign everyone into teams and roles (like tester, developer etc), and then the workflow will decide where the ticket goes based on the kind of ticket and it's status. Mind blown. I could almost appreciate how such system might be of use on a really large project where you don't know and interact with most project members directly - they had a team of 8 people including testers and analysts. And in their minds they were doing Agile.
In another case I was arguing for the use of the Jira Fisheye plugin to enable meaningful access to VC to enable things like code review and release diffs and the like. The so called "Agile practitioners" had a different idea however - they were keen on a different plugin called Greenhopper which apparently does Agile process management and the like. I knew something was wrong when it was mentioned that it does nice Gantt charts. I probed a little deeper into why they didn't see the value in Fisheye and found that their actual VC practices were a joke - ludicrously large commits with minimal comment just before a release, no consistent release tags, broken commit history (they seemed to be deleting and re-creating their trunk after every release...what I don't even...). Advanced process/project management techniques over getting the basics like VC right? That doesn't sound like Agile in any universe I am familiar with.
I really struggle to think of any other examples where a worthy movement has been so thoroughly corrupted and debased into something almost diametrically opposed to it's original vision. Fuck Agile programming and what it has become. I think I'll stick with being a Pragmatic programmer.
You are saying that Agile is supposed to mean programming in Ruby instead of Java? And only small teams can be Agile? Amazon.com would disagree with you, for one.
"You are saying that Agile is supposed to mean programming in Ruby instead of Java?"
Of course not. But in my experience and observations, corporate IT programmers, especially those with a Java background, are the worst offenders when it comes to abusing the Agile concept and failing to get the basics anywhere near right.
"And only small teams can be Agile? Amazon.com would disagree with you, for one."
I am not saying that, but I think it is a good question. I have never seen a team of hundreds coordinated to an outcome using an Agile approach. I have been involved in large projects with up to 300 people (think multiple, large teams of business analysts, developers, database designers, architects and testers and a little hierarchy of IT project management) work towards a single outcome using a highly managed, strict waterfall approach over several years. It wasn't pretty, but we got there in the end, and I would not swear on the Bible that we could have done the same using Agile.
If Amazon is really using an Agile approach to coordinate hundreds of people working on a single project, I would love to read about it.
Of course not. But in my experience and observations, corporate IT programmers, especially those with a Java background, are the worst offenders when it comes to abusing the Agile concept and failing to get the basics anywhere near right.
"And only small teams can be Agile? Amazon.com would disagree with you, for one."
I am not saying that, but I think it is a good question. I have never seen a team of hundreds coordinated to an outcome using an Agile approach. I have been involved in large projects with up to 300 people (think multiple, large teams of business analysts, developers, database designers, architects and testers and a little hierarchy of IT project management) work towards a single outcome using a highly managed, strict waterfall approach over several years. It wasn't pretty, but we got there in the end, and I would not swear on the Bible that we could have done the same using Agile.
If Amazon is really using an Agile approach to coordinate hundreds of people working on a single project, I would love to read about it.
Amazon is split up into many different teams and each team follows it's own process. Some of these teams do what they call "agile."
Glad to see disdain for "agile" is finally becoming mainstream. Now, it may be that someone writing rote software should follow a process, but for anyone doing anything actually innovative, you can't get into their head and tell them what process they must follow, whether waterfall or agile. It's like telling Michelangelo the process for sculpting.
Rather than teaching people processes, they should help foster better ways of actually thinking about the code itself. E.g., learning new programming languages and frameworks gives one a variety of perspectives to think about code from.
Rather than teaching people processes, they should help foster better ways of actually thinking about the code itself. E.g., learning new programming languages and frameworks gives one a variety of perspectives to think about code from.
Mocking Agile strawman has been a pop pastime since Yegge wrote Good Agile Bad Agile years ago.
I think you can't effectively impose process, but I do think that good teams can happily decide what process they're going to follow. Which is how we got Extreme Programming in the first place.
Why stop at teams? How about "good departments happily deciding"? Or "good companies happily deciding"? Or "good nations happily deciding"?
> In many shops, Agile is just another way of micro-managing teams, sadly.
I think this is a big source of the complaints, yeah. If I had to narrow it to one specific mis-implementation of agile, it'd be having daily standup meetings turn into daily mini-performance-reviews with the boss. Iirc the Official Scrum Rules try to avoid that by decreeing that the scrum-master should be just another team member, and not a project lead or other kind of supervisor/boss, but afaict that recommendation isn't often followed.
I think this is a big source of the complaints, yeah. If I had to narrow it to one specific mis-implementation of agile, it'd be having daily standup meetings turn into daily mini-performance-reviews with the boss. Iirc the Official Scrum Rules try to avoid that by decreeing that the scrum-master should be just another team member, and not a project lead or other kind of supervisor/boss, but afaict that recommendation isn't often followed.
Yeah, you nailed it. I have seen this done so poorly so many times that I simply tell people to rotate the ScrumMaster role. Otherwise they just make it into a manager.
A lot of times they want to keep the old Project Manager around, and that's very difficult to do. Project Managers and ScrumMasters are completely different animals. A few times as a coach I have literally thrown the PM out of the stand-ups and told them not to come back because they were turning it into a status meeting.
I'm not trying to plug coaching, but if you're trying Agile, you really need an independent outsider to help referee stuff like this. Maybe it's only the SM from the team down the hall, but stuff like broken standups can be impossible to fix without a little neutral nudging.
A lot of times they want to keep the old Project Manager around, and that's very difficult to do. Project Managers and ScrumMasters are completely different animals. A few times as a coach I have literally thrown the PM out of the stand-ups and told them not to come back because they were turning it into a status meeting.
I'm not trying to plug coaching, but if you're trying Agile, you really need an independent outsider to help referee stuff like this. Maybe it's only the SM from the team down the hall, but stuff like broken standups can be impossible to fix without a little neutral nudging.
Exactly. It was amazing how quickly, at my last place, standups devolved from
...recounting verbally what one did the previous day...
...to marking one's progress on a whiteboard...
...to having to write down on an index card beforehand and turning it in to the IT director after the scrum meeting (in addition to the above).
With the boss (and sometimes, the CEO) in attendance, there was no chance of an honest verbal exchange about roadblocks etc.
Good metrics for measuring coding progress are so elusive, I can't imagine management NOT trying to mess with pure agile principles if tight deadlines and delivery dates are at stake.
...recounting verbally what one did the previous day...
...to marking one's progress on a whiteboard...
...to having to write down on an index card beforehand and turning it in to the IT director after the scrum meeting (in addition to the above).
With the boss (and sometimes, the CEO) in attendance, there was no chance of an honest verbal exchange about roadblocks etc.
Good metrics for measuring coding progress are so elusive, I can't imagine management NOT trying to mess with pure agile principles if tight deadlines and delivery dates are at stake.
Unfortunately, I got Scrum going at a small, chaotic, mismanaged consulting shop I worked for after using it at my previous job with reasonably positive results. Management loved it because it fed their natural micromanaging attitudes (e.g., employees are basically lazy children, will not work unless coerced, and must observe strict deadlines). I realized all too late that I was contributing to that.
These days they only do the daily stand-up, which is of no value to anyone except my former manager, since people talk directly to the manager and not to each other (this is one of many reasons why managers should not be in stand-ups). It became exactly what you said: a daily mini performance review.
I've since realized that the things that make Scrum successful are the same things that make a team successful, and that you can't necessarily connect a causal line between Scrum and team success if the team would have probably been successful anyway. It basically comes down to the team having a good rapport--regular communication between team members, the ability to seek advice without judgment, and the ability to communicate blocking issues in a timely way to the right people.
These days they only do the daily stand-up, which is of no value to anyone except my former manager, since people talk directly to the manager and not to each other (this is one of many reasons why managers should not be in stand-ups). It became exactly what you said: a daily mini performance review.
I've since realized that the things that make Scrum successful are the same things that make a team successful, and that you can't necessarily connect a causal line between Scrum and team success if the team would have probably been successful anyway. It basically comes down to the team having a good rapport--regular communication between team members, the ability to seek advice without judgment, and the ability to communicate blocking issues in a timely way to the right people.
I think this kind of weird misinterpretation of the buzzwords happens because most people don't actually read anything about agile. They just hear other people say they need to be doing "daily stand-up meetings", and they interpret what they think that means, instead of bothering to find out.
I had a wonderful example of this behavioral pattern last week. I was called into my project's first "sprint planning meeting" where I was asked to write down for the next 8 sprints which features would be delivered when. Of course, since we were now "doing agile" I was allowed to be off by one or two features every sprint. But it still had to all fit into 8 sprints, because the project's deadline was by the end of the 8th sprint, and we needed to be sure we would deliver the full scope by then. As pepe le pew so aptly described: "le sigh".
I had a wonderful example of this behavioral pattern last week. I was called into my project's first "sprint planning meeting" where I was asked to write down for the next 8 sprints which features would be delivered when. Of course, since we were now "doing agile" I was allowed to be off by one or two features every sprint. But it still had to all fit into 8 sprints, because the project's deadline was by the end of the 8th sprint, and we needed to be sure we would deliver the full scope by then. As pepe le pew so aptly described: "le sigh".
"The second secret is that most teams, frankly, are not that good. So you need some kind of way [...]"
Agree. Let's not forget the HR challenge most organizations have today. It's hard to find, hire, develop and keep talented people in the company. I heard the other day: "every job seeker is a potential low performer". The basis of that is that most talented, highly qualified people is either managing teams or freelancing/consulting, and inevitably making interesting amounts of cash either way. So the chances of finding this profile on every Agile team is low.
In this scenario, Agile has its intrinsic value of providing teams members of various competence levels with some minimum rules of conduct, processes and tools. Maybe good teams will think they are all about bureaucracy, or they'll think it's something the management layers of the company can look and understand, like a burnout chart.
That's why I cut the second sentence of the quote above in the middle. Sometimes, as a manager, you need a "way", like the Japanese word for "Do", to keep discipline and make things moving forward.
Agree. Let's not forget the HR challenge most organizations have today. It's hard to find, hire, develop and keep talented people in the company. I heard the other day: "every job seeker is a potential low performer". The basis of that is that most talented, highly qualified people is either managing teams or freelancing/consulting, and inevitably making interesting amounts of cash either way. So the chances of finding this profile on every Agile team is low.
In this scenario, Agile has its intrinsic value of providing teams members of various competence levels with some minimum rules of conduct, processes and tools. Maybe good teams will think they are all about bureaucracy, or they'll think it's something the management layers of the company can look and understand, like a burnout chart.
That's why I cut the second sentence of the quote above in the middle. Sometimes, as a manager, you need a "way", like the Japanese word for "Do", to keep discipline and make things moving forward.
Don't you think that agile proponents are frequently using a No True Scotsman here?
That is,
Statement: No Agile Team would do X.
Response: An Agile Team did do X.
Statement: Well, no True Agile Team would do X.
(http://en.wikipedia.org/wiki/No_true_Scotsman)
That is,
Statement: No Agile Team would do X.
Response: An Agile Team did do X.
Statement: Well, no True Agile Team would do X.
(http://en.wikipedia.org/wiki/No_true_Scotsman)
It depends.
For instance "No true Scotsman is born in Tuscany to Romanian parents and has never ventured west of Florence" isn't an instance of the fallacy because it truly does violate what it means to be a Scotsman.
Similarly, no true agile team would, say, agree to a single 6-month "sprint" at the end of which they will deliver the end product to a customer who has never seen it before, based only on a set of specs drawn up by an analyst.
And yet corporate shops that do similar absurd, not-within-the-common-idea-of-agile things will routinely label themselves as agile shops.
For instance "No true Scotsman is born in Tuscany to Romanian parents and has never ventured west of Florence" isn't an instance of the fallacy because it truly does violate what it means to be a Scotsman.
Similarly, no true agile team would, say, agree to a single 6-month "sprint" at the end of which they will deliver the end product to a customer who has never seen it before, based only on a set of specs drawn up by an analyst.
And yet corporate shops that do similar absurd, not-within-the-common-idea-of-agile things will routinely label themselves as agile shops.
So what? It doesn't absolve the team of the fact that they're doing Agile incorrectly. Call them whatever you want, they're still Doing It Wrong.
The hitchhikers guide to the galaxy gave the most succinct advice for how to fly. You fall down and miss the ground.
The upon reading this and in the absence of any native examples of flying animals the pelzo decided to directly follow this grand advice. After 100 billion attempts, over a billion broken bones, and hundreds of millions of deaths the great zaxuvex finally discovered that the correct way to do so is to reach orbital velocity above the atmosphere in a space ship that provides an internal atmosphere, comfortable temperature, shielding from harmful radiation, chemical rockets to slow down, AND most importantly a heat shield and parachute for reentry. Two weeks later a vising dignitary introduced the idea for wings which was was deemed heretical and started the 42 great war.
PS: If your 'training courses' don't provide enough information to actually implement your process in the real world then it's practicably worthless.
The upon reading this and in the absence of any native examples of flying animals the pelzo decided to directly follow this grand advice. After 100 billion attempts, over a billion broken bones, and hundreds of millions of deaths the great zaxuvex finally discovered that the correct way to do so is to reach orbital velocity above the atmosphere in a space ship that provides an internal atmosphere, comfortable temperature, shielding from harmful radiation, chemical rockets to slow down, AND most importantly a heat shield and parachute for reentry. Two weeks later a vising dignitary introduced the idea for wings which was was deemed heretical and started the 42 great war.
PS: If your 'training courses' don't provide enough information to actually implement your process in the real world then it's practicably worthless.
Love this metaphor and there's some truth here but no amount of training is going to make a manager butt out when the manager is the problem.
Isn't it ironic that by simply capitalizing the word 'agile' you can change its meaning to describe something that's the very antithesis of agility?
If a methodology is so brittle that any diversion from the straight and narrow (a) means you're no longer using that methodology and (b) ostensibly (or actually) invites disaster, then that is a very, very rigid methodology.
If a methodology is so brittle that any diversion from the straight and narrow (a) means you're no longer using that methodology and (b) ostensibly (or actually) invites disaster, then that is a very, very rigid methodology.
That's like saying Javascript is a very rigid language because your program breaks if you change braces to parenthesis.
> The second secret is that most teams, frankly, are not that good.
It's so important to remember this, as well as the corollary: I'm not that good myself. The article included this line:
> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
I'm not sure if I agree with the statement itself, although I certainly think -- and know no one who doesn't think -- that the quality of your staff is more important than your process. But I'm sure I disagree with the way this statement is used to dismiss the idea of a prescribed process. One of the main goals of such a process is to get as good work as possible out of mediocre staff. Because there aren't enough high quality staff to go around. You won't get great work out of mediocre workers, but if you can get pretty bad work instead of total garbage, in many environments that's a big win. (In the startup environment that is hn's focus, pretty bad might be just as bad as total garbage.)
It's so important to remember this, as well as the corollary: I'm not that good myself. The article included this line:
> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
I'm not sure if I agree with the statement itself, although I certainly think -- and know no one who doesn't think -- that the quality of your staff is more important than your process. But I'm sure I disagree with the way this statement is used to dismiss the idea of a prescribed process. One of the main goals of such a process is to get as good work as possible out of mediocre staff. Because there aren't enough high quality staff to go around. You won't get great work out of mediocre workers, but if you can get pretty bad work instead of total garbage, in many environments that's a big win. (In the startup environment that is hn's focus, pretty bad might be just as bad as total garbage.)
> I certainly think [...] that the quality of your staff is more important than your process.
I don't think those are independent variables.
In my experience, one of the properties of a good development team is that if a project lacks clear guidelines so the developers can work effectively together, the team will naturally tend to self-organise. They will establish enough ground rules among themselves to collaborate effectively, and they will adopt or create any tools necessary to support that basic process. A good team that does already have a decent process and competent leadership will still naturally review and update that process over time based on their experiences using it.
This also explains why one or two substandard developers on an otherwise competent team are so damaging: they are sufficient to disrupt any reasonable attempt at self-organisation, and the team now requires strong leadership rather than merely collaboration among peers. Unless the leader is capable of both instilling discpline in the rogue elements and simultaneously accepting and promoting good ideas from the remainder of the group, which is a very difficult thing to do even for an experienced manager with good intentions, the result will still be lower performance than a team without the negative elements.
I don't think those are independent variables.
In my experience, one of the properties of a good development team is that if a project lacks clear guidelines so the developers can work effectively together, the team will naturally tend to self-organise. They will establish enough ground rules among themselves to collaborate effectively, and they will adopt or create any tools necessary to support that basic process. A good team that does already have a decent process and competent leadership will still naturally review and update that process over time based on their experiences using it.
This also explains why one or two substandard developers on an otherwise competent team are so damaging: they are sufficient to disrupt any reasonable attempt at self-organisation, and the team now requires strong leadership rather than merely collaboration among peers. Unless the leader is capable of both instilling discpline in the rogue elements and simultaneously accepting and promoting good ideas from the remainder of the group, which is a very difficult thing to do even for an experienced manager with good intentions, the result will still be lower performance than a team without the negative elements.
I objected to the same statement but for slightly different reasons. It works when your project is of a size that can be done by a fairly small team that can communicate intimately and instantaneously at all times. We're talking 1 -5 people max. But what happens when there are 30 developers, 50 developers, or 100 developers. Without some overarching system of coordination these people will just be flailing around, constantly treading on each other, breaking each others stuff. Somehow you have to break it down and give people a way to understand what everyone else is doing, and that turns into "process". You can do it any way you like, but what ever you come up with is still going to be that evil word "process".
The problem is that said "process" then gets deployed in a cargo cult manner to any project regardless of size, divisibility, who is managing it working on it, etc.
The problem is that said "process" then gets deployed in a cargo cult manner to any project regardless of size, divisibility, who is managing it working on it, etc.
Just differentiate between what Agile is and how people are pushing Agile on you. Different things entirely.
Agile could be deleted, and replaced with a variable. Sturgeon's Law at work.
The second secret is that most teams, frankly, are not that good.
Again, Sturgeon's Law at work.
Agile could be deleted, and replaced with a variable. Sturgeon's Law at work.
The second secret is that most teams, frankly, are not that good.
Again, Sturgeon's Law at work.
I have nothing to say but to offer words of encouragement in your effort to write e-books to undo some of the damage.
It breaks my heart to see something that emerged from technical people to make their lives better and make them more effective be co-opted to the point where it's scorned by the same technical people who have the most to gain.
It breaks my heart to see something that emerged from technical people to make their lives better and make them more effective be co-opted to the point where it's scorned by the same technical people who have the most to gain.
> [Obligatory plug and disclaimer: Agile professional
You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right.
Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yourself, or pointy haired bosses who don't know a fucking thing about programming.
Programming. Either learn and do it, or get the fuck out of its way.
You sell process for a living. You claim, "After all, it's not like you can have no process at all. Whatever you're doing already is a process." When you said that, you accidentally got something right.
Programming is a process. It's the only one that fucking matters if you're a shop that sells software. All the other process comes from snake oil salesmen as yourself, or pointy haired bosses who don't know a fucking thing about programming.
Programming. Either learn and do it, or get the fuck out of its way.
Spoken like a true cowboy programmer who can't collaborate his way out of a wet paper bag and blames process when a team he's part of fails because of that...
I hate that term cowboy programmer. Very effective rhetoric, though. Let's take the archetypical example of people who get stuff done without our process, and call them cowboys! Now, anytime someone points out a dumbass process-driven decision that could have been avoided by using our brains, we can just disparage them as a cowboy.
Note, we're using small-a agile at my shop and it's working well, but that's because of good people, not because of blind adherence to a process and eschewing individual thought.
Note, we're using small-a agile at my shop and it's working well, but that's because of good people, not because of blind adherence to a process and eschewing individual thought.
It's ridiculously easy to get stuff done without any process when you work on your own and the projects are small enough for that. You don't even need to be very good to succeed in such a scenario.
Cowboy programmers are those who extrapolate from that and believe that teams efforts can work the same way, and who think that process causes only inefficiencies rather than preventing much larger ones.
But for a team to work effectively, you need structure, you need process. Even if the team members are very good, they can get completely lost without process. If they are not completely antisocial, they will come up with some sort of process themselves, but it's not automatically going to be a very effective one (and that has nothing to do with their programming skills). The point of agile is to try and minimize process while still enabling teams to work effectively. And it has absolutely nothing to do with "eschewing individual thought". Quite exactly the opposite, really. But of course there's no concept that can can't be perverted into its opposite by a sufficiently point-haired idiot.
Cowboy programmers are those who extrapolate from that and believe that teams efforts can work the same way, and who think that process causes only inefficiencies rather than preventing much larger ones.
But for a team to work effectively, you need structure, you need process. Even if the team members are very good, they can get completely lost without process. If they are not completely antisocial, they will come up with some sort of process themselves, but it's not automatically going to be a very effective one (and that has nothing to do with their programming skills). The point of agile is to try and minimize process while still enabling teams to work effectively. And it has absolutely nothing to do with "eschewing individual thought". Quite exactly the opposite, really. But of course there's no concept that can can't be perverted into its opposite by a sufficiently point-haired idiot.
Yeah man, I get that. I said that I'm at a small-a agile shop and it's working well for us.
That doesn't change the fact that the only time I've seen the phrase 'cowboy programmer' used, it's as a preemptively ad hominem argument that anything besides Capital A Agile As Written On Stone Tablets can't possibly work. And if it does, it's cause they're cowboys.
As a counterpoint, demanding something is deployed every 2 weeks, whether it's a 1-week task or a 3-week task, leads to plenty of cowboyism right within the process.
That doesn't change the fact that the only time I've seen the phrase 'cowboy programmer' used, it's as a preemptively ad hominem argument that anything besides Capital A Agile As Written On Stone Tablets can't possibly work. And if it does, it's cause they're cowboys.
As a counterpoint, demanding something is deployed every 2 weeks, whether it's a 1-week task or a 3-week task, leads to plenty of cowboyism right within the process.
Who demands 3 week tasks launch in 2 weeks? And Agile dev cycles delivers whatever is ready every two weeks, instead of shipping everything on an arbitrary deadline.
Funny thing is, both this guy and the author of the TFA touch the same problem in passing: regardless of the process, there are too many incompetent people plaguing our industry. Instead of addressing the problem, managers usually exacerbate it by trying to "fix it" with a "correct process".
No process in the universe is going to turn the Infinite Monkey Theorem [1] into solid reality.
[1] http://en.wikipedia.org/wiki/Infinite_monkeys
No process in the universe is going to turn the Infinite Monkey Theorem [1] into solid reality.
[1] http://en.wikipedia.org/wiki/Infinite_monkeys
Yet it never occurs to them when dividing people into groups that maybe they're the incompetent ones...
Who's more competent? The person using Agile successfully and getting things done, the guy using no specific development process and getting things done, or the guy writing long blog posts about why he doesn't care for a development process he doesn't understand and doesn't need to participate in if he doesn't enjoy it?
Who's more competent? The person using Agile successfully and getting things done, the guy using no specific development process and getting things done, or the guy writing long blog posts about why he doesn't care for a development process he doesn't understand and doesn't need to participate in if he doesn't enjoy it?
I'm currently on two missions. In one of these, we kick ass. Deliver on schedule or even in advance. It's scrum, we simply work as a team of four and ship, ship, ship, ship, feature after feature and fix after fix. We have our hands free, management is trusting our cell with the strategic future of their Tech tree, and we deliver.
In the other mission, I am not making this up, I spend 1hour/day on poor excuses of stand up meetings, 3 hours/day in various meetings, 1hour/day on various administrative tasks and 3 hours/day preparing powerpoint plannings for the meetings of the next day, and I'm a dev. I work with equally awesome devs in either mission, but in this one the customer is absolutely crazy inefficient and a control freak, and the best example of what NOT to do with scrum I've ever seen.
So who is more competent? The me that's killing it with scrum in the first mission or the me that can't do anything because of scrum in the second mission?
In the other mission, I am not making this up, I spend 1hour/day on poor excuses of stand up meetings, 3 hours/day in various meetings, 1hour/day on various administrative tasks and 3 hours/day preparing powerpoint plannings for the meetings of the next day, and I'm a dev. I work with equally awesome devs in either mission, but in this one the customer is absolutely crazy inefficient and a control freak, and the best example of what NOT to do with scrum I've ever seen.
So who is more competent? The me that's killing it with scrum in the first mission or the me that can't do anything because of scrum in the second mission?
The first you. The second you needs to run far away from what he's doing. :)
I was in that situation before -- bad agile is BAD. I was on a team of 4 developers with literally 8 project managers. I know how that daily 1 hour crappy stand up goes. I also know how it feels to have deliverables for half the project managers in any given week, and what it's like to get constantly interrupted by 8 different people during your minimal development time to answer non-urgent questions.
But you know what? Not everywhere is like that and you usually have a choice to find something else. You're obviously competent enough to find something else; you already have two things going on.
If they aren't doing it right and they aren't listening and you aren't happy, GTFO.
I was in that situation before -- bad agile is BAD. I was on a team of 4 developers with literally 8 project managers. I know how that daily 1 hour crappy stand up goes. I also know how it feels to have deliverables for half the project managers in any given week, and what it's like to get constantly interrupted by 8 different people during your minimal development time to answer non-urgent questions.
But you know what? Not everywhere is like that and you usually have a choice to find something else. You're obviously competent enough to find something else; you already have two things going on.
If they aren't doing it right and they aren't listening and you aren't happy, GTFO.
I enjoy programming with other programmers. But I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming.
Cowboy is a complement. It doesn't mean "lone ranger" or "asshole", it means lazy, hard worker who takes the shortest path to greatest output. So, yup. Cowboy here.
Cowboy is a complement. It doesn't mean "lone ranger" or "asshole", it means lazy, hard worker who takes the shortest path to greatest output. So, yup. Cowboy here.
I don't collaborate well with people who don't know a fucking thing about programming who try to put process on top of the process of programming.
Fair enough. But what about someone who does know a lot about programming, who runs his team using agile methods. Could you collaborate well with that person?
Fair enough. But what about someone who does know a lot about programming, who runs his team using agile methods. Could you collaborate well with that person?
HN's algorighm thinks I'm a spammer and wouldn't let me reply, but really, itsnotme.
I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.
I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.
No but communication is part of any effective process. Standup is just having everyone say what they accomplished yesterday and what they're planning on doing today. If you're on a team with more than three or four people, it's a useful way to get a quick summary of where everyone's at. Some people are good at letting other people know when they're stuck, but some aren't, and if you've got the latter on your team standup is a good catchall. Most teams, whether they're in software, sales, or sports, have some variation of the standup. Of all the scrum paractices it seems like it should be the least controversial.
No amount of process can fix bad communication. Standups are an attempt at that. Teams that have good communication succeed more, and standups aren't integral to their success. Teams with bad communication fail more, and standups can't help them.
Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site.
Tom: "Yesterday I.."
Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?"
Good teams communicate while they build, and know where each other are.
Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site.
Tom: "Yesterday I.."
Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?"
Good teams communicate while they build, and know where each other are.
Personally, I like having a daily stand-up. So do my colleagues. First thing in the morning is a great time to sync up on things.
I have seen places that do them poorly, and I gather that's what you've experienced. But it's also possible to do them well.
I have seen places that do them poorly, and I gather that's what you've experienced. But it's also possible to do them well.
No amount of process can fix bad communication.
Sure it can. If I've got a team member who can't be bothered to let people know what he's doing on his own, I can hold a standup every morning to make sure the information gets communicated to the team. If he lies every day about what he does, the longest he can go is one sprint before his work gets verified.
I'm trying to imagine standups on a building site.
I don't know, I think it goes something like this:
"Hey Tom, how far did you guys get on the roofing yesterday?"
"Only about a quarter of the way. Some dipshit ordered the wrong shingles."
"Ok, Bob will you get on that today so Tom and Dick can finish the roofing? How about you Fred, where are you at on the sheetrock?"
"Living room and kitchen are done, I should finish the bedrooms today..."
etc. Pretty much what actually happens at a construction site if the builder is competent.
I don't know what kind of standups you've been in but they sound like they were run by someone with no training or experience in the process.
Good teams communicate while they build, and know where each other are.
How do they communicate? What if Tom doesn't know what Dick's doing and Dick doesn't think to tell him because he doesn't know Tom needs to know? This doesn't magically happen even if everyone is individually a star at what they do.
Sure it can. If I've got a team member who can't be bothered to let people know what he's doing on his own, I can hold a standup every morning to make sure the information gets communicated to the team. If he lies every day about what he does, the longest he can go is one sprint before his work gets verified.
I'm trying to imagine standups on a building site.
I don't know, I think it goes something like this:
"Hey Tom, how far did you guys get on the roofing yesterday?"
"Only about a quarter of the way. Some dipshit ordered the wrong shingles."
"Ok, Bob will you get on that today so Tom and Dick can finish the roofing? How about you Fred, where are you at on the sheetrock?"
"Living room and kitchen are done, I should finish the bedrooms today..."
etc. Pretty much what actually happens at a construction site if the builder is competent.
I don't know what kind of standups you've been in but they sound like they were run by someone with no training or experience in the process.
Good teams communicate while they build, and know where each other are.
How do they communicate? What if Tom doesn't know what Dick's doing and Dick doesn't think to tell him because he doesn't know Tom needs to know? This doesn't magically happen even if everyone is individually a star at what they do.
"Sure it can... If he lies every day about what he does, the longest he can go is one sprint before his work gets verified."
That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks.
"etc. Pretty much what actually happens at a construction site"
That communication happens continuously, throughout the day. If isn't happening continuously, throwing a standup at it ain't gonna fix it.
That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks.
"etc. Pretty much what actually happens at a construction site"
That communication happens continuously, throughout the day. If isn't happening continuously, throwing a standup at it ain't gonna fix it.
That's wrapping it up in process, and calling it "good enough".
"Good enough" is certainly better than "not good enough". And it doesn't have anything to do with morale. The team's morale might be sky-high and they can still make mistakes because person A didn't know what person B was doing in a timely fashion. People have a tendency to overestimate their skills in general, and communication is no exception. Standups are just a form of insurance and cost almost nothing. Even if your team communicates like they're telepathic, 15 minutes a day in standup isn't going to hurt them.
If isn't happening continuously, throwing a standup at it ain't gonna fix it.
If I'm managing 5 job sites, I'm not there continuously. It might not be perfect, but once a day sure beats nothing. Most of the time when someone is doing something wrong, they don't know they're doing something wrong. No one is going to call me up and say, "Hey, I'm about to do something stupid and wanted to run it by you."
"Good enough" is certainly better than "not good enough". And it doesn't have anything to do with morale. The team's morale might be sky-high and they can still make mistakes because person A didn't know what person B was doing in a timely fashion. People have a tendency to overestimate their skills in general, and communication is no exception. Standups are just a form of insurance and cost almost nothing. Even if your team communicates like they're telepathic, 15 minutes a day in standup isn't going to hurt them.
If isn't happening continuously, throwing a standup at it ain't gonna fix it.
If I'm managing 5 job sites, I'm not there continuously. It might not be perfect, but once a day sure beats nothing. Most of the time when someone is doing something wrong, they don't know they're doing something wrong. No one is going to call me up and say, "Hey, I'm about to do something stupid and wanted to run it by you."
"Good enough" is certainly better than "not good enough".
In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough.
If I'm managing 5 job sites ... once a day sure beats nothing
If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard. If you attempt to control those teams by adding more process, you will interfere with the productivity of your good teams, and your bad teams will continue to suck.
In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough.
If I'm managing 5 job sites ... once a day sure beats nothing
If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard. If you attempt to control those teams by adding more process, you will interfere with the productivity of your good teams, and your bad teams will continue to suck.
Well, if you mean "Programming is a process" to include techniques of effective collaboration, then agile is part of programming.
Claiming that people who try to define methods to do that better "don't know a fucking thing about programming" is A) a non-sequitur and B) indicates that you don't collaborate well, period.
No, Cowboy is not a compliment. It means a hard worker who takes the shortest path to the greatest output of code that doesn't fulfill requirements and which nobody else can maintain.
Claiming that people who try to define methods to do that better "don't know a fucking thing about programming" is A) a non-sequitur and B) indicates that you don't collaborate well, period.
No, Cowboy is not a compliment. It means a hard worker who takes the shortest path to the greatest output of code that doesn't fulfill requirements and which nobody else can maintain.
You say "techniques of effective collaboration", I say "talking to people". If you need guidelines for that, that's cool.
The thing that suggests to me that you and I wouldn't work well together is that you make broad value judgements based on twisted interpretation and extrapolation of these comment threads.
The thing that suggests to me that you and I wouldn't work well together is that you make broad value judgements based on twisted interpretation and extrapolation of these comment threads.
And you don't?
Interesting. So how do you build things that take thousands of programming hours to complete? What about projects involving complex rulesets requiring legal input and/or HR input?
Programming is a means to an end. The end is solving some problem. For many problems programming is a small part of the overall solution.
Programming is a means to an end. The end is solving some problem. For many problems programming is a small part of the overall solution.
I meant to answer your original question, but HN decided I couldn't post any more under "itsnotme".
"So how do you build things that take thousands of programming hours to complete?"
By programming for thousands of hours. Through the process of programming, I'd try things out, use what works, dump what doesn't, write tests first where it makes sense, last where that makes sense, not at all where that makes sense, buy hardware where it will save me time and money or work better, interface with it by writing code, step back, look at some mistakes, rip them out, replace them with nothing if I can, or less bad mistakes if I can't replace them with nothing.
You know, programming.
If in addition to my process of programming someone wants me to tolerate some other meddlesome process, well, it depends how meddlesome that process is. If they want me to use a particular IDE, they can fuck right off. If they mandate I write code in a particular order, they can fuck right off.
On the other hand, if they are awesome people with awesome product, I'll engage in standups (or whatever), and I'll write my cards and move them along (or whatever), and burn down my time (or whatever). But I won't pretend that it part of the process of programming, or that it's speeding things up.
"So how do you build things that take thousands of programming hours to complete?"
By programming for thousands of hours. Through the process of programming, I'd try things out, use what works, dump what doesn't, write tests first where it makes sense, last where that makes sense, not at all where that makes sense, buy hardware where it will save me time and money or work better, interface with it by writing code, step back, look at some mistakes, rip them out, replace them with nothing if I can, or less bad mistakes if I can't replace them with nothing.
You know, programming.
If in addition to my process of programming someone wants me to tolerate some other meddlesome process, well, it depends how meddlesome that process is. If they want me to use a particular IDE, they can fuck right off. If they mandate I write code in a particular order, they can fuck right off.
On the other hand, if they are awesome people with awesome product, I'll engage in standups (or whatever), and I'll write my cards and move them along (or whatever), and burn down my time (or whatever). But I won't pretend that it part of the process of programming, or that it's speeding things up.
If you're planning a project to take thousands of programming hours to complete, you are an idiot, and nothing can help you.
So, there's nothing worth building that can't be accomplished in under 1000 hours?
Well, the Agile approach is to break them down into smaller things that can be accomplished in under 1,000 hours.
"There's nothing that can be accomplished in a single chunk taking more than a 1,000 hours that will produce a system with a manageable and maintainable level of complexity unless it is broken into smaller, well-defined and loosely-coupled components," perhaps.
"There's nothing that can be accomplished in a single chunk taking more than a 1,000 hours that will produce a system with a manageable and maintainable level of complexity unless it is broken into smaller, well-defined and loosely-coupled components," perhaps.
Lots of meaningful things take thousands of programmer hours. Projects where those thousands of hours are meticulously planned for by non-programmers (whether by using "Agile" or any other process that sits on top of the process of programming) are fucking doomed from the jump.
The software that keeps all modern airliners in the sky is written by companies that have lots and lots of process. Do you think those software projects are doomed from the jump just because there's a lot of process involved?
The cost/benefit tradeoff is very different for those companies. Usually, no one almost dies when your social app goes belly-up.
Sure, I was just trying to prove a point - more process doesn't necessarily mean worse software.
That's right. It means slower software.
That's not what Agile consultants are selling.
That's not what Agile consultants are selling.
You said "...Agile, or any other process...", so you're explicitly not limiting your statement to Agile methodologies.
Do you think _slower_ (as in taking longer to develop) software is the only outcome of the processes that avionics software companies use? Or do you think they are wrong or would be better off not using any of these processes?
Do you think _slower_ (as in taking longer to develop) software is the only outcome of the processes that avionics software companies use? Or do you think they are wrong or would be better off not using any of these processes?
The companies have a lot of process, but how do you know how the software was written? Usually I see things like a huge project that is failing while the initial prototype that works gets upgraded to production...which has often been produced by cowboys.
However, I don't work in the airline industry. I do work somewhere where one errant line of code can destroy productivity around the entire globe, brick computers, and really piss people off, and it's low process, cause the process guys can't ever get anything shipping.
As for Agile, I would suggest reading the Mythical Man Month circa 1995, the final chapter covers iterative development and makes a lot of sense, imho. Not sure why we need people with certificates selling snake oil where common sense works just fine.
However, I don't work in the airline industry. I do work somewhere where one errant line of code can destroy productivity around the entire globe, brick computers, and really piss people off, and it's low process, cause the process guys can't ever get anything shipping.
As for Agile, I would suggest reading the Mythical Man Month circa 1995, the final chapter covers iterative development and makes a lot of sense, imho. Not sure why we need people with certificates selling snake oil where common sense works just fine.
I don't know that Boeing follows your cowboy methodology. Hipmunk probably does. But Boeing puts the planes in the air.
Processes implemented to save lives are the product of death, and the process is put there to slow things down. Ask your friendly agile consultant how much their process is going to slow down your company.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.
That's not obviously true to me.
Any professional has some process, explicit or implicit: it's the observable regularities in the way they work.
Any team is going to have some explicit process, because there's no way people will converge on the maximally effective way of working together without some discussion.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. That doesn't make much sense to me.
In our case, the process we've converged on is the most efficient one we can find. But we're always looking for ways to make it more efficient.
Any professional has some process, explicit or implicit: it's the observable regularities in the way they work.
Any team is going to have some explicit process, because there's no way people will converge on the maximally effective way of working together without some discussion.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. That doesn't make much sense to me.
In our case, the process we've converged on is the most efficient one we can find. But we're always looking for ways to make it more efficient.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient.
Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.
Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.
I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming.
However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you're screwed. Ditto if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.
I also think you're creating a bit of a false dichotomy. When I first tried XP, it wasn't for the sake of doing XP. It was because I wanted to improve how we made things for our users. So exploring XP wasn't tangential to better programming; for me it was closely related, in that programming was a big part of making.
However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you're screwed. Ditto if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.
I also think you're creating a bit of a false dichotomy. When I first tried XP, it wasn't for the sake of doing XP. It was because I wanted to improve how we made things for our users. So exploring XP wasn't tangential to better programming; for me it was closely related, in that programming was a big part of making.
... if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.
That's impossible.
That's impossible.
Just because something doesn't have a name and isn't written down anywhere doesn't mean it doesn't exist. If you don't like agile, it doesn't mean you have no process. It just means you are following another process. Assuming you have a project that actually involves interacting with multiple programmers, your ability to interact with them is a key part of getting the job done.
If you're a lone cowboy doing it all alone, then good for you, but please state that upfront in your blog posts about how the software world is doing it wrong so we know you are evaluating things from a very unusual position.
If you aren't a sole programmer, then you've got a process. Maybe it's better than agile processes. If so, please, tell us what that process it.
This whole article reads like a racecar driver dismissing automotive technology because the only thing that matters is the skill of the driver.
If you're a lone cowboy doing it all alone, then good for you, but please state that upfront in your blog posts about how the software world is doing it wrong so we know you are evaluating things from a very unusual position.
If you aren't a sole programmer, then you've got a process. Maybe it's better than agile processes. If so, please, tell us what that process it.
This whole article reads like a racecar driver dismissing automotive technology because the only thing that matters is the skill of the driver.
The world is full of mediocre programmers, and in each cluster of mediocre programmers you'll find that they're surrounding much better programmers.
Ergo, since mediocre programmers exist, agile isn't a sham, and is necessary. QED
Ergo, since mediocre programmers exist, agile isn't a sham, and is necessary. QED
Even for really talented developers - imo just because they are talented (they can code and can solve problems) doesn't mean they can play well within a team - especially in a team without any processes to guide them through.
I personally find the author's view on processes to be very naive - and a bit offensive, it's almost like saying if you employ processes, then you are stupid.
EDIT:
My thoughts in a separate entry: http://news.ycombinator.com/item?id=3765693
I personally find the author's view on processes to be very naive - and a bit offensive, it's almost like saying if you employ processes, then you are stupid.
EDIT:
My thoughts in a separate entry: http://news.ycombinator.com/item?id=3765693
The notion that some 'good,' 'quality,' or 'talented' programmer is somehow entirely autonomous is entirely a fallacy. I'd trust a team of 'mediocre' programmers that follow process and get it done than place blind trust in a couple cowboys or post-docs who have some claim to genius in a prior life.
Sure, some are better than others. But to those who somehow believe that Great Programmers can do anything, get over yourselves. They (read: you) probably aren't nearly as good as you think.
Sure, some are better than others. But to those who somehow believe that Great Programmers can do anything, get over yourselves. They (read: you) probably aren't nearly as good as you think.
So aggressive! I'll be the first to proudly proclaim that I know practically nothing, and am a terrible programmer. But I'm not mediocre. Mediocrity == doesn't know how to ask questions, decompose problems, troubleshoot or research. Calm down bud.
Relevant article: http://www.joelonsoftware.com/articles/fog0000000024.html
Of course, you need process if you really want to consistently create defect-free software: http://www.fastcompany.com/magazine/06/writestuff.html
Of course, you need process if you really want to consistently create defect-free software: http://www.fastcompany.com/magazine/06/writestuff.html
Direct quote: "Process is, actually, just tax. If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project."
No.
Read some history; you'll see the same arguments back years ago about processes being stupid then (80's, 90's) too.
I'm willing to accept that perhaps Agile isn't a perfect process, and that agile projects don't always work out.
However, process just means that you have a repeatable set of steps for generating a repeatable outcome. It's an absolutely vital part of every industry, from manufacturing to farming to, yes, programming.
Everything is a process; TDD is process, writing a plan for your code is process, hell, even just sitting down and hacking away and keeping everything you need in your head is a process.
When you have a team that is larger than one person, organizing that team relies on having expectations from each group in the team, and from each person in the group. That's _formalized_ process, and that's what agile is.
Summary: Opinion piece, unsubstantiated, no background context. Bleh.
No.
Read some history; you'll see the same arguments back years ago about processes being stupid then (80's, 90's) too.
I'm willing to accept that perhaps Agile isn't a perfect process, and that agile projects don't always work out.
However, process just means that you have a repeatable set of steps for generating a repeatable outcome. It's an absolutely vital part of every industry, from manufacturing to farming to, yes, programming.
Everything is a process; TDD is process, writing a plan for your code is process, hell, even just sitting down and hacking away and keeping everything you need in your head is a process.
When you have a team that is larger than one person, organizing that team relies on having expectations from each group in the team, and from each person in the group. That's _formalized_ process, and that's what agile is.
Summary: Opinion piece, unsubstantiated, no background context. Bleh.
Thinking is hard. It seems like the cycle is a) someone thinks b) people follow without thinking c) someone realizes that unthinkingly following some process doesn't work so they debunk the theory without thinking.
So the question you have to ask yourself before you participate in b) or c) is do you have any idea why or how agile is supposed to help?
So the question you have to ask yourself before you participate in b) or c) is do you have any idea why or how agile is supposed to help?
Just wasted 5 minutes of my life reading this. save your time.
Just a rant with no direct point or constructive thinking.
I view Agile the same way I do P90X, which if you swapped one term for the other this post would probably be just as valid. Yet, I use P90X and get good results. Is it dependent on my motivation and physical abilities? Yes, of course. Will it help an unmotivated person become fit? No, of course not. But what it does give some people is a road map to follow and a process for following it. Much like Agile does.
My team is using Agile and it's effective. It's not a silver bullet, but it keeps us on the same page for the most part and it gives the business team goal posts for getting features designed and queued up. If us developers sucked, it probably wouldn't help that. But since we're all decent, motivated workers, it has been going pretty well.
So is Agile a sham? Sure, whatever. So is P90X. I'll keep using both, thanks.
My team is using Agile and it's effective. It's not a silver bullet, but it keeps us on the same page for the most part and it gives the business team goal posts for getting features designed and queued up. If us developers sucked, it probably wouldn't help that. But since we're all decent, motivated workers, it has been going pretty well.
So is Agile a sham? Sure, whatever. So is P90X. I'll keep using both, thanks.
I disagree with the author's opinion on processes, and I have put some of my thoughts in a separate entry here: http://news.ycombinator.com/item?id=3765693
See, the thing is, the success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow.
The success of the non-coding part of a project is dependent on the calibre of your sales/management and how they interact with the customer. If you are trying to prescribe some rigid process, however lean, in order to make that interaction effective, then you have a customer interface problem and process isn’t going to help it.
Couldn't agree more. The only thing I'd like to add is that there also must be a solid interface between sales/management and engineers.
Thanks for this.
The success of the non-coding part of a project is dependent on the calibre of your sales/management and how they interact with the customer. If you are trying to prescribe some rigid process, however lean, in order to make that interaction effective, then you have a customer interface problem and process isn’t going to help it.
Couldn't agree more. The only thing I'd like to add is that there also must be a solid interface between sales/management and engineers.
Thanks for this.
I anticipate a kicking for this but, hey ho.
IMHO if you have great people (developers, sales, test, whatever), process is near irrelevant. Sadly if we're being honest most people are not great (even when they think they are).
Where that's the case, process is the sticking plaster that attempts to make up for the failings of us mere mortals. Generally speaking process takes away some freedom from those involved and adds some overhead but provides some predictability.
Bad people don't make good use of freedom (and indeed often abuse it) and the project benefits from them being made more predictable. Good people not only make good use of freedom but are already largely predictable (they manage expectations, communicate well and so on) so not only do you add overhead and lose opportunity, but you gain almost nothing.
The issue is understanding how good your team are and what level of process is appropriate.
IMHO if you have great people (developers, sales, test, whatever), process is near irrelevant. Sadly if we're being honest most people are not great (even when they think they are).
Where that's the case, process is the sticking plaster that attempts to make up for the failings of us mere mortals. Generally speaking process takes away some freedom from those involved and adds some overhead but provides some predictability.
Bad people don't make good use of freedom (and indeed often abuse it) and the project benefits from them being made more predictable. Good people not only make good use of freedom but are already largely predictable (they manage expectations, communicate well and so on) so not only do you add overhead and lose opportunity, but you gain almost nothing.
The issue is understanding how good your team are and what level of process is appropriate.
[T]he success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow.
And the success of an NFL team has nothing to do with process either. It's all the players. That's why they never hold practices or review footage with the coaches. Who needs set plays? Tom Brady just tells Wes Welker to go deep and get open. You guys up front block. That's it. Super Bowl. Process is for losers.
And the success of an NFL team has nothing to do with process either. It's all the players. That's why they never hold practices or review footage with the coaches. Who needs set plays? Tom Brady just tells Wes Welker to go deep and get open. You guys up front block. That's it. Super Bowl. Process is for losers.
Programming != football.
True, but the argument in favor of process applies equally well to both.
[deleted]
I've been using scrum for about ten years at several companies. Each time I do it, I explain to everyone that the process has nothing to do with getting people to be more efficient or work harder. It has everything to do with helping me estimate when stuff will get done so that I can let all the dependent parts of the company know well ahead of time.
If the work being done doesn't get re-prioritized, I can pretty accurately judge about 3 months out and very accurately judge a month out. That lets the rest of the company plan fundraising, PR, sales, etc.
This is where I disagree with the author. You do get fairly predictable output out of a group of engineers regardless of their ability as long as they are consistent in their estimates for how long something will take (it doesn't matter if they over or underestimate, just that they do it consistently). You just won't like the results if they are mediocre.
I really want to stress how important the whole self-learning and re-adjustment part of the process is (if someone doesn't scream at least once during a retrospective, they're probably just going through the motions.) While I've run "scrum" for 10 years, the details of how each worked were pretty different depending on the teams involved.
That said, I tend to hire self-managing, self-learning engineers which scrum works beautifully for. I also am completely comfortable with delegating away large amounts of authority especially given the type of people I hire.
If the work being done doesn't get re-prioritized, I can pretty accurately judge about 3 months out and very accurately judge a month out. That lets the rest of the company plan fundraising, PR, sales, etc.
This is where I disagree with the author. You do get fairly predictable output out of a group of engineers regardless of their ability as long as they are consistent in their estimates for how long something will take (it doesn't matter if they over or underestimate, just that they do it consistently). You just won't like the results if they are mediocre.
I really want to stress how important the whole self-learning and re-adjustment part of the process is (if someone doesn't scream at least once during a retrospective, they're probably just going through the motions.) While I've run "scrum" for 10 years, the details of how each worked were pretty different depending on the teams involved.
That said, I tend to hire self-managing, self-learning engineers which scrum works beautifully for. I also am completely comfortable with delegating away large amounts of authority especially given the type of people I hire.
Must be Wednesday.
TODO next week: Go collect all of the blog post cycles of "Agile Sucks" -> "No, agile in theory is fine, it's just marketing and implementation that sucks."
It's a full-fledged meme at this point. And I think if you distilled all of these posts down to their essence, you'd have a really solid critique and we could build some lessons learned, and the next time someone gets burned by a bad implementation of s/Agile|XP|Scrum/ maybe the narrative will change a bit from "Agile sucks" to something more productive, something closer to "there's that Agile execution thing again, and here's what I did about it."
Everything OP says is true, Agile is misapplied, overmarketed and badly executed, and much suffering in the name of "Agile" has happened.
But we need to change the story now. This same cycle of "sucks" -> "yeah but" is generating more heat than light. Time to reset and redirect our expectations to something productive.
"In time there will be a new movement which paints Agile as broken, inefficient and bad and we’ll get a new brand. That’s the kind of iterative development I’m looking forward to; a new target for our collective disdain ;)"
Here we've hit on something. On common refrain in anti-Agile screeds is "Meet the new boss, same as the old boss." And it's true, but instead of cynically setting us up for some other jaded iteration of Good Process Idea -> Marketing Scam/Bad Implementation -> Backlash, let's distill the lessons learned into something a little more focused and circumspect.
Let's not cycle through this again, please. Let's set Agile in its proper place, good stuff, bad stuff, the whole thing. And let's tell the right story that might help us stop looking to things like Agile as the One Best Way to do software and see it as the limited tool it is, dependent on many other concerns, such as quality of developer, product focus, political environment, etc. Agile was a great insight in its time, and I think the time is come for a large-scale retrospective by the community to state the lessons learned.
One iteration I would really like to see end is "Agile Sucks" -> "But Not Really". Time to move on to the next level, one that acknowledges Agile's failings but doesn't involve a wholesale scrapping of Agile's important insights.
TODO next week: Go collect all of the blog post cycles of "Agile Sucks" -> "No, agile in theory is fine, it's just marketing and implementation that sucks."
It's a full-fledged meme at this point. And I think if you distilled all of these posts down to their essence, you'd have a really solid critique and we could build some lessons learned, and the next time someone gets burned by a bad implementation of s/Agile|XP|Scrum/ maybe the narrative will change a bit from "Agile sucks" to something more productive, something closer to "there's that Agile execution thing again, and here's what I did about it."
Everything OP says is true, Agile is misapplied, overmarketed and badly executed, and much suffering in the name of "Agile" has happened.
But we need to change the story now. This same cycle of "sucks" -> "yeah but" is generating more heat than light. Time to reset and redirect our expectations to something productive.
"In time there will be a new movement which paints Agile as broken, inefficient and bad and we’ll get a new brand. That’s the kind of iterative development I’m looking forward to; a new target for our collective disdain ;)"
Here we've hit on something. On common refrain in anti-Agile screeds is "Meet the new boss, same as the old boss." And it's true, but instead of cynically setting us up for some other jaded iteration of Good Process Idea -> Marketing Scam/Bad Implementation -> Backlash, let's distill the lessons learned into something a little more focused and circumspect.
Let's not cycle through this again, please. Let's set Agile in its proper place, good stuff, bad stuff, the whole thing. And let's tell the right story that might help us stop looking to things like Agile as the One Best Way to do software and see it as the limited tool it is, dependent on many other concerns, such as quality of developer, product focus, political environment, etc. Agile was a great insight in its time, and I think the time is come for a large-scale retrospective by the community to state the lessons learned.
One iteration I would really like to see end is "Agile Sucks" -> "But Not Really". Time to move on to the next level, one that acknowledges Agile's failings but doesn't involve a wholesale scrapping of Agile's important insights.
I like to say to people:
"Software Engineering is an attempt of turning an art into science".
Let's be honest. Software development is an art form. Just like people form groups from quartets to orchestras to make music, so do people form groups of differing skillsets to develop software.
That doesn't mean an art is shooting from the hip. There is still tons of practice to be done, and the various skill levels of each individual determines the possibility for success.
The problem, then, is that there are not enough Bubles, Joshua Bells, Ashkenazys, etc. around to make all the software in the world. Most companies have to make do with large concentrations of amateurs led by the occasional Bieber/Gaga.
So what are all these processes then? They're essentially what companies wish to use to artificially increase their chances of success... However, manufacturing art leads to potential stagnation and also the possibility that every project that follows the same process have the same flaws (like how all pop music nowadays all sound the same).
Sadly, it'll take an extremely brave company to get artists to develop their software nowadays. Nowadays, the artists stick to developing their own products =)
"Software Engineering is an attempt of turning an art into science".
Let's be honest. Software development is an art form. Just like people form groups from quartets to orchestras to make music, so do people form groups of differing skillsets to develop software.
That doesn't mean an art is shooting from the hip. There is still tons of practice to be done, and the various skill levels of each individual determines the possibility for success.
The problem, then, is that there are not enough Bubles, Joshua Bells, Ashkenazys, etc. around to make all the software in the world. Most companies have to make do with large concentrations of amateurs led by the occasional Bieber/Gaga.
So what are all these processes then? They're essentially what companies wish to use to artificially increase their chances of success... However, manufacturing art leads to potential stagnation and also the possibility that every project that follows the same process have the same flaws (like how all pop music nowadays all sound the same).
Sadly, it'll take an extremely brave company to get artists to develop their software nowadays. Nowadays, the artists stick to developing their own products =)
Maybe you should go and read this again:
http://agilemanifesto.org/
[deleted]
A fun anecdote is to consider the belief the TDD crowd entertained that, by creating tests for a problem you couldn’t solve, you could somehow evolve a code that passed the tests and therefore solved the problem!
I'm all for a healthy debate of TDD, but the above statement seems ridiculous to me. For me, TDD helps with two main things:
- I specify the behavior I'm adding/changing before I implement it. This helps document the change I believe I'm making.
- I feel more confident when making changes to a large codebase.
TDD works for some and not for others. There are very interesting arguments to be had about the subject. However, can we please stop acting as though TDD advocates view their tests as having psuedo-mystical powers to solve problems automatically?
I'm all for a healthy debate of TDD, but the above statement seems ridiculous to me. For me, TDD helps with two main things:
- I specify the behavior I'm adding/changing before I implement it. This helps document the change I believe I'm making.
- I feel more confident when making changes to a large codebase.
TDD works for some and not for others. There are very interesting arguments to be had about the subject. However, can we please stop acting as though TDD advocates view their tests as having psuedo-mystical powers to solve problems automatically?
Well, yes and no, but mostly no.
Looking at the collection of things that people refer to as "Agile", some of the practices work for certain teams at certain times. Saying "its all a sham" is as much bullshit as calling Agile a silver bullet that will solve all your woes. (Just because it's not one extreme, doesn't put it at the other).
The OP calls out two practices, Scrum and TDD. I've tried "Scrum" at 3 different places, where by "Scrum" they meant "have a stand up meeting". Never worked. For that project!
However, TDD has actually been a silver bullet for some tasks. And on other tasks it killed my productivity.
Basically, stop thinking there are silver bullets, and figure out what works for your team and project.
Looking at the collection of things that people refer to as "Agile", some of the practices work for certain teams at certain times. Saying "its all a sham" is as much bullshit as calling Agile a silver bullet that will solve all your woes. (Just because it's not one extreme, doesn't put it at the other).
The OP calls out two practices, Scrum and TDD. I've tried "Scrum" at 3 different places, where by "Scrum" they meant "have a stand up meeting". Never worked. For that project!
However, TDD has actually been a silver bullet for some tasks. And on other tasks it killed my productivity.
Basically, stop thinking there are silver bullets, and figure out what works for your team and project.
We use agile at my company w/ about 15 employees. We introduced it about two years ago to help focus our development process. Although I know there are some issues with agile, we've fully embraced agile by modifying our process along the way to suit our style. It has worked really well and I wouldn't change it for anything else right now. Does it produce high quality software? I agree that depends on the engineers, but it does produce a predictable process that we all are on board with. That's huge in my eyes.
To me, agile is essentially common sense. sprints, story cards,scrums are not nonsense, but discipline. I don't care what these are called, but they have served as a good set of tools to bring in discipline to the team. It helps a lot, when your team is not full of self-driven, talented developers. While that may point to an issue in hiring, we all know how difficult it is to hire and retail such people.
Not sure where the poster comes from.
(The poster seems to confuse Agile in "Agile is a Sham" and the Agile "industry". I can't talk about the Agile "industry" as I'm no part of it or have no contact to it, so I will concentrate on the "Agile is a Sham" part)
After introducing Agile/Scrum in 3 companies over the last 10 years, not as a consultant but as a permanent employee, I'd think it has been a success three times. Measuring success with two metrics: Predictable, ongoing results and developer happiness.
Developer happiness in agile usually comes from calming down the fury of requirements and wished for features. Sprints do enable developers to focus for 2-3 weeks on one topic instead of being pushed to the most urgent topic of the day by management. Happiness also comes from communicating and working and feeling as a team.
I assume the poster has - if he has - a different agile experience. Perhaps he's not a team person or uncomfortable with coordinating and working with others. 10% of the developers I've worked with just don't feel right with agile, it's not their thing. They should not try to adapt to agile from my experience, as it does not work. Better to find a non agile environment that does work for them.
From asking developers after agile introductions we had >90% approval rates on the question "Would you like to go back before agile?" and "Would you like to have a different development model?"
Scrum in particular is different from, e.g. XP. It focuses on process and - deliberately - says nothing about engineering practices or craftmanship. Coders are free to chose those for themselves. Some struggle on this or think they don't need to have them just because Scrum doesn't prescribe those. Some think Scrum is sh* as it does not talk about engineering practices or developer quality. But this is intentional.
Scrum will not make development "work" with bad developers. But it will make good developers work smoother together and make them - if they are team people - more happy from my experience.
One final note: Some people here agree that Agile is a Sham and does not work, then citing examples of managers/scrum masters that deliberately did not follow Scrum. Following Aristotelian logic at least this does not make sense.
A final final note: I got a very fine and tasty chocolate cake from my current team for birthday, so I might not be doing things that wrong ;-)
(The poster seems to confuse Agile in "Agile is a Sham" and the Agile "industry". I can't talk about the Agile "industry" as I'm no part of it or have no contact to it, so I will concentrate on the "Agile is a Sham" part)
After introducing Agile/Scrum in 3 companies over the last 10 years, not as a consultant but as a permanent employee, I'd think it has been a success three times. Measuring success with two metrics: Predictable, ongoing results and developer happiness.
Developer happiness in agile usually comes from calming down the fury of requirements and wished for features. Sprints do enable developers to focus for 2-3 weeks on one topic instead of being pushed to the most urgent topic of the day by management. Happiness also comes from communicating and working and feeling as a team.
I assume the poster has - if he has - a different agile experience. Perhaps he's not a team person or uncomfortable with coordinating and working with others. 10% of the developers I've worked with just don't feel right with agile, it's not their thing. They should not try to adapt to agile from my experience, as it does not work. Better to find a non agile environment that does work for them.
From asking developers after agile introductions we had >90% approval rates on the question "Would you like to go back before agile?" and "Would you like to have a different development model?"
Scrum in particular is different from, e.g. XP. It focuses on process and - deliberately - says nothing about engineering practices or craftmanship. Coders are free to chose those for themselves. Some struggle on this or think they don't need to have them just because Scrum doesn't prescribe those. Some think Scrum is sh* as it does not talk about engineering practices or developer quality. But this is intentional.
Scrum will not make development "work" with bad developers. But it will make good developers work smoother together and make them - if they are team people - more happy from my experience.
One final note: Some people here agree that Agile is a Sham and does not work, then citing examples of managers/scrum masters that deliberately did not follow Scrum. Following Aristotelian logic at least this does not make sense.
A final final note: I got a very fine and tasty chocolate cake from my current team for birthday, so I might not be doing things that wrong ;-)
Agile may well be a sham, but this statement:
the success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow.
seems to me obviously untrue, for >3 engineers, and the larger that count gets, the more process you need. As an engineer I find that statement very appealing, but experience suggests it's off base.
the success of the coding-part of a project is dependent on the calibre of the engineers doing that coding and not the process they follow.
seems to me obviously untrue, for >3 engineers, and the larger that count gets, the more process you need. As an engineer I find that statement very appealing, but experience suggests it's off base.
"thats SCRUM and TDD and all the rest; it is all those new ways of managing development projects"
TDD is a style of developing and nothing to do with management. Anyone who has worked on something more than a trivial size app knows how useful having a decent set of automated unit tests are. Anyone who dismisses this as a "management scam" is fooling only themself.
TDD is a style of developing and nothing to do with management. Anyone who has worked on something more than a trivial size app knows how useful having a decent set of automated unit tests are. Anyone who dismisses this as a "management scam" is fooling only themself.
I'm glad you parsed the first line... now please read the rest of the article ;)
That should be clear to anyone that has even a little mathematical/computer science training.
Anyone that says you can follow some process to ensure success is effectively telling you they have implemented artificial intelligence that simulates a production line designer and to be able to do it by using humans pushing bits of paper around as their computer.
Anyone that says you can follow some process to ensure success is effectively telling you they have implemented artificial intelligence that simulates a production line designer and to be able to do it by using humans pushing bits of paper around as their computer.
> Anyone that says you can follow some process to ensure success
I'm going to argue this on both of its implications.
Firstly: Agile is not about ensuring success. It's about greatly increasing the chances of success, and minimizing failure from fallout. No amount of process will rescue you from truly dreadful technical team, but so what? Plenty of processes will almost guarantee failure with the best tech team and will in the world.
I'm going to go for the assumption that you knew that already, though, and are attacking the idea that a management-related solution can help in the solving of technical-related problems.
Take a look at a modern hospital, and you will see layer upon layer of 'management' solutions to support medical problems. Prescriptions are checked by the doctor, checked by the pharmacist, and then checked by the nurse. Do hospitals throw these rules away with sufficiently good doctors? No. Do hospitals do this because they think their doctors are shit? No.
Agile can be a highly effective management solution for supporting technical development. I know this because it has been for me, on many occasions, with many different teams, in many different settings. I've also seen it badly implemented to the point where it's an impediment to teams, but ... so what? That's a risk with any process.
I'm going to argue this on both of its implications.
Firstly: Agile is not about ensuring success. It's about greatly increasing the chances of success, and minimizing failure from fallout. No amount of process will rescue you from truly dreadful technical team, but so what? Plenty of processes will almost guarantee failure with the best tech team and will in the world.
I'm going to go for the assumption that you knew that already, though, and are attacking the idea that a management-related solution can help in the solving of technical-related problems.
Take a look at a modern hospital, and you will see layer upon layer of 'management' solutions to support medical problems. Prescriptions are checked by the doctor, checked by the pharmacist, and then checked by the nurse. Do hospitals throw these rules away with sufficiently good doctors? No. Do hospitals do this because they think their doctors are shit? No.
Agile can be a highly effective management solution for supporting technical development. I know this because it has been for me, on many occasions, with many different teams, in many different settings. I've also seen it badly implemented to the point where it's an impediment to teams, but ... so what? That's a risk with any process.
Agile and other processes go much much further than your contrived example of checks and balances in a typical hospital. It would be like hospital directly interfering into the daily doctor/patient interaction or say stipulating that no surgery can be longer than 2 hours. You want to do 9 hour heart transplant surgery. Sorry, can't do that. Break it up into 2 hour chunks and measure progress after each to make sure you are going in the right direction.
This is why agile is like religion. It is so vague and so thinly disguised into general meaningless correct sounding "principles" that it can be anything to anyone.
This is why agile is like religion. It is so vague and so thinly disguised into general meaningless correct sounding "principles" that it can be anything to anyone.
You're messing up agile and Scrum. Scrum has the restriction that every task has to fit within a single iteration. And even with scrum, that limit is self-proscribed. If you regularly have tasks that dont fit in a single iteration and you can't cut those down to smaller tasks then you're free to choose longer iterations. Scrum just says "make iterations, measure progress during iterations to get an estimate how much you can fit in the next." It's like doctors measuring how long they usually need for heart transplant surgery and applying that knowledge to the operations plan for the next week. I'm sure they do. And I'm sure they limit the time they have in the operation room and won't schedule a non-critical long operation at the end of a packed day. (I actually dated a doctor for 6 years and they surely did - apart from working tons of overtime and other unsensible things)
I'm not really confusing the two, I know perfectly well the distinction. However, agile is usually sold exactly like that, as a solution that will improve/solve problems.
Generally, few teams in any organization have so much autonomy to choose their own process. If they did and they decided on their own to do some kind of agile, so be it. But agile is usually imposed externally (because it's in currently) but so is any other process. By the way I'm not criticizing agile per se, I'm criticizing the idea of process as solution.
Generally, few teams in any organization have so much autonomy to choose their own process. If they did and they decided on their own to do some kind of agile, so be it. But agile is usually imposed externally (because it's in currently) but so is any other process. By the way I'm not criticizing agile per se, I'm criticizing the idea of process as solution.
But then your issue is not with "agile" or "scrum", it's about how people abuse the notion of agile or scrum. It's the same with every other tool, programming language or process. They get abused by people pushing their agenda.
I've seen organizations that started calling their lack of planning "scrum" because that sounded better than saying "d'oh we just make up our mind on what to do every couple of days." But that's not scrum or agile and it's not the fault of people applying or promoting proper agile techniques.
I've seen organizations that started calling their lack of planning "scrum" because that sounded better than saying "d'oh we just make up our mind on what to do every couple of days." But that's not scrum or agile and it's not the fault of people applying or promoting proper agile techniques.
This quote summarizes how terrible the article is:
> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
> If you need to follow a prescribed process in order to be in any way an effective coder then you are mediocre at best and so is your work and your project.
I try to emphasize the agile principles. I think there is a lot of wisdom there. The most important: "Continuous attention to technical excellence
and good design enhances agility"
This blog post offends me a little bit. The post screams hey, I am a cowboy programmer, and it almost implies that if you employ processes then you are stupid.
In this day and age, I would have thought finding the right tool for the right job is common sense. Apparently not.
Agile, among many other things, is not a silver bullet - it never was and it never will be. The key thing is to experiment and find what works for you, your team and your company. Most software projects are done in a team environment - putting a bunch of talented developers and designers together actually isn’t as simple as many seem to think. One example is right out of that original blog post:
> Given that I am not a fan of prescribed process as the solution to our problems, you can infer my opinion of the general quality and effectiveness of those programmers who teach these courses.
From that attitude, I can already see that he is an interesting developer to manage.
A team needs to function efficiently as a team. Having one or two ace developers aren’t going to help a lot if they can’t get along with the others.
Not to mention that people have spent time and effort proving that techniques such as TDD work for certain projects [1].
As many things in life, there are always people who try to take advantage of others. No doubt there are questionable ‘agile consultants’ who try to make a fortune out of uninformed clients. Just because some people aren’t using agile effectively or even correctly, doesn’t mean agile itself is a sham. Developers constantly make mistakes and write shitty code - should we say all the programming languages out there are a sham?
Keep an open mind is important, and a lot of times even necessary. To dismiss agile all together is in my opinion childish, and offensive to others who try to improve things and create more value.
[1] http://research.microsoft.com/en-us/news/features/nagappan-1...
Originally posted at http://fredwu.me/post/20058808238/agile-is-not-a-sham
In this day and age, I would have thought finding the right tool for the right job is common sense. Apparently not.
Agile, among many other things, is not a silver bullet - it never was and it never will be. The key thing is to experiment and find what works for you, your team and your company. Most software projects are done in a team environment - putting a bunch of talented developers and designers together actually isn’t as simple as many seem to think. One example is right out of that original blog post:
> Given that I am not a fan of prescribed process as the solution to our problems, you can infer my opinion of the general quality and effectiveness of those programmers who teach these courses.
From that attitude, I can already see that he is an interesting developer to manage.
A team needs to function efficiently as a team. Having one or two ace developers aren’t going to help a lot if they can’t get along with the others.
Not to mention that people have spent time and effort proving that techniques such as TDD work for certain projects [1].
As many things in life, there are always people who try to take advantage of others. No doubt there are questionable ‘agile consultants’ who try to make a fortune out of uninformed clients. Just because some people aren’t using agile effectively or even correctly, doesn’t mean agile itself is a sham. Developers constantly make mistakes and write shitty code - should we say all the programming languages out there are a sham?
Keep an open mind is important, and a lot of times even necessary. To dismiss agile all together is in my opinion childish, and offensive to others who try to improve things and create more value.
[1] http://research.microsoft.com/en-us/news/features/nagappan-1...
Originally posted at http://fredwu.me/post/20058808238/agile-is-not-a-sham
"buzzword-compliant" that's a good one...lol
I do think think that there's a combo of simple techniques and rules of thumb, that, taken together, yield better results, with less ceremony, than Agile. And certainly far better than Waterfall, in the general case.
That combo (in my judgement) includes: iterative development, risk-driven prioritization, KISS/YAGNI, note-taking, scripted automation, CLI bias, FOSS, backups, version control and RDD (README-driven development). And several more, but these are among the biggest.
Because you don't necessarily need tests. You don't necessarily need pairs. You don't necessary need cards, or standup meetings. You don't need big upfront design. But you do need to produce working code. You should provide enough documentation to help you remember how things work and why, and bring new team members up to speed and/or project inheritors, and you ought to be flushing out assumptions or minimizing your biggest risks as early as you can, when there's still the most time to fix things, workaround, or abandon an approach entirely. These are rock solid, universal patterns I've seen over the decades. And they apply to small projects and large. Solo rockstars, small teams, large, etc. Independent of tech mix and software types.
And yes, ultimately the quality of people you have is the most important. They drive everything else: the choice of technology, tools, architecture, prioritization, morale, pace, resilience, etc.
That combo (in my judgement) includes: iterative development, risk-driven prioritization, KISS/YAGNI, note-taking, scripted automation, CLI bias, FOSS, backups, version control and RDD (README-driven development). And several more, but these are among the biggest.
Because you don't necessarily need tests. You don't necessarily need pairs. You don't necessary need cards, or standup meetings. You don't need big upfront design. But you do need to produce working code. You should provide enough documentation to help you remember how things work and why, and bring new team members up to speed and/or project inheritors, and you ought to be flushing out assumptions or minimizing your biggest risks as early as you can, when there's still the most time to fix things, workaround, or abandon an approach entirely. These are rock solid, universal patterns I've seen over the decades. And they apply to small projects and large. Solo rockstars, small teams, large, etc. Independent of tech mix and software types.
And yes, ultimately the quality of people you have is the most important. They drive everything else: the choice of technology, tools, architecture, prioritization, morale, pace, resilience, etc.
That said, this is a badly written article which doesn't convey much useful information or convincing argument. I am surprised it is on the HN front page,leave alone being the top ranked article (at the time of writing this comment).
Agile and TDD have been exhaustively discussed before on HN and an HNSearch will bring up much better arguments, both pro and con, from people who can clearly explain their viewpoints.