In the first two posts in this series, I explained some of the problems that we had with traditional Scrum and then laid out our new Agile process: Forge. In this post, I'm going to share a bit more about implementing Forge on our project and tell you about some of the benefits and challenges that we ran into.

In the first post in this series, I talked about some of the challenges that we faced trying to implement Scrum on one of our large client projects. After failing to reap the benefits from Scrum, I designed a new process that was better suited to our project and our team. Thus Intridea Forge was born.

One of the best comments I've heard about Agile development is that "adopting Agile is itself an agile process". It sums up very nicely the fact that each team and each project will have their own needs when it comes to finding a process that works for everyone, including the stakeholders. It also means that no matter how much you like a specific methodology, it's virtually impossible to implement that process on your team following its strict definition.

As a Scrum Master I've always been partial to Scrum, but after spending six months trying to make it work on one of our large client projects, I reevaluated and started from the ground up to design a whole new Agile process. We'll be introducing our new process in a future blog post, but for now I wanted to talk about some of the challenges we faced implementing Scrum.