I recently attended the Atlanta PMA TAG event, the format was excellent, it was a debate between 2 Product Management execs and 2 R&D execs. The format was an open debate with a few major topics being discussed; the best part was the absence of any sort of power point presentation.
TAG URL: http://www.tagonline.org
The Presenters:
• Renee Thompson - VP of Product Management, KnowledgeStorm
• Mark Wood - VP of Product Management and Marketing, Cambia
From Product Development
• Robert Stephens - CTO & SVP of Development, PreVisor
• Garrett Suhm - Vice President of Engineering, SilverPop
The main topics discussed were:
1. The Agile development methodology versus traditional waterfall
product development
2. Making build/buy/partner decisions
3. Why can't product management and product development just get
along?
It was interesting to see that 2 of the companies in question had success in moving from a Waterfall to Agile methodology and both Product Management and Development had made the transition with success. On the other hand, 2 of the other companies had found challenges, and continued to struggle with the shorter sprints, or scrum approach to Agile.
The consensus seemed to be that there was a lack of respect between the PM and Dev groups in the companies which had issues, and this led to both departments pointing the finger at one another for delivery failures.
The whole panel was in agreement that the work environment and the team relationships at each company had a big impact on successfully moving from one approach to the other. They all agreed that in order to make a successful transition, you needed support from the CEO level down, and everyone needed to work closely as a team to succeed in an Agile environment.
The issue of who Product Management reported to in an organization was also brought up as a possible difficulty in implementing this transition. In some companies, PM's report to the CEO, others to Marketing, a few to Engineering and god help us, some report to sales. Since this changes from one company to the next, it makes it difficult to come up with a set of guidelines that can be applied as a general template for the transition.
In my personal experience working as a Product Manager, I spent the better part of 5 years working in a classic Waterfall approach to development, and close to 2 years working in an Agile like environment. I found it more challenging to work in an Agile environment since I found we never had the "slower period" after a traditional waterfall type product release, which I describe as the month or so following the release which allowed me to get ahead of the next cycle in terms of research, market position, etc. Our release cycles had gone from 2 major releases a year, to small service pak type releases every 6 weeks in addition to a few major releases a year. I found I was always struggling to stay ahead in terms of my Product Management responsibilities.
My personal opinion is that the Waterfall approach to development is better aligned with the responsibilities of solid product management, as it provides more reasonable periods of time to properly research your market and better define your requirements.
"My personal opinion is that the Waterfall approach to development is better aligned with the responsibilities of solid product management, as it provides more reasonable periods of time to properly research your market and better define your requirements."
Isn't the allure of Agile that you could do that solid product management, do your homework, and then easily task development resources in Agile grouplets to build your product more efficiently?
Sure each Iteration takes 2 weeks, but isn't that awesome news when you finally reach the conclusion that you need to have something built as soon as possible?
"Isn't the allure of Agile that you could do that solid product management, do your homework, and then easily task development resources in Agile grouplets to build your product more efficiently?
Sure each Iteration takes 2 weeks, but isn't that awesome news when you finally reach the conclusion that you need to have something built as soon as possible?"
You make some good points, and I have seen it work in several companies. However, my personal experiences with an agile approach led to rushed code that resulted in broken requirements. This led to compounding delays, and constant rescoping of requirements to try and deliver a build on time. This leads back to the original discussion and much of what the debate focused on, an Agile approach requires a lot more team work and constant communication to work, and frankly, we simply did not have this nailed down very well.
Don't get me wrong, I am not anti-Agile ... I just find the rushed concept of Agile development also leads to rushed requirement definition.
Agile is the development answer to market-driven. What they generally do not realize is that the effort, cost and grief do not outweigh the benefits. No one articulates Agile better than Scott at Tyner Blain (see http://tynerblain.com/blog/2007/03/16/explaining-agile-development).
I am still not convinced it is worth switching... however, if you have no process and are new to the software development world - then why not change - it seems no worse that waterfall and least you are willing to try. Just be prepared to stick with it.
The "problems" that usually development teams and PMs face with Agile Methodologies is due to the fact that somehow the overall idea is that these Methodologies are chaotic. From my experience both in Waterfall and Agile, this idea is completely wrong.
Actually, Agile Methodologies, like scrum, request for a more thorough and detailed Project Management than Waterfall. Being able to control the constant negotiation of the requirements and the scope, the involvement of the stakeholders and the tight schedules is the greatest challenge of agile. Once, this roadblock is overcome the success in agile projects is a reality.
Visit the following blog where a video explains why agile projects make economical sense: http://holtsblog.blogspot.com/2006/12/agile-development-competitive.html
I find it interesting you mention "rushed requirement definition".
Let's think about that for a moment. What requirements are is a list of agreements that define what functionality the user wants. These requirements you speak of are a translation of business need into acceptance tests and validation of the user need.
In my experience people who write requirements in agile are missing the point of what requirements provide. They are useless documentation in a true agile environment because the people who know the answers are the users, so put them right there with the team to tell the team what they want instead of using third hand information baked into requirements.
Sounds like you were protecting your team from talking directly to stakeholders who could make the decisions about the product. Sounds like there was a lack of trust or interpersonal skill on the team.
Or maybe i have no idea what i'm talking about.
James, the end-user/stakeholder cannot always sit in the same office as the team and answer questions all-day. There is no harm in have a representative of the customer (i.e. product owner/manager or business analyst, etc.) WRITE down the requirements. But there is a definite skills (and knowledge) required to do this well.
I will go with waterfall development strategy.. It is basic and effective methodology...