In this series by organizational problem-solving expert Johanna Rothman, uncover the mystery behind agile project management. What is it? How does it apply to your workplace each day? Why should you be looking for technology candidates with agile experience? See how separating decisions, prioritizing projects and tackling one thing at a time produces a smoother, more ‘agile’ process in tech.
Part 2 in Dice's series about Agile The first article in our series, What is Agile, Anyway?, covered the basics of agile. Here you will learn how the typical development cycle works in agile and how teams identify and manage workload. With agile, work is estimated by the number of ‘stories’ that need to be completed. Each iteration (generally a two to four week time period) involves a plan to code, test, and deliver some number of stories. Time to Commit Once the team estimates the size of each of the stories, it's time to see what can be done in this iteration. They add up all the stories the product owner created for this iteration. The question is how many will actually fit into the iteration? What output can the team commit to? Note that the team estimates together. As a recruiter, you need to find people who can work well in a team. Team collaboration skills are critical for agile team members. If the team has experience working together, they use their experience and say, "How many points did we do in the last iteration? How many points do we have here? Are they comparable?" If they are the same, the team can and should commit. However, if the product owner wants the team to commit to more, the team will say "No, we can't. Let's look at your ranked backlog and we'll commit to the features in rank order until we can't commit anymore." The team then creates their board and they start the iteration. The scrum board is the way the team manages their work during the iteration. The board has three columns: "Ready," "In Progress" and "Done." All the stories for the iteration start as a ranked backlog in the Ready column.
Moving Work Across the Board Let's assume I'm a developer on that team ready for more work. I look at the board, and I see that there is a card in the Ready column. No one has said they need my help in the standup this morning, so I go to the Ready column, and I take the top card, and move it to the In Progress column. I work on the card, asking for help if I need it from my teammates. I talk to the testers on the team, letting them know I have started development. I will let everyone know at the next standup. As a recruiter, you will need to look for people who have the courage and initiative to be able to ask for help. That's not all that common. When I am done with my development, I mark the story as "development-done," and let the testers know it is ready. The card is still in the In Progress column. One of the testers will take the card next, and finish the testing, and then move the card to Done. When the tester is done, the tester lets the product owner know that he can see a demo. Either the developer or the tester can provide the demo. We might have agreements to work together, as a developer/tester pair, but unless we have enough testers, that is unlikely. We do this throughout the iteration, picking up cards, moving them to In Progress, and then to Done. At the end of the iteration, the entire team has a demo for the Product Owner, showing all of the features we completed this iteration. Then we have a retrospective for ourselves, looking for ways we can improve our process. And, we plan the next iteration and start again. In the next article, we’ll take a look at Kanban, a Japanese system of prioritizing work.
Part 2 in Dice's series about Agile The first article in our series, What is Agile, Anyway?, covered the basics of agile. Here you will learn how the typical development cycle works in agile and how teams identify and manage workload. With agile, work is estimated by the number of ‘stories’ that need to be completed. Each iteration (generally a two to four week time period) involves a plan to code, test, and deliver some number of stories. Time to Commit Once the team estimates the size of each of the stories, it's time to see what can be done in this iteration. They add up all the stories the product owner created for this iteration. The question is how many will actually fit into the iteration? What output can the team commit to? Note that the team estimates together. As a recruiter, you need to find people who can work well in a team. Team collaboration skills are critical for agile team members. If the team has experience working together, they use their experience and say, "How many points did we do in the last iteration? How many points do we have here? Are they comparable?" If they are the same, the team can and should commit. However, if the product owner wants the team to commit to more, the team will say "No, we can't. Let's look at your ranked backlog and we'll commit to the features in rank order until we can't commit anymore." The team then creates their board and they start the iteration. The scrum board is the way the team manages their work during the iteration. The board has three columns: "Ready," "In Progress" and "Done." All the stories for the iteration start as a ranked backlog in the Ready column.
Moving Work Across the Board Let's assume I'm a developer on that team ready for more work. I look at the board, and I see that there is a card in the Ready column. No one has said they need my help in the standup this morning, so I go to the Ready column, and I take the top card, and move it to the In Progress column. I work on the card, asking for help if I need it from my teammates. I talk to the testers on the team, letting them know I have started development. I will let everyone know at the next standup. As a recruiter, you will need to look for people who have the courage and initiative to be able to ask for help. That's not all that common. When I am done with my development, I mark the story as "development-done," and let the testers know it is ready. The card is still in the In Progress column. One of the testers will take the card next, and finish the testing, and then move the card to Done. When the tester is done, the tester lets the product owner know that he can see a demo. Either the developer or the tester can provide the demo. We might have agreements to work together, as a developer/tester pair, but unless we have enough testers, that is unlikely. We do this throughout the iteration, picking up cards, moving them to In Progress, and then to Done. At the end of the iteration, the entire team has a demo for the Product Owner, showing all of the features we completed this iteration. Then we have a retrospective for ourselves, looking for ways we can improve our process. And, we plan the next iteration and start again. In the next article, we’ll take a look at Kanban, a Japanese system of prioritizing work.