Hello
Join Lithespeed, LLC with Arlen Bankston and Sanjiv Augustine on
October 10th and 11th for a Certified ScrumMaster course in Washington
DC.
This course will introduce the essential concepts and tools of Scrum,
highlighting differences between agile processes and traditional
"waterfall" methodologies and providing a roadmap for adopting Agile.
Participants will learn how to lead development teams towards agile
operations by: managing product backlogs, planning releases and
sprints, tracking and reporting progress, and conducting
retrospectives. This course is taught by active Agile practitioners
with decades of real-world industry experience at companies ranging
from small business to the Fortune 100. Exercises, case studies, and
examples are interwoven throughout the course to illustrate the
principles being taught.
For more information, please go to www.agileuniversity.org.
Thank you
Jennifer Beaupre
info@...
This is the third week of September, and the time for our meeting. Thursday, September 20th 7pm @ Wired Monk, on the corner of Morris and Hollis streets.
I'd recommend "Agile
estimation and planning" by Mike Cohn. This book covers things like
estimation, iteration planning, release planning in other words how to
manage agile software projects.
On the software development side, there is "Test Driven
Development: By Example" by Kent Beck, "Agile Software Development,
Principles, Patterns, and Practices" by Robert Martin.
I'd also
recommend "Refactoring to Patterns" by Joshua Kerievsky and if you
spend a lot of time with legacy code "Working Effectively with Legacy
Code" by Michael Feathers.
And my favourite - "Domain Driven Design" by Eric Evans.
My name is Anthony Neal, I am a software developer here in the HRM,
and while I'm new to Agile (just starting to look into it seriously),
I am familiar and have used some of it's tenets.
If anyone can point me in the direction of some of the "bibles" of the
Agile methodology, that would be great.
Hope to see you all at the next meeting, whenever that is. :)
I'd recommend "Agile
estimation and planning" by Mike Cohn. This book covers things like
estimation, iteration planning, release planning in other words how to
manage agile software projects.
On the software development side, there is "Test Driven
Development: By Example" by Kent Beck, "Agile Software Development,
Principles, Patterns, and Practices" by Robert Martin.
I'd also
recommend "Refactoring to Patterns" by Joshua Kerievsky and if you
spend a lot of time with legacy code "Working Effectively with Legacy
Code" by Michael Feathers.
And my favourite - "Domain Driven Design" by Eric Evans.
My name is Anthony Neal, I am a software developer here in the HRM,
and while I'm new to Agile (just starting to look into it seriously),
I am familiar and have used some of it's tenets.
If anyone can point me in the direction of some of the "bibles" of the
Agile methodology, that would be great.
Hope to see you all at the next meeting, whenever that is. :)
While most of these wouldn't be considered "bibles" of Agile, here are
a few of my favourite books that relate to Agile Development in one
way or another:
http://on-agile.blogspot.com/2007/07/agile-bookshelf-10-must-read-books.html
If you're in the mood for a lighter read, I'd recommend "The Goal",
"Waltzing with Bears", and/or "Peopleware" to start. If you're in the
mood for something a bit more nitty-gritty, I'd recommend Robert
Martin's "Agile Software Development: Principles, Patterns, and
Practices" or Michael Feather's "Working Effectively With Legacy
Code".
Cheers,
Ryan
On 9/14/07, dorian_grey772000 <dorian@...> wrote:
> Hey everyone,
>
> My name is Anthony Neal, I am a software developer here in the HRM,
> and while I'm new to Agile (just starting to look into it seriously),
> I am familiar and have used some of it's tenets.
>
> If anyone can point me in the direction of some of the "bibles" of the
> Agile methodology, that would be great.
>
> Hope to see you all at the next meeting, whenever that is. :)
>
> -Anthony
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
Hey everyone,
My name is Anthony Neal, I am a software developer here in the HRM,
and while I'm new to Agile (just starting to look into it seriously),
I am familiar and have used some of it's tenets.
If anyone can point me in the direction of some of the "bibles" of the
Agile methodology, that would be great.
Hope to see you all at the next meeting, whenever that is. :)
-Anthony
Wow - that sounds like a frustrating spot to be in. It certainly sounds like this developer is having trouble taking on larger tasks and working without lots of guidance. I can think of many reasons why an otherwise productive developer could be in a slump, but it sounds like this person is permanently at this low level of productivity.
It sounds like you're between a rock and a hard place here if management is unwilling to do anything substantial about the situation (this sounds like a dysfunctional environment if they're putting up with this). I think talking directly to the developer is key -- but in a supportive, non-ultimatum fashion. I would suggest asking him/her what most motivates them and allow them to play a part in designing a role change. Make it clear that the current situation isn't a great one, and you would like to transition to one that works for everyone.
Interpersonal and emotional stuff comes in here big time. If this person is sensitive/defensive about their level of productivity, or just generally low/unhappy/depressed then handling this effectively is going to be a challenge. This also provides some opportunity though - if their low productivity is due to emotional factors (which it almost certainly is) - then there is a potential to work on this -- perhaps have the person talk to a workplace counselor.
Finally - it could be that you are simply working with someone who needs lots of hand holding, and who is never going to be very productive. If you're not given the ability to fix that situation, is it possible for the team to be able to accept this? Perhaps transition this person to a role that's more supportive, and less relied-upon by other team members? (An exploratory tester comes to mind - they don't block anyone, and anything they find adds immediate value) I think I'd like any approach which reduces tension among existing team members, and allows this person to feel like an engaged team member. Normally I'd try to reduce waste from an unproductive employee for the business's sake, but they don't seem concerned by it.
Unfortunately, I've been in a similar situation - I didn't have any clout to change it, and the business wasn't interested in change -- so we had to put up with it for a while. In both circumstances the business eventually took action by letting the employee go. I still think that wasn't an optimal solution - the business didn't gain anything from a person that could be useful in a different role, and the person let go probably felt bad about a somewhat hasty termination. Of course - there is a minimum threshold of initiative and independence that one must show - if they're below that, then I'm not sure they would provide value in any role.
Of course - I'm certainly no expert at this, but it's my 2 cents :)
Sorry for the late response, I've been very busy with work in the lead
up to my vacation.
I agree with everything you've said here, but ultimately I'm still
struggling for creative ways to engage this developer. To put this in
context, this developer joined the project in January of this year, but
the team only managed to get him to commit to tasks three sprints (six
weeks) ago. The team has tried lots of things, but nothing has really
worked, we just got different excuses.
I was really hoping that some of the scrum practices which have made
this behaviour obvious to everyone, would help address it. In part I
suppose they have, as to address this problem we have paid more
attention to executing the scrum practices. The standups have been more
focussed on discussing what was completed and in ensuring this developer
knows that anything that is preventing him from completing work is an
obstacle.
This has lead to the team doing more hand holding in order to resolve
these obstacles than any one seems comfortable with, but it has resulted
in something being delivered. It has not addressed the core issue, this
developer is free to continue making excuses for why he isn't able to
meet his committments.
I really like how servant leadership addresses this issue, i.e. agreed
upon performance standards, tempered with compassion and an
understanding of personal issues, highs and lows (as you mention below).
Given that this developers supervisor is unwilling to address this
issue, or move him to another project, I don't see many options left;
let this situation continue and hope it improves, address the issue with
the developer directly, or ask that I be allowed to leave the project.
Additional comments inline.
Dave LeBlanc wrote:
>
> Hi David,
>
> This sounds like a question that pervades all of the working
> environment, so I'd expect most of the good literature to be found in
> non-agile (and probably non-software) places. To me that kind of
> behaviour would indicate a really serious lack of motivation, and
> perhaps low morale. Has this developer always dodged work, or are they
> productive sometimes, and slow/stopped others? Is this an issue across
> the team, or isolated to 1 or 2 people?
The team is comprised of customer employees and contractors. I'm a
contractor. There has been a problem with productivity among some of
the customer employees for various reasons, some have other duties, most
are new to this technology, and some appear to work at their own pace
because there is zero oversight for customer employees, not even the
bums in seats kind.
The developer in question has previously worked alone in the same small
area for years. Its hard to judge previous levels of productivity
because he appeared to have very little to do. Perhaps that is the root
of the problem, he may have simply forgotten how to work in a team with
deliverables.
> If they just don't work at all I think I'd do what I have to do to get
> this person off the team. A team that accepts 'sandbaggers' is going to
> really kill the morale of your top performers in no time.
It certainly has frustrated not only members of the development team,
but our product owner, and sponsors of the project. When I look back at
the previous five or six sprints, the evidence of frustration among the
development team is clear, faked estimates, lots of descoping, and low
quality. We are just beginning to clean up the mess from those sprints.
> On the other hand, if this person is just in a very deep slump then I'd
> suggest there might be hope for trying to understand what's going on
> with them. Working together to learn how to get the developer
> re-engaged would seem to be important. I'd suggest taking an empathetic
> and supportive approach first, and if all else fails then perhaps turn
> to some tough love. The reasons for this kind of slacking can be really
> varied, but sometimes people do it to send a message. If the work is
> not challenging enough, if the person does feel accepted/respected, if
> there are personal happiness issues going on, if they're not happy in
> the culture of the team -- all of these things can play a part. Heck, I
> feel this way sometimes on projects that are technologically hopeless
> (though I doubt this is true of your project).
Yes, this is the key, I just don't know what else to try. We have done
lots of soft sell, offerred to pair, asked the developer to help me and
others. Provided books and articles to ease the learning curve. For
several sprints we explicitly planned work below capacity, so we could
work with this developer directly. We tried having this developer work
on larger tasks to give him the freedom to work in his own way. We tried
smaller tasks. Nothing seemed to work until we pushed very small
constrained tasks on him, and even then it took him a week before he
wrote a line of code.
> I would also try to be introspective about team morale issues - if
> there's low morale, often it will show up with this kind of behaviour.
> Being overworked or under appreciated are surefire ways to lower my
> morale (and the teams I've been a part of).
>
> In essence - try as hard as you can to put yourself in their shoes to
> understand the issues - then be creative about finding ways to re-engage
> them. And if they're truly just grade A slackers - then you need to
> find a way to get them off the team.
>
> On 8/26/07, * david_morash* <davidmorash@...
> <mailto:davidmorash@...>> wrote:
>
> --- In agile-halifax@...
> <mailto:agile-halifax%40yahoog
roups.ca>, "Dmitri Dolguikh"
> <dmitri@...> wrote:
> >
> > Hi everybody,
> >
> > it is time again for our monthly meeting. Thursday, August 23rd, 7pm
> > at the Wired Monk, corner of Morris and Hollis streets.
> >
> > Cheers,
> > -Dmitri
>
> Sorry I missed the latest meeting, I got stuck at work integrating
> stuff for a build. I was hoping to discuss one item at the latest
> meeting as it has been weighing very heavily on my mind.
>
> What is the best way to deal with team members who lie and make
> excuses because they don't want to do the work?
>
> This has happened with two different developers on our team, one has
> subsequently been reassigned, but the customer isn't prepared to do
> anything about the second developer. The second developer finally
> managed to deliver some functionality this sprint, after two sprints
> where he didn't write a line of code.
>
> I've subsequently been told by others that, in part, this was because
> this developer simply wasn't interested in doing the work and that his
> many excuses were fabrications.
>
Hi Dave,
Sorry for the late response, I've been very busy with work in the lead
up to my vacation.
I agree with everything you've said here, but ultimately I'm still
struggling for creative ways to engage this developer. To put this in
context, this developer joined the project in January of this year, but
the team only managed to get him to commit to tasks three sprints (six
weeks) ago. The team has tried lots of things, but nothing has really
worked, we just got different excuses.
I was really hoping that some of the scrum practices which have made
this behaviour obvious to everyone, would help address it. In part I
suppose they have, as to address this problem we have paid more
attention to executing the scrum practices. The standups have been more
focussed on discussing what was completed and in ensuring this developer
knows that anything that is preventing him from completing work is an
obstacle.
This has lead to the team doing more hand holding in order to resolve
these obstacles than any one seems comfortable with, but it has resulted
in something being delivered. It has not addressed the core issue, this
developer is free to continue making excuses for why he isn't able to
meet his committments.
I really like how servant leadership addresses this issue, i.e. agreed
upon performance standards, tempered with compassion and an
understanding of personal issues, highs and lows (as you mention below).
Given that this developers supervisor is unwilling to address this
issue, or move him to another project, I don't see many options left;
let this situation continue and hope it improves, address the issue with
the developer directly, or ask that I be allowed to leave the project.
Additional comments inline.
Dave LeBlanc wrote:
>
> Hi David,
>
> This sounds like a question that pervades all of the working
> environment, so I'd expect most of the good literature to be found in
> non-agile (and probably non-software) places. To me that kind of
> behaviour would indicate a really serious lack of motivation, and
> perhaps low morale. Has this developer always dodged work, or are they
> productive sometimes, and slow/stopped others? Is this an issue across
> the team, or isolated to 1 or 2 people?
The team is comprised of customer employees and contractors. I'm a
contractor. There has been a problem with productivity among some of
the customer employees for various reasons, some have other duties, most
are new to this technology, and some appear to work at their own pace
because there is zero oversight for customer employees, not even the
bums in seats kind.
The developer in question has previously worked alone in the same small
area for years. Its hard to judge previous levels of productivity
because he appeared to have very little to do. Perhaps that is the root
of the problem, he may have simply forgotten how to work in a team with
deliverables.
> If they just don't work at all I think I'd do what I have to do to get
> this person off the team. A team that accepts 'sandbaggers' is going to
> really kill the morale of your top performers in no time.
It certainly has frustrated not only members of the development team,
but our product owner, and sponsors of the project. When I look back at
the previous five or six sprints, the evidence of frustration among the
development team is clear, faked estimates, lots of descoping, and low
quality. We are just beginning to clean up the mess from those sprints.
> On the other hand, if this person is just in a very deep slump then I'd
> suggest there might be hope for trying to understand what's going on
> with them. Working together to learn how to get the developer
> re-engaged would seem to be important. I'd suggest taking an empathetic
> and supportive approach first, and if all else fails then perhaps turn
> to some tough love. The reasons for this kind of slacking can be really
> varied, but sometimes people do it to send a message. If the work is
> not challenging enough, if the person does feel accepted/respected, if
> there are personal happiness issues going on, if they're not happy in
> the culture of the team -- all of these things can play a part. Heck, I
> feel this way sometimes on projects that are technologically hopeless
> (though I doubt this is true of your project).
Yes, this is the key, I just don't know what else to try. We have done
lots of soft sell, offerred to pair, asked the developer to help me and
others. Provided books and articles to ease the learning curve. For
several sprints we explicitly planned work below capacity, so we could
work with this developer directly. We tried having this developer work
on larger tasks to give him the freedom to work in his own way. We tried
smaller tasks. Nothing seemed to work until we pushed very small
constrained tasks on him, and even then it took him a week before he
wrote a line of code.
> I would also try to be introspective about team morale issues - if
> there's low morale, often it will show up with this kind of behaviour.
> Being overworked or under appreciated are surefire ways to lower my
> morale (and the teams I've been a part of).
>
> In essence - try as hard as you can to put yourself in their shoes to
> understand the issues - then be creative about finding ways to re-engage
> them. And if they're truly just grade A slackers - then you need to
> find a way to get them off the team.
>
> On 8/26/07, * david_morash* <davidmorash@...
> <mailto:davidmorash@...>> wrote:
>
> --- In agile-halifax@...
> <mailto:agile-halifax%40yahoogroups.ca>, "Dmitri Dolguikh"
> <dmitri@...> wrote:
> >
> > Hi everybody,
> >
> > it is time again for our monthly meeting. Thursday, August 23rd, 7pm
> > at the Wired Monk, corner of Morris and Hollis streets.
> >
> > Cheers,
> > -Dmitri
>
> Sorry I missed the latest meeting, I got stuck at work integrating
> stuff for a build. I was hoping to discuss one item at the latest
> meeting as it has been weighing very heavily on my mind.
>
> What is the best way to deal with team members who lie and make
> excuses because they don't want to do the work?
>
> This has happened with two different developers on our team, one has
> subsequently been reassigned, but the customer isn't prepared to do
> anything about the second developer. The second developer finally
> managed to deliver some functionality this sprint, after two sprints
> where he didn't write a line of code.
>
> I've subsequently been told by others that, in part, this was because
> this developer simply wasn't interested in doing the work and that his
> many excuses were fabrications.
>
This sounds like a question that pervades all of
the working environment, so I'd expect most of the good literature to
be found in non-agile (and probably non-software) places. To me that
kind of behaviour would indicate a really serious lack of motivation,
and perhaps low morale. Has this developer always dodged work, or are
they productive sometimes, and slow/stopped others? Is this an issue
across the team, or isolated to 1 or 2 people?
If they just don't work at all I think I'd do what I have to
do to get this person off the team. A team that accepts 'sandbaggers'
is going to really kill the morale of your top performers in no time.
On the other hand, if this person is just in a very deep slump
then I'd suggest there might be hope for trying to understand what's
going on with them. Working together to learn how to get the developer
re-engaged would seem to be important. I'd suggest taking an
empathetic and supportive approach first, and if all else fails then
perhaps turn to some tough love. The reasons for this kind of slacking
can be really varied, but sometimes people do it to send a message. If
the work is not challenging enough, if the person does feel
accepted/respected, if there are personal happiness issues going on, if
they're not happy in the culture of the team -- all of these things can
play a part. Heck, I feel this way sometimes on projects that are
technologically hopeless (though I doubt this is true of your project).
I would also try to be introspective about team morale issues
- if there's low morale, often it will show up with this kind of
behaviour. Being overworked or under appreciated are surefire ways to
lower my morale (and the teams I've been a part of).
In essence - try as hard as you can to put yourself in their
shoes to understand the issues - then be creative about finding ways to
re-engage them. And if they're truly just grade A slackers - then you need to find a way to get them off the team.
--- In agile-halifax@..., "Dmitri Dolguikh" <dmitri@...> wrote:
>
> Hi everybody,
>
> it is time again for our monthly meeting. Thursday, August 23rd, 7pm
> at the Wired Monk, corner of Morris and Hollis streets.
>
> Cheers,
> -Dmitri
Sorry I missed the latest meeting, I got stuck at work integrating
stuff for a build. I was hoping to discuss one item at the latest
meeting as it has been weighing very heavily on my mind.
What is the best way to deal with team members who lie and make
excuses because they don't want to do the work?
This has happened with two different developers on our team, one has
subsequently been reassigned, but the customer isn't prepared to do
anything about the second developer. The second developer finally
managed to deliver some functionality this sprint, after two sprints
where he didn't write a line of code.
I've subsequently been told by others that, in part, this was because
this developer simply wasn't interested in doing the work and that his
many excuses were fabrications.
--- In agile-halifax@..., "Dmitri Dolguikh" <dmitri@...> wrote:
>
> Hi everybody,
>
> it is time again for our monthly meeting. Thursday, August 23rd, 7pm
> at the Wired Monk, corner of Morris and Hollis streets.
>
> Cheers,
> -Dmitri
Sorry I missed the latest meeting, I got stuck at work integrating
stuff for a build. I was hoping to discuss one item at the latest
meeting as it has been weighing very heavily on my mind.
What is the best way to deal with team members who lie and make
excuses because they don't want to do the work?
This has happened with two different developers on our team, one has
subsequently been reassigned, but the customer isn't prepared to do
anything about the second developer. The second developer finally
managed to deliver some functionality this sprint, after two sprints
where he didn't write a line of code.
I've subsequently been told by others that, in part, this was because
this developer simply wasn't interested in doing the work and that his
many excuses were fabrications.
For those in Halifax that couldn't make it to Agile 2007, check out XP
Day Manhattan. Ryan and Dima will pledge that it was life changing
(especially for Ryan who swindled money off of JB and I in a
"friendly" poker game).
Diaspar Software is proud to present another installment of the XP Day
North America series: XP Day Manhattan taking place on October 13, 2007.
The focus of XP Day is to bring top extreme programming practitioners
to North American XP communities to share their successes, failures
and perspectives on how to release high-value software sooner.
Our program for Manhattan includes:
1)A keynote address by Steve Freeman. Steve is a fixture in the London
software development community, a regular organizer of the original XP
Day, well known for his contributions to test-driven development
practice and co-recipient of the 2006 Gordon Pask Award.
2)A tutorial by JB Rainsberger, a recipient of the 2005 Gordon Pask
award. JB will talk about why XP works using the Theory of Constraints
model developed by Goldratt.
3)A tutorial by George Dinwiddie, a respected member of the XP
community, and author of an insightful blog about coaching XP teams:
http://blog.gdinwiddie.com. George will talk about sustainability at
multiple levels in XP.
4)Open Space. There's plenty of room, the space is superbly run and
the conversation is lively. Collaborate intensively with both local
and invited advanced practitioners on issues that interest you most.
Cost of the conference is $249 USD and includes breakfast and lunch.
Registration is limited to 100 attendees. To register visit
http://www.xpday.info. For group rates, contact me at the address
provided in the header of this message.
Check out the following links for pics of our last conference:
http://tinyurl.com/2ysz6v and http://tinyurl.com/23ktwx
Thanks for reading,
Niraj.
Hey Patrick, sounds interesting, we'll need to figure out the mechanics; video chat over skype might work.
Cheers, -Dmitri
On 8/20/07, Patrick Wilson-Welsh
<patrick@...> wrote:
Hi Dmitri,
One of these days, I would like to call into your meeting, and share with folks what I learned at Agile 2007, unless you already have someone doing an experience report from it...
Hope you guys are well!
--
Best regards,
Patrick
Monday, August 20, 2007, 11:01:49 AM, you wrote:
>
Hi everybody,
it is time again for our monthly meeting. Thursday, August 23rd, 7pm
at the Wired Monk, corner of Morris and Hollis streets.
One of these days, I would like to call into your meeting, and share with folks what I learned at Agile 2007, unless you already have someone doing an experience report from it...
Hope you guys are well!
--
Best regards,
Patrick
Monday, August 20, 2007, 11:01:49 AM, you wrote:
>
Hi everybody,
it is time again for our monthly meeting. Thursday, August 23rd, 7pm
at the Wired Monk, corner of Morris and Hollis streets.
Hi everybody,
it is time again for our monthly meeting. Thursday, August 23rd, 7pm
at the Wired Monk, corner of Morris and Hollis streets.
Cheers,
-Dmitri
--
http://www.appliedlogic.ca
Ryan Cooper wrote:
> Hi all;
>
> My latest blog post is a agile "required reading" list. Obviously the
> only authority behind the "required" part is my personal opinion, so
> don't take it too seriously. :) They're all books I found
> thought-provoking, and they're the books I seem to recommend most
> often. The list can be found here:
> http://on-agile.blogspot.com/2007/07/agile-bookshelf-10-must-read-books.html
>
> I thought it might be interesting to start a thread and find out what
> interesting books everyone else has been reading lately. Feel free to
> mention what you like about each one in a few sentences, or just the
> titles if you'd prefer (or are pressed for time). I'm looking
> forward to picking up a few recommendations to add to my to-read list.
>
> Thanks,
> Ryan
>
Great list!
I'd add two books, "The Pragmatic Programmer" by Andrew Hunt and David
Thomas, and "The Practice of Programming" by Brian W. Kerhighan and Rob
Pike. Both of these provide a lot of practical advice on technical
aspects of programming; coding style, debugging, performance tuning,
code generation, etc. I amazed by the number of developers I've worked
with who don't know how to use tools like debuggers let alone write unit
tests!
IMHO, these subjects simply don't get enough exposure, but are essential
to successful software projects. More importantly, these books
reinforced my attitude that there is always something new and useful to
learn, however small.
If I could find my copy of "Death March" by Edward Yourdon, I'd
recommend that too! I picked this up while in the middle of my second
death march in succession. I can't remember much, or any of the advice
in the book, but it's the book that made me realize that I didn't have
to sacrifice my personal life, and health for a software project.
I'll second the recommendation on Bob Martin's "Agile Software
Development: Principles, Patterns, and Practices", and Fowler's
"Refactoring"; the code smells section alone makes the book worthy.
While I recommend Beck's "Test-Driven Development: By Example", I think
it could have been much shorter. My preference these days is to simply
sit with the person and introduce TDD by writing tests.
Hi all;
My latest blog post is a agile "required reading" list. Obviously the
only authority behind the "required" part is my personal opinion, so
don't take it too seriously. :) They're all books I found
thought-provoking, and they're the books I seem to recommend most
often. The list can be found here:
http://on-agile.blogspot.com/2007/07/agile-bookshelf-10-must-read-books.html
I thought it might be interesting to start a thread and find out what
interesting books everyone else has been reading lately. Feel free to
mention what you like about each one in a few sentences, or just the
titles if you'd prefer (or are pressed for time). I'm looking
forward to picking up a few recommendations to add to my to-read list.
Thanks,
Ryan
I'd also be interested in learning about Grails & Groovy, but I'm also
interested in what does/doesn't work for various teams, from engineering
practices to basic team issues, the effects of the particular problem domain on
how the team functions, etc.
So on a broader note, maybe adding experience reports to the potential list of
"formal" topics would be valuable.
However, I may not make tonights meeting; I'm waiting on the availability of DBA
and CM people to formally build and deploy our tenth sprint! Gotta keep hitting
those dates!
----- Start Original Message -----
Sent: Thu, 19 Jul 2007 12:51:58 -0000
From: "ryanpcooper" <ryan.p.cooper@...>
To: agile-halifax@...
Subject: [agile-halifax] Re: Next Meeting
> Hi Allan;
>
> I'd like to learn more about Grails & Groovy.
>
> BTW, you can find a picture of me at http://www.onagile.com so you
> know who to look for tonight at the coffee shop. :)
>
> Cheers,
> Ryan
>
> --- In agile-halifax@..., "brafoo" <brafoo@...> wrote:
> >
> > I've not met any of you guys yet, but am going to try to make it on
> > Thursday.
> >
> > Anyone in the group interested in Grails/Groovy? We are starting a new
> > project using ICONIX Agile methodology. Main stack components are
> > Grails, Java, Groovy, and TIBCO GI.
> >
> > Cheers,
> > Allan Haggett
> > Director, Product Development
> > IMP Solutions
> >
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
----- End Original Message -----
Hi Allan;
I'd like to learn more about Grails & Groovy.
BTW, you can find a picture of me at http://www.onagile.com so you
know who to look for tonight at the coffee shop. :)
Cheers,
Ryan
--- In agile-halifax@..., "brafoo" <brafoo@...> wrote:
>
> I've not met any of you guys yet, but am going to try to make it on
> Thursday.
>
> Anyone in the group interested in Grails/Groovy? We are starting a new
> project using ICONIX Agile methodology. Main stack components are
> Grails, Java, Groovy, and TIBCO GI.
>
> Cheers,
> Allan Haggett
> Director, Product Development
> IMP Solutions
>
I've not met any of you guys yet, but am going to try to make it on
Thursday.
Anyone in the group interested in Grails/Groovy? We are starting a new
project using ICONIX Agile methodology. Main stack components are
Grails, Java, Groovy, and TIBCO GI.
Cheers,
Allan Haggett
Director, Product Development
IMP Solutions
Hi all;
Lets have another get together this week. Regular time & place (Wired
Monk Coffee Shop, corner of Morris & Hollis, 7:00 pm on Thursday).
For those who haven't been able to make it to the last few meetings:
we've been throwing around the idea of doing something slightly more
formal in the near future, like a coding dojo
(http://wiki.agilefinland.com/?CodingDojo) or a tutorial on Test
Driven Development, or Ruby on Rails, or some other topic that people
are interested in.
Do any of these ideas grab your interest? Is there another
agile-related topic you'd like to learn more about? Please feel free
to come to the meeting with your ideas, or just reply to the list. As
with all things agile, the more feedback, the better. :)
Thanks,
Ryan
Hey Folks! Just wanted to let you know that I am returning to Halifax
to deliver this course. I wanted to offer everyone on this list a 10%
discount until the end of this week (Sunday night). Here is the link
to follow to get the discount... feel free to pass this along:
http://www.berteigconsulting.com/secure/a.php?r=AgileHalifax
Thanks,
Mishkin Berteig
(and by 'next Thursday', I mean June 14.)
On 6/4/07, Ryan Cooper <ryan.p.cooper@...> wrote:
> Hi all;
>
> It's been a little while since our last meeting. Dmitri and I have been out
> of town and busy/lazy, but it's about time we got together again to drink
> tasty beverages and discuss all things agile.
>
> How about a meeting next Thursday, 7 PM as usual, at the Wired Monk?
>
> (As always, if a different time or venue would be better for anyone, lurkers
> included, let us know.)
>
> Cheers,
> Ryan
>
It's been a little while since our last meeting. Dmitri and I have been out of town and busy/lazy, but it's about time we got together again to drink tasty beverages and discuss all things agile.
How about a meeting next Thursday, 7 PM as usual, at the Wired Monk?
(As always, if a different time or venue would be better for anyone, lurkers included, let us know.)
Hi all;
Dave Henderson, a researcher at Virginia Tech, contacted me wondering
whether members of Agile Halifax would be interesting in participating
in his research project by filling out a short survey. See details
below.
Feel free to participate, or ignore completely. :)
Cheers,
Ryan
---------- Forwarded message ----------
From: Dave Henderson <davidlhenderson@...>
Date: Apr 23, 2007 11:13 PM
Subject: Systems development methodology survey from researchers at
Virginia Tech
To: ryan.p.cooper@...
Hello Ryan,
How are you? My name is Dave Henderson and I am a doctoral student at Virginia
Tech majoring in Information Systems. I emailed you approximately two weeks ago
about participating in a web-based survey on systems development methodologies
for my dissertation. I am following up with you to determine if the Agile
Halifax Users Group is interested in participating in participating in the
survey.
I am currently conducting the survey with various systems development
methodology user groups. Please let me know if your organization is interested
in participating as well. In return for your participation, I will provide a
summary of the results of my research. Furthermore, participants will be able
to enter into a random prize drawing to win $250.00. The survey is completely
anonymous and takes 25 minutes to complete.
I have included the hyperlink to the web-based survey in the invitation letter
below. I hope you and your organization decide to participate as your response
is very important to my research. I look forward to hearing from you. Thank you
for assistance!
Best Regards,
Dave
_______________________________________________
Hello:
My name is Dave Henderson and I am a doctoral student at Virginia Tech majoring
in Information Systems. I am conducting a web-based survey for my dissertation
to investigate attitudes of Information Technology professionals toward using
systems development methodologies. My dissertation further investigates what
makes a systems development methodology useful to Information Technology
professionals. The anticipated results will help researchers to find strategies
for encouraging systems development methodology use.
I am currently looking for Information Technology professionals who have used a
systems development methodology to participate in my survey. As a member of the
Agile Halifax Users Group, your input would be extremely valuable to my
research. Participation in the survey is completely voluntary.
If you are not familiar with any systems development methodology, please do not
complete the survey. The survey requires approximately 25 minutes to complete,
is completely anonymous, and will expire at midnight on Friday, May 11th 2007.
Furthermore, participants will be able to enter into a random prize drawing to
win $250.00. Please make sure you have time to complete the entire survey as
partial responses are not counted. The survey can be accessed at
http://www.surveymonkey.com/s.asp?u=385383631721. If you have any questions or
concerns about the survey, please contact the survey administrator, David
Henderson at davidlhenderson@... or his advisors, Steve Sheetz at
sheetz@... or France Belanger at belanger@.... Thank you for your
assistance!
Best Regards,
Dave Henderson
Ph.D. Candidate
Department of Accounting and Information Systems
Virginia Tech
Email: davidlhenderson@...
I live far away, but my pal Jeffrey Miller (cc'd here) claims that a pal of his is looking for agile Java programmers in Halifax. Jeffrey, please explain to the group. :-)
--
Best regards,
Patrick
Sunday, March 25, 2007, 7:46:32 PM, you wrote:
>
Let's have a meeting Thursday April 5, 7 PM at the Wired Monk.
Everyone is welcome, including the lurkers on the list. ;)
Cheers,
Ryan
P.S. If there is a different time that's more convenient for anyone
who would like to come, please let me know. It's no trouble to reschedule.
P.P.S. If you'd like to come to a meeting but don't know what we look
like, let me know. We can post photos somewhere online.
I live far away, but my pal Jeffrey Miller (cc'd here) claims that a pal of his is looking for agile Java programmers in Halifax. Jeffrey, please explain to the group. :-)
--
Best regards,
Patrick
Sunday, March 25, 2007, 7:46:32 PM, you wrote:
>
Let's have a meeting Thursday April 5, 7 PM at the Wired Monk.
Everyone is welcome, including the lurkers on the list. ;)
Cheers,
Ryan
P.S. If there is a different time that's more convenient for anyone
who would like to come, please let me know. It's no trouble to reschedule.
P.P.S. If you'd like to come to a meeting but don't know what we look
like, let me know. We can post photos somewhere online.
Offline 
Send Email
Online Now 