tag:blogger.com,1999:blog-15136575.post8552499131563757790..comments2023-10-17T12:00:16.772+01:00Comments on Code rant: Coconut Headphones: Why Agile Has FailedMike Hadlowhttp://www.blogger.com/profile/16441901713967254504noreply@blogger.comBlogger99125tag:blogger.com,1999:blog-15136575.post-10484646863871366492020-07-31T02:31:25.811+01:002020-07-31T02:31:25.811+01:00It is the year 2020 and every so often I still sen...It is the year 2020 and every so often I still send this bookmarked link to threads (too often LinkedIn) where a bunch of PMs with the coding knowledge of a rutabaga bemoan the state of "Agile Project Management". Often with "we're going back to waterfall because agile doesn't work".<br /><br />Nothing has changed - and likely never will.Marakaihttps://www.blogger.com/profile/15394221702571617097noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-13808769575796718222016-11-22T23:58:20.157+00:002016-11-22T23:58:20.157+00:00I literally thought agile meant "stand-ups, r...I literally thought agile meant "stand-ups, retrospectives, two-week iterations and planning poker", LOL. The analogy to a cargo cult seems perfectly apt. I've never understood how in the world management agile could have ever come into existence - much less remain so long.Jessehttp://jesse-hogan.com/noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-207756203054601262016-05-06T12:38:51.938+01:002016-05-06T12:38:51.938+01:00Well... I think failure's often a matter of no...Well... I think failure's often a matter of not understanding things you use. Being aware of the fact Agile CAN FAIL in some situations is basic, for example Kanban http://kanbantool.com/kanban-library/kanban-results/when-kanban-fails . Relying on a method without beinng aware of its limitations is somehow not wise.Anonymoushttps://www.blogger.com/profile/16203789598614457209noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-78366700271225845732016-03-11T03:36:02.117+00:002016-03-11T03:36:02.117+00:00Agile seems dumb to me. As I developer I constantl...Agile seems dumb to me. As I developer I constantly am in the position of humouring semi-technical scrum masters and ceremony masters. Smiling and nodding like my job depends on it, meanwhile knowing that the real work will get done when I leave the open-air noisy office full of foosball playing amateurs and get home to catch up often into the wee hours of the night. Then if I'm tired in the morning I'm blamed for not "engaging."<br /><br />To me I think agile is more about companies trying to emulate Google or something and consequently is more of a marketing and/or feel-good thing than actually putting out working software -- because I know the software being put out often sorely lacks in quality and often doesn't hold a candle to the kind software written about by greats like Martin Fowler and Robert Martin. So it's not about software any more really, it's about appearances. After all most of the software is actually being written by freelancers or in overseas sweat shops. If the corporate/government shops in the West put out any working software it's probably at a 10x cost and thus is largely a token gesture perhaps to prove something, or out of necessity due to citizenship requirements etc., meanwhile agile practitioners have a strangle hold on the onsite shop -- any opposition to the dubious practice is stamped out. <br />Seriously I wouldn't mind the idiotic rituals if they weren't so humuliating and resonent of some mixture of a religious cult and a communist platform. Please, just give me a deadline some requirements and leave me in peace. I think only insecure newbies need "daily standups" to attain some kind of positive re-enforcement to compensate for their lack of software skills/interest.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-17559303340628681252016-01-18T21:40:44.044+00:002016-01-18T21:40:44.044+00:00geometric relationship between the length of an es...geometric relationship between the length of an estimate and its inaccuracy.<br /><br />what is "geometric relationship" in this context? <br />are we drawing geometric shapes or something? <br /> <br />or is it geometric progression? or what? kbmhttps://www.blogger.com/profile/11715398420377961933noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-47290181433135699462015-10-09T13:02:47.008+01:002015-10-09T13:02:47.008+01:00I have been working as a software engineer for ove...I have been working as a software engineer for over 7 years now and I can tell you that software development and software project management are completely different things. Software project management is not a method of leading software development but a series of methods for delivering software to customers. Software project management is not a technical discipline and that's why non-technical project managers can exist.<br /><br />Software development simply means taking a list of requirements and building a software that will fulfill them. Software development can exist without software project management and those doing software project management don't need to be able to do software development. <br /><br />That being said the methodology used by software project management has little to no impact on the actual software development process and as such I as a developer don't care how the project is being managed as long as I receive requirements that I need to implement in code. <br /><br />And another thing non-technical project managers don't actually manage the developers in the sense that they don't give them instructions on how to do their work. The influence that the project managers have on the actual development process is minimal to non-existing. In all my projects the project manager was the guy that came to us with the requirements from the client and asked us to give estimates. After a while he was coming back saying that the customer has approved that, that and that and we can start working. During development the project manager basically only tracked the progress and nothing more. If things didn't go as planed he was powerless to do anything about it other than report the issues and change the plan so that it will be in touch with the reality. <br /><br />Developers are really led by senior developers and software architects and not by non-technical project managers. Even when I worked in Agile environments there was always a team member who was the de facto leader and all the developers were going to him for advice. In one of my assignments the de facto leader was actually a software architect.<br /><br />So don't mind the project management methodology or the non technical project managers as they don't influence developers in their work, software development is the same no matter how the software project is being managed. And when talking about project and product managers always state the full title as these people are not real managers but rather links between the customer wishes and the development team. <br /><br /> Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-38611108133792679892015-09-23T09:01:18.215+01:002015-09-23T09:01:18.215+01:00Title is a bit misleading, SCRUM is probably a fai...Title is a bit misleading, SCRUM is probably a failure, Agile is fine.<br /><br />Don't think it's also fair to blame consultants for this, you can only blame the human nature, agile is more a different philosophy of doing things and most people are still not used to it.<br /><br />I see SCRUM as just a mean to an end: Introduce some agility while not scaring people and traditional management away.<br /><br />I agree with the main point of the post, if you have team of great developer and a good tech lead...you don't even need any kind of "process". Highly skilled and motivated people will always find their own "process". But the reality is different.mochihttps://www.blogger.com/profile/00553223563491477076noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-39894639535452152842015-09-21T16:27:20.428+01:002015-09-21T16:27:20.428+01:00IMHO, Agile has not failed, its just evolving.IMHO, Agile has not failed, its just evolving.Shreyashhttp://java67.blogspot.comnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-28767330506249885672015-09-19T07:07:41.544+01:002015-09-19T07:07:41.544+01:00I think this is a silly article that totally misse...I think this is a silly article that totally misses the mark. You can fuck up Agile and you can get Waterfall to work, and vis versa. It's not about the process. It's about the people. Do they understand why they practice any particular development methodology? Do they understand which ceremonies bring the values they require, and which ones don't? Do they understand the values and risks of said methodologies? If the answer is no, then the company has hired the wrong people, and/or failed to train them. Agile development is a means to end, not an end. The end is producing business value through software (or whatever you are applying your methodology to). <br /><br />With the right people, you could create great products using waterfall, or no formal process at all, in the right situations. 'Agile' (referring to all the things we might think of as agile practices) is neither good, nor bad. It's a set of tools to be used to support the efforts of an organization as they attempt to create business value. You pick and choose tools that make that effort easier, more reliable, safer, more predictable, etc. Whatever you value in a process, you choose those tools that provide those values. <br /><br />Agile, or any other set of tools fail because people don't understand what they want, what they need, and what tools will provide those wants and needs. To paraphrase the Agile Manifesto, People before process. It's the people stupid.<br /><br />Anonymoushttps://www.blogger.com/profile/09242297486267471138noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-28050465121813944152015-09-18T19:24:54.724+01:002015-09-18T19:24:54.724+01:00Agile is no silver bullet (cue shock, horror).
An...Agile is no silver bullet (cue shock, horror).<br /><br />Any process can be misused by idiots, even no process, and process is not a solution when the problem is "idiots".<br /><br /><br />A good team, with the right people in all roles including the developer roles, can use agile to good effect and will produce better results than if they are forced to use something else like waterfall (the straw man process).<br /><br />However, "a good team" means good people in *all* roles. Venting about the process is usually a sign of trouble. If you're genuinely being constructive about this where you work, and nobody is listening ... then why do you work there?<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-19273836982753973342015-09-13T21:18:22.113+01:002015-09-13T21:18:22.113+01:00Agree. But even Google has this bunch of non techn...Agree. But even Google has this bunch of non technical idiots and pays them charity while all they cause is negative influence in the teams. It is a strange world.ImmortalManhttps://www.blogger.com/profile/09183889555724613976noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-54648276453067695432015-07-02T07:16:30.254+01:002015-07-02T07:16:30.254+01:00@Ignatius:
you said:
"I would just like to ...@Ignatius:<br /><br />you said:<br /><br />"I would just like to caveat your warning about not using 'non technical managers' to manage software projects. A good non-technical manager will recgnise that where the expertise in the team lies and will trust them to make the right technical decisions. S/he will not use the agile framework to beat the team but will make sure the framework supports what they are trying to achieve.<br />Your concern appears to be more around the 'command and control' behaviours of certain managers (technical or non-technical) which is the real problem with agile implementation in the real world. Without addressing the cultural/behavioural shift required in an organisation, there will be a complete mismatch between management and development that cannot possibly be fixed."<br /><br />WOW.. ok.. there is a large elephant in the room you are missing. That elephant is this:<br /><br />A non-technical manager is very easily duped. Some people will actively lie to you to get their way. This is not theoretical with me, is based on direct observations of PRECISELY what I'm describing. Further, a non-technical manager will not have a bag of tricks to fall back on the LEAD their team in how to solve problems. Since software teams tend to be made of of many technically and/or emotionally immature individuals, the component of leadership simply cannot be overstated. In its absence, great chaos can happen, which affects not just delivery, but morale. <br /><br />I simply can't state strongly enough, non-technical managers depend on folks that can be trusted. But they lack the technical judgement to know when they are being misled.. and can easily be led into situations that are untenable and require tons of remediation. I prefer more resilience and less wishful thinking in managers. <br /><br />Maybe its just me ;)weezlhttps://www.blogger.com/profile/09214946890338702028noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-4721302098836306072015-07-02T07:06:24.656+01:002015-07-02T07:06:24.656+01:00You had me right up until 'self organizing tea...You had me right up until 'self organizing teams'.<br /><br />Everything else in your post is stellar and accurate.. but self-organizing teams? <br /><br />That one little concept requires something I've pretty much never seen.. a team that embodies these things:<br /><br />its small.<br />all of its members are highly experienced.<br />all of its members are emotionally very mature.<br />all of its members are fairly selfless.<br />all of its members accept that process must be understood, not just followed.<br />all of its members are all willing to 'do the boring stuff', and are all capable of leading on their own.<br /><br />All the teams I've been on have pretty much broken all these rules.. namely:<br /><br />very few of its members are highly experienced.<br />very few its members are emotionally mature.<br />all of its members are fairly selfish.<br />most of its members want to follow process, and not think.<br />Most of its members only want the cool/exciting work. Which means the rest end up getting the crap work all the time.<br />Most of its members don't want to lead.. abhor responsibility.<br /><br />What I'm describing are very HUMAN factors that prevent utopian situations from forming except in very rare circumstances. Yes.. it CAN happen. I've read about it. But I've literally NEVER seen it. <br /><br />I've been programming/managing programming for 30+ years now. I think the only real solution to the normal situations we find ourselves in is good management that recognizes individual effort, allows encourages freedom where there is obvious maturity, contains the immature, and seeks to motivate all based on their personality traits. There is NO process solution that works on its own. Its all about the people management side of it.<br /><br />Some of the points of agile are good (especially reacting well to changes as they come in).. but on balance the human factors are the ones that bite us, not the process ones. Take good managers and they'll converge on a good process for their products, and contain the natural chaos in their teams due to lack of maturity/experience. Take bad managers, and no matter what else you throw into that mix, you'll get chaos and crap. People people people. Get it right, your golden, get it wrong, your screwed.<br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-11964140119280262482015-04-24T22:30:07.838+01:002015-04-24T22:30:07.838+01:00Your biggest chip on the shoulder seems to be the ...Your biggest chip on the shoulder seems to be the non-technical manager which is, frankly, a red-herring. <br /><br />Pretty much all other industries are able to have non-SME managers create products, so why is software different? The answer, of course, is that it isn't, but that some of the people writting software want to believe that no one can understand them/feel their pain/delve the depths of thier suffering/ad nauseum without a technical degree. Which is just a gate. People who insist on technichal managers are simply gatekeepers, who hope, that if a suitable candidate can't pass through the gate, then they won't have to be managed.<br /><br />Senior developers, or team leads, fulfill the role of people who make decisions + understand the precious little programmer snowflakes. I wouldn't call them management, but the fact of the matter is that at some point, techs will need to interact with non-techs. Some will listen, some won't. <br /><br />I have seen examples of technical management who ignore issues and slavishly hold to deadlines. I have seen non-tech managers who will simply trust me, and adjust deadlines etc. when an issue comes up. Technical proficiency has nothing to do with good management. The worst managers in my experience are those that think because they can code, they can manage. <br /><br />But I know I am wasting my breath here. Too many developers think because they can code, they can do ever other job at a company, better than people who have degrees in that field, because, ya know, everyone else is mentally inferiour. Sad.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-8774590438131451212015-03-27T13:53:38.561+00:002015-03-27T13:53:38.561+00:00Agile seems to be used by people that do have a cl...Agile seems to be used by people that do have a clue about what project management is about. If you do not do project management (analyzing, planning,...) and thus you have unlimited budget, time, resources, scope Agile is the way to go. <br /><br />Can someone get rid of Agile PM please as it's method is opposite to what a good project is about. And too many companies do not even realize it...<br /><br />What comes to the technical vs non technical discussion, project management is a technical skill. A real PM can handle projects in SW development, infrastructure, building houses, engineering,... whatever the scope or technical area. So a project manager doesn't need other than PM skills. <br /><br />Good article, so people with an own opinion do exist. Thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-67068514186559511362015-01-27T18:16:06.892+00:002015-01-27T18:16:06.892+00:00Amen. I've been developing software for 30 ye...Amen. I've been developing software for 30 years, and being paid well for it in the process (as two mortgages, 3 private high school educations, 3 college educations and 1 wedding will attest. ).<br /><br />Bottom line: Smart developers have used agile techniques for many years, before "agile" ever became a formalized method. Short, flexible development sprints, agile estimation techniques, etc., have been part of our arsenal for a long time.<br /><br />What I see in the industry today is a bastardization of these concepts, in the name of adhering to a methodology. The result is a process that is about as "agile" as an overweight elephant with a ball & chain around each foot.<br /><br />I'm not sure what will satisfy those yearning for an academically attested methodology that is flexible and effective in delivering projects on time. The difficult news is that fundamentally, software development is all about understanding the problem domain, understanding the development tools, common sense, communication, hard work and... honesty.<br /><br />Agile? I've seen it work... sometimes. Usually, it is applied in ways that are anything BUT agile.David Arndthttps://www.blogger.com/profile/16705218457172595786noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-11615627813908108812015-01-27T18:16:06.247+00:002015-01-27T18:16:06.247+00:00Amen. I've been developing software for 30 ye...Amen. I've been developing software for 30 years, and being paid well for it in the process (as two mortgages, 3 private high school educations, 3 college educations and 1 wedding will attest. ).<br /><br />Bottom line: Smart developers have used agile techniques for many years, before "agile" ever became a formalized method. Short, flexible development sprints, agile estimation techniques, etc., have been part of our arsenal for a long time.<br /><br />What I see in the industry today is a bastardization of these concepts, in the name of adhering to a methodology. The result is a process that is about as "agile" as an overweight elephant with a ball & chain around each foot.<br /><br />I'm not sure what will satisfy those yearning for an academically attested methodology that is flexible and effective in delivering projects on time. The difficult news is that fundamentally, software development is all about understanding the problem domain, understanding the development tools, common sense, communication, hard work and... honesty.<br /><br />Agile? I've seen it work... sometimes. Usually, it is applied in ways that are anything BUT agile.David Arndthttps://www.blogger.com/profile/16705218457172595786noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-57168150441162500572015-01-25T21:38:51.106+00:002015-01-25T21:38:51.106+00:00Sometimes i get the feeling agile is just a moveme...Sometimes i get the feeling agile is just a movement trying to get rid of management...<br /><br />I agree, a lot of managers don't have the necessary skills to earn a management job.<br /><br />I would be glad if my teams were self organizing and delivering software on time and within budget with whatever methodology or software they feel to, but until now i noticed most of the software developers aren't capable of working in such way, so supervision is needed (monitor and control...). Sad but true...<br /><br />There is not one "best" methodology, framework, ... and people are always the crucial part.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-85760861882319991302014-11-15T17:50:59.328+00:002014-11-15T17:50:59.328+00:00Very good article. Agile methodology made my life ...Very good article. Agile methodology made my life miserable buat one point, I was brought in as a system tester on an air force project. ,<br />'The gang of four' developers had years to implement the project with little focus and direction. It was just a free for all to do what you want. I could not make good programmers out of childish ones and the gang of four freaked when presented with real testing and a geometric progression of increasing issues and bugs. Kill the messenger of course. This 'Agile is neither agile nor friendly. <br />Our government and ourselves as taxpayers are paying for this nonsense. I see Agile advertising and it makes me angry, is this the church of Scientology or something ?chrzyhttps://www.blogger.com/profile/06201881907902000647noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-75589913218681016392014-10-21T18:36:10.884+01:002014-10-21T18:36:10.884+01:00Attack non-technical managers all you like. Devel...Attack non-technical managers all you like. Developers left to their own devices will almost always develop a product that has no meaning in the marketplace. I've seen it time and time again at my company.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-32017359804000558692014-09-19T18:35:21.797+01:002014-09-19T18:35:21.797+01:00Consider me for a moment.
Years of experience in ...Consider me for a moment.<br /><br />Years of experience in developing software solutions, on a variety of platforms - working on small teams and large teams from time to time.<br /><br />Whether it was waterfall or something else, I always had the curiosity and motivation to approach "the business" whenever I didn't understand a requirement, or if it was incomplete or simply if my intuition told me it wasn't right. I had good managers, technical AND non-technical, who recognized a good thing and let it ride. They saw results, they trusted me, and they got out of the way. Things got done, and got done well.<br /><br />From 2010 to the present - I am increasingly exposed to Agile - specifically the Scrum variety. In some cases, mere lip service and we go about our business and deliver results. However, the hype reaches a fever pitch as Agile adoption starts to crest.<br /><br />Finally I land in a project that is completely sold out to the Scrum methodology. Never have I felt more restricted and hemmed-in by a process. Never before have I experienced the crushing overhead of daily meetings, status reports, poker-planning sessions that didn't really "plan" anything. Never before had I been asked to plan, design, develop, and deliver complex functionality in the span of a few days. That by the way, was intended to be production quality. <br /><br />My exposure to any business people or product owners was completely cut off. We had project managers, analysts, "UX architects", Scrum masters, etc. who interacted with the product owners. Not one single developer. <br /><br />Documented requirements for an epic or a story were typically a sentence or two, sometimes stretched to a paragraph if we were lucky. "Planning" sessions consisted of a half-day to maybe a day of rambling discussions where no decisions were made or any direction given. The developers on the "team" were asked for input from time to time, which was summarily dismissed or immediately trumped by a contrary opinion from a non-developer.<br /><br />Anyway, my good friend of 15 years, who I consider to be a better developer than myself, quit in frustration. He is now the proud owner of a Chick-Fil-A franchise in Alabama. I held on in that situation for another six months and then I left as well. I took an Architect job at a different company, who has cautiously adopted Agile methodologies on a FEW projects as a pilot. I just don't think I can function as a developer in that kind of environment. Anyone who is "selling" Agile, is going to sell management on the things they want to hear. Be warned.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-74094070778851161942014-09-03T22:34:06.224+01:002014-09-03T22:34:06.224+01:00The first sentence says it all "They identifi...The first sentence says it all "They identified that the programmer is the central actor in the creation of software, and that the best software grows and evolves organically in contact with its users."<br /><br />The customer is the central "actor" (another agile term i hate) in the entire process. The programmer is just a tool to achieve the end result. Wake up and get some common business sense. Also, software isn't grown organically like a plant. Software needs to be precise and written preferable once based on precise rules (aka specifications), smart coding and bullet proof testing. It's all about precision not iteration.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-74133161256378325662014-08-10T03:11:26.168+01:002014-08-10T03:11:26.168+01:00I have seen just about every crazy thing you can i...I have seen just about every crazy thing you can imagine happen under the guise of "Agile" process. Like one week sprints followed by the weekly production release. Like two week sprints that encompassed major pieces of functionality that were time-boxed then forgotten once the next sprint started. No matter the status of said functionality. In that project, I once worked 24 hours straight fixing 18 defects the weekend before a release.<br /><br />I also once saw a manager fire an "agile coach" who was getting paid $125 an hour, and the project took off like a rocket after that.<br /><br />I don't have a problem with non-technical managers - I've had some good ones. What made them good? They took the heat, and stayed out of our way. Because they knew we were good, and that we delivered.<br /><br />However - there are people out there with no background AT ALL in software development who are getting some sort of "SCRUM certification" and schmoozing their way onto development teams. That is never going to work in my opinion. I once worked with a guy that fits that description, who didn't understand basic, fundamental concepts about IT in general. It is a real head-scratcher how that could ever happen, but it does.<br /><br />There is no magic bullet. You have to have good people.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15136575.post-34110492923662101632014-08-08T06:24:44.596+01:002014-08-08T06:24:44.596+01:00I think you raise some valuable ideas but some of ...I think you raise some valuable ideas but some of them I question:<br /><br />* non-technical managers: my 20 yrs as a dev doesn't gel with this. The best manager I ever had was non technical. But she was very adept at honing in on exactly what she needed to know about the domain (but not more). Excellent people skills, encyclopedic domain knowledge, never scared to go toe to toe with management on behalf of her team or to push back against bs requirements. And a number of my weakest managers have been highly technical.<br />* I will back the output of a solid team with a mix of high-to-medium-ability members against a team entirely of genius assholes any day. <br />* James Shore's article says nothing about Agile failing, just about the spread of cargo-cult Agile. Just saying.charles mark fergusonhttps://www.blogger.com/profile/13385121479729236749noreply@blogger.comtag:blogger.com,1999:blog-15136575.post-67948686945818903142014-07-24T21:23:15.517+01:002014-07-24T21:23:15.517+01:00Where are those 10x and 100x improvements eh? Snak...Where are those 10x and 100x improvements eh? Snake oil at its finest...Anonymousnoreply@blogger.com