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

Read This If: You want to ensure you are basing your projects value on input from true subject matter expert (for any type of project).

A fake subject matter expert or SME can derail a project. Improvements to your business should be based on the best information you have access to, not outdated or incorrect information. The acronym “SME” seems to pop-up everywhere. I agree that saying “subject matter expert” does not flow as well as SME, but the phrase drives home that the person should be an expert (and in the right subject)!

Subject matter experts are used on projects from IT Strategy, to business process improvement, to software development, to organizational change . . . to name a few. They are supposed to impart the wisdom of what is actually happening, and often, what is needed. But if they are NOT an expert, then what? Are you basing the success of your project on poor information?

So what exactly is a fake SME? The basic premise is that they are someone who appears or pretends to be a subject matter expert, but is not. There are many types, but let me outline some of the more common ones:
(more…)

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!

A colleague and I were discussing a merger they were involved in. The organization that acquired them was amazed to see that the acquisition had drastically better systems and processes. They did not, pre-merger, fully grasp the efficiencies the new acquisition brought to the table. Clearly they saw value in the acquisition - but did they overlook where the value was coming from and does that matter?

Organizations overlook IS and business process improvement as a source of value for many reasons including complexity, reactive approaches, and lack of measurements. These are common themes at Fortune 500 companies and small and medium businesses alike.

Business is complex. It is hard to avoid that. We hear “there is not enough time” and also “if you do not have time to do it right, when will you have time to redo it?” Which saying wins in your organization? Complexity and lack of time tend to feed off of each other. If you do not understand your business and where it is adding value (and losing value!) you are living in that reactive zone that all of us slide into at times.

Reactive approaches seem difficult to avoid with the endless funnel of projects pouring in. The problem here is that we often try to use the “strategic hammer” - simply saying we need to be more strategic does not make it so. Experience shows that you often do not even realize you have slipped into a reactive mode, until you are there.

There is typically no time allocated after a project to measure or complete retrospectives on the project. Additionally, time is rarely allocated before a project begins to recap what failed and succeeded on past projects. If the only lessons learned are by the individual, how can the organization increase its knowledge? If no goals (time and budget don’t count) were developed when the project was approved, how do you know if you have been successful?

It is important to understand where your value is coming from and going. Without understanding these sources you cannot focus your resources on the most important areas of the business. Until those “magic beans ” are created to solve all problems, consider a few ideas to deal with these issues.
► Develop a high level overview of your business or simply one business area. Start small and build!
► Outline key areas that are causing problems (time, money, frustration, loss of moral). Use basic measurements to start and keep it simple! Determine the root cause!
► Drill down and focus on one area or sub-area and set some goals to improve it. Empower a champion to achieve these changes or ask to be empowered to make them!

Bottom line here is to start in one small area, and iteratively move forward. Build on each step. Think ‘lean strategy’.

It is important for the source of value to be recognized. Without this recognition, resources are not allocated to business process improvement and information systems projects. Shining the light on this value is up to everyone in the organization, since everyone suffers if the organization wastes money and time.

Have questions about how to get started? Email me with questions or comments.