The Knightlore | 15 May 2013 18:40
Picon
Favicon
Gravatar

XP for one?

Hi,
I've just started Ron's book Extreme Programming Adventures in C#.

I really like the idea of XP but being a lone developer, I was wondering whether or not you could still be
deemed to be doing XP without pair coding?

Perhaps I could embrace my split personality, the side of me that wants to get things done and my annoying
perfectionist, to help imitate the pair programming?

I suppose I'm missing the point of the advantages gained from pair programming, but if I bare in mind, that
someone should be looking over my shoulder and vice versa, could I achieve some of that benefit?

Thanks,
Warren.

Esther Schindler | 13 May 2013 06:27
Favicon
Gravatar

Help with an article?

Howdy, folks. I'm working on an article for ITWorld.com, and I'd like your input.

The working title is: “Why your users hate Agile software development.”

Despite the challenging headline -- hey, we have to attract people's attention here -- I am not against
Agile. Quite to the contrary. But I do want to see it done WELL and RIGHT and to the benefit of all concerned.
My premise in this article is: Agile developers and project managers should have some insight into why
Agile causes anxiety and what they can do to minimize that.

Most developers I know really like Agile. There are a lot of advantages, and I doubt we need to go into what
they are.

Clients and users, however, may not appreciate all those things. They have their own concerns -- and
sometimes Agile developers don't recognize them. 

It isn't always the user's fault. Sometimes the users have a _perception_ of a problem that they blame on
Agile... for good reasons. For example, I've spoken with corporate users who kept trying to shoe-horn
more and more functionality into an initial iteration. That sounds like they didn't grok what
"iteration" meant, when in reality it was a response to their own corporate culture: They knew full well
that the funding would go away after the "first phase," with excuses like, "We'll do that in phase 2, next
spring," when reality taught them that phase 2 never never does get funded. The developers are moved onto
some other project and the users never get that must-have requirement EVER.

Another reason that the users might hate agile: The developers talk to the wrong users. They interview the
department managers, who might care about things like reporting, but the developers never have the
opportunity to talk to the day-to-day users who might have reasonable requests to improve the data entry
process. To those users, "Agile" is just another way to ignore their needs while claiming that the process
is to serve them.

And those are just off the top of my head.
(Continue reading)

Vlietstra, Joe (ES | 29 Apr 2013 22:50
Picon
Favicon

RE: Code review practices

On 26 April 2013 23:33, Charles Bradley - Professional Scrum Trainer and Coach <charles <at> scrumcrazy.com> wrote:
> Hi,
> I'm trying to come up with a list of different ways of doing code 
> reviews as they relate to a Scrum definition of done.
>
> In practice, I've seen:
> ...

We use some form of code inspection (ala Fagan) almost exclusively.
In theory, this makes defining "done" easy -- the inspection is
done when the moderator verifies that the rework is complete.
In practice, there are four different events that may be called
"done":
1. Developer completes code and sets up inspection
2. Inspection (logging) meeting (possibly virtual) itself
3. Developer fixes any issues identified from inspection
4. Moderator verifies fixes
Which event counts as "done" depends on the purpose.  For example,
when the developer completes code, he or she is available to pick
up the next open task; so event 1 is "done" when working resource
scheduling.  At the other extreme, we use all 4 events (weighted
80%, 10%, 0%, and 10%, resp.) when determining earned value (EV).

Joe Vlietstra

jennifer ferreira | 29 Apr 2013 13:00
Picon

Yahooooooo!


Single Mom Makes $89,844/Yr in Her Spare Time on The Computer Without Selling Anything 

http://www.e-bda.com/hwork56.html 

4/29/2013 12:00:12 PM

[Non-text portions of this message have been removed]

Favicon

Code review practices


Hi,

I'm trying to come up with a list of different ways of doing code reviews as they relate to a Scrum definition
of done.

In practice, I've seen:

	* A scheduled meeting for a code review, several show up and review code

	* Paired Programming  (I realize XP'ers are biased to PP, and nothing wrong with that)

	* Live review by one other programmer just before code commit.
	* Code review published to code review system (like Atlassian Crucible, etc) with deadline by which
reviewers can submit feedback.
	* Code review published to code review system (like Atlassian Crucible, etc) 
where code cannot integrate until one person says "ship it"
	* No code reviews
	* Code reviews only on special occasions or in certain parts of the code
What other code review type practices have you seen?
 
-------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
ScrumCrazy.com

[Non-text portions of this message have been removed]

(Continue reading)

Cÿffffe9lio Jÿfffffanior | 22 Apr 2013 20:30
Picon
Favicon

4th Brazilian Workshop on Agile Methods - Last Call for papers

4th Brazilian Workshop on Agile Methods (WBMA)

Agile Brazil'2013
http://www.agilebrazil.com/2013/en/wbma/
Brasilia, Brazil, 27/June/2013

Call for papers
===========

The Brazilian Workshop on Agile Methods (WBMA) is the research stage 
of the Agile Brazil Conference. It is an academic event on Agile software 
development. For this third edition, we hope to repeat the success of previous 
years, when the workshop received many papers and the participation of a 
large number of students, researchers, and professionals from all over World.
Last year, Agile Brazil (the event hosting WBMA) counted over 800 attendees 
from the whole world. This year the workshop expects to receive even more 
participants from Brazil and researchers and students from abroad, coming from 
top international universities and IT companies.

This year, WBMA will happen on June 27th in Brasilia, collocated with the 4th Agile Brazil.

The main topics of interest for this workshop are:

* Adoption of Agile / Lean
* Systems and Software Architecture and Development of Critical Systems
* Human and Social Aspects in Agile Methods
* Agile Project Management, Outsourcing and Governance in the agile context
* Development in distributed and global agile teams
* DevOps and Continuous Delivery
* Teaching and coaching Agile and Lean
(Continue reading)

☈king | 19 Apr 2013 05:08
Picon
Favicon
Gravatar

Developer Stories

Hi all!

Am I wrong, or is it generally bad for developers to put their own stories into the Planning Game? This gets
more complicated if there is a legacy/technical debt.

Shouldn't they just decide what is right to chip at as far as internal improvement, then just let that play
out in the velocity?

Maybe I'm seeing this wrong, but it seems like if you try to mix those discussions into the planning, the
Customer won't have a clear way to prioritize the stories they know/understand/feel vs. these weird
techie ones from some strange land.

I know XP addresses this, but I don't remember how or where.

Thanks!
—RK

JackM | 13 Apr 2013 00:49
Favicon

Re: Architecture backlog

I buy that, and in actual fact our architecture does evolve. However the way we work is upfront of a release we
identify investment areas and Epics upfront. we work in 6 week increments 3 sprints of 2 weeks each. so
generally we know which epics are coming up in the next 6 week increment and we identify any potential risks
upfront and try to start thinking about what architecture elements we need in place, what security pieces
will be impacted etc. So ahead of the next cycle we're working on risk reducing our backlog so we can drive
more certainty in our process.

At the sprint level we do something similar - we have at least 2 sprints worth of stories ranked, and any
uncertainty in the forthcoming sprint we try to run spikes in the current sprint. this makes our planning
better, it makes us more reliable and we're able to commit better through upfront understanding.

So these architecture pieces we identify upfront is kind of where my question lies. what should an
architecture roadmap look like, are they simply epics in and of themselves. Is it a separate backlog etc. 

In regards the link to the presentation, i'll try to post later as i don't have it handy.

Cheers
Jack
www.agilebuddy.com

--- In extremeprogramming <at> yahoogroups.com, Curtis Cooley <curtis <at> ...> wrote:
>
> On Fri, Apr 12, 2013 at 7:44 AM, JackM <jack <at> ...> wrote:
> 
> > **
> >
> >
> > I have a feeling that this forum is going to say that architecture
> > shouldn't be ahead but rather handled together with the epic development in
> > a thin slice approach.
(Continue reading)

JackM | 12 Apr 2013 16:44
Favicon

Architecture backlog

I was fortunate to catch one of Mike Cottemeyer's webinars on Acieving Business Agility at the Porfolio level.

He spoke about the architectural roadmap and how that overlays onto the epic roadmap all in an effort to help
to risk reduce the backlog.

I am wondering if anyone in this forum is doing this and if so what the architectural roadmap might look like,
is it just a backlog of architecture epics.

I have a feeling that this forum is going to say that architecture shouldn't be ahead but rather handled
together with the epic development in a thin slice approach.

The problem we have is that we are building software that's deployed into huge financial institutions and
some of the architecture "bits" are extremely complex that need to be figured out to a level that when the
teams are ready to sprint they have this reasonably figured out.

Any information would be helpful.

Thanks
jack
www.agilebuddy.com

Ram Srinivasan | 11 Apr 2013 20:33
Picon

Planning Poker online tool which support observers

Thanks to Mike Cohn for making PlanningPoker.com available to all of us,
free of charge. Its simple and quite easy to use.  I like the fact that all
cards flip over when the last person has given his estimate.

The tool, in its current version, does not support observers.  Do you know
of an online Planning Poker tool which can support observers (say Product
Owner/Scrum Master) ?

Thanks,
Ram

[Non-text portions of this message have been removed]

Ram Srinivasan | 9 Apr 2013 18:10
Picon

Re: [Scrum] Distributed team - tools for Story Mapping

Thanks Alan, I have tried that. Considering that it is free, it is a pretty
decent tool. Some of the challenges that I encountered using the tool are
that there is a considerable lag in updating the board (if someone moves a
card) and there is no way to import stuff into it. But its free, so I
cannot complain. And thanks to Jeremy Lightsmith and Jeff Patton for making
it available for all of us

On Tue, Apr 9, 2013 at 12:06 PM, Alan Dayley <adayley <at> gmail.com> wrote:

> Try cardmapping.com. It has some limitations but seems to strike a
> reasonable balance between useful and too fancy.
>
> Alan
>
> On Apr 9, 2013, at 9:02 AM, Derek Davidson <derek.davidson <at> gmail.com>
> wrote:
>
> I've used TFS (in a .NET environment) and Jira with Greenhopper (in a Java
> environment).
>
> I prefer to use physical boards only wherever possible but in
> circumstances where that's not practical (i.e.: Distributed Teams), either
> of the above fills the bill.
>
> --
> Derek Davidson
>
>
>
> From: Ram Srinivasan <vasan.ram <at> gmail.com>
(Continue reading)


Gmane