Posts filed under Development Methodologies

What Makes Agile Software Development Better Than Waterfall?

One of the first decisions for every development project team is the ideal methodology to be employed in order to provide the desired result for the particular situation. This can often lead to debate.

Let’s back up for a second though to clarify what we mean by development methodology. It is essentially the process of organizing the work for a software development project. It does not necessarily involve the style of project management or a particular technical approach, but often these are interconnected.

So, back to our debate. Waterfall and Agile are the two popular frameworks often part of these discussions. Both are mature, usable methodologies, but Waterfall can best be termed a traditional approach, whereas Agile is a more specific type of Rapid Application Development (RAD), often implemented using Scrum. Scrum itself is a simple framework for team collaboration, providing an effective management and control structure for complex projects and reducing complexity, allowing the focus to be on building the software to meet client needs. And, actually, Agilists don’t call it a methodology, but more of a movement.

The Waterfall methodology uses a sequential design process and its workflow is much like manufacturing and construction processes. It has eight stages, each of which has to be satisfactorily completed before moving to the next.  This means that once the developers have completed one stage, there is no going back!  If problems arise, the only escape is ditching the entire project and starting anew. So, there really isn’t room for errors or change meaning that the project plan must be detailed, extensive, and carefully followed from the start in order to reach the desired outcome. There is stress on meticulous record keeping which does allow for the ability to make improvements in future if done properly.

In response to such a rigid framework and the perceived failure of the dominant software development project management paradigms like Waterfall, the so-called Agile Manifesto placed the emphasis more on collaboration and communication, team organization, and the flexibility to adapt. Agile software development relies on an iterative and incremental and adaptive approach. The methodology is open to the changing and encourages feedback from the end users of the product so that it also encourages accountability and consistent communication. Cross-functional teams will be able to work on iterations of a product within a specific range of time, ensuring that the end product is organized and prioritized on the basis of the customers or the business in general. Ultimately, with Agile methodologies, developers and clients work together in order to align the product with the goals and requirements.

So what makes Agile software development superior to Waterfall in our humble opinion? The concept of teamwork is often considered a powerful tool in the achievement of the goals for almost any organization. Extra Nerds, for example, works within a team paradigm and it is extremely effective. The team will vary, based on the project. The Agile movement creates a better platform on which decisions can be made by all parties at the table. It sources the efforts of both the developers and the stakeholders and combines them to form a unit that works for the greater good. Man is to err, and Waterfall methodologies make it really difficult to mend any broken bridges in software development. In contrast, Agile frameworks allow a window for changes, making it much easier to roll with the punches so to speak in the makeup of the system and to reduce redundancy.  Still, we are very flexible and some folks still prefer the rigidity of Waterfall et al. Regardless, the choice or recommendation of the software development methodology will be heavily weighted on the nature of the project. Once everyone has a clear analysis of the project, choosing the ideal framework shouldn’t be difficult.

Of course, this is just a basic overview, but there are many resources out there to learn more about Agile. You can also check out Extra Nerds to see what we can do for you and how we can manage your next project using any methodology - or movement -  you want!

Check back next month when we go more in depth about the core concepts of Agile, including Scrum.

Posted on March 24, 2017 and filed under Development Methodologies, Agile Development.

What is a scope document and why is it important for software development?

A scope document, or a statement of scope, is one of the most critical aspects of any project as it provides a fundamental understanding of the magnitude of the project for all involved. Especially critical in software development, it explains the boundaries of a project, establishes the responsibility of each team member, and sets up the procedures for how completed pieces will be validated and approved. Essentially, it defines goals, deliverables, tasks, deadlines, andcost. It is a way for the client and the development team to come to consensus on the vision and what it will take to get there.  Its relevance lies in managing the client’s expectations and coming to an agreement about what will define the project’s success.

Without a detailed requirements agreement, a developer might end up confined to an unrealistic fixed cost and possibly unreasonable time limits. Or the client may end up feeling frustrated with constraints. It is in these cases that defining the scope of a project is most important. Gathering the functionality requirements in the outset of the project can be difficult. Using a basic outline can help with that.

The scope document should generally start with a justification for the project or, in other words, the need it is to fulfill. Next, you might want to include some of the proposed characteristics of the project or, at the very least, an overall description of the desired result. Objectives and criteria for deliverable acceptance would be included as well as any exclusions, or unwanted bi-products. It’s important to try to identify any potential constraints or restrictions upfront so that everyone knows to expect and can also agree that they don’t actively know of any other restrictions which may impede progress.

In some situations, you might want to include what industry types call assumptions. These address how uncertain information is managed as the project moves forward. As you can imagine, this aspect is critical in software development.  Once all parties agree on the scope outlined in the statement, it becomes somewhat of a binding agreement and will define the client-developer relationship as well as the likelihood of continued success.

A scope document allows for a thorough analysis of the software development process, but, of course, having this document in place does not guarantee that issues will not arise. While the document provides the project manager with guidelines for decision-making as the project moves forward, unforeseen roadblocks can become an issue, as is true more often than not. When this happens, the scope may have to be revised. A client will likely accept the proposed changes once the project is underway, recognizing that change is often inevitable in software development, but it can also be decided not to continue the project if the depth of the unanticipated problem is for some reason too daunting or somehow renders the project obsolete.

So, the purpose of creating a scope document is to develop a common understanding as to what needs to be included in or excluded from a project. With a well-outlined document, the software developer will be much more able to complete the project within the agreed upon time and within the anticipated cost expectancy making it paramount to success from all sides.

Extra Nerds offers a dedicated project manager to each client, helping to keep both the developers and clients clear on the scope of the project as well as in the loop on progress or issues as work moves forward. Contact us if you have an idea for a project that we can manage for you!

Posted on February 24, 2017 and filed under Other, 5 Qualities of a Good PM, Development Methodologies.