Project Management Methodologies and DevOps
Have you ever researched project management methodologies before? Well then, The Agile, Scrum, XP, and Waterfall methodologies have surely come up and when it comes to the lists of popular, trusted project management methodologies, these methodologies have their own place and sit comfortably among all the popular project management methodologies ( Agile, Scrum, Lean, XP, Six Sigma, and Kanban for example )
Resuming the previous story, we’ll now talk about some popular project management methodologies. You can also skip to the previous story first if you haven't gone through it.
A project management methodology is a system of principles, techniques, and procedures used by those who work in a discipline. It's basically a set of guiding principles and processes that drives how work is prioritized and completed. Not only do the top methodologies differ in how they’re structurally organized, but they also require different deliverables, workflows, and even project management software development. Let’s dive into some of these.
Waterfall Model Methodology
The Waterfall Method is an example of a Sequential model where a sequential development process flows like a waterfall through all phases of a project eg requirements, design, code, integration, test, and deploy with each phase completely wrapping up before the next phase begins.
The waterfall method is a breakdown of project activities into linear sequential phases, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. — Wikipedia
We see, With Waterfall, everything happens in phases. Requirements are gathered and a requirements document is generated. Then that phase ends. The artifacts for that phase flow down into the next one. In the next phase, we do all the design and the design is documented in high-level designs, low-level designs, system-level designs, and then that phase ends. Those artifacts get passed down to the next phase and the coding begins where developers take the low-level design documents and write the code that implements those designs. There are entrance and exit criteria to each of the phases. So, all along, we’re coding in isolation, we’re not integrating modules with the next person’s module. Finally, you get to the integration phase when all those modules come together. This is the first time we realize, we don’t know whether all these pieces even work together. And then we move on to the testing phase because now we’ve got a system that people can test. And as they find bugs, they must go swim back, up the waterfall, open some bugs in the coding phase and do some re-coding. Finally, after all the testing, we deploy the software. It is called Waterfall because if there is a problem, it is very hard to go back, like trying to swim up a waterfall. You have to go all the way back to the design phase.
So this methodology has its pros and cons as well, talking about pros
- This model is simple and easy to understand and use.
- It is easy to manage due to the rigidity of the model — each phase has specific deliverables and a review process.
- In this model, phases are processed and completed one at a time. Phases do not overlap
Well, It’s well suited for smaller projects where requirements are well defined and each phase must be completed before the next phase of development.
So what is wrong with this approach? Well, there’s no provision for change. Every phase has entrance and exit criteria. When one phase ends, the next one begins. There’s just no provision for going back and changing the design or changing the requirements or anything like that. Another problem is that you don’t know if it works until the end. There is no intermediate delivery. Nothing is delivered, until that last step, when we give it to the operations team and say, go deliver this thing into production. So it is not desirable for a complex project where requirement changes frequently and Error can be fixed only during the phase. Here comes Agile and DevOps.
Extreme Programming (XP)
Let’s see how Extreme Programming was the beginning of Agile and how it became part of DevOps.
In 1996, Kent Beck came along with extreme programming. Kent based this on an iterative approach. He described these feedback loops. Release plans take months, iteration plans take weeks, acceptance plans take days and stand-up meetings are conducted every day. And pair negotiations are done every hour and unit testing in minutes and programming in seconds. These tighter and tighter loops represent the approach. The idea was to improve software quality and get feedback quickly: get something out to the customer, get feedback quickly, and then iterate on it.
Extreme programming was intended to improve software quality and responsiveness to changing customer requirements. It emphasized concepts like pair programming. Where it gets two sets of eyes on every line of code and helps cross-train your team with skills. For example, a person who really knows Python will pair with one who is just learning Python. They work together and the junior programmer gets to see how the senior programmer approaches the problem. Pair programming is a great way of mixing the skills in your team and getting everyone under the same code to understand it at the same time.
Kent Beck’s Extreme Programming was one of the first Agile methods. In 2001, seventeen software developers met in a resort in Snowbird, Utah to discuss these lightweight development methods. What they came up with is called the Agile Manifesto. The Agile Manifesto emphasized
- Valuing individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation, and
- Responding to change over following a plan.
That is to say, while there is value in the items on the right, we value the items on the left more. It was a big breakthrough. People began to change their organizations to be Agile.
Agile Development and Scrum
According to Project Management Institute, more than 70 percent of organizations have incorporated some Agile approaches and 77% of companies adopt scrum. Additionally, more than 25 percent of manufacturing firms use Agile exclusively. And based on research from Price Waterhouse Coopers, Agile projects are 28% more successful than traditional projects. Unfortunately, 47% of all Agile transformations fail, according to Forbes. 47% that’s almost half. Why do you think that is? One study by VersionOne shows the number one reason Agile projects fail is inexperience with implementing and integrating the Agile methodology. You see, Agile is not just a process that you follow. It’s a mindset that you become. It’s a philosophy that requires you to think differently about managing teams and projects. Executive leadership needs to change their long-term focus and instead focus on delivering value quickly and iteratively to delight their customers. In order to succeed at becoming agile, you must change the company culture. Another reason Agile projects fail is that Agile is not something you can simply learn from a book.
In Agile development, requirements and solutions evolve through a collaborative effort of self-organizing cross-functional teams and their customers. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement. It also encourages rapid and flexible responses to change. Work is done in increments called sprints. Planning is adaptive. We plan for the next two weeks, and then the two weeks after that, Agile includes continuous improvement, that is asking what you learned, and what you are going to do to change.
But being Agile doesn’t solve all the problems. There is still Ops to consider and Agile was in direct opposition to the way operations were being measured. Because it’s actually crazy that the developers are being Agile, working in sprints, working in sprints, and then waiting, waiting, waiting for the Ops team to deploy something. Agile, alone, is not good enough. So We need a solution to this problem and DevOps has an answer.
Scrum Methodology
Let’s see Scrum and distinguish between Agile and Scrum, define the key characteristics of the Scrum methodology, and describe the steps in the Scrum process. Agile and Scrum are two words that many people use interchangeably, but there is a difference. Agile is a philosophy. It is not prescriptive. It’s a philosophy for doing work. Scrum is a methodology. It is prescriptive. It’s a methodology for working in an agile fashion. So, what is Scrum?
Well, it’s a management framework for doing incremental product development. It emphasizes small, cross-functional, self-managing teams. And it provides a structure of roles and artifacts. It also uses these fixed-length increments that are called sprints. And it has a goal of building an increment each time through a sprint, a potentially shippable increment each time through that iteration. Very, very important that you get stuff in your customers’ hands early. So basically, “Easy to understand, difficult to master.” There’s not a lot of rules in Scrum, but somehow it’s really, really hard to do, Not as easy as it looks
Let’s talk about the sprint. A sprint is one iteration through the design, code, test, deploy cycle, right? So, you’re doing these mini iterations. It’s kind of like the software delivery lifecycle. In a mini inner iteration. Every sprint should have a goal, everybody should understand what it is we’re trying to build with this increment. What should this increment do at the end of the sprint? Sprints are usually two weeks long.
Let’s look at the steps in the scrum process. You’ve got the product backlog. This is the list of all the stories of everything you ever want to do with your product. This is it, this is everything, it’s kind of your to-do list of everything you might want to do. Then we’ve got something called backlog refinement, that’s when we go through the product backlog. And we groom the stories to make sure that they’re sprint ready because we want to start doing planning on those stories. Then, we have a planning meeting where we produce a sprint backlog. Notice the sprint backlog is smaller than the product backlog. The sprint backlog is just those stories that we want to accomplish in the next sprint, in the next two weeks. So we take from that product backlog, pare it down into a sprint backlog of just the stories to execute in the next sprint. And then we start our two-week sprints. And every day we get together and do the daily Scrum or the daily stand-up where everybody gets to answer three questions.
- What did you do yesterday?
- What are you going to do today? And
- Is there anything blocking you or impeding you from getting up further?
So you go through that every day for two weeks, building your sprint. And then finally, hopefully, you’ve got a valuable shippable increment at the end of that process. Agile development is iterative. You’re going to go through this again and again. Design, code, test, deploy, design, code, test, deploy. And notice, you know, you’ve got to have some kind of deploy, it’s not enough to just do design, code, and test, design, code without deploying it and getting feedback, right? So, every sprint you make a plan, you go through the software delivery lifecycle cycle, and then you deploy that application and you get some feedback from the customer that is input to the next plan to go through the next cycle.
Final Thoughts
The waterfall approach is a structured, step-by-step process that can lead to problems not surfaced until later in development, while Agile is an iterative approach to software development that emphasizes flexibility, interactivity, and transparency using small, cross-functional teams and Scrum is a methodology that follows the Agile philosophy. We also talked about Extreme Programming that advocates an iterative approach that valued simplicity, communication, feedback, respect, and courage.
That’s all for now!
In the next article, we’ll look into Minimum Viable Product, What is Test and Behavior Driven Development, and why it’s important to embrace failure and design for it. If you enjoyed this article please do Like and Follow. Let me know your thoughts and comments on this.
