For project managers who are training in SCRUM agile, here is a scrum methodology diagram for reference:
Scrum Agile Methodology
User stories (and tasks, features, etc.) are written and added to the product backlog. These can be written by the team, the project manager, project owner, or any other stakeholder.
The Product Owner (or project manager) organizes the product backlog.
During a sprint planning meeting, user stories are selected for design and development and implementation and prioritized into the sprint backlog by the product owner.
The team works on the items in the sprint backlog with the Scrum Master helping to unblock team members.
Every day the team meets for a daily scrum meeting where they discuss what they are working on and if they are blocked or stuck on anything.
At the end of a sprint, there is a retrospective to see what went well and what needs to change.
Then the cycle begins again with new user stories added, existing user stories selected for development and so on.
What is the Product Backlog?
The product backlog is the list of potential user stories that can be worked on. The list can contain tasks bugs and features as well.
It can be organized by priority, by estimated dollar value, by urgency, by number of customers who would be happy, or by some other criteria.
What is a User Story?
In contrast to traditional project management where work packages are worked on, in agile you have a user story. Each user story includes the user persona or actor. It also includes what they would like to be able to do in the system.
Examples of user stories
As an author, I would like to write a book (for a word processor)
As the system administrator, I would like to view all performance metrics of our active systems
As an educator, I want to create a course outline
As an teacher, when creating a course outline, I want to include PDF presentation files and images
Cause and effect diagrams, also known as Ishikawa diagrams, are one of 7 basic tools of quality. You won’t see them used very often in software development or IT projects though they should be. So today we’re going through what cause and effect diagrams are, why they’re useful, an example diagram, and case studies.
You will learn:
What a cause and effect diagram is
The usefulness of cause and effect diagrams
Using industry-wide common causes as a starting point
Common causes in the IT & software development industries
Example cause and effect diagrams
Case studies, example cause explorations based on real-world experience
Applying cause and effect diagrams, applications of the diagrams to explore root causes
I like the goal of eliminating defects while you’re writing code rather than fix bugs later on.
When it comes to testing, my goal is to eliminate defects. At least the ones that matter. (Netscape 4.01 users, you’re on your own.) And I’d much rather prevent defects than find and fix them days or weeks later.
I think of defects as coming from four sources: programmer errors, design errors, requirements errors, and systemic errors. When trying to eliminate defects, I look for practices that address these four causes.
He lists some solid methods for preventing defects for each of these classes of errors.
Preventing programming errors is done with test-driven development; unit-tests, focused integration tests and end-to-end integration tests.
Preventing design errors is done by having a simple clean design, incrementally improving the design and architecture and constantly refactoring to ensure it continues to be clean.
Preventing requirements errors:
a whole team is required, cross-functional and able to get what they need to finish the project
customer examples, using multiple examples can help clarify the general idea of the feature to implement
customer review, get the programmers to walk through the new functionality with customer, kinda like the client UAT (User Acceptance Tests) we do at work.
push testers to help in the build process rather than relying on them after releases are made. They can work with the customer to figure out requirements or set up automated regression testing (most companies rely on manual regression testing which eats up a lot of time)
Find ways to give users some sense of predictability
Earn trust incrementally
Explain how updates will become more accurate as the project progresses
Give users enough information to make good decisions
Make sure you talk to all the stakeholders
Don’t use developer buzzwords
Adopt Agile techniques gradually
Agile Switching Between Projects and Operations
It’s interesting how clients expect things to be projects with a well-defined beginning and an end. However, since there is ongoing maintenance for websites, web apps, and other software, these projects inevitably turn into products. They should be managed that way:
“Businesses might be anxious that constant iteration = never-ending,” says Josh Oakhurst, from Skookum Digital Works. Sure, to an educated client, “open-ended” is an advantage, with flexibility that can be celebrated. But most clients just want to know what they’re buying, he says. “With Agile, software developers are selling a process, not a product.”
Furthermore, the project is going to be never-ending unless it stops making money or accomplishing whatever goal the client has in mind. It is no longer a project and becomes operations. Most clients are not set up to handle this switch between projects and operations. They need guidance and help in setting up expectations for Agile.