Quick update on a presentation I am doing in a few weeks at the Rocky Mountain Information Management Association (RMIMA). The presentation is targeted at folks who want to get a basic understanding of agile (Scrum), why so many people promote it, and what issues and challenges are brought to the surface when you move towards agile. Here is the abstract:

Agile – Myth or Reality

Why do we keep hearing more and more about agile? When will it arrive? Has it already arrived or has it departed? The presentation will provide an overview of agile-Scrum to demystify it. What is a standup, a sprint, why do people talk about chickens and pigs? Understanding why many people are “agile fanatics” requires clarity about the types of issues that agile can resolve.

Building on the overview of agile, the presentation will review common “software project challenges” and review why agile is often cited as a solution to these problems. Can “being agile” really solve these issues and reduce risk? Are these problems actually related to the software project? Finally, the presentation will review why Agile can’t solve all problems, although we often seem to only hear about ‘agile magic beans’. The session will review issues that agile may expose, but cannot solve, and how those issues can make or break your agile success.

Learning Objectives:
- Understand the basis of agile-Scrum.
- Understand how agile minimizes risks and why people promote it.
- Understand types of issues that agile exposes but cannot address.

Learn more and RSVP here.

If you have questions or comments please post them here (include your email and add “private” to the post if you would prefer a direct response via email).

While more and more people are aware of what Scrum is, most people still have no idea what you are talking about when you say “Scrum.” This is even truer outside of the software development world, where ideally Scrum can be put to use to quickly achieve valuable results. Scrum is ultimately a management process, although it is often referred to as a “software development management process.” It can be used on any project to deliver results to the customer quickly.

Scrum, a lean or agile approach, is focused on frequent review and interaction with the customer and puts the team in the driver’s seat to deliver value quickly (not a long x year process). This is not to say the team does everything. The ScrumMaster and Product Owner are critical to successful results. Strong focus on iterative results, the team, and less ceremony (useless events, documents, etc.) put the focus on adding value that the customer can see quickly.

A quick overview of Scrum:
The Product Owner develops a “Product Backlog” of all the features, functions, and requirements that the product needs to have. They prioritize this from 1 to n (not all 1 or “high”!). The Team reviews the product backlog, and based on how much work they believe they can do in a Sprint (based on size of feature, duration of sprint, size of team, etc.), they select the features for the sprint. A sprint’s (or iteration) time frame is typically 30 days, although they can range from a week to months. The team keeps track of the time remaining (not work/hours completed) for each item on the Sprint Backlog, a list of all features (and their tasks) for the current sprint.

A Daily Scrum is scheduled for each day. This is a 15 minute meeting that ALL team members attend, and ideally standup (sometimes called a daily standup). Each team member reports what they did the day before, what they will do today, and if they have any impediments to moving forward. The Scrum Master ensures that the process and rules are adhered to. They are not a project manager and do not tell the team what to do, they ensure the team can do their job by removing barriers and enabling them to succeed.

Think of the Scrum Master as the coach of a football team (minus the headsets they all wear now for instant communication). They are on the sidelines. They do what they can, then send the team into the game. At that point, the team needs to do their job! Traditionally, a Project Manager may be the quarterback, directing the team and plays, but in Scrum, the quarterback is the TEAM and there is no traditional Project Manager.

Remember this is just a very high level overview! You can check out this Knol on Scrum for a lot more detail.

So where does this all lead?
1. Recognizing and benefiting from value every 30 days instead of waiting till the “end” of the entire project.
2. Embracing and taking advantage of changes that can’t be predicted at the beginning of a project anyway.
3. Adapting the product based on what you are learning as you go, instead of being locked into a design you realize will not longer work.

If you want to understand how Scrum can help you improve your project delivery or just want to brainstorm on some ideas, shoot me an email!

PS. Not sure what a Knol is? Write a Knol on yourself, I did!