Scrum/Agile Projects-Lead Generation System-Good/Bad

The first project I used the Scrum framework for was a lead generation system for the IDG network, home of such publications as Computer World, InfoWorld, PC World just to name a few. The PM/ScrumMaster on this project had no PM experience and was the architect of the system, the system was totally new, built from the ground up.

1. He had NO experience-In this case it was a good thing, as a company we were able to convince the business/stakeholders that this was a faster to market framework and they gave us the green light. The leader was not familiar with Scrum and he applied just right kind of guidance as we built our teams. I think that he didn’t have any pre-conceived notions is what made the project a success, he was learning the framework with the entire team at the same time. I also believe his style even before implementing Scrum was a hands off style of management, not unengaged but was very keen on individuals showing what they could do on their own. I also believe that the team as a whole was excited about the new framework and was determined to see it succeed, they had been through many years of waterfall development and everyone was chomping at the bit to try something new. All of these components led to a successful project on time and under budget.

The second project I used the framework for was another lead generation system/technical directory for TechTarget. Some of the examples of the sites are located here (1, 2, and 3) The PM/ScrumMaster on this project had PM experience and was also doing some coding to the project.

2. He HAD experience as a Project Manager-What I think doomed us from the start was that he wanted to use Scrum and we did, but he added things that just turned the project into a mini waterfall development project. He totally had that “command and control” personality so he became a Micro manager, as a ScrumMaster you are supposed to be a facilitator not a micro manger. Also I think that the iterations were too short (2 weeks) and an iteration schedule is not cut into stone, it will need to be adjusted as per project. The introduction of extra documentation and the just enough paperwork that Scrum is preaches, he was introducing mini waterfalls and the project became a Scrum/Waterfall/Agile mess. And of course what happens in this case the team got disgruntled, depressed and unmotivated, so the project was over budget did not meet the time criteria, you also had team members excited to get OFF the team, oh so un-scrum. Now to be far he also had a business/stakeholder that was changing things on the fly, was pretty much never at the meetings, (first big NO NO) BUT as the ScrumMaster you have to have all of these things at the beginning of the project documented in the product backlog. During your first few sprints you will be adjusting your velocity and some of the priorities might change slightly. With that said you still need them written down, complete and finalized so you have a direction and everyone is on the same page especially the business/stakeholder.

Popular posts from this blog

Burn Down vs. Gantt Chart

Agile/Scrum- Communication Plans

Cost Control Agile/Traditional