Business Analysis According to Sherlock Holmes

(Taken from http://www.batimes.com/steve-blais/business-analysis-according-to-sherlock-holmes.html)

I have been reading and rereading Arthur Conan Doyle’s stories and novels about the brilliant detective Sherlock Holmes for years. With the possible exception of Edgar Allen Poe’s lesser known Auguste Dupin (see The Murders on the Rue Morgue), Holmes stands as the pre-eminent and archetypical critical thinker and detective of all time. Sherlock Holmes provides the model for all the genius eccentric crime solvers who occupy the books, airwaves, and movie theaters of today. Holmes has a lot to say about how to analyze information and evidence and deduce the best solution or the perpetrator of the crime.

Sherlock Holmes is one of the charter members of the Business Analysis Hall of Fame. He has left a vast legacy of advice and counsel to business analysts of all ages. Herewith, direct from 221B Baker Street, are the words of wisdom from Sherlock Holmes.

“Approach the case with an absolutely blank mind, which is always an advantage. That way you formed no theories. You are simply there to observe and to draw inferences from your observations.” (Adventure of the Cardboard Box)

The business analyst needs to be objective. The business analyst cannot have preconceived notions, including those foisted on them by the customer, sponsor, or subject matter expert. When eliciting information the business analyst listens naively and asks questions without prejudice (see the series “How to Ask the Right Questions”, especially part 4: “Asking the Naked Question” for more information about listening naively). When the business analyst comes to an interview with a solution in mind, for example, one proposed to them by the sponsor or another stakeholder with political clout, the business analyst will tend to ask questions and hear the answers that support the solution and ignore or discount any information that may cast doubt on the solution. This is called confirmation bias. Sherlock Holmes cautions us against such behavior if we want to be top notch business analysts.

“It is a capital mistake to theorize before one has data. One begins to twist facts to suit theories, instead of theories to suit facts.” (A Scandal in Bohemia)

This is Holmes’ way of saying “Don’t jump to solutions.” A business analyst should look for more than one solution to a business problem. Once a solution has been established, ask “is there any other way to solve this problem?” In that way we keep ourselves from accepting the first, and not perhaps the best, solution that comes to mind. Looking for that second or third solution also forces us to seek out more information, some of which might invalidate the original solution (that is also a reason for not seeking additional information: it might prove our initial solution wrong, and who wants to be proven wrong?)

“Nothing clears up a case so much as stating it to another person.” (The Silver Blaze)

The Silver Blaze was a race horse and presented a challenging puzzle for Holmes. At one point he asks Watson to listen to him while he “enumerates over the facts of the case.” He knows that verbalizing what is in our heads forces us to focus on what we are saying and how we are saying it. We are trying to get the pictures and concepts in our brains into the brain of someone else and will tend to make those concepts simpler and clearer. And so he does. And so should we. Before conducting an information gathering session, perhaps it is a good idea to ask another business analyst the questions you plan to ask the subject matter expert or another stakeholder. Hearing the questions aloud might cause you to restate a question or two, or not ask them at all. You might also verbally walk through your solution, or your requirements, with another business analyst before committing the solution to a formal document for submission. And if you are creating user stories in an agile environment, reading them aloud is not just a good idea according to Sherlock Holmes, but also from others including the “inventor” of user stories, Ron Jeffries.

“There is nothing more deceptive than an obvious fact.” (The Bascombe Valley Mystery)

There are “facts” that everybody thinks they know. One of the more common is “It’s done this way because it’s always been done this way. It’s the only way to do it.” The business analyst is aware of the ‘fact” that cannot be proven, but must be taken as truth. In The Bascombe Valley Mystery, Holmes is responding to Watson’s claim that the evidence as reported is somewhat condemning to their client. Holmes points out that evidence, especially circumstantial, points in one direction, but with a little shift in your point of view, you may be looking at something completely different. It is similar in business analysis in the pursuit of a solution. The solution that everyone seems to agree to may not be the best solution when all the facts are in, including those facts not in play at the moment. In theory, those thinking the solution is best assume that all the facts are known.

“When you have eliminated the impossible whatever remains, HOWEVER IMPROBABLE, must be the truth.” (A Study in Scarlet)

“It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth.” (The Beryl Coronet)

“We must fall back upon the old axiom that when all other contingencies fail, whatever remains, however improbable, must be the truth.” (The Adventure of the Bruce-Partington Plans)

These similar quotes refer to the method that Sherlock Holmes uses to solve a mystery. He begins to construct theories based on the data that he has in front of him. He is creating alternate solutions to the problem (the problem, of course, is to figure out who committed the crime and how was it committed). He then looks for more data or evidence that will either further confirm or eliminate each theory. Eventually, through a logical process of elimination, Holmes has solved the mystery. As business analysts we can perform a similar process of elimination by starting with the facts, confirming those facts, and then forming potential solutions. Then our investigative job becomes one of gathering information to disprove or eliminate each solution. As solutions are eliminated based on evidence gathered, we can determine the one, best solution. (Note that if all potential solutions are eliminated, we need to go back and re-theorize.) As Holmes says:

“If the fresh facts which come to our knowledge all fit themselves into the scheme, then our hypothesis may gradually become a solution.” (The Adventure of the Wisteria Lodge)

“A further knowledge of facts is necessary before I would venture to give a final and definite opinion.” (The Adventure of the Wisteria Lodge)

In this piece of advice, Holmes is suggesting that we hold off on rendering opinions or conclusions until we have enough information to do so. In many of his adventures he had the solution to the mystery in mind (his predominant theory, for example) and refused to disclose it until he got that last piece of evidence that confirmed the theory beyond doubt. We should be as careful about advancing our solutions until we are sure of them based on the information. (Or to quote someone from a different world altogether: Davy Crockett said, “Be sure you’re right, then go ahead”)

“Education never ends, Watson. It is a series of lessons with the greatest for the last.” (The Adventure of the Red Circle)

As brilliant as Holmes was, he never stopped learning. He admitted when he made a mistake, immediately recognizing what that mistake was. You get the feeling that once admitted he would never make that same mistake again, or perhaps not make even a similar mistake. For example, in “The Adventure of the Stock Broker’s Clerk”, Holmes and Watson enter a room to confront their suspect who is sitting at a table reading a newspaper. Upon seeing them, the suspect races into the next room and attempts to hang himself. Holmes is at first mystified that the fellow would attempt suicide at their appearance. Later when the man is revived, the motive for the suicide becomes apparent. It was something he read in the paper. Holmes then exclaims, “The paper! Of course! Idiot that I was! I thought so much of our visit that the paper never entered my head for an instant.”

Sherlock Holmes had a lot more to say that still resonates across the decades to us, advice that can be applied to our day-to-day work as business analysts and critical thinkers.

If we could all be like Sherlock Holmes, Conan Doyle’s protagonist would never have achieved the publishing success and lasting fame that Holmes has enjoyed for over a century now. We don’t have his remarkable ability to eradicate the emotional, eliminate the irrelevant, and focus with laser-like intensity on the given problem. We don’t have Holmes’ amazing powers of observation. (He could distinguish 75 different perfumes (The Hound of the Baskervilles) showing that he even brought his sense of smell into his observations). However, we can learn to better examine the information we receive with more critical thinking and withhold our judgment longer when evaluating that information. We can learn to restrict our observations more to the evidence that exists rather than what we think exists, or what we have been told.

While we are pursuing the best solution to the business problem and endeavoring to add value to the business through improving processes and solving problems, we might find we are doing a better job of it if we remember and apply the acronym WWSHD: “What would Sherlock Holmes do?”

5 Lessons from working with Agile and Waterfall teams

(Taken from http://www.projecttimes.com/articles/5-lessons-from-working-with-agile-and-waterfall-teams.html)

Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.

I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.

We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.

Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.

I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?

Here is what I’ve learned about Agile and Waterfall approaches:

1. WE NEED MORE COLLABORATION IN EVERY PROJECT.

What happens after your morning SCRUM or status meeting? Does everyone wander back to their cubes and belly up to their keyboards for the rest of the day, and meander into boring meetings?

Collaboration should be an all-day event! The occasional prairie-dog-pop-up to ask your neighbor a question is not enough. That’s not collaboration!

Lightening does not strike at your desk—you need to get up and get moving. Good collaboration is physically and mentally engaging. It’s not sitting at your desk or lounging around a conference room table. It’s a group of active people standing at a whiteboard with lots of dialog and movement. It’s a small group taking a walk and sharing ideas.

What about conference calls? Meaningful collaboration is harder over the phone, but it’s possible. Virtual collaboration does not involve one person reading a document and asking for feedback. It’s a group of people—not multitasking but—adding, moving, deleting from a virtual whiteboard. It’s a lively discussion where everyone contributes.

Even after years of Agile, many organizations still don’t collaborate enough. Too many teams still delegate work to individual desks and then throw it over the cube wall to their sequestered neighbors.

Teams should use collaboration techniques to see the big picture, to fully engage all stakeholders, and to generate more conversation and dialog.

2. AGILE PROJECTS HAVE BA TASKS.

“Agile” roles, like Product Owner and SCRUM Master, are not all encompassing, neither are any of the Agile methodologies. They are not meant to accomplish everything needed to deliver a solution. Traditional BA tasks are still needed in Agile. You may or may not need the title of “BA” to do those tasks, but the tasks remain relevant.

Planning, monitoring, business need definition, communication, elicitation, requirements validation, traceability, etc. still happen in all projects. The factors that change might include timing, duration, emphasis and documentation. Rigor and adaptability might vary as well, but the basic BA tasks apply in all projects.

In an Agile project environment, you might replace the 400-page requirements document or the exhaustive, step-by-step process models with an evolving prototype or a sticky note-filled whiteboard with dry erase arrows. Either way, the fundamental tasks remain the same despite methodology. The BA uses many of the same techniques to get to the differing outputs. They may use the same technique more or less collaboratively. I hope it’s more collaboratively no matter what approach is being used.

3. TECHNIQUES DON’T CHANGE.

Just like BA tasks, BA techniques don’t change based on the project methodology either. You may try new techniques in new ways at different times, but, all in all, good techniques can be used in Agile and waterfall environments.

Traditional methodologies require techniques for requirements elicitation, analysis, prioritization, change management, issue resolution and more. Projects using an agile approach require techniques for the same functions. It’s really just the external stuff that changes—the timing, structure, format and process. Certain Agile methodologies use a specific set of techniques (SCRUM ? User Stories), but they are not all encompassing for requirements activities, they are a minimum to start with, a placeholder for conversation and more collaboration to follow.

We need to elicit requirements from stakeholders for every project. BAs on traditional projects might elicit all requirements at the beginning of the project. BAs on Agile projects might elicit requirements in one small chunk at a time, but the techniques are similar.

4. STOP POLARIZING AGILE AND WATERFALL

Agile and waterfall are not opposites—they are not mutually exclusive. Agile is not meant to be a polarizing force that pushes teams away from Waterfall.

Agile is a mindset born from the Agile Manifesto written by 17 men, probably on a napkin, at a Utah resort in 2001. Have you read it? It’s remarkably simple and packed with common sense:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools

Working software over Comprehensive documentation

Customer collaboration over Contract negotiation

Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

The intention of the Manifesto was not to replace a particular methodology—instead, the authors wanted to bring visibility to what works to build better software by:

Balancing the scales and slide away from the slow, document-heavy, procedural methods of the time
Bringing flexibility and fluidity back into the world of software development
Creating an efficient and effective process that would bring meaning and purpose into every task

Take note: The manifesto offers values, not demands, process, or requirements. They are meant to guide or refine, not constrain. These values can be applied to all projects.

I don’t think the authors of the Agile Manifesto meant to create such polarization in the industry or organizations and their practices.

5. DON’T FREAK OUT YOUR STAKEHOLDERS.

So given the simple foundation of the Agile approach, the transition to Agile does not need to be an historic event full of pomp and circumstance. Yes, Agile looks and feels a bit different than waterfall, but that doesn’t mean you need warn your stakeholders about major changes. Many of the agile principles can be implemented well on Waterfall projects without alarm or need for major change management. It takes relationship skills, facilitation skills, and confidence.

It is important to help all stakeholders understand the agile mindset, but we don’t need to overemphasize differences. Think about it this way: Why and how will it look and feel different? Is Agile driving the differences or is it just a better way of working?

It really doesn’t matter what it’s called, you just need to help stakeholders understand the value and move them forward gently. Any methodology done well will provide stakeholder value. Keep them focused on the output and how the process gets them to the value. As long as you are efficient, organized, effective, you will keep stakeholders engaged.

It may be the comfort of governance and process they are missing the most when transitioning to Agile. Help them through this, but don’t let it get in the way of being more collaborative and value minded working through requirements.

Angela Wick, CBAP, PMP – After more than 15 years of consulting, mentoring and teaching, Angela knows that great BAs transform organizations. Angela encourages BAs to be agents of change. She helps BAs develop the skills they need to inspire collaboration, creativity and innovation. Get free BA tips and trends by following Angela on Twitter @WickAng or by visiting http://www.angelawick.com/

Great Cloud Applications for Business Analysts

Being a consulting Business Analyst, the array of high quality cloud applications (you may know them as Chrome Apps) as provided me with a wealth of invaluable tools to help me deliver quality client solutions. The main benefit for me that cloud-based tools provides is that when I’m working from the client’s location and often on the client’s hardware, there is no need to request permission to install software (including all the justification, form filling and waiting) all I need is a browser (Google Chrome of course) and the Internet.

I am always looking to try out new apps to use for various different requirements such as process mapping, diagramming (visualising analytical output), brainstorming, ideas sharing, remote document collaboration, mind mapping and many more. Below I’d like to share my current favorite collection of BA-focused Cloud Apps for you to try.

If you can suggest others for the list, please email me at simon[at]terranconsultancy.co.uk for consideration.

Mindomo – www.mindomo.com
Mindomo is a brilliant online Mind Mapping tool. Extremely easy to create new maps on-the-fly, great for brainstorming sessions. You can also password protect maps if you need to. Also includes a nicely animated map manager facility.
Price: $65.99 for One Year for the basic subscription upto $291 for the team package

Conceptboard – www.conceptboard.com
Conceptboard provides a powerful visual, collaborative, real-time whiteboard application. Plenty of tools such as comments, highlighting, drawing and live video chat. Also works really well on mobile devices.
Price: Basic free plan is good but upgrade to $9.50 per user/month for unlimited board space

Stormboard – www.stormboard.com
I only found Stromboard recently and by accident. Very different to Conceptboard, it provides a real-time online brainstorming tool in the form of a sticky note whiteboard. Plenty of excellent template forms to get you started.
Price: Free version allows unlimited storms with a maximum of 5 user per storm. Basic paid package begins at $5 per user/month.

LucidChart – www.lucidchart.com
Lucidchart has always been my weapon of choice for process mapping. It allows you to create every thing from Engineering to business process to mobile os prototype diagrams. It does everything you can on Visio, it’s just a little more intelligent and a lot more fun to use.
Price: Good free subscription with paid starting at $39.96 per year for the basic package to $252 per year for 5 users.

Go to Meeting – www.gotomeeting.com
Well known and one of the best online/video/phone conference tools. Nuff said.
Price: $423 per year

Smartsheet – www.smartsheet.com
The title pretty much says it all. An easy to use Project Management tool with excellent collaborative facilities. Also includes a mobile app.
Price: Basic price is $168 per year with gives you unlimited collaborators

Trello – www.trello.com
Anyone who uses Lean will be familiar with Kanban boards. A simply yet effective visual task management tool. Trello is by far the best online Kanban board. It includes plenty of great examples how it can be used to organise your life too. I can’t say enought good things about Trello………oh yes I can, there’s a brilliant mobile app too.
Price: The free version pretty much has everyting but if you want a little extra, Trello Gold will cost you $45 per year.

Prezi – www.prezi.com
Are far as I know, Prezi was one of the first, and still one of the best, online ‘powerpoint alternative’ presentation tools around. Once you’ve created a presentation with the easy to use interface, traditional slides will just never seem the same again.
Price: $120 per year but there is a free version if you need the basics.
Honorable Mentions

Presenter Media – www.presentermedia.com

Superb collection of presentation templates, animations and illustrations for you to jazz up your presentations or documents and impress the boss.
Price: $49.99 for One Year

The 12 Agile Principles Explained

(Taken from https://www.scrumalliance.org/community/articles/2013/november/the-agile-manifesto-principles-what-do-they-mean)

The 12 Agile principles that, when followed properly, lead to better outcomes and better software. This article discusses these principles.

Of course, the devil is in the details, and understanding principles that may seem contradictory, in some cases, doesn’t always make them easy to implement. My goal with this article is to shed some light on these principles and provide tangible advice that will help teams deliver better software.

These 12 principles can be divided into three broad categories. We will discuss these categories next and include the associated Agile principles.

Regular delivery of software

Many of the older processes measure progress with detailed plans and Gantt charts. Software that is the true deliverable is one of the last things to be delivered to the customer. In contrast, Agile principles focus on the software, which is the most important thing, being delivered early and often.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Teams work together better when they trust each other. It is common for tension to exist between the customer and the delivery team. When the customer is satisfied by constant delivery of valuable software early rather than later, trust is built.

The term valuable is important. In Scrum, the customer or product owner decides what is valuable. The product backlog is prioritized and the most valuable features are delivered first.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
It is important to deliver software frequently. Scrum is built around this principle. Under Scrum, features are delivered in sprints of two to four weeks, with a preference toward two weeks.

Working software is the primary measure of progress.
Software not only must be valuable and delivered often, it must be working or done. Scrum requires the features to meet a team-defined Definition of Done. Ideally, this should mean that the feature is potentially shippable.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
As teams build trust and build and deliver software over and over, a constant pace that is sustainable without overtaxing anyone will emerge. This allows the team to work forever — or until enough value has been added to the product.

An important aspect of this is regular releases of a product. If a team can deliver a shippable product each quarter, for example, it makes conversations with the customer much easier. The team learns that they ship every 12 weeks. When a feature request doesn’t fit into the current release, it is only a short wait till the next one.

Team communication

It is common knowledge that teams need to communicate in order to be successful. Simply saying, “We need to communicate better” is a bit like saying, “To be successful at the stock market, we need to buy low and sell high.”

These principles provide some insight into how to communicate.

Business people and developers must work together daily throughout the project.
The whole team needs to be readily available to each other. Scrum uses the daily stand-up meeting as a critical communication mechanism. Here the team reports what was accomplished since the last meeting, what will be accomplished by the next meeting, and whether there are any impediments to completing the features in the sprint.

This meeting exposes issues early so they can be addressed before they become critical.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This principle was authored before geographically separate teams were common. Today, with offshore teams and teams that are divided across the country and the globe, regular face-to-face communication is often not possible.

On-line meetings and instant messaging tools are available that improve communication when teams are separated.

Meetings that include the whole team may be planned so that face-to-face communication is possible. This does add cost to the project, because portions of the team need to travel to a central location for the meeting. This approach is helpful for important meetings like sprint and release planning.

When offshore resources are used, portions of the offshore team may be rotated to the U.S. for a period of time. This allows team members to interact personally and get to know each other. It allows the offshore team to return home with firsthand experience that helps the remote team gain valuable insight. This is often a win-win situation, because offshore team members look forward to an experience in the U.S.

When possible, separate out teams so the individual teams are co-located. For example, it is better to have one whole team in the U.S. and another in India than it is to have the teams split. This allows the individual teams to benefit from face-to-face communication.

It is best to have face-to-face communication, and techniques like this should be used to get as close to this goal as possible. Separated teams do pose a challenge, and a cost, but on large projects, the incremental cost addition is often worth the expense.

The best architectures, requirements, and designs emerge from self-organizing teams.
The team knows the best way to get something done. They are the experts. However, this does not mean the right outcome will happen on its own.

Each individual is at a different place in his or her personal growth and career. The term “servant leader” has emerged in the Agile community and replaced the typical command-and-control project manager.

A servant leader observes how the members of the team operate and interact with each other. He or she asks probing questions and acts as a “flashlight,” shining light on areas that individual team members may not notice. It is critical for the servant leader to treat everyone with respect and dignity, even when tensions are high. Conflict among team members is normal and actually a good thing. A servant leader understands this and embraces healthy debate.

Self-organizing teams do not happen automatically. They emerge under the proper guidance and advice of a servant leader.

Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
This is an extension of self-organizing teams. There are some important words in this principle.

No one would ever admit to not being motivated. The servant leader pays attention to the aspirations and goals of the team members and aligns these goals with project needs wherever possible. People perform best when they are doing something they are passionate about.

A good servant leader also shelters the team from outside distractions. In Scrum, a team commits to completing a set of features. Anything that distracts from this is a risk. By being there for the team, the servant leader provides them with the environment and support needed for success.

Trust is not automatic but is built over time — and is easy to lose. The team members must trust each other and be comfortable with conflict. Here are some tips to building trust in a team:

Do what you say. No matter how small the task, if you tell someone you will do something, do it.
Admit when you are wrong. Everyone makes mistakes. When you make a mistake, admit to it and make it right.
Follow up. Follow up on open issues that take some time. This allows people to see that you have not forgotten them.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum uses the retrospective for this purpose. Teams often need help for this activity to be effective.

People may be challenged when it comes to engaging in true self-reflection. This is all part of the Agile journey. Each of the Agile principles are interrelated. The retrospective is the perfect place for the team to reflect and improve. It is up to the ScrumMaster to elicit self-reflection.

Once we have identified areas for improvement, we need to really improve. If teams spend time reflecting and do not improve, they see the retrospection as a waste of time.

It is again up to the ScrumMaster to tactfully remind the team about areas of improvement they agreed to. Some teams hang the points they agreed to up on the wall where the stand-up meetings take place.

Design excellence

If we hope to maximize an Agile approach, we need to design and build excellent software solutions. These principles emphasize these points and allow us to accommodate change. Design excellence is not a once-and-done thing. Like most of Agile, it is a journey that requires vigilance and attention to changing events.

Continuous attention to technical excellence and good design enhances agility.
We need to pay close attention to technical excellence and design as our product evolves. There is a balance between “Building the right thing” and “Building the thing right.”

We must also be wary of delivering fragile systems. If we make a few changes and our application falls apart like a house of cards, we are not in a good place.

Extreme Programming and, to some degree, Scrum recommend test-driven development and automated builds as a way to avoid fragile solutions.

When we have a set of proper automated unit tests that are included in some sort of automated build, we see problems every time the build runs. The higher our code coverage is and the closer we get to continuous integration, the better our solution will be. It is all about balance.

Over time, our solution will accumulate technical debt. As we weigh the trade-offs between “building it right” and “building the right thing,” this is bound to happen. It is best to include a few technical-debt features along with features that add value in sprints so each sprint is delivering business value.

Simplicity — the art of maximizing the amount of work not done — is essential.
Agile is all about doing the right amount of something at any given time, and no more. We should author user stories small enough to get the job done and no more. We should build what we know we need now. We should not build some huge framework we think we may need someday.

It is critical to have a complete and thorough understanding of the software frameworks we use. Code is evil, and we can eliminate quite a bit if we have a good understanding of our chosen frameworks.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This principle will scare teams who are used to Waterfall projects. At first glance, it seems crazy to welcome change late in the development process.

First, we must be successful at implementing the first two principles in this section. If this is not happening, welcoming change is impossible.

“Late in development” means late in the release of the complete product. Scrum delivers features in short sprints. We do not welcome changes in an in-process sprint. Because we are delivering features in short cycles, change is part of the whole process.

In Scrum, the change is directed by the product owner. It is up to the product owner to understand what the competitive advantage is for each feature in the backlog. – See more at: https://www.scrumalliance.org/community/articles/2013/november/the-agile-manifesto-principles-what-do-they-mean#sthash.CsusROl1.dpuf

Transitioning to Agile

(Taken from https://www.scrumalliance.org/community/articles/2013/march/transitioning-to-agile)

I recently completed a long assignment implementing Scrum and decided that, in the spirit of continuous development and learning, it would be useful to run a personal retrospective while between jobs.

This paper articulates some of my key findings and probably confirms what many Agile practitioners already suspect. I have suggested some techniques and ideas that may be effective in managing future transitions to Agile. I assume the audience for this article is already familiar with Agile methodologies, so I’m not going to repeat them.

On the surface it would appear quite easy to transition an organization to Agile, but you shouldn’t underestimate the strength of resistance you may encounter. Not many people have worked in a truly Agile environment, so there may be a fear of the unknown or “how it’s done,” and a compulsion to stick with what they know — i.e., Waterfall.

On the whole I found that the developer community seemed to be more outward looking and receptive to change. Most bear the scars of previous projects and are willing to give Agile a go.

People working in supporting functions or the broader business can have strong beliefs about “the way we do things around here.” Even when there’s clear evidence that their assumptions are incorrect, they will still make any number of excuses to justify them. If you’re only measured against your last project, there’s terrific pressure to claim success, even if the project delivered very little value.

I came across some organizations that claimed they had tried using Agile but it didn’t work for them. When taken to task, it was clear they had made no real effort to transition to Agile, preferring instead to maintain the status quo. Their project managers kept running projects but called them Agile projects. They retained their business analysts and technical architects, so the results should hardly surprise any of us.

It’s easy to drown in detail, so now I have attempted to step back from the situation and apply a more systemic approach to the problem. Therefore some of the activities I propose here may seem counterintuitive. For more information about advanced problem solving, please refer to Stafford Beer’s Viable Systems Model (VSM) and Peter Checkland’s Soft Systems Methodology (SSM).

Here are some of the issues I encountered. I’m sure you’re also familiar with many of them:

Wanted: Agile project manager. Spot the warning signs early on. An organization looking for Agile project managers is probably running projects and may have heard that Agile is the way to “do more for less” — i.e., save money. The role here will need clarification. Why does the organization want to transition to Agile? Is it to save money, do more for less cost, or do they want to keep running projects and create the illusion of Agile?
The governance excuse. We can’t govern Agile projects like Waterfall projects, where there are the gates and decision points. How can we control the budget, where is the stakeholder engagement and accountability?
Lack of leadership support. Without buy-in and support from the top, you’re unlikely to succeed. Also watch out for middle managers pursuing their own agendas.
Scrum as a process or method, not a guiding principle.
People don’t always understand the principles underlying Agile methods. Scrum is a simple process based on these principles. The trouble starts when people start adapting Scrum methods without understanding the principles (like tinkering with your car engine without understanding how it works), which is why you end up with things like Water-Scrum-Fall.
Project managers’ beliefs. Watch out for project managers who believe it’s a well-known fact that rigid adherence to a recognized project management method is the only way to deliver effective change, and if it’s not working you need to do more “project stuff” (strengthen your change-control procedures and adhere to stricter governance).
Agile is just another fad or new methodology. People believe they just have to ride it out until it goes away.
The focus is on delivering projects instead of products and services. Is the focus of the organization on delivery, or have your projects become bigger and more important than the products they deliver?
People don’t know what Agile looks like. Can you share a vision of what a good Agile organization looks like? If somebody had never seen a sunrise, how would you describe it to them; what if you had never seen a sunrise either?
External suppliers and offshore workers. These are usually based on fixed requirements and deliverables. Collaboration through contract negotiation and intermediaries isn’t going deliver value in an Agile environment. Another approach is required to make these relationships work.
A lack of trust or communication between the business and development communities. Agile principles are based on building a culture of trust and respect between both parties.
Partial adoption, or Water-Scrum-Fall. The best you will achieve is mini-Waterfall; at worst you get suboptimal Waterfall.
The use of estimates instead of story points. This is a subset of partial adoption. It places the focus on what things cost and not on what generates the most value.
A big-bang culture. Storing up inventory and delivering it in a splurge of disruptive chaos gets noticed more than incremental change.
Isn’t the ScrumMaster just a project manager? Some organizations send their project managers to a Scrum course, expecting that to sort things out.
The illusion of progress. Some organizations run lots of projects (even though they have insufficient resources), so people have to participate in multiple teams. They create lots of progress reports to paper over the cracks in the hope that nobody notices the true state of the project until it’s too late.
There is no “I” in “team.” Some project teams are set up and disbanded so swiftly they never ever get past the storming phase.

Change and transition management

There’s lots of information on organization structures and change. It was the focus of my MBA and it can end up being a lot more complex than many people imagine. That said, there are some tricks to herding these cats.

The move to Agile is very simple, but at the same time extremely difficult. Implementing Agile processes is the simple bit; stopping the doing and thinking in projects in order to deliver your products is the hard bit. It’s hard because projects are probably embedded in your organizational culture, and to stop doing them challenges the values and beliefs of nearly everyone.

Every organization is different, and so their journeys to Agile will differ. I help people try to understand these five things:

What the organization looks like. Is the organization large or small? Dynamic or inflexible? Focused on cost or value?
Where the organization is on its journey to Agile. Just starting out? Some progress but now stalled or backsliding? Running Water-Scrum-Fall projects?
The organization’s ability to manage effective change. Is change embraced? Do people understand transition management? Are people more adept at resisting change than implementing it?
The organizational structure. Function follows form. Does the form support its customers?
Is the change to Agile being made within a subset of the organization? Meaningful change is likely to involve the broader business, not just a department or IS.

It’s best to perform this analysis early on, while you can still smell the culture. Live too long beside a sewage farm and you won’t smell a thing, and eventually you have to rely on indirect evidence. Why don’t our friends visit us anymore?

Don’t be surprised if simply employing a ScrumMaster doesn’t deliver you Scrum. If you want to transition to Agile or Scrum, look for an Agile practitioner or a ScrumMaster with change-management skills. Don’t assume a ScrumMaster can achieve the transition for you!

Sharing the vision

The transition to Agile is likely to require significant organizational change. Analysts may find themselves working for the business and becoming product owners. You may have to reduce your project management headcount. Not all change can be managed in a soft, comfy way, and sometimes a leap of faith is required. The change manager is there to support and coach the organization at all levels. Sometimes there’s good news and sometimes it’s less good; either way, it’s important that everyone is involved and understands the need for change and how it’s going to be achieved.

Not everyone has worked in an Agile environment. Big or small, it’s important to include them in the journey. My favorite technique for creating a common understanding is through the use of a simple metaphor. I like to compare the Agile development team in an organization to a car production line.

In most circumstances it’s probably best to run a project to build the new product (although this wouldn’t be the case for a high-performing Agile team). Being pragmatic, something of this size probably needs funding and governance to get it moving in a large organization.

The question is, would you build a new production line and then tear it down every time you wanted to produce a new model? That’s what you’re doing when you run discrete development projects or Water-Scrum-Fall. Delivering Waterfall projects breaks one of the fundamental principles of Agile, by disbanding your team as soon as they have started to perform. In some cases the team never make it out of the forming stage, which is highly inefficient.

You wouldn’t project-manage a production line, so why try to project-manage an Agile delivery system? Once the production line and product is up and running, using Agile or Scrum is the most effective way to maintain and improve the production line (Scrum team) and the product. Organizations running successful Agile don’t run many projects (some run none), because their focus is on the product and delivering value.

Agile organizational structures

Part of sharing the vision is discussing what your organization looks like and how it needs to be structured. Function follows form, and this may need to change during the transition to Agile.

Waterfall or Water-Scrum-Fall: The focus of the organization is on running projects. A functional structure relies on matrix management to build project teams. People’s focus is on their function or profession.
Transitioning: The focus of the organization is on delivering products through projects. It uses an Agile team structure, matrix managed by projects. People’s focus is on the project and product.
Agile: The focus of the organization is on delivering products and solutions. The organization is based on Agile teams. People’s focus is on delivery to the customer.

Returning to the metaphor, the transitioning organization may have set up some production lines with projects running in parallel. The projects book capacity on the production line through a product-management function. The challenge for program management is to schedule the requirements across the production lines (this could be run like a Kanban system), keeping the teams fed at a steady rate (velocity). Any capacity gaps can be filled by the team with small change and maintenance (refactoring) tasks.

Why do organizations run projects?

Don’t ignore projects. One of the first things I encountered at Agile forums was an attempt to ignore or treat project management as though it didn’t exist. Living in an Agile world is as bad as living in project world!

I would argue that projects still have their place in the new order; creating the product in the first place is probably best run as a project. Once you’ve delivered the basic product, the most efficient way to change and improve the product is through Agile.

If you’re transitioning to Agile, you need to take a hard look at the projects you run. Look at your proposed or in-flight projects and ask the following questions:

Is this just a change to an existing product? Why run a project to implement a small change or improvement?
Is this a big project? Is it really big, or has someone just bundled a load of stuff together to justify a business case, or made it big because small projects don’t scale in a way necessary to support your big-bang culture? If it’s just a lot of small stuff, why not challenge your Agile teams to break it down, remove the dependencies, and deliver it piecemeal. If they can’t, you may have yourself a project.
Will your customers accept iterative deliveries? Have a conversation with your customers and ask them whether the whole thing must be completed before they will accept the product. If not, push back and challenge them to answer why this is so.
Will it deliver huge value? If you run a project, it’s going to be high ceremony and incur significant overheads. Also you won’t realize any benefit until the delivery. Make sure that’s part of the business case. If the business case doesn’t stand up, stop the project.
Is the project delivering something that’s required now, as opposed to something the customer actually wants when the project delivers it? How dynamic is your business environment? By the time you have your website delivered, will it be obsolete because your market and customers will have migrated to mobile devices?
Is there little or no risk of change? Change is the enemy of the project and needs to be avoided. Managing change is built into and part of the Agile process.
Does it need “project managing”? Once a project is delivered, project managers tend to hang around like a bad smell, convincing you that the only way to make change is through running another project. Keep checking: Do you really need to run a project to deliver the next change?
Do you have a fixed budget? if so, Agile is probably the best approach, as you can stop when funds are exhausted.
How do people know what’s going on? Are managers content with reading project reports and reviewing risks and issues, or do they prefer to get out and see the progress for themselves (i.e., the Gemba)?

It takes time and effort to establish a project, but if you’ve just started to implement Scrum, I think it’s best to stick with in-flight projects and accept them as a lost cause. As soon as the project team has delivered its product, you should be ready to establish your Scrum teams and take ownership of the product, run Scrum, and give control back to the product owner. The first few sprints may be needed to make the product maintainable and fit for the purpose, but after that the team can start to deliver some value to the product owner.

Implementing the change

I believe that everyone needs to experience the feelings of motivation and self-worth that being part of a high-performing team provides. It fosters respect, provides support, and really delivers. Scrum works because it recognizes that high-performing teams (not just a loose collection of individuals in a functional department) actually work. Self-organizing teams fulfill an intrinsic urge to belong and be much more than the sum of their parts. That alone is a good enough reason to transition to Agile.

To support the transition to Agile, ScrumMasters need to be more than simple servant leaders and facilitators. They have to be ambassadors of change. There is a lot of soft stuff surrounding change management, which really isn’t an adequate approach to making the transition to Agile successful. In order to be successful, you have to convince people that it’s safe to let go and take a leap of faith. It takes leadership and drive and it’s not easy — but if it were easy, wouldn’t we all be doing it already?

Change managers recognize that what you stop doing is as important as what you start doing. If you stop thinking in projects, it becomes easier to focus on products, value, and delivery.

Think about your organizational structure. Can you build and maintain a production line (or production lines) and support them so they can focus on delivery of your products? Set out and agree on some clear transition activities with measurable outcomes, then follow up on them. Alternatively, use Scrum to implement the change, listing each of your transitions as user stories and use sprints to deliver them. That’s a great way to teach Scrum to the broader business.

Whatever your approach, it’s important to keep up the pressure. If business managers want you to stop the transition, tell them to do what they agreed to. If you settle into a comfy compromise, you only have yourself to blame.

Findings

It’s nice to be part of a successful transition, but you may learn more from failing to implement Agile.
If you only take away one thing from Agile, it should be the necessity to reflect and learn. Good or bad, reflect on how it went, learn from the experience, and remember: “The person who never made a mistake never made anything.”
If you only have project managers, the solution to every problem is probably a project!
Are you content with generating status reports, managing risks and issues, and chairing meetings with angry stakeholders? Why not have a look at real governance, like Gemba — that is, get out there and find out what’s really going on!
If you can’t stop projects completely, try to be prescriptive over the entry criteria. Make sure they scale and can’t be done more efficiently by your Scrum team.

The move to Agile is very simple: Start doing Agile. It’s also extremely hard: Stop doing projects.