CodeStock 2010

March 12th, 2010

My good friend Josh Carroll and I have submitted a session to CodeStock about practicing Agile on small software development teams. Sign up and vote for our session!

Chaos to Awesome in 60 minutes / the heart of Agile without all the fluff
Track / Area: Developer / Methodology
Technology: Agile, CI, testing, development processes, tools
General / Specific Experience Level: Beginner / Beginner
Co-Presented with Josh Carroll.
Want to increase visibility, collaboration, and communication in your development process? Striving to ensure higher quality products with rapid feedback cycles? Don’t know where to start?
Our goal is to show you how we use simple tools and practices to work in an agile way – without any fluff. We will cover how we manage our task board and source code; simple continuous integration; unit testing with mocks; design patterns for clean separation of concerns and testability. All in one hour. ‘Cause that’s how we roll.

Chaos to Awesome in 60 minutes / the heart of Agile without all the fluff

Track / Area: Developer / Methodology

Technology: Agile, CI, testing, development processes, tools

General / Specific Experience Level: Beginner / Beginner

Co-Presented with Josh Carroll.

Want to increase visibility, collaboration, and communication in your development process? Striving to ensure higher quality products with rapid feedback cycles? Don’t know where to start?

Our goal is to show you how we use simple tools and practices to work in an agile way – without any fluff. We will cover how we manage our task board and source code; simple continuous integration; unit testing with mocks; design patterns for clean separation of concerns and testability. All in one hour. ‘Cause that’s how we roll.

You can check out all the details on the CodeStock session page.

.NET, Agile, News, Technology ,

Agile Degeneration: the Antidote

October 2nd, 2009

A friend posted a piece about agile team degeneration on his blog and this is my reply. Take a couple of minutes and go read his post for proper context: http://blog.mspatch.com/post/2009/10/01/Agile-Degeneration.aspx

So you read it, right?

Whatever. I know you didn’t read it. I have Google Analytics and it’s telling me a different story.

Well, since you didn’t read his post, I’ll distill it down to fit your impatience. An agile team can be taken over by a single, forceful, individual in one of two ways: (1) being confidence, charismatic, and passionate about their idea and reasoning until it wins or, more subliminally, (2) using their social influence to gain a majority on the team and use that to make sure their idea is chosen.

Can this happen to a team? Uh, yeah. Does this happen? I would say so.

Obviously, the issue is that agile teams contain human beings. That’s mistake number 1. What were they thinking?

Sure, a team consists of people and we’re flawed. However, I think there are checks and balances built into agile/scrum to help prevent this from happening. Here are four lines of defense, as I see them.

First line of defense: The Team. Each team member has the responsibility to listen to and help each other. It’s not about one person winning or being the star. However, we become lazy, passive, unwilling to step up and contend. It’s hard work after all. You have to show up and make an effort. Every day. Besides, the arena of ideas is a dangerous place. What will people think of me? What if I don’t have the best idea? Complacency is easy. I’d much rather do that.

Second line of defense: Scrum Master. The scrum master is a facilitator. It’s their responsibility to make sure all team members are engaged in the conversation. They need to create balance by knowing each team member: who to draw out and who to prevent from shutting down discussion. They also need to keep it on point and on time. It’s a very difficult job.  And who really wants to do that all the time? Why does it have to be hard? Maybe no one will notice…

Third line of defense: Product Owner. The product owner needs to be assisting the scrum master in facilitation. When the scrum master is absent (physically or de facto), the product owner must step in and provide the missing facilitation.  But there are so many other things to worry about. And, really, let’s be honest, it’s more than a little below what I should really be doing.

Fourth line of defense: Management. Management is really the first and last line: after all, the buck stops with them. They are responsible for bringing in exceptional people and creating teams with the critical mass to succeed. There are times they will have to make difficult decisions with team changes or helping people move on to a “better fit” (i.e. fire them). Good leadership is hard to find. Who wants to be a leader when you can be a celebrity? Planning, vision, difficult decisions, dealing with all the problems: blah! Who wants that? I’ll take a triple frapalattemocha with cinnamon and some non-dairy whipped cream with just a pinch of sprinkles to go. Yeah, now that’s something I can enjoy.

“Management” is not a universal cop-out for the problems that exist.

Each of us need to be leaders and take ownership on our team. We can try to claim ignorance or find excuses when the team fails but, ultimately, it will be our fault if we don’t do our part.

Agile , ,

Speaking tonight on XNA at ETNUG

October 1st, 2009

Michael Neel, Dylan Wolf, and I are speaking at the ETNUG meeting tonight. We’ll be talking about finishing an XBOX game on XNA and publishing it as an Indie game on XBOX LIVE.

Hope to see you there!

.NET, News, XNA , , , ,