[powerpress]

Kevin Tolva is a senior management consultant with Kenway Consulting in Chicago, Illinois. He focuses on developing, and implementing leading edge solutions that take advantage of critical business opportunities. Kevin’s true passion is agile development methodologies and is a recognized leader in the field. He’s coached over 20 teams through their agile adoption journey, and has  authored multiple training courses for Kenway’s consulting practice.

Show Notes

Waterfall project management was predicated on very large sequential steps in order to get delivery. Planning phases with exit criteria, then functional design, coding, testing & deployment. Usually very long phases that got you to an end goal.

Waterfall was taking too long to get projects out the doors and a company’s ability to react was impeded by these very long cycles of development. The degree of error gets much larger as you get farther out. The degree of uncertainty is much smaller for the things that you know this week or in two to three weeks.

The agile manifesto has been around since the 1970s but the agile manifesto was written in 2001.

With agile, the focus is on right sizing of documentation at the right time. By breaking the work down into smaller chunks you can make what you’re defining much more digestible. It doesn’t have to be perfectly defined from the beginning. This shorter cycle allows stakeholders the ability to react and change courses more easily throughout the process. This not only delivers a higher quality product but the features are what are actually wanted and desired.

The most popular agile framework is scrum.

There is still some amount of planning; sometimes referred to as Sprint 0. After that you have one to many interations or sprints. These iterations are typically one to three weeks. Anything longer than that is closer to waterfall.

The first step is a sprint planning meeting where the whole team gets together with the product owner and the product owner has a prioritized list of work they want to do. The developers get a consensus and common understanding of the work that needs to be done and they pull it into the sprint and commit to doing that work within the sprint. At the end of the sprint there is a showcase or demo where the development teams shows off what they’ve gotten done. Repeat and rinse until the work is completed.

After the sprint, especially for young teams, is completing a retrospective. This is an opportunity to look at what went wrong, what we need to improve, and then agree on the few things that we really need to focus on to improve as a team. This is critical for young teams in their agile adoption journey.

In the beginning you need to build a product backlog. This will be the items that need to be done to get your product out the door. In the beginning having enough stories to fill one or two sprints will be enough to get started. If your backlog is ready the time to get a sprint started will be fairly minimal. Once the backlog is ready, you can begin a sprint planning session. This is typically the product owner, the scrum team, the scrum master and the business analyst deciding what they want to bring into the sprint. During the duration of the sprint it’s really the job of the product owner to answer ad hoc questions.

If you’re going by the book, product owners don’t sit in on the daily meetings to allow the team to speak more freely but this is not a hard and fast rule.

Typically stories are written by either the product owner of the business analyst. Stories don’t have to be all that complicated are typically contain who (the actor), what needs to get done, and the result of the story. Typically this is a very small piece of work. The acceptance criteria is very granular. You have to make sure the acceptance criteria is not subjective.

Stories should be written in the business voice rather than the technical voice. The technical details get brought in during the sprint planning process. Part two of sprint planning are going off and creating technical tasks to achieve the business story.

One way to size stories is with “Planning Poker.” Many teams will use the Fibonacci series to size their stories. Sizing is to demonstrate relativity and is can be different from team to team. You can’t compare teams based on their sizes. Assigning hours or days somewhat defeats the purpose of relative sizing.

Over time you will begin to see a pattern emerge with the number of points you are finishing in a sprint which will allow you to begin planning the length of time necessary to get things out the door.

Tasks should not be sized. Hour estimates can be used and is merely a confirmation to the sizing.

When creating your backlog, think in terms of goals; with a defined start and end. Themes relate to the business process. Epics are the next level or chunk of work down from there. Stories are the next level down to get the work done. You can size at the theme, epic, and story level. You can use points or even t-shirt sizes.

Tolva proposes to point everything that a scrum team needs to do. This helps compare velocity over time.

Spike stories are generally in-sprint and something that was realized needs to get done but might be more technical in nature and not usually a business story.

The single most critical factor in adopting agile is a team that actually wants to do it. The team has to want to change to a model of a collaboration and interaction.

The single biggest factor in being successful would be to get an agile coach.

More about Kenway Consulting