• Post Reply Bookmark Topic Watch Topic
  • New Topic

My 'first' scrum experiences. Was it all waterfall before?

 
Jan de Boer
Ranch Hand
Posts: 624
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am new to a scrum team, and I am having mixed feelings about it.

I work in a company with about 50 developers. Our manager constantly says that scrum is the alternative to waterfall, and waterfall is bad. And we all did waterfall before, and it is old fashioned. Scrum is good.

I think he is totally exaggerating here. I have about 20 years of experience, and the real waterfall model, I only saw in practice in big mainframe systems of large banks. In almost all other companies there was a good mixture of planning ahead, and coming back on it, when the goal was not feasible, or the product probably was doing what was described, but not useful for the customers. If you see something probably won't work, you say that to the other people, even if they are higher in rank. So, I do not see this 'it used to be waterfall always, and that is bad'. I was not completely waterfall before. Yes, perhaps 30 years ago in mainframe programming, but in practice this bad waterfall thing to me was something of the seventies. Not something recent.

Furthermore I think now this scrum thing is going to the extreme. And sometimes it gets on my nerve, and it actually takes the pleasure out of programming for me. You used to get a task, and you would do it to your best abilities, but of course you would not keep all knowledge for yourself. What happens if you walk under a tram? But you could go in deep into some problem at least for a few weeks. Now we forcefully have to divide tasks in stories that last only a few days. You cannot work it out completely, and if you are done, you must drop it again. After two weeks there is the sprint review.

So I am beginning to dislike at least this obsession with scrum like it is some divine idol we must revere. It múst be a two weeks period for a sprint, it múst be a task of a few days, we must dual program. Even if you would like to dive deeper into a problem at least sometimes. Also because criticism towards scrum is seeing as being old fashioned...and bad. I sometime have had it with this scrum here there and everywhere as a holy grail. Now if that manager guy is talking about scrum...okay, I think: 'oh please, cut the crap..'. Sorry but I do think that sometimes.

On the other hand, they seem to be happy with my work in the present scrum team, so I have adapted myself to the process. I am just not into this black/white, good/bad, scrum/waterfull..

 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are many people who feel the same way as you do. I would say a good percentage of the people I've dealt with in my own journey to Agility feel and react this way. Interestingly enough, more often than not, they will have a programming background and experience very similar to yours. I too have similar experience, having worked for a few banks, programmed in traditional settings and older languages like COBOL (IBM mainframe) and RPG (on AS/400) on occasion. Sometimes the enthusiasm that proponents of Scrum and other Agile methods can get on people's nerves and it can be a source of great angst for people trying to make a shift from a familiar way of doing things to a very different and unfamiliar way.

Scrum and other Agile methods are not silver bullets and anyone saying otherwise is trying to sell you something. But as with any other method, they require you to understand and buy in to them. I think that with Scrum and Agile, you need even more of that because it's not really so much about two week sprints and stories that are decomposed to a few days worth of work. There is a requisite shift in mindset and attitude that's needed to fully comprehend and accept the premises of these methods and if you're not there, then it will always grate on you and you will naturally resist it. So to me, the key to getting comfortable with and more accepting of Scrum is to really understand the reasons for doing things that way.

Then again, there are the few who just can't make that shift in mindset. And that's fine, I have encountered people like that, too. Sometimes that's just how it works out and there's nothing much you can do about it except to come to a mutual understanding to part ways. And we've done that on our team, too.
 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan de Boer wrote:I sometime have had it with this scrum here there and everywhere as a holy grail. Now if that manager guy is talking about scrum...okay, I think: 'oh please, cut the crap..'.

I'm curious, what exactly has this guy been saying that makes you say that he's touting Scrum as "the holy grail." And what is this manager guy saying about Scrum that makes you think that it's all just "crap"? Are his actions not consistent with what he's saying? Does he say one thing but yet does something totally different? I'm not saying that your take is wrong but I'd like to get a clearer idea of what the other party is saying and what you're seeing that you haven't really detailed out to us.

There are many people out there who get Scrum wrong. They go for a two-day course, get half-baked ideas about what Agile is and then start regurgitating twisted nonsense to their teams. This is not an uncommon occurrence. On the other hand, there are folks who are just over-the-top gung-ho and excited about the possibilities of Scrum and Agile and they are just so excited to start seeing the benefits promised by it. Sometimes their zeal can be seen as obnoxious and/or off-putting even if their intentions are in the right place. Which one do you think it is in your situation and why?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36007
422
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that Scrum is not a holy grail, but has many good points. Have you read a book on Scrum yet? I recommend the [url=http://www.amazon.com/review/R2IVXVQ238RXK4]The Scrum Field Guide: Practical Advice for Your First Year/url]. In addition to covering the *why* for how these practices help, it shows how Scrum should be done and how to make it better. Many things in Scrum are meant to be customized. When my team started Scrum, we did three of four week sprints (I forget). We switched it to two weeks and it was better. I resisted the two week changes for a few reasons, but it did work out better and now I'm a supporter. This doesn't mean two weeks is right for all projects. Something to put in the retrospective for your team.

I suspect that your team might not be splitting up the tasks well. Back (before Scrum) when I was introducing my team to continuous integration, I was told that we couldn't *possibly* split up the work to commit often. I showed how a task could be carved up into smaller pieces. Scrum is supposed to make sure those pieces have business value.
 
Guillermo Ishi
Ranch Hand
Posts: 789
C++ Linux Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan de Boer wrote:Our manager constantly says that scrum is the alternative to waterfall, and waterfall is bad. And we all did waterfall before, and it is old fashioned. Scrum is good.

When I read about Agile, a lot of times my impression is that it incorporates a lot of what decent developers do naturally. But it seems like its purpose is to rob that experience from you and micromanage it back to you. A weekly or bi-weekly meeting to make sure things continue moving is all the participation a manager should have, in my opinion. The rest should be good team players doing what's natural. Got us to the Moon just fine.

 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guillermo Ishi wrote:When I read about Agile, a lot of times my impression is that it incorporates a lot of what decent developers do naturally.

Quite accurate. There are agile developers who don't even know or care that they are, in fact, doing Agile. They just do what they do. These are the folks at the Ri stage of their craft. Agile is more for the folks at the Shu and Ha stages. See Shu Ha Ri. There are those who might scoff at the idea of Shu Ha Ri or even dismiss it as a load of philosophical nonsense but I have found that being aware of it can actually guide you to the best way to approach many things. YMMV.

But it seems like its purpose is to rob that experience from you and micromanage it back to you. A weekly or bi-weekly meeting to make sure things continue moving is all the participation a manager should have, in my opinion. The rest should be good team players doing what's natural.

This is a common misconception and if it's happening on your team, there's something wrong. I go back to the analogy of "Aikido works; your Aikido doesn't." Similarly, "Agile works; that kind of Agile doesn't." It's not about micromanaging and sucking the joy out of development. When done properly, Agile creates an environment that is actually very satisfying for team members and they tend to be more engaged and eager to come to work. They are also more autonomous. The getting together frequently is about collaboration, planning, assessing progress, and quickly adapting to changes. You can't do that as well if your team only gets together once or twice a week. Managers become visionaries and obstacle removers, not commanders and slave drivers. That's what being a servant leader is all about.

Got us to the Moon just fine.

There are many who can't even ride a bike to the corner. This is mostly for those who are fumbling around in the dark, not so much for those who are blazing trails to the frontier.
 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wrote:There are agile developers who don't even know or care that they are, in fact, doing Agile.

And as a nod to our guest author, Sandro Mancuso, I really meant to say "...they are, in fact being Agile."

Agile is a way of being, an attitude, a mindset. As Sandro writes, "We don’t do Agile. Either we are Agile or we are not."

Looking forward to some great discussions this week. I have already favorited this book on Safari Books Online.
 
Christian Peacock
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:Scrum is supposed to make sure those pieces have business value.


That's the bit that I don't like.... I like to be free to spend a bit of time improving things behind the scenes (refactoring etc) that may / will have value further down the line, but how do you justify this to most business managers?
 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Christian Peacock wrote:
Jeanne Boyarsky wrote:Scrum is supposed to make sure those pieces have business value.


That's the bit that I don't like.... I like to be free to spend a bit of time improving things behind the scenes (refactoring etc) that may / will have value further down the line, but how do you justify this to most business managers?

I never have to justify doing a good job to business managers. Refactoring is part of development work and business managers have no business telling me whether or not I am allowed to refactor. The problem comes when engineers need to spend significant amounts of time refactoring without delivering an increment of value in the software. This is when I have the "Technical Debt" talk with them and the business managers to negotiate how much time and effort can be spent paying that debt down.

Often you just have to suck it up as an engineer and live and work in the filthy code. That seems to be par for the course in many places. In those cases, I still apply The Boy Scout Rule whenever I can.

The best answer to this is prevention. If you manage your technical debt and constantly keep your code clean, then there is hardly ever any need to ask permission to write quality code. It's just what you do as a good software developer. That's kind of the idea behind software craftsmanship.

I encourage you to read Professionalism and Test-Driven Development by Uncle Bob Martin
 
Jan de Boer
Ranch Hand
Posts: 624
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:I'm curious, what exactly has this guy been saying that makes you say that he's touting Scrum as "the holy grail."


It is not scrum as such. It is just a general personal quirk. What irritates me is the black and white picture. He is talking like: first only a few years ago, everybody was doing waterfall, and second we are one of the few companies who picked it up, and we are unique. That we are the good, and (most of) all the other companies are doing it bad.. As soon as something goes to 'us' and 'them', and 'we are smart' and 'the others are dumb', it naturally goes against my free soul. I will judge that for myself. I don't need someone to think for me and overload me with 'propaganda'. I want to make an independent judgment. (Of course I have the same thing in non computer related things. For example politics, relations. It is my personality.)

So if scrum is good, let it be good, but I will experience that for myself. There are a few things about scrum I really like. For example the daily stand-up. I used to keep on trying too long for myself when I am stocked. Now I tell every day, what my progress is. And then someone helps me to get going again. What I do not like is the two weeks sprint period. I had a discussion about it. And he told us that making it three weeks does not win anything. My answer, if it does not lose anything either, I would like it to be a little longer, because I find this is more pleasant, was laughed away, without arguments. Furthermore I think that scrum is 'noisy' sometimes. Yes we have to work together as a team. But also I want to have some time to figure out something by myself, in silence. I work the best like this. I am very sensitive to distractions. And if everybody is dual programming or something, I cannot get anything done at all.
 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan de Boer wrote:So if scrum is good, let it be good, but I will experience that for myself.

I certainly agree with the approach of finding out for yourself. This kind of skepticism is healthy and seeing for themselves is about the only way that skeptics can become bought-in. It works the other way, too, where a person's doubts are reinforced by the team's failure to follow a particular practice or set of practices in principle, rather than just form. That's why I always emphasize understanding the principles and values behind the practices when I coach teams.

Read more about that by searching for Cargo Cult Agile

Jan de Boer wrote:What I do not like is the two weeks sprint period. I had a discussion about it. And he told us that making it three weeks does not win anything. My answer, if it does not lose anything either, I would like it to be a little longer, because I find this is more pleasant, was laughed away, without arguments.

Here's a funny thing (not really in a "ha ha" sort of way) that I've noticed, and yours is just another instance of the same: People seem to be much quicker to blame Agile/Scrum/whatever for things that they dislike rather than try to deal with the real source of the problem: other people. In your case, as with many I have seen, your attempts to deal with the problem via the other people on your team did not go so well so now you resort to dealing with it on a personal level by saying you don't like the process and resent it. Furthermore, your failure to resolve the issue with the other people on your team turns into resentment for them as well.

I think this is a natural, human reaction. As a coach, I try to be sensitive to these things and try to work it out with the person who feels slighted or neglected. On the other hand, a skeptic needs to keep an open mind and realize that the process, Scrum, is not to be blamed. Scrum is just a framework and as such is subject to the vagaries of interpretation of the people who implement processes around it. If the implementors do not fully understand Scrum, its principles, values, and practices, then conflicts that could have very well been avoided otherwise are bound to arise. I think that is the situation in your case. It's hardly ever Scrum's fault. The inventors of Scrum and the proponents of Agile never set out to make these techniques oppressive to a certain segment of the population of software developers. The feeling that it is oppressive comes from some kind of conflict between the person's own values and principles and those of Scrum/Agile/whatever.

In his book, "The Software Craftsman," author Sandro Mancuso refers to these people as "The Wronged." Sandro writes that there is hardly anything that can be done with these people. I'm an eternal optimist. Most developers are. I always hold out hope for the skeptics if they come to the table and are willing to meet halfway. Otherwise, I have to agree with Sandro: there's little hope of ever convincing them that Scrum/Agile is meant to help rather than hinder the developer.

So again, it is important to understand the principles and values and see where those conflict with your own principles and values. Then you need to go back to the implementors and figure out where the disconnect/misalignment is happening. Anything short of this is just unproductive bitching and moaning. Sorry if that seems a little blunt but that's about as plainly and honestly as I can get to giving you what I think is the truth.

Jan de Boer wrote:Furthermore I think that scrum is 'noisy' sometimes. Yes we have to work together as a team. But also I want to have some time to figure out something by myself, in silence. I work the best like this. I am very sensitive to distractions. And if everybody is dual programming or something, I cannot get anything done at all.

Scrum is just a framework and as such, you can always modify certain aspects of it to suit your situation. The principle you need to go back to here is "Collaboration" -- Scrum/Agile encourages collaboration between all the folks involved in delivering the software. This is not a bad thing. However, as I explained above, you are falling into the trap of blaming Scrum for what you perceive as a conflict between your values/principles/preferences and what is happening when the team follows through with an activity or behavior that Scrum suggests to encourage collaboration.

Scrum itself is not noisy. How your team does Scrum may be noisy. How you perceive your team does Scrum may be noisy. The truth may lie somewhere between these two. Talk to your team and ask them to help you address your "noise" issues. If that doesn't work, then you probably have a decision to make: stay and try to adapt, stay and suffer in silence/resentment/defiance, stay and resist, remove yourself from the situation, wait until you are removed from this situation. Of these choices, only two are aligned with what I would deem as professional behavior.
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36007
422
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan de Boer wrote:And if everybody is dual programming or something, I cannot get anything done at all.

Junilu got at this, but I want to say it more directly: Scrum does not require pair programming. In fact, it doesn't weigh in on pair programming at all.
 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeanne Boyarsky wrote:Scrum does not require pair programming. In fact, it doesn't weigh in on pair programming at all.

A fact that is not lost on even the creators of Scrum. I attended a conference in which Ken Schwaber gave a keynote where he said he wished they had emphasized some of the more technical engineering practices from XP from the start. He reiterated that Scrum is just a framework and its focus is on process management. He said that Scrum works best when used with something like XP. That's why we need books like Sandro's because engineers need to be reminded that it's not all about process: we need to step up and make sure we are using techniques and following practices that promote technical excellence.
 
Jan de Boer
Ranch Hand
Posts: 624
5
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Junilu Lacar wrote:In his book, "The Software Craftsman," author Sandro Mancuso refers to these people as "The Wronged".


"The Wronged" ???

Now I am trying to keep an opened mind to this, but using this terminology does not really help. It's like the people who would not like scrum are not only "The Wronged" but "The Evil Ones", or even "The Losers" who are not good enough for our method. And that is the attitude I am feeling here presently. What ever the cause maybe, if it is not scrum as such then the team here. Now I am not that much against Scrum at the moment, but things like these does not get me enthousiastic about it either. I apologize. I will continue to read about it and try to understand it better though.
 
Junilu Lacar
Marshal
Posts: 10391
124
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan de Boer wrote:
Junilu Lacar wrote:In his book, "The Software Craftsman," author Sandro Mancuso refers to these people as "The Wronged".

"The Wronged" ???

Now I am trying to keep an opened mind to this, but using this terminology does not really help. It's like the people who would not like scrum are not only "The Wronged" but "The Evil Ones", or even "The Losers" who are not good enough for our method. And that is the attitude I am feeling here presently. What ever the cause maybe, if it is not scrum as such then the team here. Now I am not that much against Scrum at the moment, but things like these does not get me enthousiastic about it either. I apologize. I will continue to read about it and try to understand it better though.


It's unfortunate that this is how you perceive it. That you can read that much into the phrase "The Wronged" would seem to me a projection of the dysfunction you are seeing and experiencing on your team rather than an indictment of Scrum or what Sandro wrote in his book. In citing that part of the book, I was just trying to point out that it is the term Sandro used to refer to skeptics who felt that they are somehow being treated unfairly, which from what you have written so far, appears to be the case for you. My point is that it's unreasonable to blame Scrum for this situation. Scrum did nothing to you or to create the environment that makes you feel the way you do. Your TEAM created the environment and culture in which you work. If the team, and in particular, those who lead the team, have misinterpreted Scrum or did not adhere to the agile principles and values of collaboration and teamwork, then that's the problem that you and your team needs to address.

Here's the entire passage from "The Software Craftsman" about "The Wronged":
Sandro Mancuso wrote:
Identifying Skepticism Patterns
...
The Wronged: This is a dangerous type. Developers in this group think the company has wronged them. They usually feel they are underpaid, or never had the recognition they deserved, or are being unfairly treated. They usually don’t like the company and never miss an opportunity to badmouth it. In extreme cases, they may do things that can harm the project they are in just for the satisfaction of quietly saying, “I told you so. You got what you deserved.” Their presence on a team can be extremely destructive, contaminating other developers. And worst of all, they don’t resign. They just stay there waiting to be fired so they can press charges against the company.

This is quite an extreme position to be in but I don't think you're there, yet. Honestly though, you do fit the part that says "They usually feel they are... being unfairly treated."

Again, some people have personalities and preferences that make them well-suited for Agile methods, and some people just don't. I don't see the latter folks as "losers" or "evil" as long as they are still trying in good faith to contribute to the success of the project.

If you and your team can come to terms and recognize the differences in work styles and preferences and decide on the best way to move forward so that everyone can work the way they are more comfortable with, it should be fine. Maybe that means you have to work on things that don't require as much collaborative work like pair programming. Maybe you can do more system admin work or whatever. You and your team just have to talk it through. If that doesn't work, then perhaps it's time for you to look around for another team. I don't think you want to be "that guy" who just won't resign, right?
 
chris webster
Bartender
Posts: 2407
33
Linux Oracle Postgres Database Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I'm a bit late to this party, but it strikes a nerve for me, so here goes.

Let me start out with a bit of background. I worked for many years as an Oracle application developer, mostly doing Rapid Application Development using 4GL tools like Oracle Forms and so on. So for the first 18 years of my career, my experience of software development was that:

  • You can build software fast and early, based on your current understanding of the requirement.
  • When you find out more about the requirement or the real technical challenges involved, you can revise your code accordingly.
  • Rapid, iterative prototyping works well with the right tools.
  • Working in small multi-skilled teams on a limited set of functionality in each iteration works well.
  • Working in close collaboration with your users works well.
  • Some foundational stuff - like data modelling of your core entities - really needs to be done fairly thoroughly up front, but with experience you can design this stuff intelligently to make it easier to change later on.
  • If you don't yet know enough to realise that you need e.g. a Customer entity and so on, you should probably step away from the keyboard and do a bit more analysis with your users.
  • Never mind ideological prohibitions on "premature optimisation", some things really are a lot cheaper if you can get them right early on.
  • Contrary to what a lot of superficial Agile proponents claim, you can't just deliver what your users ask for, because most of they time they don't understand what they need any more than you do, and they will never really understand why they need to pay you to implement so-called non-functional requirements.
  • The easy stuff is easy to prototype and test on your users so it is cheap to change, just as Agile claims. But the hard stuff needs you and your users to think before you implement anything because these are the things that will cost real money to fix if you get them wrong.
  • So don't use your methodology as an excuse to avoid thinking about what is really required at each stage - your methodology X is no substitute for hard analytical thinking.

  • Anyway, right back in the dawn of time (1988), in my very first IT project, our small team of 2 analysts and 2 (very) junior developers delivered our organisation's first Oracle Forms RDBMS application on time, on budget, on scope and with very positive responses from our in-house customers, using a lot of techniques that I guess would today count as "Agile". Back then, I was so naive I thought this was how software development always worked!

    Since then, I've learned better, but until recently I never really worked on anything I would remotely characterise as "waterfall". In 1998 I completed a DSDM Practitioner course (DSDM being one of the early varieties of Agile) and felt that most of this new-fangled stuff was pretty much what I and my colleagues had always been doing anyway: we'd been doing Agile before Agile existed.

    Later on, after being exposed to a lot more Agile rhetoric, I read James Shore's "Art Of Agile Development", as well as "The Pragmatic Programmer" by Dave Thomas/Andrew Hunt. I thought there was a lot of good stuff in both those books, but a lot of it also seemed to be aimed at a "waterfall" 3GL world I had never really worked in anyway. I am still convinced that the Agile caricature of "waterfall" is mostly a strawman for propaganda purposes. Or maybe they were just doing waterfall wrong?

    Since 2005, I have worked on several enterprise Java projects for various organisations that loudly proclaimed their commitment to Agile at every opportunity. Not one of these has been able to deliver anything like the productivity, quality or cost-effectiveness that we dinosaurs used to achieve in pre-Agile days. Indeed, the closest I've ever experienced to the caricature of "waterfall" was on a noisily (indeed aggressively) "Agile" enterprise Java project. In many cases, we have been swamped in Agile Ceremony - my current office is like the most boring kindergarten in the world, festooned with post-its and scrawled-on white-boards as outward evidence of our Agility, while nothing actually gets delivered and developers spend days of each sprint marooned in the assorted meetings that are supposedly prescribed by this week's preferred flavour of Agile. We've done RUP, SCRUM, Kanban and to be honest I don't know which one we're on now, but I can always ask one of the legions of Agile Coaches who flutter around the hallways like lost meeting-moths inexorably drawn to yet another bloody stand-up. I swear if they could find Agile Aromatherapists, we'd have one of those on each team now as well.

    So, despite my conviction that much of the core Agile message is well worth listening to (based on my own experience before "Agile"), I have to say that a lot of the contemporary version of Agile smells rather cultish and dogmatically prescriptive to me. Like many cults, there is a strong tendency to close ranks against those who don't (yet) believe, to treat the sceptic as a heretic, and to indulge in blame-storming against those who doubt or struggle with the One True Faith. When somebody claims that their attempt at Agile isn't working, the Agile priesthood too often argue that we're just doing it wrong. But that's what Agile people always say when yet another member of the poor bloody infantry asks why this Agile stuff isn't working in their project.

    Now, this accusation of failing to implement Agile correctly may be true in many cases - I'd certainly accept that my own organisation is probably bumping against the Agile Cargo Cult end of the Agile spectrum! And in any case, Agile certainly isn't a silver bullet because - as we knew long before Agile - there are no silver bullets. But if we're more than 15 years into the Glorious Agile Revolution, in an industry that has been completely dominated by the Agile movement for at least the last 10 years, where most developers and indeed many managers have never really known anything else, why is it that so many of us are still having problems getting it to work for us on regular projects with regular teams of regular developers in regularly dysfunctional organisations?

    Maybe it's time to consider whether we need another approach to make Agile work better for more people more of the time, rather than just pointing the finger and blaming the heretics. And that includes the crude stereotyping that goes on in so many wanna-be corporate self-help books aimed at our hype-ridden industry (this is not specific to Agile, but seems to be a common feature of many Agile missionaries). Just because you might disagree with people, they are not "The Wronged" - maybe you should just try listening to them properly instead of preaching at them.

    So I sympathise with Jan's and Guillermo's comments above, because they are far closer to my own experience of working in self-proclaimed "Agile" environments, even though my now fading memories of the first half of my career remind me that Agile can work, even (perhaps especially?) if you don't call it "Agile".
     
    Paul Clapham
    Sheriff
    Posts: 21969
    36
    Eclipse IDE Firefox Browser MySQL Database
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    This sort of thing has happened repeatedly in the history of computer programming. In the 1960's, for example, "structured programming" was the new paradigm. It arose as a reaction to the morass of bad code being written with the heavy use of GOTO statements, and it was a revolutionary act to say that GOTO's were unnecessary as well as harmful.

    So a system was written for the New York Times which was hugely successful, and then everybody claimed that they'd always believed that structured programming was the way to go. However it soon turned out that the success of the Times's project was mostly due to the fact that it had been implemented by an extremely competent programmer. Before long it was evident that it was possible to write really bad code using only structured programming -- and I don't think that you'll be surprised by that. If you only have mediocre programmers, I think that no matter what system they follow you won't get anything better than a mediocre system.
     
    Junilu Lacar
    Marshal
    Posts: 10391
    124
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Problems will always be there no matter what method or process you use. That's because there are people involved and none of us are perfect. I realize that when you're a proponent of something, you're inevitably going to come across as preachy or dogmatic to some people. This isn't the first time I've been told this and I don't expect it to be the last. But I recognize that there are always at least two sides to a story and often even more. I have given up on trying to convince people about certain things, much less get into pissing matches. I'm at a point where I kind of know what Kent Beck was thinking and feeling when DHH came out publicly against TDD: you just state your position and leave it at that. You patiently try to correct misconceptions and point out what you think is really going on. If people take what you say as being "preachy" even though you recognize and acknowledge that there are many gray areas, what are you going to do?

    I agree, there are projects out there that are not proclaimed as "Agile" but are far more agile than those that proclaim themselves to be. I even hesitate to call my own projects Agile sometimes because we don't really live up to the ideals; but we keep trying to nonetheless and I think that's what makes the difference for us. I know Agility when I see it and because of that I'm compelled to point out when I hear people say "this is Agile" or "this is what Agile is about" when I know it's really not.

    I have been on many projects, too. I started out studying Structured Analysis and Design and structured programming. Back then, all that stuff made a lot of sense. I tried it but it never really quite worked out so well. But I kept trying anyway.

    My first project when I came to the US was a huge $36M failure, traditional waterfall. Everywhere I went after that it was the same thing over and over. When I read Beck's book about XP and Fowler's book on refactoring, I had a moment of clarity. It was almost an epiphany. I realized how it can work even though I had never really seen it fully work first-hand. But here's the thing about Agile that I have come to realize: it's not so much about the process or the rules, it's about the mindset, attitude, and the willingness and readiness to adopt and adapt, even if that means breaking the rules and making new ones. Most of all, it's really about the people you work with and treating them like people, not replaceable cogs in some big piece of machinery. It's about admitting that we still can mess up despite our best efforts. It's about owning up to our problems and taking responsibility. And here I am probably sounding preachy again. And that's fine if you think that. I can't help it, it's just what I believe and I know in my heart to be true.

    For the record, I think that the people who try to "do" Agile will never get it right. The only people who will get it are those who try to "be agile"; and they'll never be perfect either but that was never really the point.
     
    Junilu Lacar
    Marshal
    Posts: 10391
    124
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Paul Clapham wrote:
    So a system was written for the New York Times which was hugely successful, and then everybody claimed that they'd always believed that structured programming was the way to go. However it soon turned out that the success of the Times's project was mostly due to the fact that it had been implemented by an extremely competent programmer. Before long it was evident that it was possible to write really bad code using only structured programming -- and I don't think that you'll be surprised by that. If you only have mediocre programmers, I think that no matter what system they follow you won't get anything better than a mediocre system.

    Exactly. This is pretty much the gist of what I say to participants in the TDD workshop that I give at work: TDD is not a magic bullet. For it to work, you need to have the skills and the right mindset to make the most of the tools and techniques. A Stradivarius can't produce beautiful music in the hands of an untrained person; you need a skilled musician. Same thing for any tool or process you use: you need to know how to use it properly. It all boils down to the people and everything that they bring to the table, both good and not so good.
     
    Junilu Lacar
    Marshal
    Posts: 10391
    124
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Chris webster wrote:I am still convinced that the Agile caricature of "waterfall" is mostly a strawman for propaganda purposes. Or maybe they were just doing waterfall wrong?

    If you're being sold something then, yes, it will sound like a lot of propaganda. But for me, because I sincerely believe agile is a better way to work, comparing it to waterfall is just a way to provide contrast. For example, doing analysis and design up front for several months is not a "caricature" - it's the truth. I've seen and experienced it first-hand. And it's true that I have been told and have myself declared that "we need to get it right the first time!"

    These as opposed to doing analysis and design iteratively and incrementally. As opposed to making a lot of mistakes and learning from them up front so that you can get it right in the end rather than the first time.
     
    chris webster
    Bartender
    Posts: 2407
    33
    Linux Oracle Postgres Database Python Scala
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wow - thanks for such prompt and thoughtful responses, chaps. That's why we come to the Ranch, eh?!

    Junilu wrote: I realize that when you're a proponent of something, you're inevitably going to come across as preachy or dogmatic to some people. This isn't the first time I've been told this...

    Sorry if I seemed to be accusing you personally - I should have been clearer that this was more of a general experience. I'd say you are more "passionate and committed" - and you clearly have much more experience of doing Agile right than I do!
    Junilu wrote:I know Agility when I see it and because of that I'm compelled to point out when I hear people say "this is Agile" or "this is what Agile is about" when I know it's really not...

    Interesting - my experience is almost the mirror image of that: even after all these years, I still struggle to get a clear handle on what "Agile" really is, but I have started to feel like I know when something is not Agile. It feels like I've spent years in a world of Agile anti-patterns, so maybe my view of Agile is just particularly jaundiced!
    Junilu wrote:My first project when I came to the US was a huge $36M failure, traditional waterfall.

    Clearly I've been fortunate in not being exposed to classic waterfall (and no, I would never suggest the classic waterfall approach anyway). As a veteran of several, er... "challenging" public sector IT projects, let me reassure you that a $36m failure is far from "huge" compared to many government screw-ups, Agile or not!
    Junilu wrote:
    it's not so much about the process or the rules, it's about the mindset, attitude, and the willingness and readiness to adopt and adapt, even if that means breaking the rules and making new ones. Most of all, it's really about the people you work with and treating them like people, not replaceable cogs in some big piece of machinery. It's about admitting that we still can mess up despite our best efforts. It's about owning up to our problems and taking responsibility.

    Agree 100% with this. My only Agile-related dissent would come when - as happens on a lot of the "Agile" projects I see - self-proclaimed Agile experts insist "that's not Agile!", "you're doing it wrong!" etc without being prepared to demonstrate how to do it right.

    Junilu wrote:I think that the people who try to "do" Agile will never get it right. The only people who will get it are those who try to "be agile"...

    I think I understand what you mean here, and I'd probably agree. But this is also the kind of thing that encourages the sense of Agile as a New Age cult - if you're hearing this constant woolly criticism from people who don't seem to be able to communicate/demonstrate what they think you should do in order to become more Agile, it's hard to avoid a certain frustration at all the Agile Ceremony, especially when the available evidence in my organisation is that our (Cargo Cult?) version of "Agile" really doesn't work.

    Like Jan above, I'm inclined to say, "Don't tell me what Agile is. Show me."

    So far, I've seen a lot of "Agile" but not much that I think is really Agile. I'd love to work on the kind of Agile project you and many others have clearly experienced, because it sounds like a great way to work, as well as being more fun. But that's not my experience of the "Agile" brand so far.

    Paul wrote:
    If you only have mediocre programmers, I think that no matter what system they follow you won't get anything better than a mediocre system.

    This relates to my point about why we are still - apparently - so bad at Agile. The reality is that at least 50% of programmers are probably mediocre or worse (and personally I doubt there is a normal distribution of programming talent in the first place). Any methodology that only works for the top 10% is not really going to help most organisations, because many of them are going to be fairly mediocre as well. Either we need to be a lot better at enabling mediocre programmers to become better at Agile, or we need to find a different methodology that actually works for them. So far the Agile industry just doesn't seem able to address this problem.

    Anyway, enough rambling from me on this topic. Thanks for your input, folks.
     
    Junilu Lacar
    Marshal
    Posts: 10391
    124
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Chris wrote:This relates to my point about why we are still - apparently - so bad at Agile. The reality is that at least 50% of programmers are probably mediocre or worse (and personally I doubt there is a normal distribution of programming talent in the first place). Any methodology that only works for the top 10% is not really going to help most organisations, because many of them are going to be fairly mediocre as well. Either we need to be a lot better at enabling mediocre programmers to become better at Agile, or we need to find a different methodology that actually works for them. So far the Agile industry just doesn't seem able to address this problem.

    Thanks, Chris. This is why I love hanging out at the Ranch

    I think the 50% line between being mediocre and not is a statistically safe and logical bet Seriously though, in my experience, I have only been able to hire 1 out of 10 candidates that I interview at best. Some people tell me that I set a very high bar but you can ask Jeanne, who was gracious enough to try out my screening process and give me feedback, and I'll bet she'll tell you it's quite reasonable.

    I think you've hit upon the answer though, in a way. It's not that we are still so bad at Agile -- it's the fact that in general, software development efforts of any significant size and complexity are inherently difficult to get right. This will never change. Ever. But we can't start to solve our problems by pushing blame entirely out to whatever process we use. And yes, the process and organization or lack thereof contributes to our difficulties but things like Conway's Law also imply that communication and collaboration also play a big part in success and that means people are a big factor. The agile approaches account for this and help people take an honest and critical look at what they are doing that may or may not contribute to the success of the project. If developers lack skills, that's an impediment. If they're not refactoring and keeping code clean, that's an impediment. If they're not testing often or at all, that's an impediment. If they are not committing to technical excellence, that's an impediment.

    This is why books like Uncle Bob's "Clean Code" and Sandro's "The Software Craftsman" are important and I do wish more developers would read them. We developers also need to step up and do everything we can to raise the quality of our work. We can't just say "I'm going to do what I do and if things go wrong, then it's the process that's messed up." We also need to change, adapt, and be agile.

    P.S. And as far as methods working only for the top 10% of practitioners, again I think it's more about people rather than the methods. Only a very small fraction of the population have the talent and skills to be successful professional athletes, musicians, actors, stuntmen, artists, etc. This doesn't mean that nobody else has any business playing football or putting on concerts or plays or shows. They just can't be expected to perform at the same level that the top 10% do (although they can certainly aspire to do so). Wouldn't you agree that no matter what I do now, there's absolutely no chance that I'll ever play in the NBA finals with Lebron James and the Cavaliers? And I'm fine with that.

    As software developers, we have to know our own limitations and just do the best we can in our own little niches. As long as we put in our best effort and keep trying to get better every day, I don't think anyone can hold that against us.
     
    Junilu Lacar
    Marshal
    Posts: 10391
    124
    Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Some very thought-provoking statements by Marty Cagan at the recent #CraftConf in Bucharest

    Marty Cagan (Silicon Valley Product Group) - Great Engineering, Failed Product http://ustre.am/:4a0Cy

    Watch this and see if he describes your organization. His descriptions are spot on for most of the companies that I have worked for and even for my current company.
     
    What are you doing? You are supposed to be reading this tiny ad!
    the new thread boost feature brings a LOT of attention to your favorite threads
    https://coderanch.com/t/674455/Thread-Boost-feature
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!