Types of Project Methodologies¶
★ Linear (Waterfall) - Means the previous phase or task has to be completed before the next can start.
★ Waterfall - Formally approved project plans work well when the desired product is known & understood. Ex – Clear requirements & goals are based on mandated regulation.
★ Iterative (Agile) - Means some of the phases & tasks will overlap or happen at the same time that other tasks are being worked on. Can deliver & test out parts of the project as it’s completed. Gather feedback & make adjustments. This methodology is often used in Agile & Scrum projects. (Link to Agile & Scrum Section)
★ Scrum (Agile) - The most popular methodology of agile PM. You form a team that will work together to quickly develop & test a deliverable. The work is completed in short cycles & the team meets daily to discuss current tasks & clear up anything that’s blocking their progress.
★ Extreme Programming XP (Agile) – Built around simplicity, designing, & releasing a basic product that works then adding features in later. Design, Code, Test (lots of testing), Listen customer feedback. Intended to improve product quality and responsiveness to changing customer requirements. XP it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. Other elements of extreme programming include: programming in small batches, pair programing, extensive code review, and automated and manual unit testing of all code. XP also prescribes continuous integration of code. Integration is a difficult activity. However, if it is done continuously, in small batches the difficulty is reduced. * Keeping a test case linked to a feature or story has long been a challenge. Features undergoing modifications, upgrades or defect resolutions often neglect revalidating the feature test case. Unless the test case is also updated, or, at least checked it may no longer be sound and able to adequately test the feature. This is a quality problem. * XP’s Test-Driven development addresses this shortcoming as the feature is driven by the Test. The developer writes the test at the same time the feature is being written. This also applies to updating the developer updates the test, at the same time the feature code is being updated. * N-Unit testing provides a great environment for Test-Driven Development. N-Unit Testing is almost always included in development environments. This architecture links the test and the feature. Tests can be run, at the same time the feature is coded. This way a running feature is always hard linked to a passing (or failing) test.
★ Behavioral Driven Development (BDD)
★ Pair Programming (Agile) - Typically considered part of Extreme Programming or XP, involves two or more developers working on the same task, or some people say the same code module, sometimes is called gang programming. It can really be situated like a conference room type of approach or a virtual meeting type of approach where there is the code module that is on a projector or on a screen or shared then everybody on the team that’s there contributes.
★ DevOps (Agile) - Bridges the gaps between the development team, and the team that operates the product delivery and runtime. The business and development team are tasked with adding new features and functionality to the solution. They also fix issues that were discovered in production. The Operations teams looks to support a stable product that delivers value to the customer. The introduction of new features, and updates can disrupt that operation stability. This causes a conflicting goals between development and operations. The DevOps methodology has practices that allow teams to continuously improve the product, and continuously stabilize the product. No matter where you go, DevOps experts will say that it’s a mindset and that is true. It’s also a different way of thinking about product development. DevOps has three major components continuous improvement, continuous integration and continuous deployment with continuous improvement. That’s where team members and stakeholders test the product, gather feedback to improve the product.
DevOps and Continuous Deployment - Continuous Deployment (CD) is the continuation of Continuous Integration. Once the tests have been validated on the dev environment, it must be put into production. Continuous deployment, therefore, consists of automating deployment actions that were previously performed manually. Take a few minutes to read Continuous Deployment
★ DevSecOps - We have already discussed that DevOps is a combination of the words development and operations. However, the industry has also moved to adding security to the DevOps methodology. Secure DevOps, or DevSecOps is the process of adding security to the DevOps methodologies.
DevOps and Virtualization - Virtualization and Cloud are a major DevOps components. Virtualization and Cloud allow teams to copy the production environment and use it as development and test environments. This way, the team can develop and test in environments identical to production. Development and testing using this approach greatly increases quality.
Make sure to check for vulerabilities in virtual environments.
★ Kanban (Agile) - A visual tool to represent progress. Sign board with To-Do, In-Progress (WIP Limit), & Done. With a backlog for tasks to be completed later.
★ Lean-Six Sigma (Agile) - Uses technique of making the team feel valued to motivate them. Streamline processes – Reduces variation to ensure processes are the same every time. 6-Sigma 5 Principals:
Define Value - What the customer wants
Map Value - Streamline process
Create Flow - Eliminate waste
Establish Pull - Pulling on product
Preserve Perfection - Continuously improve
★ Lean (Agile) - Lean is an agile framework that promotes an incremental flow of work to the customer. Lean promotes visualizations of work status, and working with small tasks. Lean prescribes focusing on a core set of tasks in a flow environment and completing them. This process then repeats. Lean has 7 principles:
Eliminate waste: Review the value chain and eliminate wait time
Build quality in: Test all features that are built
Create knowledge: Train workers and take on challenges.
Deliver fast: Work with tasks that are as small as possible and get them done
Respect people: People do the work
Optimize the whole: Work with the complete solution that is deliverable to the customer, not the solution components.
❤ Process improvement – Find where problems are occurring in current processes and fix the using these frameworks.
❤ This technique can be used to solve any business problem
Define the project goals & what it takes to complete it
Measure how the current process is performing & figure out where the problem is & how to fix that problem. – Data Measurement
Analyze the data – Causes & solutions
Improve – Present findings
Control & implement it & keep it there
Agile vs Waterfall¶
❤ Agile was created in response to the strict linear process of waterfall.
❤ Agile embraces the reality that the world, customer, markets, & users are uncertain & unpredictable.
◆ Agile is an iterative process - Works by using cycles of feedback & improvements to create quality products & improve operational processes. Can take notes on what worked, what didn’t & improve product/processes using feedback for next round/test.
❤ Changes as team receives feedback & new info. Usually, initial set of requirements or feature ideas, but the list continually grows & changes throughout the project. Team works with the stakeholders to prioritize the requirements, moving most urgent or valuable items to the top. Then go down the list, working on requirements in iterations.
❤ Real-time, person-to-person conversations – shorter documents that are much more focused on their purpose. These documents are much more focused on what the reader needs to know to get the job done & written as needed.
❤ A deliverable is a tangible outcome from a project.
In waterfall the deliverable is not released until the very end
In Agile the deliverable is smaller more frequent releases – it builds up to be just as exciting as waterfall
❤ 5 Steps in Agile:
Plan
Design
Implement
Test
Review
★ Agile aims to get customer feedback quickly
★ Working with agile you find ways to work more efficiently by focusing on streamlining processes without reducing product quality or value
★ Streamline = Reduce Waste
★ More collaboration means less documentation & earlier feedback about the product
Agile Manifesto¶
Manifesto for Agile Software Development
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:”
★ 4 Values of the Agile Manifesto:
Individuals and interactions - over processes and tools
Working software - over comprehensive documentation
Customer collaboration - over contract negotiation
Responding to change - over following a plan
❤ That is, while there is value in the items on the right, we value the items on the left more.
★ 12 Principals of the Agile Manifesto Grouped into 4 Themes:
❤ Value Delivery – How do agile teams delivery highly valuable products to their customers?
❤ Business Collaboration - How do agile teams collaborate with their business partners & stakeholders to create business value to the organization?
❤ Team Dynamics & Culture - How does a team create & maintain the right interpersonal & team dynamics to deliver value for the customer & the business?
❤ Retrospectives & Continuous Learning - How does the project team learn to continuously increase performance of an organization & business?
Value Delivery¶
❤ Our highest priority is to satisfy the customer through early & continuous delivery of valuable software
❤ Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
❤ Working software is the primary measure of progress.
❤ Simplicity – The art of maximizing the amount of work not done – is essential – less confusing – less buttons & features – those can be added later – we want to release a working product.
❤ Continuous attention to technical excellence & good design enhances agility. Delivering work as quickly as possible in order to get feedback & mitigate time risk.
Business Collaboration¶
❤ Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
❤ Businesspeople & developers must work together daily throughout the project. Collaborating with your customers helps the team get critical business information immediately allowing them to adjust & scope to any new information instantly.
Team Dynamics & Culture¶
❤ Build projects around motivated individuals. Give them the environment & support they need & trust them t get the job done.
❤ The most efficient & effective method of conveying information to & within a development team is face-to-face conversation.
❤ Agile processes promote sustainable development. The sponsors, developers & users should be able to maintain a constant pace indefinitely.
❤ The best architectures, requirements, & designs emerge from self-organizing teams. Create an effective team culture that is inclusive, supportive, & empowering. Keep them motivate & trust them. Give them the tools & resources they need to reach their goals & let them decide on procedure. Help them feel that their input is valued.
Retrospectives & Continuous Learning:¶
❤ At regular intervals, the team reflects on how to become more effective, then tunes & adjusts their behavior accordingly.
Strive to continually learn & adapt to what’s working & what’s not
Set time aside to focus entirely on how to improve
How is the team doing?
Are customers happy?
Are there processes we could optimize?
Are our tools working for us?
Are we following the values?
VUCA¶
❤ The US military War College developed a concept called VUCA, spelled V-U-C-A. VUCA is an acronym that defines the conditions that affect organizations in a changing and complex world. It was designed to help us factor in the forces of change and uncertainty in our projects and businesses. VUCA stands for volatility, uncertainty, complexity, and ambiguity.
❤ Helps decide which project management approach is best for you. An acronym that define the conditions of the organization in a changing & complex world.
V – Volatility
U – Uncertainty
C – Complexity
A – Ambiguity
❤ Volatility – Refers to the rate of change & churn in a business or situation. In a volatile project, you would discuss how the next disruption to your operations is always right around the corner. Or it feels like things never have time to settle into a normal rhythm.
❤ Uncertainty - Refers to the lack of predictability or high potential for surprise. In an uncertain environment, it would be difficult to create plans for the future that we’re not based on a large number of assumptions that could turn out to be incorrect.
❤ Complexity - Refers to the high number of interrelated forces, issues, organizations, and factors that would influence the project. For example, if one product being worked on relied on diverse and global suppliers, that would add to the complexity of the project.
❤ Ambiguity - Refers to the possibility of misunderstanding the conditions and root causes of events or circumstances. A project that suffered from ambiguity would have difficulty pinpointing the causes of project delays, making it difficult to design mitigation plans to reduce the risks.
★ If your project environment has high levels of volatility, uncertainty, complexity, and ambiguity, then it’s a good sign that you should consider an Agile approach. While an Agile approach is not a perfect solution that will get rid of VUCA, it will lead to better outcomes by giving you and your team tools and systems to mitigate the risks that VUCA presents. When you consider Agile values and principles, it’s clear that Agile is a proven and well-documented solution to the challenges VUCA presents to your project.
Blending Methods¶
The test first approach can be really drawn out by a lot of documentation that you read. A lot of the blogs, a lot of the books really seem to overthink test first. But really, test first is just about having a solid test and updating that test along with the source code, and having it in a way that it can be automated, particularly when you’re talking about TDD. I like this picture here because it shows how test-driven development and behavior-driven development can be layered on top of Scrum because we see the product owner here, so we know it’s Scrum. We have the team here, we have the team here, the testers, and we are able to layer in test-driven development and also behavior-driven development, BDD. BDD is what we use to validate the stories and the features that we get from the customer, or from the product owner, or from the product manager.
We can see here a traditional, they call this a V model. For every item on the left, no matter what it is, there is a corresponding test on the right, and that’s what we always want. In the world of Agile here, that’s the approach we want to take when we layer on this test first to test-driven approach on top of Scrum. But you could see here, we’re using a behavior-driven development to dramatically reduce the time it takes to write a feature and test a feature because we have the test first. There are tools, there are languages for behavior-driven development, but you can create use case diagrams, you can do brainstorming, and walk through the written feature. You don’t need to get into a language such as cucumber or other behavioral-driven tools. You can, it certainly helps, but it can be done just as easy as role play. If you don’t want to do that, use case diagrams or workflow diagrams. Those can also be a source of behavior-driven development. Features and stories, it’s the business case for the feature or the story, is it indeed valid. If you write the test, if you have some way to test it, if there’s ever a change, you also have this fall back on to the behavior-driven development test. Again, for coding, we have the test first approach which we discussed a little bit earlier, where we have a test initially, when we first start to write the code, and if it has just barely any code in it, it’s not going to be a passing test, it’ll essentially be a failing test, and then the developer improves that test until it is indeed a passing test, and then maintains the test along with the code module, and were able to automate it, and use it for regression testing.
In today’s approach, we immediately write a test right next to it and we can use behavior-driven development to continuously validate it. We write a story at the same time we write a test, and again, we can still use behavior-driven development. When we write code for our stories or features, we immediately write the test at the same time and we can use test-driven development. This allows us to always have a test. This allows us the maximum flexibility for automation. Automation is big especially for regression testing because there’s not often time to go back in regression test. But if we automate, we can run those automated regression tests all the time. Well, the testers focus on the newly written stories and features.
❤ Agile & waterfall are both effective ways of approaching project management that add specific value. There are times when blending these styles will add even more value than sticking with just one. Don’t change too much, some consistency on the project team is good.
❤ Agile is a mindset - a way of thinking about the project. Delivery process through the value & principals outlined in the agile manifesto.
★ The Spotify Model:
Because of their flexible approach, Spotify—a music streaming company with millions of listeners—is known in the Agile project management field for setting the standard pretty high. In this reading, you will learn about the Spotify model and the importance of being flexible when scaling an Agile team.
Spotify has been able to do what so many other companies dream of doing, and they’ve done it as their team size scaled. How did they do it? Agile coaches Henrik Kniberg and Anders Ivarsson have instilled an overall approach of the constant blending of methods and adapting as time goes on.
The Spotify model encourages innovation, collaboration, and productivity while maintaining autonomy, quality, and necessary communication. It does so by using a unique organization system that features Squads, Tribes, Chapters, and Guilds.
At Spotify, teams are broken down into what they call Squads. A Squad is like a Scrum Team and is supposed to feel like its own start-up within the company. Squads are self-organizing and collocated. They work together to achieve a long-term mission. At Spotify, a Squad may be in charge of a task such as improving the app’s usability for Android, improving the Spotify radio experience, or providing payment solutions. Just like a Scrum Team, the Squad doesn’t have a formal leader, but they do have a Product Owner. Product Owners collaborate with one another to maintain a roadmap to track Spotify’s progress as a whole. Each team also has access to an Agile coach to encourage continuous improvements. Tribes are collections of squads that work in a specific area and are meant to have less than 100 people. Chapters are small groups of people across a tribe that have similar skills and work in the same general competency area. Guilds are the largest group, comprised of people across the organization who want to share knowledge, tools, code, and practices.
★ Be inspired by the Spotify model, but don’t emulate it
❤ Each team requires differences in their workflow and systems. It is never a good idea to try to copy and paste an exact model to your team just because it worked for another team. In fact, some people have tried copying Spotify’s model and found that it was not a suitable model for their team at all.
❤ You must always be able to adapt based on your team’s preferences and goals. The Spotify team started in Squads, but as they scaled, they added new types of groups within the organization—without disrupting the existing Squads. They continued to do so until they found the perfect balance of collaboration and ownership.
❤ Always examine the needs of your project and organization. What works for Spotify may not be an exact fit for your team. If you are on a team that needs scaling, be inspired by this model, but use the aspects that work best for your organization.
❤ Don’t be afraid of trial and error. If you try something and it doesn’t feel quite right, you can easily adjust.
❤ You should never consider yourself done improving. There are always changes that can be made for the better.