In relation to product development, agile methodologies vary widely in their approach. The literature for Scrum is extensive and has many recommendations of how we can encourage a team to self-form all the way to getting a product to market with a minimal number of bugs and getting paying customers lined up. It is not a detailed guide like PMI’s Project Management Body of Knowledge (PMBOK) which provides a fairly detailed guide to get from inception to closeout, but Scrum goes into more depth than the PMBOK when it comes to software development. When speed to market and quality are vital to a project or company’s success I think Scrum handily beats the PMBOK approach. With the speed of software product release, the low tolerance of customers to bugs in the code and the difficulty of securing capital, Scrum provides a faster and more reliable method to get from idea to market with the least amount of overhead.
Sponsors and stakeholders have additional goals in mind: the desire a product to sell profitably with the least amount of overhead possible. For a project to be funded we need capital, and in most organizations a plan must be created to show how not only the product and quality targets mentioned earlier but also how efficiently we can utilize the capital we are seeking, profit margin, and return on investment to name a few. Scrum doesn’t address or focus on this. PMI’s PMBOK, on the other hand, has documented several approaches to address these concerns. To secure capital, we can use project scoping methods, cost-benefit analysis models and a host of other tools that the business community is familiar with and has come to trust over the years.
Let’s imagine we’re not successful in securing capital. Without capital we have no way to get people dedicated to our project, thus no product to develop. We have an idea but no one to work on it. Some teams are lucky enough that they can form with just a few cycles each week to get a product at least to a reasonable inception phase. This applies to start-ups all the way to corporate environments. Maybe we have to do the work after hours, or maybe we have time to spare during work hours. Either way, people have to be motivated to make it work. This is where the “self-forming” aspect of Scrum comes into play. Project Management takes a more formal approach to organization and makes an assumption that people can be assigned to and will work on the project. In situations where this is not the case and we need to find a way to get people together to work on a project quickly, I think Scrum’s approach wins, hands down.
Once a team forms, we can have a few quick meetings for estimating and planning. Both Scrum and Project Management methodologies have many books covering this topic. The main issue is getting to the point where we can have these meetings, and again, I think this is where Scrum’s recommended approach is more manageable, especially for smaller organizations with limited resources.
Distributed team models are one of the topics lacking in the current Scrum literature. There are many ideas but not many proven answers. Project Management has addressed this only from a high level but much more so than the Scrum community. Distributed models can work in the Scrum environment; it’s just a matter of how you structure your teams. Although many believe that co-located teams are required to make Scrum work, this logic is fundamentally flawed.. For instance, even the first iPhone had a distributed team and we’ve all heard about the level of secrecy that Apple keeps on its development. To have a distributed team, we just need to employ a different set of tools. Several reliable and proven collaboration tools exist that bridges the gap between distributed teams and make things much more manageable than they were a few years ago. We can share documents, code, even the same workspace with the right applications. Distance should not be an issue, regardless of the team(s) utilizing Scrum or Project Management methods.
The limitations of either approach in the software development environment are well documented and can be found with a simple Google search. While neither on their own can address each limitation fully, I think we can see that when we start taking different tools and practices from each methodology we can address many of these issues. This is where I believe the next evolution in the software development environment will take place. The blending of proven Scrum and Project Management methods available today can not only move us beyond these limitations, but also make our projects nimbler, cheaper and “lighter-weight” than ever before thus getting our products to market faster, cheaper and with higher quality. Who wouldn’t want that?
Don't forget to leave your comments below.