Agile, the ultimate flow killer?

DanCooper

Hi ppls, first time poster here in the dev forum. I've been working as a software developer for the last two years. Java, Eclipse RCP. Interesting really.

Recently I was invited onto a new team within my company and they intend on running the project as iterative/agile style. I've been thinking about it for a while, about agile as a concept, and I do like the sound of it but... there is always a but isn't there? The only reservation I would have is, does it completely go against the concept of "flow".

I'm sure you know what I mean by "flow" if you don't here is a quick description:

“Flow” is a term used in psychological circles to describe a human state of high concentration, which most people refer to as being “in the zone.” Whenever a person is engrossed by a task they become immersed in a state of flow and are oblivious to the passage of time, whilst experiencing a mild state of euphoria.

http://softwarenation.blogspot.ie/2009/01/importance-of.html

I just wonder, between daily standup meetings, pestering over/constant attention being paid to estimates and velocities...etc will a programmer really manage to get into a state of flow, is that a relax environment to achieve it?

On a side note, it seems to me that most office environments are completely gear towards breaking flow, between IMs, daily automated emails, meetings...etc one wonders when we would ever find the time and room to get down to it?

Anyway, those are my thoughts, what do ye think. Have any of ye worked on a true Agile team. How did you find it?

srsly78

Every place I work seems to have a slightly different idea about Agile...

Place I'm in now isn't so bad, short standup meetings, log time on jira etc. Rest of the time everyone just puts headphones on...

jimmycrackcorm

Seeing as a typical sprint lasts two weeks I would fail to see how flow us affected. A 15 minute standup at the start of the morning will not affect flow but lunchtime will, but the reason you have to eat.

Agile also emphasizes teamwork over the single developer. But getting it to work well is difficult.

jgh_

I've been working as a developer for about 7 years and I can't say I've worked in a pure agile shop... People tend to love doing the stand ups, but I generally find them to be at best the team leader exercising his "leadership" role, and at worst a total flow killer. Half the time I attend them agitated because they happen as I'm making a breakthrough.

I see the logic behind them, but I honestly feel like if my manager just wants to come by and ask me how things are going it would be a lot better. I feel like a lot of the agile methodologies are ego-stroking for people with management aspirations (I.e. not me)

robbiezero

Worked for a while in a bastardized Agile environment.
Had stand-ups every morning at 10, often up to 30 minutes.
For starters 10 o clock is a brutal time, just after getting into your flow for the day and it is interrupted.
Team of up to 15 people at the stand up - way too many.
3 different projects within the team, with the result that status updates were irrelevant to 2/3's of the people attending.
Stupid retrospective crap meetings which were just a waste of time.
Complete waste of time, but had to be done so as to be seen to be Agile.
Code freeze for a few days at end of sprint, basically do nothing time.


I actually quite like the Agile idea of delivering features/user stories in a short time frame, although it can put serious pressure on developers if they dont get estimates right, there can be a lot of late nights.

If its not done right it can lead to a pretty horrible code base, as the main focus can be on some visual feature to demo at the end of the sprint to show progress, so time is spent on getting this in possibly at the expense of code quality or testing.

ChRoMe

robbiezero wrote: »

Had stand-ups every morning at 10, often up to 30 minutes.

Heh, they managed to completely miss the point.

Mmmm_Lemony

If it's not done right then it doesnt work right. And it doesnt suit every environment as its a framework rather than a methodology. So trying to force rules on people who dont believe or support something will never work.

In a typical SCRUM setup, teams should be 7 +/- 2, with someone controlling, so having 15 people present at a daily stand up is ridiculous. And quality is paramount, so there needs to be someone there to control and monitor quality and define what 'done' is.

It's also about commitment and courage, and standing up and saying something isnt working. I've had no commercial experience with agile/scrum but I am genuinely looking forward to it.

I think if done right with scrum, the developers are given a level of self control and resposibility, which should improve how they see the job and themselves within the team, and with a strong and able scrum leader, to act as a go between, to prevent developers getting pestered by someone outside the group. And a product owner signing off on a complete product at the end of a sprint. Also everyone in the team (developers) decides how long something will take, so you dont get over zealous seniors saying 'ah we will bash that out in a couple of days', so overruns are less likely.

I think its a fairer system to developers than what I've worked at in the past.

COYW

jgh_ wrote: »

I see the logic behind them, but I honestly feel like if my manager just wants to come by and ask me how things are going it would be a lot better. I feel like a lot of the agile methodologies are ego-stroking for people with management aspirations (I.e. not me)

I agree on this point too. In certain situations, I think it is better to be left alone with your manager popping over, or vice-versa, to give a quick update. Scrum meetings turn into 30 minute plus events after a while, which is a waste of development time and it ends up breaking the flow of the day and annoying everyone on the team. The meetings should happen first thing in the morning.

Sparks

I've worked in a few places now where Agile was used, to one degree or another, ranging from using the terminology but not doing the task, to actually doing Agile but not calling it that.

I don't think it's a silver bullet, and I don't think it's even a good idea for some kinds of projects -- for example, anything where your product is going into a heavily managed enterprise environment with strict SLAs and supported lifetimes measured in decades shouldn't get anywhere within an ass's roar of Agile, which is predicated on quick, early releases to get functionality out the door as fast as possible. When your customers have multi-year adoption plans, the impedence mismatch is so high and the gains so minimal that it's just disruption for nothing.

That said, I saw it work really quite well in a web development shop for a year or so. It wasn't like we were all singing and dancing, but it did the job and it did it well, and to me that earns it a place in the toolbox.

I just think there's more than one tool in there, y'know?




ObNote: I've found, in general, that if people are sitting down during a standup, that your "Agile" process is probably not going to be worth the effort

ChRoMe

Sparks wrote: »

and I don't think it's even a good idea for some kinds of projects -- for example, anything where your product is going into a heavily managed enterprise environment with strict SLAs and supported lifetimes measured in decades shouldn't get anywhere within an ass's roar of Agile,

..........................

That said, I saw it work really quite well in a web development shop for a year or so. It wasn't like we were all singing and dancing, but it did the job and it did it well, and to me that earns it a place in the toolbox.

You have touched on one of the core things here. There is a huge difference between building a product... and working on a project. Agile product development is not usually a good fit, for the reasons you listed.

dazberry

We've started doing 2 week sprints, daily stand-ups etc. Problem is the organisation is very feature (i.e. sales) driven, so I'm not seeing it as a great fit in some respects, too much operational / urgent customer issues coming in and pushing stuff back into the backlog.

But having said that it feels progressive in the sense that a lot of the things put in place 10 years ago by the old school (all now left) that may or may not be fit for purpose have found a vehicle for review and replacement - for instance going from source safe to git and cruise control to team city - while mooted in the past was never "got around to" as feature driven but we found scope to put it in the sprints are progress has been made.

On a side note, it seems to me that most office environments are completely gear towards breaking flow, between IMs, daily automated emails, meetings...etc one wonders when we would ever find the time and room to get down to it?

It's just something you get used to, I've worked in some very disruptive environments, you just filter it out and get used to context switching back and forth. I'd actually find it difficult to work somewhere quiet now as I'm so used to all sorts of carp going on around me...

D.

Sparks

dazberry wrote: »

you just filter it out and get used to context switching

Sorry, but no, you don't. You think you do, and you can get to the point where you just complain internally or externally as much as you did in the beginning, but this question has been studied to death by psychologists and neurologists for decades now and the results are pretty much unequivocal - it doesn't matter if you do it a lot or a little, if you're young or old, male or female, or from any particular ethnic group, Homo Sapiens is just no damn good at context switching conscious tasks and everyone does better, faster work the less they context switch.

*ahem*
Sorry, pet bugbear that one.

GreeBo

dazberry wrote: »

We've started doing 2 week sprints, daily stand-ups etc. Problem is the organisation is very feature (i.e. sales) driven, so I'm not seeing it as a great fit in some respects, too much operational / urgent customer issues coming in and pushing stuff back into the backlog.

D.

Stuff going back onto the backlog isnt really your problem (as a developer)
It might get a bit annoying, but really stuff that has been started shouldnt be just stopped in the middle of something, it should be the lower priority things for the sprint (that should be done last) that get dropped.

If every sprint has these same unforeseen issues then you should be allowing for them in your sprint planning. If you average 5 points lost for these then take that off your velocity during planning, same as if you know someone is off that week.

Also, when things get dropped off and new things added, *I* think its important that the team doesnt always go the extra mile (overtime, weekends etc) to get it completed within the sprint; you dont want to train the business team that there is no downside to them chopping and changing their minds constantly.

DanCooper

Sparks wrote: »

Sorry, but no, you don't. You think you do, and you can get to the point where you just complain internally or externally as much as you did in the beginning, but this question has been studied to death by psychologists and neurologists for decades now and the results are pretty much unequivocal - it doesn't matter if you do it a lot or a little, if you're young or old, male or female, or from any particular ethnic group, Homo Sapiens is just no damn good at context switching conscious tasks and everyone does better, faster work the less they context switch.

*ahem*
Sorry, pet bugbear that one.

Hear, hear!

Looks like I started a nice discussion here, some food for thought before I get into this new project I've been put on.

IRLConor

DanCooper wrote: »

The only reservation I would have is, does it completely go against the concept of "flow".

It's implementation dependent.

For example, some agile places encourage pair programming. I can't see how you could possibly get into a flow state while talking to someone. Pair debugging can be great, but I've never been able to pair program with anyone without stifling the need to shout "Shut up and let me think!" at them.

If your employer/group's notion of "agile" is a brief standup at the start of the day and lots of short iterations that can be a great environment for flow. Almost no meetings and since everyone knows what they're supposed to be doing for the day, people tend to put their heads down and get it done.

DanCooper wrote: »

On a side note, it seems to me that most office environments are completely gear towards breaking flow, between IMs, daily automated emails, meetings...etc one wonders when we would ever find the time and room to get down to it?

I'm curious, what are all these meetings people go to about? At the moment I average about a meeting a week and the most I've had in the last year was averaging about a meeting a day and that's only if you count standups.

And what are "daily automated emails" when they're at home?

I find open plan offices the worst contributor to breaking my concentration. I can't work properly when listening to music - I find it too distracting - so headphones can't properly compensate for the noises. If I need to get some complex work done I work from home and turn off e-mail/IM/etc.

dazberry

Sparks wrote: »

Sorry, but no, you don't. You think you do, and you can get to the point where you just complain internally or externally as much as you did in the beginning, but this question has been studied to death by psychologists and neurologists for decades now and the results are pretty much unequivocal - it doesn't matter if you do it a lot or a little, if you're young or old, male or female, or from any particular ethnic group, Homo Sapiens is just no damn good at context switching conscious tasks and everyone does better, faster work the less they context switch.

*ahem*
Sorry, pet bugbear that one.

Dude, I feel your pain, I'd say I've done 10 of the last 18 years in sub-optimal development environments, and yes I've complained bitterly at times, to no avail. I don't condone it and I never liked it personally, but I've still had to delivery in these environments and you DO find ways of working because you HAVE to, like it or not.

I spent over 7 years in a finance company that for instance put support and development together, and then lumped us beside commercial sales all in an open plan office, and in true Dilbert fashion no one was allowed wear headphones. I can't listen to music and develop at the same time anyway so it's a mute point, but for me I had already learned to filter it out, it just becomes white noise...

D.

DanCooper

IRLConor wrote: »

It's implementation dependent.
I'm curious, what are all these meetings people go to about? At the moment I average about a meeting a week and the most I've had in the last year was averaging about a meeting a day and that's only if you count standups.

I'm probably being a bit over the top with this one, I really don't have that many meetings these days. One a day at most right.

IRLConor wrote: »

And what are "daily automated emails" when they're at home?

Someone decided to put all developers on the build/test email list. If anything goes wrong we all know about it. I guess with the notion that someone will get down and fix it quickly, which I can't or at least find it hard to argue with.

srsly78

Daily automated mails? That's nothing... how about hundreds of automated mails per day from continuous integration? Can't complain seeing as I'm supposed to look after the builds tho.

IRLConor

DanCooper wrote: »

I'm probably being a bit over the top with this one, I really don't have that many meetings these days. One a day at most right.

Yeah. Any more than one meeting a day on average and someone is doing something very wrong somewhere.

DanCooper wrote: »

Someone decided to put all developers on the build/test email list. If anything goes wrong we all know about it. I guess with the notion that someone will get down and fix it quickly, which I can't or at least find it hard to argue with.

Ah right, I'm mostly in favour of those if it's reasonable for you (in the context of your job and your team) to dive in and fix the problem.

If it's purely informational, then it gets filtered very quickly.

GreeBo

Do you guys not take regular breaks every hour (or 40 minutes if you are going by the book)?
Do you find this impacts you or not, perhaps not because you are not switching to another specific context (problem!)?

srsly78

Yeah I go for a fag every hour or so, but for some reason manager keeps glaring at me. I just shrug and mumble something about health and safety.

Sparks

GreeBo wrote: »

Do you guys not take regular breaks every hour (or 40 minutes if you are going by the book)?

Not when I get into the swing of it; I'll try to take breaks two or three times during the day, but that regular break every hour thing doesn't really apply to the design phase (or the debugging phase if you're doing it right) because it originated for typists who would be typing for 40-60 minutes straight doing dictation; contrast that kind of work with someone doing design work, where half the time you're reading stuff rather than writing, and the writing you are doing is whiteboarding more than coding (as in, scribbling in a notebook or on the wall, not coding at 120wpm).

You *do* need breaks, but I never thought that that one-per-hour rule made much sense for developers*.




*I'm not counting regular eye relief breaks, where you look away from close-focus objects like your notebook or your screen to far-field objects like the outside or whatever; those you should be doing a lot more often than once an hour and generally, I just do that when I'm trying to think about stuff anyway.

GreeBo

I probably average a break (away from my desk) an hour, but they are on my terms.
So if I am in the middle of something I plough ahead, but if I have just finished something or am at a natural break in flow then I will hop up and get a cuppa, have a chat in the kitchen etc.

That said I typically find that I do most of my work when everyone else has gone home, especially if I'm in hardcore coding or problem solving mode. Its not unusual to realise thats its 10pm and all the other lights in the building have gone out! (and Im freezing!)

ChRoMe

GreeBo wrote: »

Its not unusual to realise thats its 10pm and all the other lights in the building have gone out! (and Im freezing!)

Dont let that become a habit.. its bad for you both personally and professionally.

DublinWriter

This is one of the things that always makes my blood pressure go through the roof about IT and IT people.

All you need to know about Agile is contained in the original Agile Manifesto.

One of the first principals of this is 'Individuals and interactions over processes and tools'.

I can't stress that first principal strongly enough.

Agile as practised in most organisations now just pays lip-service to the original ethos and has degenerated into as formalised a process as any of those management fads of the 90's such as TQM, Kanban and Kaizen.

Dboy85

Code reviews on a 100 odd commits an hour...now that's a **** buzz

Manach

I'm more in maintaining legacy code so agile does not impact myself. I've seen other teams have a very regimented utilisation of Agile, as mentioned by DublinWriter. Personally I'd work the normal 9-5 office hours, with a break at lunch.

Duggys Housemate

Scrums are 0(n^2) in terms of man hours wasted. At a one minute talk per person at a 15 person scrum is 225 man minutes or approx 4 man hours. A 30 minute scrum for 15 people wastes a man day.

Agile is a tool, it can work, it can be abused.

GreeBo

^ isnt that part of the reason why scrum teams are supposed to be small teams, 7/8 people?

conor.hogan.2

GreeBo wrote: »

^ isnt that part of the reason why scrum teams are supposed to be small teams, 7/8 people?

And short, like 5 mins or so otherwise take it outside the standup.

Smoggy

ChRoMe wrote: »

Dont let that become a habit.. its bad for you both personally and professionally.

It's actually worse than that, it's bad for all of us in development.

Firstly it makes overtime and late nights become the norm and then it's expected, this has a domino effect, other team members feel under pressure to be doing the same hours, other teams are then required to cover this extra work, such as QA etc

Secondly it lets management off the hook for bad project planning, again leading back to late nights and long days being required to get the work in, in time.

Now I know many developers enjoy thier job and would be happy developing at home as well as in work, but the unseen impact is quite large and we aren't doing ourselves any favours.

Have you ever wandered the office @ 10 o'clock looking to see who is in from HR or the Finanace departments ? I think you will find these offices empty. So why is it expected that Development will be doing these late hours and not the other departments ? This is because we bring it on ourselves by working late for fun.

Edit : Im in work today - So maybe this accounts for some of the bitter tone to the post