My opinion after one year of scrum experience

[Jan de Boer]

My opinion after one year or scrum experience is not positive. I am happy that in my present job I like the subject I am working on, so I am not directly looking for another job. But scrum is not one of the reasons I like my present job. Now I only have scrum experience in this setup, so it might also be the scrum implementation here. At least that is what the scrum evangalists say here. My frustration are:

Scrum is almost like a religion with holy rules. The standup must be less than fifteen minutes. The sprint must take two weeks. These are sacred numbers. People who criticize scrum are a bit like like apostates according to the zealots, they are either bad programmers or have not understood scrum correctly.

Scrum to me seems noisy. This could also be just the team I am in. But the promotion of pair programming is not something I am happy with. Also I read some things about this in the agile books. Comments like, "they were now in a noisy room, but happy since they were communicating as a real scrum team" in the book of Kent Beck, Extreme programming Explained, sets my teeth on edge as a person who is rather sensitive to noise. (Yeah it is probably not what is litteraly written there, but that is what I remember. Somebody else got this book from our library now.)

Scrum here is a marketing sales argument to the upper management. We even got a price for it, for customer involvement, and our big company organized a department outing as reward. I was not 'energized' by this, and did not go.

Scrum makes idiotic claimes. With scrum everybody is happy, and half the team will produce twice as much? There is a book with such a title on the desk of one of our managers. I cannot imagine an intelligent person would take such a claim seriously, but it seems he did.

One things that has advangtages and disadvantages is continuous delivery. You might see errors sooner, but if you are working with old legacy code that falls over all the time, you constantly wonder, have I made a mistake in my code, or did a recent get-latest source base update cause it?

Another thing I do not like is always splitting things up in the stories that fit into the sprint. Sometimes I like to work a bit longer on the subject I am into. But I cannot do it. Why? It is not scrum. And scrum is sacred.


My conclusion after a year is that scrum is tiresome. I won't be defiant towards it. But it is certainly not a plus if a future employer tells me that my new work environment is 'totally scrum'. Mainwhile I just manage here and they are satisfied with my work sofar. I focus on learning new technical stuff, studying the scientific calculations we implement, and those are really interesting. Hiding from the scrum stuff, more or less.

[Tim Holloway]

Despite literally decades of demonstrated evidence to the contrary, There Is No Silver Bullet when it comes to software design.

You can shift around where the work gets done, for example, towards the compiling phase for strongly-typed languages such as Java or the runtime phase*, as in the scripted languages, but in the end, the total amount of time and effort to get an enterprise-grade product up and running properly is generally about the same.

Too often methodologies are used as an excuse for vendors to hype overpriced development software and by managers as medieval torture devices to keep the peons in their place. Agile is supposed to be about relaxed expectations under the understanding that getting something incomplete sooner rather than waiting a long time for a "perfect" product is a Good Thing and comes with the added advantage that user feedback as they see the system evolve will make the end result more in keeping with their true needs - as opposed to what everyone "thought" was needed originally. And trust me, I learned decadees before the term "Agile" was coined that once you put software in people's hands, they'll see possibilities that no one could have ever imagined, as well as the uselessness of many of the "must-have" features.

Two of your complaints are likely management faults. When the development process becomes too rigid, with over-tight scheduling, you're not only actually setting up a series of waterfalls instead of being agile, you're probably giving someone an excuse to force you to overtime. Secondly, if you're having problems keeping track of what's "in" and what's "obsolete", the entire team needs to work out better co-ordination techniques and management should have seen to that.

Agile wasn't intended to be a religion. But then again, neither was market economics or politics or any number of other things that people get dogmatic about. It's supposed to be a guide, not a god. When they start sacrificing people, it's time to cut and run.


===
*Or, as I call it: "The getting embarrased in Public phase", since nobody sees your compile-time errors, but with luck, your runtime errors will end up being documented on the front pages of USA Today and so much for being able to show visible results to management and users faster.

[Tim Moores]

I agree that a lot depends on the implementation of the Scrum process, and also that it is not a silver bullet. I think it doesn't help to say "Scrum makes idiotic claims", though - rather, it may be that some people make unrealistic claims about Scrum. That's not Scrum's fault. I wanted to address a couple misconceptions, though. While 2 weeks may be the most common sprint length, that's something teams should adjust to their own needs - in my last team, we switched to 3 weeks because we felt that suited us better. Also, pair programming is not a feature of Scrum. Use it when it helps (which is definitely not always), and don't when it doesn't. Thirdly, stories can absolutely be stretched over more than one sprint. That's just a reflection of not all tickets fitting neatly into a sprint, and is not uncommon. And lastly, continuous delivery is also not a feature of Scrum - both are independent of one another.

Overall, it sounds to me like the process you have to work with has not been tailored to the specific circumstances - something that should definitely be done to get good results.

[chris webster]

You might find this interesting: Why Agile and especially Scrum are terrible

His experience of Scrum sounds very similar to mine. My organisation is obsessed with Agile ritual (Scrum is just the latest in a long line of Agile cults here), although despite years of this cargo-cult nonsense it remains the least productive software development environment I have ever worked in. Like Tim H. above, I learned long ago about the advantages of being able to sit down with your customers and show them some working software, and I was able to do that successfully in the Old Days without all the Agile ritual that paralyses most IT projects I've worked on over the last 10 years.

Of course, lots of clever people clearly feel that Agile works well for them, and many Agile advocates insist that if it's not working for you, then you're just doing it wrong. But so many people are hitting the same problems with Scrum and Agile in general, that you have to ask yourself if maybe it's time to look at the problems with Agile, as well as the problems with individual development teams.

As Tim H. says, there's still no such thing as a silver bullet.

[Junilu Lacar]

Disclosure up front: I am what you might call an Agile "zealot" and one of those who believes that "Agile works, your Agile doesn't."

I agree, Agile is NOT a Silver Bullet, nor was it ever meant to be. It is, however, designed to highlight rather than solve problems in the way you develop software and I think that includes the case where you don't have the right combination of people, experience, and understanding of Agile principles and values to make Agile practices work for you.

For me, what's important about Agile is not its ceremonies and "rules" but the principles and values behind those. If you don't understand the principles and values and strive to stay true to them, then you'll be caught in this "Agile works, your Agile doesn't" trap, with frustrating and disappointing results.

The teams I work with do quite well with some technical practices like TDD and pair/mob programming. Not to brag but I like to think it's due, at least in part, to my being there to guide and mentor them. I hired all these guys and one of my criteria for hiring them was their teachability. In other aspects of Agile we don't do so well though. As for Scrum specifically, I think it's fine but to me, it's largely just another way to highlight problems in the team's communication and planning practices. But it's fine, we still use it. We muddle along and do our best and try to have fun in the process. Sometimes it's fun, sometimes it sucks. C'est la vie.

[Junilu Lacar]

chris webster wrote:You might find this interesting: Why Agile and especially Scrum are terrible

I won't dispute the author's experience with Agile and Scrum. I have seen the same thing happen in my group. It again boils down to a lack of understanding of the principles and values.

The one thing I'd like to point out is his statement about open-plan offices: "Open-plan offices are the most egregious example. They aren’t productive." A lot of what he writes afterwards seems to me like a matter of culture of the people using the space, not that of the space and its openness. Now, I have never worked in an open-plan office in all my years of development. For the last 8 years, I have worked from home and have done collaborative, pair/mob programming over WebEx, my company's preferred collaboration tool, and it has worked well. Today alone, I have already done 2 sessions of refactoring and design with other developers over WebEx. It works well in most instances but there are times when I ask the developers to go in so we can talk face-to-face in a conference room. It's not an open space but it's still a very collaborative effort. There are no questions or even hints of a doubt of our productivity and effectiveness in doing this. That's just our team culture and our manager will stand up for us and will quickly set straight any outsider who would question our doing this. Our track record of delivering relatively high-quality software and satisfying our customers also speaks for itself.

So again, I have to go back to my assertion that it's about understanding and staying true to the principles and values, not the implementation. We value being on the same page, collaboration, and doing the right thing. If we can do that by working in an open space, that's what we'll do.

I would also point out that some pretty successful companies have open-plan offices, like AirBnB, Google, Facebook, etc. and even at my company's main campus in San Jose, we have open-plan spaces where pairs and groups of developers can see and hear other pairs and groups working. I'm not saying it's for everyone but just because it doesn't work for you doesn't mean it doesn't work at all.

[Bear Bibeault]

I've worked in a number of "open office" environments and they all sucked. Horrible experiences. The whole "foster collaboration" thing is nonsense -- it's all about saving money.

[Tim Holloway]

Bear Bibeault wrote:
I've worked in a number of "open office" environments and they all sucked. Horrible experiences. The whole "foster collaboration" thing is nonsense -- it's all about saving money.

There's open, and then there's Open and then there's Slam the Door and Crank up the Stereo.

Open offices work best when you have a number of people swapping concepts around freely. But if they are too open, then the overall noise level can interfere with people communicating. It's one thing to be open to the group and quite another to be open to the whole company.

Open plans are terrible when you are sitting down to do code grinding. I do not care how many movies show hackers all jammed up against a terminal (whose text can be read reflected on the wall behind them) and they crack into the Pentagon in 25 seconds or less. Sometimes you have to get far from the madding crowd and think. On the whole, I prefer to do my debugging that way as well, although collaboration works for me. What doesn't is when people come barging in demanding instant service on something trivial when I'm 12 layers deep into a trace. I've told them that it would be less injurious to simply yank the chair out from under me, but it never helped.

Then again, like a lot of people, I do my best design work in bed or in the shower, not parked in some cubicle chair like an inflatable Bozo doll. And I'm rather picky about who I sleep and shower with, so on the whole it's better not to do that on an open plan.

And yes, the greatest blessing and curse of the profession has been cheap hardware. It makes everyone think that software should be cheap and people should be cheap and work environments should be cheap. And what kind of product comes from such expectations? Cheap.

[Tim Holloway]

Oh, and incidentally on Agile as inflexible dogma, it's best to remember the Agile Manifesto:

http://www.agilemanifesto.org/principles.html

Nowhere in there did they ever suggest straitjacketing the process for the sake of being Agile. Nothing about rigid schedules, rigid mindsets, rigid anything.

[chris webster]

On Agile, Junilu has argued a strong case on various threads for Agile done right. After years of Badgile, I would really like to experience a good Agile environment before I reach retirement age - can we all come and work for you, Junilu?

On open-plan offices, I'm with Bear. Every open-plan office I've worked in has been a nightmare and a massive drain on my productivity, not to mention my already limited mental resources. People complain about Dilbert-style office cubicles, but I dream of having my own cubicle at work, just a modest space that is at least partly sheltered from the relentless racket of constant stand-ups and phone calls and managers endlessly "communicating" at each other and their staff. I have to restrain myself most days from just barking out a desperate plea to everybody to just shut up for few minutes and let me complete a single thought in peace. Maybe that's what they're all yakking about as well...

Luckily, on my current project I can work from home a couple of days a week, which is basicaly when I get all my work done. Open-plan offices are the work of the devil, no doubt about it.

[Junilu Lacar]

chris webster wrote:On Agile, Junilu has argued a strong case on various threads for Agile done right. After years of Badgile, I would really like to experience a good Agile environment before I reach retirement age - can we all come and work for you, Junilu?

By no means are we a perfect Agile team but I think more or less we have the right mindsets and attitudes. More importantly, we have leaders in the right places who matter and support us and who shield us from the sh*t that other managers with less-than-Agile mindsets throw around. I would love to work with you guys and give you a chance to experience what I have with Agile, both good and bad. The bad is pretty much in line with all your bad experiences but I like to focus on the good because that's what has kept me going and chasing the dream of even better incarnations of agility

EDIT: I just got off the phone with a couple of developers I've been working with this afternoon. This is basically how I ended our WebEx session: "Thanks guys, this was a good session. We have a basic test now that we can use as a jumping off point -- yes, it's three lines of code right now and we worked all afternoon on them but we have a good idea of where we're heading with this and we'll fill in more details on Monday. In the meantime, I'll bone up some of the Spring annotations that you guys have been using since I'm not quite up to speed with those yet. I want to thank you guys for your patience with me, I know I can get excited and at times it may seem like I'm mad at you or use very strong language but it's really nothing personal, I'm just passionate about having clear and expressive code because I know it's the only way to stay sane in the long run. Thanks for your patience with me, have a great weekend!"

The rewarding thing for me is that these guys are excited to work with me and learn how to think backwards (how I describe the TDD mindset to them). They ping me at 10am when they know I'm usually done with my morning routine and then they ping me again after the scrum meeting at 2pm. We've had a great time these past two weeks that I've been back with their project and another developer has asked to get pulled in to our virtual TDD sessions even though he's working on something else. The downside to all this is that I have to find ways to spread myself around so I get a chance to work with everybody on the team. It's all good though.

Have a great weekend and don't lose hope on agility!

----
Note: you may be wondering why it took all afternoon for three developers to come up with three lines of test code. Well, we were looking at a Spring controller class that had over 50 lines of convoluted code, worked through what that code really wanted to do, figured out how to refactor, created a test where we could define what our controller code should look like, came up with four lines of clean, clear code after much discussion, then in the final minutes, one of the developers said, "Hey, we can push that line deeper into the service class because it can already do that if we pass this as the parameter instead." So we ended up with 3 lines that would make up the bulk of what the controller would do and all the rest of the junk we had to wade through earlier would be either throw away or pushed down deeper as implementation details hidden in a lower layer of the application. Pretty sweet, I think, even if we only have 3 lines of code in a failing test to show for it.

[Jan de Boer]

Tim Holloway wrote:Despite literally decades of demonstrated evidence to the contrary, There Is No Silver Bullet when it comes to software design.

Thanks!!

That is exactly why I do not like it here. So I am not crazy after all. It is seen by some as the magic way ... et cetera. The almost 'religious' aspect. I can live with it though. I do not hate it. And I can certainly see the advantages of some things, and I practice them as good as I can. But like everything in life, there is no magic formula to solve all your problems and you still have to think for yourself. And work hard. At some times here I felt like 'the only non believer in a cult'. I know I am exagerating here, but it was just a lonely bad feeling.

I continue working! :-)

[Tim Holloway]

I am antiquated enough that I've seen the rise and fall of 4GLs, Nomad, Rational Rose, Structured Programming, Magic IDEs, Offshoring and doubtless others that I have forgotten. Many of these "Silver Bullets" did have some value that continued past their heyday - for example, I use UML on occasion even now, although I laugh at those who covered whole walls with the things and piddled away 3/4 of their project time budget drawing stick-figure diagrams only to panic and shovel out ill-designed code as the deadline came near.

But none of them has every been the be-all and end-all that allows untrained monkeys to produce quality product in a hurry for peanuts. And I'm not optimistic that the next fad will be any better.

[Junilu Lacar]

Tim Holloway wrote:I am antiquated enough that I've seen ..., Magic IDEs

You wouldn't by any chance be referring to Magic Software and the supposedly 5GL language, are you? I only know a handful of people besides myself who had been subjected to it back in the mid 90s.If so, then that would quite amazing. What's even more amazing is that it looks like they're still in business somehow.

[Tim Holloway]

Junilu Lacar wrote:

Tim Holloway wrote:I am antiquated enough that I've seen ..., Magic IDEs

You wouldn't by any chance be referring to Magic Software and the supposedly 5GL language, are you? I only know a handful of people besides myself who had been subjected to it back in the mid 90s.If so, then that would quite amazing. What's even more amazing is that it looks like they're still in business somehow.

No, I never ran into it, although I dimly recall some hype about it. It might have made a bigger splash but people were still stinging from the relative failure of the 4GLs. Does remind me of another fad in the 1990s, though: Japan Inc, and Prolog.

By "Magic IDEs" I was thinking more about shops that think a powerful IDE with wizards could replace competence in their programming staff. Like my current signature says.

[Stevens Miller]

I'm joining this discussion because Tim pointed me here (so it's his fault).

Quick comments: I have worked at a dozen banks and a couple of research labs, under a mix of leadership styles and design methodologies. After all that, I agree with Bear about the money. Management typically wants us to use (or say we use) whatever technique gets the project done fastest. I was always the one who said we should design something before we write it, always being told, "we don't have the luxury of being able to take that much time on it." As though putting in the work to get it right was somehow luxurious. Wall Street, in particular, seemed consumed by its search for the magic bullet. Anyone remember RAD ("Rapid Application Development")? My managers all seemed to love it, though none of them could ever really tell me what it was. Sure sounded good. I mean, rapid, you know? (But, really, did they think we had been deliberately using Slow Application Development until RAD came along? Most likely, I suppose they did.)

I've never worked in an Agile shop, but my wife (when she still made her living as a programmer) has. She liked it, but my impression was that it worked well in those same places where people tend to refer to "computer programs" as "scripts." If your problem can be addressed in small increments, and the code required is fairly easy to write, once you've done your pre-coding work (often, the hardest part of a software project), then it sounds appealing. Back in the '80s, we used to call that "management by objective." I have found it useful, at times. For problems where you are trying to crack a complex nut, however, it doesn't always fit. For example, it's no longer a popular option, but one attempt at solving the "hidden-surface removal problem," (for drawing realistic pictures of three-dimensional objects) involves a points-polygons data structure, where you end up having to find all the intersections among the edges of polygons that make up polyhedra, as seen from a particular point in space. This turns out to be an exceedingly complicated problem, one that, as a research effort, revealed many of its challenges only after some working code started running. When working on it, the folks I knew sometimes had multiple successes in the span of a single week, while, at other times, a month would go by before that "eureka!" moment when someone had the insight necessary for the next move forward. It's hard to imagine scheduling something like that in two-week blocks, or even asking the researchers to join stand-up meetings.

On open offices: I worked for a Japanese bank, once. Man, that's brutal. They don't have cubes. They have one gigantic desk, where everyone has a kind of "berth" your chair sits in. We were all close enough to shake hands without leaning over. Place was as quiet as a library. No one spoke. People rarely even used their phones. Turning pages in a book was considered intrusive.

Ick.

When I'm on a tough software problem, I tell the wife to treat me as though I were Mr. Spock, deep in the state of plak tow, consumed with the blood fever, unable to respond to outside events until, at last, I rise victorious, arms held high, head thrown back, laughing at the failure once again of modern technology to stop my almighty- well, until I crack the problem. Can't do that when I'm not left alone to concentrate.

My own feeling is that almost all of the philosophies/techniques I've been asked to use could have been successful, productive ways to create software, but that nearly all of them are shams, because management just wants it done, done soon, and done without complaint.

[Bear Bibeault]

Stevens Miller wrote:as though I were Mr. Spock, deep in the state of plak tow

You are my new hero.

[Bear Bibeault]

Stevens Miller wrote:Place was as quiet as a library. No one spoke. People rarely even used their phones. Turning pages in a book was considered intrusive.

What a diference in cultures. The "project rooms" I've worked in were clamorous to the point of my bringing in ear plugs. And I'm mostly deaf to begin with!

[Stevens Miller]

Bear Bibeault wrote:

Stevens Miller wrote:as though I were Mr. Spock, deep in the state of plak tow

You are my new hero.

Oh, I can do better than that...

[chris webster]

Bear Bibeault wrote:

Stevens Miller wrote:Place was as quiet as a library. No one spoke. People rarely even used their phones. Turning pages in a book was considered intrusive.

What a diference in cultures. The "project rooms" I've worked in were clamorous to the point of my bringing in ear plugs. And I'm mostly deaf to begin with!

I think you're all onto something here. What do Badgile and noisy project rooms have in common, that distinguishes them from genuinely productive environments? They're both characterised by people talking about software development instead of actually doing it. Or maybe that's just how things are in my current workplace...

By the way I did RAD with 4GLs for 10 happy and productive years with lots of happy customers, until being swallowed up by enterprise Java and the Agile crowd. Sigh.

[Bear Bibeault]

[Stevens Miller]

chris webster wrote:By the way I did RAD with 4GLs for 10 happy and productive years...

Then do me a favor, would you Chris? I've waited a long time to find out: what is RAD, really?

[Jeanne Boyarsky]

Jan,
As Tim said, not everything you mentioned is required by Scrum. So some of it s your team's implementation.

In particular:

Scrum does not require 2 week sprints. You can do 1 week sprints. You can do 3 week sprints. My team used to do 3 week sprints. That didn't work well for us because too much changed from a priority point of view. There are some best practices. A 1.5 week sprint is probably a bad idea

Scrum doesn't require pair programming

Communication matters, but you don't all have to sit in the same room

The half the team producing twice as much is something to shoot for. I do believe it is possible though. Remember they are comparing to a "before" state of an extremely inefficient way of working. Picture a team of 10 people who attends two hour long status meetings a week and works on low priority work that doesn't need to be done. An extreme example, but it does happen.

Continous delivery isn't Scrum either. It's certainly a good thing, but it isn't from Scrum. Scrum requires showing the working functionality every sprint; not continuously

Does your team have retrospectives? (They should if doing Scrum.) This is a way to "tweak" processes that aren't working. Some of the things you are mentioning may be team culture that everyone likes. But they aren't all mandated by Scrum.

[chris webster]

Stevens Miller wrote:

chris webster wrote:By the way I did RAD with 4GLs for 10 happy and productive years...

Then do me a favor, would you Chris? I've waited a long time to find out: what is RAD, really?

Honestly? I think it was mostly a marketing label for the 4GLs to give managers a reason to buy into them.

I didn't actually use the term myself at the time, partly because I was working with 4GLs anyway so we were already doing rapid application development e.g. compared to traditional C or COBOL projects. I associated RAD with the kind of rapid, iterative prototyping cycles and frequent feedback from customers that we were able to achieve with these tools. When I did my DSDM practitioner course in 1998, all that groovy proto-Agile stuff felt like "So what? We've been doing this for years already".

I'd never seen a waterfall project until I started working in Java-land. Unlike most people around here, my experience of Java projects has been mostly SAD!

[Winston Gutkowski]

Bear Bibeault wrote:I've worked in a number of "open office" environments and they all sucked. Horrible experiences. The whole "foster collaboration" thing is nonsense -- it's all about saving money.

And yet, even in the twenty-teens, I don't know of a single IT company that practises the one thing that could save them a PILE of money - "flexible office" working.

Anyone remember the SunBlade? That was one of the first attempts at a truly flexible workstation. You stuck your card in and logged on, and you got YOUR desktop and home environment, regardless of where you logged on. I'm sure there are many such systems now.

The single biggest expense for western companies - and probably even more so now than back in the late '90s when I was studying this stuff - is real estate. Not equipment; not even people; but the space they take up. And yet IT management styles are still geared around the 19th century notion of "bums on seats". People not only have to work, they have to be seen to be working. And this despite the fact many areas of management - such as sales - operate perfectly well without having to see their staff all the time.

Study after study - and if I still had access to Bournemouth University library, I could cite dozens for you - have shown that, with a bit of training and organization, programmers can be happier, more motivated, and more productive if they spend up to three days a week at home (50% seems to be the cut-off point; after that you run into issues of exclusion and social interaction).
And it saves money. One particular case I remember reading about for one of my essays was a pilot "home working" project at a large company (American Express I think) in New Jersey that saved six million dollars in its first year, despite the design team freely admitting that they'd made tons of mistakes.

I even remember going to Munich in 2000 to install a server at one of Sun's new offices which was designed entirely around the idea of flexibility. You didn't have a desk, you had a trolley; and the workstations were all SunBlades, with the telephone system built into the desktop.

And yet even in these days of tablets and smartphones and "clouds", we're still only assumed to be working when someone can SEE us. So much for companies only being interested in the "bottom line"'.

Winston

[Junilu Lacar]

Well, Winston, meet my company, Cisco. Everyone on my team is a remote worker which means our commutes are as long as it takes to get from one corner of the house to another. When we all went remote a number of years ago, our branch office was able to take off an entire floor from the building lease. I imagine that was a hefty chunk of change that got channeled to other avenues. But I get to cut down on my carbon footprint tremendously as well, although my wife would argue I'm still polluting because I'm not inclined to shower as much any more

A large portion of our employees are remote workers. It's actually an official designation assigned by HR. It also saves me some taxes because my local township does not tax based on income, only property values. If I were an Office worker on the other hand, I'd have to pay income taxes to the county where our office is located. That's a good chunk of change as well.

I think most of all, it turns my commute time to whatever else time. We have very flexible hours which is not to say we don't work as many hours as we would otherwise. In fact, I find I work more hours as a remote worker than I would if I went in to the office every day. The only difference is that I work about 5-6 of those hours between 9 & 5, usually collaborating with other developers over WebEx and a couple of WexEx meetings sprinkled in. The rest of my work is done whenever I'm not running out to the kids' school, the doctor (which I seem to be doing a lot lately--getting old sucks), or running errands for my wife.

I get hit up by recruiters constantly but it's really hard to think about leaving a great team of developers and a working arrangement like this. Sometimes, when I think I'm ready to move on, the very thought of having to deal with morning and afternoon rush hour traffic makes me go "Nah, things aren't that bad." I will be celebrating my 10th year with Cisco (knock on wood) in August. The longest I'd ever stayed with any of the over 10 companies I worked for prior to this was almost three years. Having a flexible work schedule is a big part of the reason I've stayed as long as I have.

[Stevens Miller]

Junilu Lacar wrote:Everyone on my team is a remote worker which means our commutes are as long as it takes to get from one corner of the house to another.

Sweet deal, as long it lasts. When Marissa Mayer took over Yahoo! and wanted to cut staff, she didn't have to fire a single person. All she had to do was revoke their long-standing (and widely praised) work-at-home policy. The people she needed to shed all obliged her by quitting, saving her the unemployment costs that would have gone with firing them.

The success of this sort of thing depends, I think, on the people, not the policy. I will (I hope) never work for a Wall Street bank again, because the kill-or-be-killed attitude there infects even the programming staff (who, btw, are generally seen by the finance staff as vastly overpaid cost-centers, not partners in the business). When I moved to Virginia, a lot changed. People here generally don't start with the assumption that, to rise, one must stand on the corpses of one's colleagues (that didn't apply when I got into politics, but that's a different story). Work-at-home would have been a disaster on Wall Street. I suspect most of us would have been starting our own businesses, outsourcing our assigned work, and drinking. If, OTOH, you are blessed by the company of people who actually want to work together, I'd be quite ready to believe that modern communications technology would make you able to be productive as a team no matter where the individuals physically are.

Just don't get taken over by Marissa Mayer.

[Junilu Lacar]

Stevens Miller wrote: When Marissa Mayer took over Yahoo! and wanted to cut staff, she didn't have to fire a single person. All she had to do was revoke their long-standing (and widely praised) work-at-home policy. The people she needed to shed all obliged her by quitting, saving her the unemployment costs that would have gone with firing them.

The success of this sort of thing depends, I think, on the people...

Just don't get taken over by Marissa Mayer.

I'll only question one point there: did Mayer really shed the people she NEEDED to shed? I submit that she threw out a few babies with the bathwater.

Yes, our team's success is largely due to our having dedicated and competent professionals onboard. I also have to give credit to our former and current manager who provided/provides support and shields us from distractions that upper management would otherwise subject us to.

[Stevens Miller]

[quote=Junilu Lacar][quote=Stevens Miller] When Marissa Mayer took over Yahoo! and wanted to cut staff, she didn't have to fire a single person. All she had to do was revoke their long-standing (and widely praised) work-at-home policy. The people she needed to shed all obliged her by quitting, saving her the unemployment costs that would have gone with firing them.[/quote] I'll only question one point there: did Mayer really shed the people she NEEDED to shed? I submit that she threw out a few babies with the bathwater.[/quote]

Oh, point well-taken. She only "needed" to shed them in order to meet her goal workforce number. That what she [i]really[/i] needed was to keep her best people has something to do with what happened next at Yahoo!

[img]http://moneymorning.com/wp-content/blogs.dir/1/files/2015/07/0715_YahooStockPrice.png?306c1a[/img]

[Jan de Boer]

Bear Bibeault wrote:I've worked in a number of "open office" environments and they all sucked. Horrible experiences. The whole "foster collaboration" thing is nonsense -- it's all about saving money.

I do not know what it is about, but I think it is very dependant of the person. I, as a person, am quickly distracted and my productivity goes down to about the half of what it is in a reasonable silent room. I cannot change that. I cannot train that, it is unfortunately in my DNA I guess.

[Jan de Boer]

chris webster wrote:Luckily, on my current project I can work from home a couple of days a week, which is basicaly when I get all my work done.

My scrum-zealot manager says I can't. As a consequence I stay until late in the evening, and in the time after 5 when it is more silent, I catch up with the work I should do. My managers argument is that scrum is about the team and people should be in the team when they work. What can I tell him?

[Jan de Boer]

Bear Bibeault wrote:

Stevens Miller wrote:Place was as quiet as a library. No one spoke. People rarely even used their phones. Turning pages in a book was considered intrusive.

What a diference in cultures. The "project rooms" I've worked in were clamorous to the point of my bringing in ear plugs. And I'm mostly deaf to begin with!

I with you Bear. I also have a hearing disability, but wearing ear plugs. I sometimes wonder if constantly wearing ear plugs is good for your hearing. It does bring some extra pressure to your eardrum. But the thing is, the distracting sounds I can still hear, even with being a little deaf, while not being able to understand the words people are saying.

This leads me to another most probably very personal dislike of scrum. Why this taboo on documents? Normally in other companies I could not always catch what people are saying but it would be written down somewhere also. Now, everything is done in the scrum team meeting. Nothing is noted, I cannot hear half and forget the other half! Normally I could reread that stuff, but documents are not cool, scrum, lean whatever. :-(

[Jan de Boer]

Jeanne Boyarsky wrote:Scrum does not require 2 week sprints.

After a suggestion doing 3 weeks the "manager of my manager" presented us with some 'computer science articles' that 2 weeks was the proven 'sacred' number in 'literature'. Not doing two weeks was something like a 'scrum but'. Meaning other things are to blame if it does not work, but not the process. If it does not work in two weeks it shows another problem that .... et cetera. I gave up.

Jeanne Boyarsky wrote:Retrospectives.

I sit in the middle of the group, on purpose, and when I have to say something, I say I agree with the others. Criticizing scrum is a career limiting move. After a few times, learnt to keep my mouth shut. I am very sorry to negative, I really do not mean to. I do not even try to comment on the scrum process anymore. I try to ignore scrum and focus on the technology here. And frankly that is interesting. It is about exact science, calculations, physics, chemistry. Physics has been my favourite subject since I was 14.

[Jan de Boer]

Okay, thanks for the input. Next week I will have my year review. My manager will probably ask what I think of scrum, and might be expecting an enthousiastic response. I am not sure what I am going to tell him. Will be very diplomatic.

[Winston Gutkowski]

Jan de Boer wrote:Will be very diplomatic.

Not TOO diplomatic though.

Otherwise he might think you actually like it and make you scrum master.

Winston

[Junilu Lacar]

Jan de Boer wrote:This leads me to another most probably very personal dislike of scrum. Why this taboo on documents? Normally in other companies I could not always catch what people are saying but it would be written down somewhere also. Now, everything is done in the scrum team meeting. Nothing is noted, I cannot hear half and forget the other half! Normally I could reread that stuff, but documents are not cool, scrum, lean whatever. :-(

That's another misconception. Documentation is not taboo. Documentation that people spend a lot of time on that hardly anyone reads is strongly discouraged. Documentation that goes against the principle of being able to adapt quickly to change is strongly discouraged. Big Up Front Design specifications are strongly discouraged. Elaborate UML diagrams of software that hasn't been written yet is strongly discouraged. Detailed requirements documents and an onerous change process is strongly discouraged. These have all been found to be more trouble than they are worth.

Again, go back to the principles of agility to guide you in when documentation is appropriate. I suggest the book "Software Architecture for Developers" by Simon Brown. It has a whole part of it that discusses the kind of supplementary documentation that developers should maintain as part of their development effort. Simon calls it the "Software Guidebook" and I try to do that on all my projects and it in no way contradicts the agile principles that we try to adhere to.

[paul nisset]

Otherwise he might think you actually like it and make you scrum master.

Yeah,Don't get promoted to Scrum Master that really would suck !

Like everybody here, I've worked in a variety of environments. I've worked in an open plan office where everybody was a programmer and it was quiet. No noise issues.
It was more pleasant than a cube. I've also worked in an office where I had a cube but the person in the next cube was a meeting planner. Nobody (managers) in the office realized why I might need a quiet environment.

My take on methodologies is take the best you can is take the best aspects you can from them but don't be dogmatic about it.
It also depends on the type of software yo are working on. If it's a website, 2 week sprints for features might keep everything on track and moving forward.
I've never been in a pair programming situation but that would really depend on the two people involved ,their abilities and personalities.

Having a dedicated person whose sole job is "Scrum Master" seems like a recipe for failure.

There is a lot of BS about "Agile" out there. I worked at a small company where they decided the whole company ( 20 people 5 programmers) regardless of their role was going to be agile .
Witnessing them trying to apply the principals was comical. What does a sprint for a customer service rep look like?

[Junilu Lacar]

I think it's fine that folks feel comfortable enough to come to this forum and air their complaints about Agile, or as Chris calls it, "Badgile", which I think aptly describes the majority of Agile implementations out there. My own organization is not immune to these woes either. I'm just fortunate to have my little corner of the world where I can exercise a fair amount of influence and steer mindsets and actions in the right direction. In other parts of our organization, things don't go so well. I have seen colleagues whom I considered strong allies get laid off or leave on their own and that was unfortunate, IMO, for the organization. Even my former manager, after almost 10 years of putting up the good fight to shield us, her team, from the BS that continuously flies around us, was eventually compelled to leave for another group. She's much happier now. She still works for the same company, only now she doesn't have to deal with politics and BS. But she still understands and believes in Agile and she's still one of my strongest allies here.

The one thing that saddens me is that people seem to take their bad experiences with bad and downright bastardized implementations of Agile and generalize them to the whole idea of Agility. IMO, this is not in line with the spirit of learning that this community is known for and to which I am constantly drawn back. It's also sad that we've lost other strong proponents like Ilja Preuss and Lasse Koskela, who have since moved on to other pursuits. Having them here to provide a balance to the negative opinions about Agile was encouraging and I always welcomed and valued their inputs, especially on the more contentious and least understood aspects of Agile.

I'm glad that there are still folks around here who seem to get it though. I sense that Jeanne and Tim H., although they may seem to have a bit less of a "zealot" level of interest in Agile, actually do understand what I mean when I say "Agile works, your Agile doesn't."

[Tim Holloway]

I've accumulated a full-to-bursting toolbox over the years, and I'm always willing to add something new to it or find an excuse to use them.

At the same time, I'm not going to run around like the proverbial small child with a hammer. I try to be pragmatic, not dogmatic, and although I'll argue up a storm, I can be persuaded. In the end, what I look for is things that work, not things that support the One True Religion. I'm not here to attend worship services, I'm here to get a job done.

Agile appeals to me in that it's a lot like what I worked out for myself many years ago, and the actual Agile Manifesto is a reasonable document. On the other hand I have an extreme distaste for any solution being touted as a Silver Bullet, and I loathe people and organizations that use a Good Thing as a blunt instrument to hammer down the peons. I've also been known to make sarcastic remarks about anything that simply provides an excuse to bring in overpriced software and/or overpriced consultants.

[Junilu Lacar]

Tim Holloway wrote:Agile appeals to me in that it's a lot like what I worked out for myself many years ago, and the actual Agile Manifesto is a reasonable document. On the other hand I have an extreme distaste for any solution being touted as a Silver Bullet, and I loathe people and organizations that use a Good Thing as a blunt instrument to hammer down the peons. I've also been known to make sarcastic remarks about anything that simply provides an excuse to bring in overpriced software and/or overpriced consultants.

Well, I certainly hope that I don't come off as a little child with a hammer. I'm fully aware of the pitfalls of Agile and I have experienced many of them firsthand. I do take exception to any characterizing of a largely optimistic viewpoint as being "religious" or "dogmatic" (I'm not saying that you're calling me dogmatic or religious although those words have been applied to my enthusiasm for Agile more that a few times before). Even though I do often strongly argue for the positive side, I accept that there are, as any idea that involves human interpretation does, different ways it can be executed, many of which may not actually be effective or true to the original intent. That said, I'm with you 100% in your aversion to overpriced software and overpriced consultants.

Our group at work had been "rolling out" SAFe (Scaled Agile Framework for the Enterprise) but I wouldn't touch it with a 50-ft pole. My former manager got involved in the initial efforts but that was one of the reasons that she gave up on our group-wide Agile Transformation effort and decide to find another group where she and her ideas of Management as a Service had a better chance to gain traction. She really took her role as a Servant-Leader to heart and for the better part delivered on the promise with her direct reports. Upper management was a whole 'nother ballgame, however. It reminds me of what C.A.R Hoare wrote in his 1980 Turing Award lecture:

C.A.R. Hoare wrote:
There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way---and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

While our team strived to simplify our processes, both from the development and management sides, upper management brought in high-priced consultants touting "Agile Enterprise Frameworks" and hundreds of man-hours of training courses and consultations on SAFe. Last I heard, they're still trying to get it off the ground. In the meantime, business keeps moving and engineers keep doing what they need to do to meet deadlines and deliver software using whatever means they are used to, no matter the effectiveness or lack thereof.