The Evolution of Project Management and Scrum
The next step in Scrum’s evolution is long overdue. Almost everyone who has spent a few years in the software development world has been exposed to a taste of Scrum. Each organization has their own twist on its implementation, but without a doubt, Scrum is the most recognized and utilized Agile methodology available today. But with Scrum’s use we all hear about its limitations and why it doesn’t work. For instance,“How can I secure people and capital with the lack of planning that Scrum encourages?,“Scrum won’t work for my distributed model”, “Scrum is too unstructured, we need a reliable approach”, and unfortunately, “unstructured” is one of the more mild words I’ve heard on the topic. The list of limitations goes on. And likewise, in the project management world we hear similar sentiments. The latest Project Management Institute (PMI) Certification (PMI) is a good step in the right direction but doesn’t bring the two methodologies completely in sync. Being from a project management background and also being a Scrum Master for several teams utilizing the Scrum process, I can attest to some of the shortcomings of both methods; however, combining the two methods could be the evolutionary change that the software development community and their sponsors/stakeholders have been looking for.
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.
Despite the differences between Project Management Institute (PMI) and Agile approaches, many of the practices identified in the Project Management Book of Knowledge (PMBOK) are quite compatible with Agile practices. In fact, when followed with discipline and rigour, Agile methods are just as compliant with the Capability Maturity Model Integration (CMMI) as traditional waterfall methods. The differences lie in when and how these practices are executed and the lexicon used by their practitioners as seen in the table below.
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 ICT 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?
