An Introduction to Agile !
Overview !
We live in an age where software literally touches everything. It is the great equalizer. Software is not built just by traditional software companies, but by companies like banks, insurance companies, car manufacturers, you name it and software is an integral part of it. Agile is many things. Iterating often, freeing development up to do what they do best, aligning the business with software, trying to produce stuff that our customers really want to buy and developing a culture of continuous improvement. All great stuff that is part of Agile. However, to me it is all about responding to change.
What is an Agile project?
The traditional approach to project management is often called the waterfall method. We plan everything out at the beginning, and then one step flows into the next in perfect sequence. That’s why Agile project management has become so popular, especially when it comes to software development. Agile is a faster, more collaborative approach to managing a project. The approach is summarized in a one page document called the “Agile Manifesto. It includes these four main values. Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Agile focuses less on the up-front, long-range planning, and more on communication and short-term planning. And there’s a strong emphasis on making sure that the project is delivering value to the customer, even if that means making changes in midstream. In other words, Agile focuses on delivering something that works quickly, rather than obsessing about creating something that’s perfect.
What is a user story?
Storytelling is one of the best tools for learning and teaching . And in Agile projects , we create user stories that help us visualize the future. A user story starts with a character , your user. That user is often represented by a persona. Then, you create a simple story that explains what a process should look like from the user’s point of view. A common template for a user story goes like this. “As a blank, I want blank, so that blank.” For example, “As an online shopping customer, “I want to be notified of the time “when my order will be delivered “so that I can be there to accept the shipment.” That simple story explains what the user wants from their point of view. A good user story focuses on high level functionality and describes what should happen but doesn’t dig into the details of how it happens. You can create user stories about anything, and you can have lots of them. You can even combine several user stories to create an epic. And if you prioritize your user stories, then it’s easy to make sure that you’re always working on the things your customers value the most.
Break a user story into tasks
We turn those user stories into tasks that can provide detailed descriptions of the work that needs to be completed for the story to be true. Here’s an example of a user story. As a customer, I want to be notified of the time when my order will be delivered, so that I can be there to accept the shipment. That explains what should happen, but not how to do it. So, the next step is for the project team to create tasks that explain the work required to make the story true. One of the tasks might be send the customer an email with the shipping date and tracking number, and that task can be broken into a bunch of smaller tasks like writing the code, configuring the servers and more, and once the tasks are broken down, you can estimate how much time they’ll take and assign them to people on the team. By starting with the user story as your goal, you know that every task is tied to something that your customer values.
What is a Sprint?
The Agile methodology is about continuous development, so instead of one long project, we run a bunch of short, iterative development cycles called sprints. A sprint is a chunk of time during which a specific amount of work will be done. Sprints usually last for a week or two. They should be short enough to keep the team focused, but long enough to deliver something of value. You might also hear a sprint described as a time boxed development cycle, because you’re committing to do a certain amount of work in a short period of time. During a sprint, the team is focused on addressing a fixed number of user stories. Those user stories define the tasks that need to be completed, and the acceptance testing that needs to be done before the sprint is over. We manage our teams’ priorities and issues by holding daily meetings, and we track progress by maintaining a Kanban board. Sprints are at the heart of the Agile methodology. We bring all the Agile tools together, and help our teams quickly deliver value based on our customers’ priorities.
What does a product owner do?
One of the big challenges in an Agile project is setting priorities and deciding what to do next. Whether it’s a push to add features and functions or an effort to increase speed and efficiency, you just can’t do everything all at once. I n Agile, the product owner navigates these pressures by balancing what your customers want with your business strategy and your capabilities. In many ways, the product owner is like a project sponsor in a traditional waterfall project. But in Agile projects, the most important job for the product owner is prioritizing user stories. In other words, the product owner must decide which features get added to the product at all. And by setting the priorities, they ensure that the team is always focused on doing tasks that will create the most value for the customer. To set those priorities, the product owner’s also the connection between the Agile team and the rest of the business. So, it’s important for the product owner to have both the business acumen to communicate with executives and the technical savvy to communicate with users and developers. You could say that the product owner sets the vision for what the team will build.
Run an Agile daily meeting
In an Agile project, communication between the team members is important. A common format for the meetings is to ask everyone to answer three questions. What have you completed? What are you working on? And what do you need help with? Daily meetings provide the information project managers need to keep the Kanban or Scorecard up to date. And they can help you catch and resolve issues quickly. Make sure that daily meetings are short and fast-paced. 15 minutes is generally enough. They should start on time and finish on time. The goal is just to provide a status update and figure out what issues the team is running into. So, if an issue comes up that can be resolved quickly in the meeting, that’s great. But if you find an issue that requires more discussion or research, don’t try to solve it during the daily meeting.
What is acceptance testing?
And the way that we decide whether a product is ready is with acceptance testing. The criteria for acceptance testing are questions or statements that show whether the requirements for a user story have been met. There are two common types of acceptance criteria. Rule-based acceptance criteria are the first type, and they’re simple. For example, the software package is stored in the install folder. The second type of acceptance criteria are scenario-based, and these usually follow a three-step template: given, when then. Acceptance criteria should be unambiguous so there’s no question whether they’ve been met or not. All the acceptance test criteria together should show that your user stories are now true.
What is a project Kanban?
The basic idea of a Kanban is to make work visual so that everyone can see what tasks are currently being worked on and what their status is. A typical Kanban board has one task in each row and a series of progress milestones in the columns. Then, you can use note cards or markers to show how each task is progressing. Here’s an example of a simple Kanban. There are three tasks on the left and you can easily tell the status of each task by looking to see which column is marked.
Kanban’s let everyone see what’s happening, and they make it easy to catch tasks that may be stuck or that are slipping behind. While it’s traditional to make Kanban’s on a wall or a whiteboard, you can also create electronic Kanban’s using a spreadsheet or with specialized software. For Kanban’s to be useful, they need to be accurate, so the tasks need to describe the things people are working on, and the status needs to be updated frequently.
What is a minimum viable product?
One of the principles from the agile manifesto is that our highest priority is to satisfy the customer through early and continuous delivery of valuable software, and one of the best ways to do that is to start with a minimum viable product or MVP. The MVP is a working version of the product that is just good enough to show how it works. One of the common challenges for waterfall projects is that they have too much scope from the beginning. In other words, they include features that customers don’t really want or need. But when you focus on building an MVP, you ensure that the features you add throughout your development process are exactly what your users want and nothing more. The MVP gets you from a promise or a theory to the point where you have an actual product that your customer can use and that they can provide feedback on. The feedback about the things that they need added to the MVP can then be turned into user stories. So the MVP plays an important role in delivering value to customers quickly and in supporting an iterative development process.
