Categories: Leadership

Scrum Methodology Diagram

For project managers who are training in SCRUM agile, here is a scrum methodology diagram for reference:

Diagram of SCRUM Agile Methodology with sprints, product owners, daily scrums
SCRUM Agile Methodology Diagram. [Click on the diagram to view the original size image.]

Scrum Agile Methodology

  1. 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.
  2. The Product Owner (or project manager) organizes the product backlog.
  3. 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.
  4. The team works on the items in the sprint backlog with the Scrum Master helping to unblock team members.
  5. 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.
  6. At the end of a sprint, there is a retrospective to see what went well and what needs to change.
  7. 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
Categories: Leadership

How to apply cause and effect diagrams in IT and Software Development

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:

  1. What a cause and effect diagram is
  2. The usefulness of cause and effect diagrams
  3. Using industry-wide common causes as a starting point
  4. Common causes in the IT & software development industries
  5. Example cause and effect diagrams
  6. Case studies, example cause explorations based on real-world experience
  7. Applying cause and effect diagrams, applications of the diagrams to explore root causes
Continue reading “How to apply cause and effect diagrams in IT and Software Development”

Alternatives to Acceptance Testing

Alternatives to Acceptance Testing

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)

This whole article is very good and Mr Shore is an excellent writer. I’d recommend getting his book too, The Art of Agile Development.

Categories: Leadership

Agile and user expectations

FiFrom this article on IT World, “Why your users hate agile (and what you can do about it)”, come some answers and strategies for dealing with user/customer/client expectations:

7 tips for making Agile more palatable to users

  • 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.