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

2009 seems to be moving right along! Was 2008 tough or not so much? Will 2009 be better or worse? Are things sometimes LESS challenging than they appear?

The recent inauguration and oath of office that the US President takes has me considering just how small some project problems actually are. I was listening to a NPR story about the oath, and a few things jumped out (note that LISTENING to the podcast provides more than reading the article summary).

So where is the oath found? It is the last paragraph in Article II, Section 1 of the Constitution. It reads “I do solemnly swear (or affirm) that I will faithfully execute the Office of President of the United States, and will to the best of my ability, preserve, protect and defend the Constitution of the United States.”

Did you realize this is the ONLY sentence in the Constitution that is in quotes? Personally, I found it quite interesting that these were the only words in the Constitution that the writers believed should be specified. Most of the Constitution is not that detailed, according to Marvin Pinkert, executive director of the National Archives Experience.

On Iterations: Can you learn from George Washington? Clearly he is not teaching any classes anytime soon, but consider that the word “ability” evolved from “judgment” to “abilities” before finally becoming “ability”.  There are notes from Mason and Adams related to changes they wanted in the oath.  I find this interesting because today, we rarely think about the fact that there was an iterative process to developing the Constitution.  There was give and take.  People had to work together.  Consider how complicated that process must have been when you are working on your next large project.

More or less all projects and tasks have some iterative component so saying Washington was on a Scrum team, is over the top perhaps (and yes, Scrum can work on non-software projects). There are always changes as work is reviewed. When working on a 100% pre-planned project, you are going to run into issues if you do not have a way to address change. Change is coming, one way or another!

On Requirements: Requirements are constantly changing and the ability to tweak words to adjust the meaning is never ending. It is important to do so, in order to to make the requirements, as they say, “consumable.” Consumable requirements are not to be used in a sandwich with mayo and pickles. Consumable requirements should be able to be used for their intended goal. The critical question: “who is the audience?” You may need multiple versions of requirements or prototypes for various audiences.

On Scope: As you can see, the words “so help me God” are not in the Constitution.  Please note that I am not looking for a debate about whether they should be or not.  From a strictly technical standpoint, I find it interesting that with only one specific sentence in quotes, the phrase is not included.  So when was it used first?  That is unclear.  Some say Washington used those words, and others argue he did not.  Likely an endless debate, and as Pinkert notes, since he does not have a tape of Washington’s inauguration, he does not know.

On Change Control: Looking at the Constitution overall, perhaps it has the strongest change control of any “solution” around?  Going into effect on June 21st, 1788 (with New Hampshire’s ratification (89-79!)), there have only been 27 changes to it.  Some of these however were quite large. For example the Bill of Rights, with those those basics like freedom of speech and religion, accounts for 10 of the 27 amendments made (ratified in 1791).

So change is allowed.  The writers realized that they must allow for changes to take place.  That said, the process is quite rigid. To amend the Constitution, two-thirds of both houses need to propose the amendment and three-fourths of all states must ratify the amendment (Article 5).  That is tougher change control than most projects I run across!

A few questions to ask yourself:
Do you allow changes on your projects?
How rigid is your change control process? How rigid should it be?
Are you stifling change?
How do you account for natural changes and the flow of new ideas?
When is scope creep OK?
How do you handle iterations?

So how do I wrap this up? My point here is that sometimes we all need to consider stepping back and asking some questions about what we do everyday. Are we making things more complicated than they need to be? Are they actually LESS complicated?

Granted they had some heavy weight thinkers working on that project (the Constitution), but consider that the writers had to wrestle with these issues throughout the entire document, not just the oath! Keep in mind, this was all without the fanciness of cool terms and technology like stakeholders, computers, PMOs, agile, Scrum, IIBA, APLN, PMI, the Internet, Twitter, FaceBook, Linked In, Plaxo, and even NPR.

They got it done - can you?

Feel free to email me with questions, comments, or ideas for future blogs!

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:

1. The person works with the subject matter, but is not really an expert. This may be a junior person, someone new, or someone who probably should not even be working the area. If this person was quick to jump at the opportunity or was the only person who was available, this is not a bad thing, but be cautious. Is this person available because they don’t really know the subject matter, and the true experts are busy getting things done? Find out how long all SMEs have worked in the area they are an expert on and who the junior and senior people are. If you determine you are not working with an expert, perhaps the person can help coordinate with the expert and can save some of the expert’s time (and learn more in the process)?

2. The person thinks they know the subject matter but have never actually done the work. Typically, these folks are in senior management. They could be a director, VP, or C-level personnel. They may also be your sponsor or product owner. I often find this type of fake SME the toughest to work with, for obvious reasons! A key to dealing with this type of fake SME is to understand two key points: (a) they may know about some of the key problems in the business, but they do not typically know ALL the details of those problems and (b) they may have some insight into how they WANT the business to run.

This second point leads to a foundational question related to a SME. You know you want an expert, but WHICH subject matter do you want an expert on? Do you need an expert on the current or future process, system, or organizational structure? Perhaps you need BOTH? To avoid problems here, a simple way to deal with this is to find two SMEs, one a “current SME” and one a “future SME.” You also have to deal with the issue of “the value of understanding the current environment”, which is often overlooked, but that is another blog on another day (or night!).

3. The person was a SME, but has not actively worked with the subject matter in quite some time. This type of fake SME can be dangerous. They THINK they are a subject matter expert, but really don’t know what is actually happening. A quick way to determine if they are an expert is to ask (in an appropriate way) when they have most recently worked in the area you are discussing. Managing people doing the work is NOT the same. If they are not an “end user” they likely do not know how things are happening NOW. Just knowing how things used to happen does not help you if you are trying to understand a CURRENT business process, system, or organization. Some of the same tips for the “#2″ person above would apply here.

So how do you prevent a fake SME from derailing your project?
Aside from the ideas above, I have found an effective method for dealing with the fake SME is to prevent having any assigned to the project in the first place. During the early stages of a project, when discussing SMEs, talk about “end users” and the current and future states of the subject matter. You can adjust the statement of work or a project definition, whatever works for you. The key is that the earlier you discuss this with the project sponsor or product owner (who, as noted may be a fake SME!), the more of a chance you have to mitigate the risks.

If the project is underway, and you did not have the opportunity to address it early on, try asking the fake SME a lot of questions. Asking a lot of questions will often cause them to recommend that you gather more information from other “experts”, which ideally gives you the chance to find a real expert.

The age old question comes up again, “who else should I talk to?”

Feel free to email me with questions, comments, or ideas for future blogs!

P.S. Thanks for the excellent comments and questions on last weeks blog about online networking and Linked In. Keep the comments and questions coming and feel free to chime in right in the blog! There were a lot of valuable comments, and I believe having them here would be valuable for others to see as well.

Lately, I have been working on a number or articles on various topics related to getting the most out of technology management and efficient business processes. How does Linked In fit in there? I get a lot of questions and see a lot of confusion out there related to online social networking (Linked In and others), and how it can help grow your business or your personal brand. As a starting point, I think it is ideal to decide what kind of online networker YOU are! I expect this will be an ongoing series, let me know if you like (or dislike!) it!

While I am primarily referring to Linked In, this applies to all online networking “tools.”

Two of the more common questions I get when coaching and training on how to use online networking tools (Linked In, Plaxo, etc.) are “what connections should I accept?” and “who should I connect with?” I was recently following some discussions on a Linked In Group, for IIBA Denver, and the same topic of Linked In and connections came up.

There are a few basic types of networkers on Linked In. Knowing what kind YOU are, and WHY, is a good thing to build your network. Many people do not realize there are informal options and that they can offend people, and hurt their network, if they are unclear with their intentions.

Three basic types of networkers on Linked In, based on how they connect, are:
1. Trust-You Networker - I have to know and trust you before we connect
2. Met-You Networker - I have to have met you via phone/in person to connect
3. Open Networker - accepts all invitations

Open Networkers
Personally, I am a “3”, an Open Networker. I have over 5,000 direct connections, with nearly 19M total connections. Initially, I was a “1”, then a “2”… and finally, I just could not find any compelling reason to not accept all invites. There was really no downside for me to be connected to more people. It meant that when I wanted to find a contact at Xyz Corporation, I was that much closer to connecting to them and in many cases, could just send a Linked In email. Additionally, a large network attracts more people to your profile, since when searching you are in more peoples networks. I have received significant business through Linked In, so yes, it does happen!

Typical concerns people have with being an Open Networker generally boil down to one main issue. That is how to handle requests from people you do not personally know, who want to connect to someone who is a trusted contact. This is a potential concern, but the key is that, all Linked In referrals should be handled within Linked In (don’t give out email addresses and phone numbers if you are not comfortable with it!).

If someone simply wants to talk and learn more from someone via Linked In, I pass along the connection request. As an Open Networker, ignoring requests is not appropriate (if you are not comfortable with open networking and helping connect people, being an Open Networker is probably not for you). That said, if a person whom I do not know, wants to connect with a trusted client or colleague, I do some initial screening for my trusted contact to make sure they understand the context of the request and that it is legitimate. I have yet to have any problems with this approach.

Met-You Networkers and Trust-You Networkers
Not ready to be an Open Networker or feel that it is just not appropriate? I have run into many people who are NOT Open Networkers and obviously respect them as well. If they choose to only connect with people they trust implicitly or know personally, that is fine with me. Don’t fault people for it!

That said, I think things become complicated, when as a “1” (Trust-You Networker) you attend a networking event and hand out business cards. IMO, if you hand me a card with your email address or even Linked In profile on it, that’s an invitation for me to send you an invite on Linked In. I use Linked In as one of the key tools in for maintaining my network, so to not connect there really puts you (unintentionally) on the outskirts of my network.

Final Points
► Consider that if you attend networking events and hand out cards, that you should accept those invitations and at least be a “Met-You Networker.”
► Realize that in this day and age, Linked In and other online social networks are part of the game. A quick way to lose trust is to not connect with someone whom you spoke with at a recent event. Still not comfortable, then at least offer to grab some coffee to get to know the person – if you’re not willing to do that, you have to ask yourself, “why was I even at that networking meeting?”
► Networking is a two way street. I spend WAY more time helping others connect with people then I do asking for help.
► Call it Network Karma, but it does come back to you, if you put it out there.

Look for another post on tips for being and working with an Open Networker soon!

As an Open Networker, I have to add, if you would like to connect with me on Linked In, view my profile and send me an invite, I will accept it!

Feel free to email me with questions or comments. If you’re interested in how you or your business can build your online brand, let’s talk and see if we can add any value.

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!

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.

This information may help you in your career or as a leader to help your team improve.

This data is from the IIBA™ website. Some of it was also recently posted on a Google Knol about business analysis in general.

Business Analysis Careers and Skills May Include:

• A Business Consultant works at a high level to analyze the stakeholder’s business objectives, recommend and develop solutions to address their business problem
• A Business Process Analyst is responsible for analyzing and defining business processes both “As Is” and “To Be”
• A Data Analyst is responsible for the logical data model
• A Business Architect models the whole business in terms of goals, data, process, organization
• A Requirements Analyst works at a lower level to identify, analyze and document the business requirements and deliver work products through the project life cycle
• A Systems Analyst translates the business requirements into System/Functional requirements, which are then passed to Application Developers
• A Management Consultant assists stakeholders with understanding their strategic goals and how best to accomplish them.

Are you leveraging your business analysis team or are they boxed in? You may be surprised at what they can do for your organization if you engage them with the right ideas and even a Business Analysis Center of Excellence.

These roles and skills can help ensure:
- Your business projects are aligned
- Technology is not just an after thought to a strategic plan
- Your team is focused on the overall business
- Root cause is determined and value assessed - so the real problems are solved

Why should you care? Without attention to these issues money and time are wasted and talent is squandered.

Email me with questions or comments.

Trademark Notice
IIBA is a trademark owned by the International Institute of Business Analysis.

It can be a challenge to explain what the business analyst does. Consider the physician-patient analogy as a straightforward way to explain a high-level view of the role. The BA is very much like a physician, with the organization as the patient.

If you are not feeling well and go to see a good physician, they will not simply hand out a diagnosis, a bottle of pills, and a date when you will feel better. First, they will conduct some level of exam based on your symptoms. The more severe your symptoms, the more skill and time it will take to complete a diagnosis. Similarly, the BA cannot rush a recommendation for a solution before understanding and examining the company and issues involved. More complex business issues require more time and effort to resolve.

Complex symptoms require the physician to gather a substantial amount of background information about the patient including family and personal history, travel habits, and working conditions. Additionally, the patient will undergo a variety of tests to understand exactly what is going on. In much the same way, the BA reviews a variety of historical data and gathers current data via requirements workshops, interviews, focus groups, and other techniques. The BA then analyzes and documents this information using additional techniques such as process maps and user scenarios.

Eventually the physician will arrive at a diagnosis of the problem and explain it to the patient and their family. The physician asks the patient about their preferences, provides options for care, and outlines the risks involved with each option. The competent BA will also develop solutions for the situation at hand and provide recommendations to implement a solution. The solution should be based on the needs (requirements) of the stakeholders involved and should outline the risks involved.

A patient may determine that they want to look at alternatives to the options the physician recommends. They may want to try a new or unconventional procedure for any number of reasons. The physician can voice their learned opinion, but ultimately it is up to the patient to endorse an option they believe in. Likewise, any BA will also need to present alternatives to ensure that the project stakeholders are satisfied with the option selected.

The next time you are looking to improve your organization look to your business analysts. Recall the physician-patient relationship as an analogy to explain the important role the BA plays in promoting the health of any organization.

Where and When:
Sheraton Hotel
June 9-10, 2008

Overview:
BusinessAnalystWorld Symposium Series features a keynote speaker, three Symposium conference tracks, formal roundtable discussions, lunch, and a networking reception at the end of the first day.

See if this event is a fit for you: Learn More or Register

Business Analysis services provide insight into business strategy and goals, uncover opportunities and dig into problems. Discovering user requirements, understanding business processes, and achieving consensuses on designs and solutions are all key parts of any solution.

Business Technology Management services are targeted at getting the most out of technology while ensuring new solutions actually solve business problems and are implemented properly! These services go hand-in-hand with VimStreet’s Business Analysis services. Bridging the gap between business and technology is a critical factor to success in getting the most business value from technology.

Training services round out our offering by making sure that organizations have the required skills to be successful and Coaching provides ongoing insight and guidance so training sticks and lessons learned are applied.

Our new Blog will offer a variety of news and information on upcoming events, links to articles, networking events alerts, insight into solving common business process and technology challenges, and much more.

Subscribe to the RSS feed to stay in touch!