Rails - The first truly agile development platform ?

Most Agile thought leaders agree that the advent of OO and languages like Smalltalk were enablers for Agile software development methodologies. Technology has come a long way since then and we now find real "Agile" development environments in platforms like Ruby on Rails.

Let me explain ...

 

Ruby on Rails, is not only just a rapid application development environment that lets you do things fast. Ruby on Rails goes one step further by adding concepts like TDD (test driven development) directly into platform itself. For example, Rails provides it's own unit test framework or you can use the more popular behaviour driven test framework called RSpec which is totally integrated into the Rails platform. This enables development teams to apply real engineering discipline to the software development process.

How does a manager add value on a Scrum team?

Another great post today on LinkedIn. The question "what role does the manager play on a Scrum team, given that the team is self managing?"

Love to hear your thoughts on this. In my opinion the Manager still plays a vital role. For example the manager should be used as a sounding board for the team to help them avoid typical pitfalls based on his extensive experience i.e. as act as a team consultant.

Should the Product Owner be an active member of the Scrum team

A couple of days ago, there was a post on one of the agile groups on Linkedin asking whether or not the Product Owner should be an active member of a Scrum team. The post went on to ask if the P.O. is actually assigned tasks on the Sprint backlog.

I have seen similar posts on other forums as well. And I am amazed by just how many folks think the P.O. should not be a part of the team. Many individuals actually stated that they did not even want the P.O. to be a part of the retrospective. This folks, is a sad state of affairs.

Accounting for Bugs in an Agile World - How we do it

Today I'd like to share with you a really important aspect of Agile software development - how to account for bugs in your daily plans. I am frequently asked by teams I consult with how to deal with bugs if you're Agile and using Scrum. Questions like the following come up time and time again: "Should I track hours burned fixing bugs?" "Should the hours burned on fixing bugs count toward my Story Point velocity?" "When do you schedule bugs and should this be done during Sprint planning?"