Tag: Best Practices

Deep Dive Models in Agile Series: Decision Models, Edition 6

Written by Candase Hokanson on December 15, 2016. Posted in Articles. 1 Comment on Deep Dive Models in Agile Series: Decision Models, Edition 6

This short paper series, “Deep Dive Models in Agile,” provides valuable information for the Product Owner community to use additional good practices in their projects.

In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.

This is the last paper in this current series and covers Decision Models, which include both Decision Trees and Decision Tables. Previous articles in this series included Process Flows, Feature Trees, Business Objectives Models, Business Data Diagrams and State Models.

What is a Decision Model?

Decision Models include two RML System models (Decision Trees and Decision Tables) that detail the system logic that either controls user functions or decides what actions a system will take in various circumstances.

Like the State Models, these two models are covered together in this paper because they show the same information in different formats. Oftentimes a PO or BA will use only one or the other of the two Decision Models based on circumstances. Decision Tables are used when the PO or BA wants to ensure that every permutation of applicable decision choices has been explored. Whereas, Decision Trees are more consumable for business stakeholders and are typically used to show a collapsed view of a Decision Tree by only modeling the decision choices that lead to an outcome. Decision Models are great for any project with logic that the system needs to enforce and even as the acceptance criteria for the user stories in some cases!

The Decision Table is the tabular format of decisions and their outcomes with each column in the Decision Table representing one potential permutation of decisions in the system. The Decision Table contains three main areas: the conditions (or decisions), the outcomes, and the columns where each permutation of each decision choice is listed with the appropriate outcomes marked. This model is read vertically (see example below) in that the user will take one column and read down: “If Condition 1 is choice 1a, condition 2 is choice 2a and condition 3 is choice 3a, then outcomes 2, 3 and 4 occur. The vertical columns each represent a business rule for the system.

A Decision Tree, like the State Diagram, is a more visual way to show the decision logic in a branching tree format by only showing the decisions and choices combinations that lead to an outcome in the system. This model is great for verifying branches of system logic with business stakeholders. See the example of a decision tree below:

When would I use a Decision Model on an agile project?

There are two main use cases for Decision Models on agile projects. One is to detail specific pieces of system logic for a user story. In this case, the Decision Model is identified and created for the user story it supports about 1-2 sprints ahead of the sprint the decision logic will be implemented in. The PO or BA would identify that a user story requires the system to execute decision logic to come up with a response for the user. This can be identified by the PO or BA during elicitation if she hears words like “If the user does X, then the system does Y, etc.” From there, the PO or BA would elicit all the possible decisions that occur in the system and walk systematically through each combination of decision choices in a Decision Table to ensure that all outcomes are accounted for. Optionally, a Decision Tree can be created to ask questions of business stakeholders and complete the system logic.

The alternative use for using Decision Models on an agile project is to identify and represent the acceptance criteria. Acceptance criteria are often written in the Given-When-Then format. “Given a certain precondition in the system, when some trigger occurs, then the system will take some action or display some response.” This aligns very well to a Decision Table as the preconditions and triggers can be modeled as decisions or conditions, and the outcomes are still outcomes in the Decision Table. One caution here is that if written acceptance criteria already exist in the Given-When-Then format, the PO or BA usually does not need to create a Decision Table to model the acceptance criteria. This technique would only be used on larger stories where the precondition list or trigger list is longer (3-5), and thus the number of combinations of preconditions and triggers is higher. In this way, the PO or BA can be sure that every path in the acceptance criteria has been explored to find any needed system response.

How do I create a Decision Model?

The first step in creating a Decision Model is for the PO or BA to identify all the decisions being made by the system for a particular outcome. This can be a list in the Decision Table or decision diamonds in the Decision Tree. Typically, a PO or BA will start with a Decision Table and move to a Decision Tree as needed.

After brainstorming the decisions in the system, the PO or BA has to identify all the applicable choices for each decision. Decisions can be binary (Y/N) or non-binary. If the decision is non-binary, the PO or BA needs to check that the decision choices are Mutually Exclusive and Collectively Exhaustive (MECE). This means that all choices are accounted for and that there is no ambiguity in choices (if a number is a non-integer, choices like 1, 2-5 and >5 would not meet MECE and instead, the PO or BA would need something like: <1, >=1 to <5, >=5). For this reason, a lot of POs/BAs prefer to use binary decisions, but it can complicate a table or tree.

Finally, the PO or BA walks through each combination of decision choices and identifies the appropriate system outcome for that combination of decisions. See the example Decision Table below:

In this case, if the listener chooses not to select artists, then the system cancels station creation and doesn’t care about the number of artists chosen. In Decision Tables, this case, where the choice of the decision or condition doesn’t matter, can be shown as a “-.“ Additionally, Decision Tables can show ordered outcomes by using numbers in the outcomes (i.e. 1 and 2). For example, in an e-commerce site, when a customer wants to use a gift card to pay for something, the system may first (1) deplete all funds on the gift card and then (2) ask for a second payment method if the gift card did not cover the full cost of the order.

Decision Trees show this same information in a branching tree format using the same elements as the Process Flow: steps and decision diamonds, except the steps are now steps the system takes in the form of outcomes. As mentioned above, Decision Trees are usually created after Decision Table to verify the decision logic with business stakeholders. However, if the PO or BA decides to start with the Decision Tree, the process for creation is essentially the same: 1- brainstorm the decisions, 2- identify the choices and 3- walk through the decision/choice combinations to arrive at outcomes. See the example below:

How do I derive user stories out of a Decision Model?

Decision Models usually supplement user stories to ensure that all paths are identified, so they usually lead to additional acceptance criteria. Each Decision Model created will usually be for a single user story, and each permutation of decisions and choices is one acceptance criteria. For example, if we had a story of:

With acceptance criteria of:

The PO or BA might see the need to create the Decision Models above to ensure that all acceptance criteria are accounted for, which would identify the following acceptance criteria:

These models are great for identifying missing acceptance criteria (and thus test cases) that might trip up an agile team and cause a story to “Fail” a sprint by not considering exception cases in the acceptance criteria.

Conclusion

Decision Models are great models for POs or BAs to use when they are unsure they have properly captured the acceptance criteria for a story. These models allow the PO or BA and business stakeholders to be aligned on the system logic and expected system behavior before a story is taken into a sprint which allows the PO or BA to give better information to the agile team.

This concludes the Deep Dive Models in Agile series. Over the course of six short papers, we have covered: Process Flows, Feature Trees, Business Objectives Models, Business Data Diagram, State Models and Decision Models. Which visual models do you use most on your agile projects?

Strategy Spotlight: 4 Communication Skill Components that a Professional Should Master

Written by Richard Lannon on December 8, 2016. Posted in Articles.

I was asked by a participant at a PM/BA World Event hosted by Diversified Communications and the local IIBA Chapter what I felt were the some key areas to study as a new business analyst.

I paused for a moment and said facilitation, documentation, integration and presentation is a good place as any to start. As I reflected on my comment I wondered why those four items came top of mind during a keynote presentation question and answer period. I realized that for years I have been preaching the importance of these skills and capabilities in my three day Business Analysis, Gathering and Documenting Requirements program where communications is the key.

But, what is communications. Well it is more than the words you use. Good or effective communications combines a skill set that includes verbal and non-verbal capabilities and as a professional, it is imperative that you become a communication master. Now, what does that have to do with facilitation, documentation and integration?

Facilitation: To be a facilitator you have to master people and group dynamics on a variety of levels. Often this means attending training, getting coaching and mentoring and practicing a variety of skill sets all aimed at developing your verbal and non-verbal communication skills. There are skill sets that include your ability to:

profile people and adjust your behaviors to their needs not yours,
actively listen where you focus fully on the speaker from their body language, tone of voice and non-verbal cues,
be an improvisational expert and adjust when needed and as required (sometimes entertain),
run meetings from the one on one interviews, small group discussions to the larger workshops,
know where it is you are starting (problem) and where you need to go (the outcome) and set the course and tone to get there and lots more.

Documentation: This is one of the areas I think is often misunderstood. By definition, documentation is material that provides official evidence and serves as a record. Generally this is not the fun stuff for a lot of people. Documentation is part of communications. From the written text to the depicted requirements using diagrams, it tells a story and brings the audience on a journey from problem to solution.

Documentation that relates to facilitation on a number of levels as it is that skill set that requires you to know how to develop surveys and questionnaires, to create interview questions like a journalists, and to capture that information as factual, authentic as possible to communicate to your respective stakeholders, your audience.

Whether you are writing a proposal, a charter, building a requirements plan, creating a summary of findings, doing a financial analysis or writing a full business case. Documentation is a communication’s vehicle as it about your ability to write and communicate with words on paper, a computer screen or some other medium.

Integration: Bringing it all together is what it is all about and this is called integration. I think this is the hardest part of any professiona’ls work as it is a lot of work. Often called the heavy lifting, you could spend twenty hours communicating with people to capture information and another sixty hours or more putting it all together.

Information integration similar to documentation requires you to know your audience and the key deliverables. You could be writing a summary of findings with no analysis for your peers or maybe the executive team. Maybe you are developing a presentation deck for the executive and you have to determine what information must be made available. You could also be required to create a requirements attribute table or a program roadmap where you need to determine the sequence and wording of requirements for the strategic, tactical or operational. There is also the possibility that you have to integrate the material as business, stakeholder, solution and transformational requirements. The list of possibilities is endless. So studying and building your information integration skills for communications is extremely important. It is not just about you.

Presentations: In today’s world I just can’t see how you can survive as a professional without developing your presentation skills. This skill is about your ability to effectively deliver engaging presentations to a variety of audiences. You need to learn how to structure presentations, design slides, set the tone of the presentation with your voice and body language. It all counts.

To develop this skill consider taking training on thinking on your feet, acting and improvisation, joining a club that teaches you and helps you practice presentation skills, learn the difference between being a speaker, trainer and facilitator. There are differences in the skill set that you apply given the audience.

As a professional developing your confidence in front of an audience is important, learn not to lecture but to engage, develop your ability to profile your audience, find ways to keep things short and simple with repetitive markers, and anticipate questions.

Final Thought

One of my favorite programs to speak and train on is Gathering and Documenting Requirements because it applies a practical and realistic skill set in communications, facilitation, documentation, integration and presentation that the professional needs to develop for their career success. This skill set can and will be applied throughout your career and life, whether you are working with your peers and other stakeholders solving a problem, researching a vacation, buying a house or hanging out with your friends engaging in conversation around living everyday and succeeding in all that you do or want to do. Yes, I guess you can say these are four skills will make you a communication expect if developed well.

You’ve Set the Goal – Now What’s Your Plan?

Written by Clinton Ages on November 29, 2016. Posted in Articles. 1 Comment on You’ve Set the Goal – Now What’s Your Plan?

We are continuing to walk on our proven path that consists of the magical seven steps towards success and achievement in life and – known as the Coach Clinton 7-Steps to Accomplishment Methodology.

We have discussed the first two steps at length which are appraise and ascertain , and now we are on the third stage which is called the ‘Approach’ step. By reaching here, we are past the mind mapping phase and things are going to get more action-oriented and practical from here onwards. So this is the time to strengthen your commitments and actually take some practical steps to start the realization of your dreams because without targeted action, all that remains is mere talk and nothing practical.

Here is a recap for you in order to help you connect the third step with the first two and understand the process more clearly.

In the first step, appraise, we talked about doing a comprehensive self-evaluation so that you can separate the positive patterns from the ones which are hindering your performance.
In the second step, ascertain, we had a detailed look at everything related to devising your goals so that these goals are based on some solid foundations instead of personal whims.

If you have worked on these two steps, you must have in your hand:

A detailed picture of your strengths and weaknesses along with a plan to further improve yourself by leveraging the pluses and eliminating the shortcomings
A full-fledged document containing your short, medium and long term goals stacked in separate categories for further action

With this information handy, you have all the prerequisites that you need to start the first step –one that will guide your actions leading to achievement of your long term goals. During this process, the information from your self-assessment and your list of goals will be used as input for directing your activities.

Developing Your Action Plan

You cannot accomplish even the smallest of goals without making its action plan and listing down the real actions that you will have to undertake. Now that you have all your goals in front of you, it’s time to take each goal and support that goal by attaching an action plan with each one.

Here are the time-tested recommendations that will help you develop your action plan in order to direct your efforts towards completion and continuous success:

Categorization – First of all, you need to take each goal and study it thoroughly before labeling it in one of the categories that you have already listed down. The categories may include personal goals, professional goals and the like.
Prioritization – Within each category, you will now make a priority list by ranking your goals according to their importance. The ranking will be done based on the importance whereas the level of importance will be the outcome of your personal desire to do something and your intended achievement from fulfilling that desire. After ranking the long term goals, you will move to rank the short term goals under each major goal in order of level of contribution in fulfillment of the parent goal.
It is of great importance to set the deadline for every one of your goals according to their rank – otherwise these goals will be very less likely to see light of the day.
Monthly Planning – When you are clear about your goals and their priority, it becomes easy to map them on a given timeframe and then pursue them according to the time limits. On the same lines, you need to create a monthly planner and chalk out your goals on that planner. Doing this will help you stay on track by giving you a visual of your to-do list so that you stay reminded of the pressing tasks that need to be completed before its deadline.
Task Division – Now take your top most important goal and make a list of all the individual activities that will have to complete in order to achieve this goal. While doing this, think the goal through and make sure that you list down all the activities without missing anything. These measurable activities – instead of a large goal – will be the ones that will bring you closer to your goal.
Weekly Planning – Once you have listed all the subsequent tasks that will help you materialize a goal, the next logical thing to do is to arrange them in their natural order of completion. By doing this, you will have a sequential to-do list which simply requires you to complete each task in this order without having to waste your energy cutting through a clutter. Just like you made a monthly plan, these sub-tasks will be planned on a weekly timeframe and at the end of every week, you should ideally be able to tick off all the week’s assigned tasks.
Weekly Review – While working on a weekly schedule, it is always helpful to identify milestones for each task and stop during the week to gauge your progress. Pat yourself on the back if you are on the right track but in case you are not, re-plan your remaining week wisely and take quick action to make sure that this week’s targets are met positively. To make more room for these tasks, audit your plans for the running week and push down anything that is not serving your goal achievement.
Resource Planning – After all your planning related to the tasks, their importance and their right order is done, the next step is to analyze your plan with a resource perspective. I recommend you to sit down and list all the resources that you will need to materialize your goals. The resources can fall into broad categories like People, Technical, Knowledge, and Information resources. Once you have a list of what you need, now plan the acquisition of that resources in terms of the possible source(s) to get hold of a particular resource as well as the time required to obtain it. This important step will ensure that you don’t waste time in the middle of the journey in arranging for resources.
Action! – Now that you have planned each and every detail of your mission, it’s time to get running and start completing your weekly tasks so that your monthly targets are met. This way, you will see yourself start to check off your short term goals from the goals’ list leading to achievement of your bigger goals.

So today, we dived into the details of planning your goals in the most effective manner and if you have followed this discussion, you can already see your life’s ambitions being materialized – one after the other.

While it’s good to take some well-deserved rest after a big breakthrough, I cannot overemphasize the importance of building and maintaining your momentum because if you relax during this process, it will take you much more energy to get this momentum back – significantly increasing your chances of failure.

So now that you are starting your action plan, here are a few motivating words from one of the most accomplished personalities:

“Action is the foundational key to all success”
– Pablo Picasso

Stay tuned for the upcoming discussions that are geared to help you keep pushing forward on this track of success and achievement.

5 High-Impact Questions Every BA Should Be Using!

Written by Angela Wick on November 14, 2016. Posted in Articles. 1 Comment on 5 High-Impact Questions Every BA Should Be Using!

Success or failure often hinges on the questions we ask throughout the project lifecycle.

It sounds a bit dramatic, but I’ve witnessed it many times—a single, thought-provoking question that changed the trajectory of a conversation, opened a floodgate of new ideas, or magically simplified a complex problem.

Great business analysts fill their toolbox with high-impact questions! BAs use these questions strategically. They figure out the right way to ask the question and the right way to gather the answers. They also consider the best time, place and audience for each question.

High-impact questions:

are difficult to answer
create moments of silence
inspire responses like, “Hmmmm, let me think about that…”
stir up emotions and politics
spark analysis
encourage stakeholders to provide context, solve problems, make good decisions
generate deep, meaningful, interactive discussions that spawn high-value systems, processes and products

5 Excellent High-Impact Questions

Tell me about your pain points and challenges with the system/process/product.

Yes, I know this is not in the form of a question, but this phrasing indicates your interest in details and deep discussion instead of a short, off-the-cuff list. Starting from a place of pain gives people a chance to get their frustrations on the table right away. It inspires storytelling that gives context to stakeholder concerns and creates a shared understanding of each stakeholder’s priorities.

If this system, product, process worked as good as it could, what would that look like?

This question approaches pain points and challenges from a positive angle and promotes problem-solving. Stakeholders will reveal their solution priorities and their definition of success. Use this question to brainstorm enhancements, features, or to diffuse disagreements about priorities, needs or decisions.

What are the top 3 things you would change?

This question can be used in multiple ways throughout the project lifecycle. You can use it in discussions about systems, features, products or processes, or you can use it to focus on internal processes and issues. This question works in the initial stages of the project when you are defining needs, and is equally useful during a retrospective or “lessons learned” discussion. It also works well evaluating how a current or newly implemented solution is working regardless of if changes are being asked for.

Asking users to limit their change list to 3 items, forces stakeholders to prioritize and focus on what’s most important. Be sure to spend time diving into the why for each item. When stakeholders reveal their top 3 things and explain why, you will begin to understand their values, priorities and pain points. You’ll also begin to see how each stakeholder is connected.

What things would you make sure not to change?

This question works well when you need your team to focus on the positive. It reveals what each stakeholder appreciates about the current process, system or product. You begin to understand stakeholder values and priorities. You discover stakeholder fears and define innovation boundaries. Digging into the why of each “please don’t change this” item, will uncover stories (requirements in context) of what’s working well and might spark ideas for enhancements or new products/processes/systems. You might also find conflict here…things in this list might also be in the top three that others want to change, which generates good discussion.

If the project or enhancement does not happen, what impact would that have for you?

This question, when discussed in a group setting, pulls each stakeholder out of their silo. They begin to discover gaps in their understanding of the big picture. As the stakeholders reveal their needs. Some may discover they do not need to actively participate in the project. Others may discover they underestimated their impact. This question often generates meaningful examples and scenarios that stick in people’s minds much longer than words in a giant requirements document.

Benefits of High-Impact Questions

High-impact questions provide multiple benefits that tip the project balance to success. Here are just a few:

Silence: High-impact questions allow the stakeholder or group to think, go back in their mind, come back and be with a space in their mind to really process thoughts and come to conclusions. Silence helps us get better requirements that are better thought out. It reduces the risk of changing requirements by giving stakeholders time to dive below the surface requirements earlier in the project.

Trust: High-impact questions build strong relationships with stakeholders and users. Deeper dialog makes them feel connected and understood, which creates trust and boosts morale.

Ownership: High-impact questions help our stakeholders own their involvement in the solution. Rather than cast blame or incite conflict, high-impact questions help stakeholders communicate and articulate the real problem they want to solve.

Be Strategic

To maximize the benefits of high-impact questions, use them strategically. Consider the following:

Why are you using the question? What do you hope it reveals? How will it help your team boost end-user value?
Who should be answering the question? All stakeholders or just a subset? Users or management?
How will you ask the question and how will you gather the answers? One on one, small group, large group? Do you need to allow opportunities for introverts by using surveys or individual brainstorming on sticky notes, then sharing with the large group?
Can you use the questions to help stakeholders focus on the end user’s perspective rather than the team’s perspective?
If you are in a group when you ask these questions, take the time to observe body language. Who is agreeing with the speaker, who is disagreeing, who looks angry or frustrated? What does body language reveal about your stakeholders’ needs, values and priorities?

High-impact questions encourage teams to talk early and often—minimizing the risk of identifying expensive, show-stopping issues late the project. Use them strategically to help your team build the right solutions, faster! Test one of these questions in your next elicitation session and let me know what happens, or share your favorite high-impact questions below.

We are So Over Scrum

Written by Steve Blais on November 14, 2016. Posted in Articles. 1 Comment on We are So Over Scrum

The question goes on in the Scrum and Agile circles about how far a team can stray from the Rules of Scrum before becoming a “Scrum Outcast” and …

earning the derision and scorn of the “True Believers.” But there is something about the stasis of staying the same and always playing by those rules that might bother some people.

Here are some thoughts on the concept of keeping to the rules or improving out of them.

The Rules of Scrum

Scrum, despite its definition by Ken Schwaber and Jeff Sutherland as “a framework for developing and sustaining complex products” ^[1], has a distinct set of rules. Unbreakable rules. In fact, the subtitle of the Scrum Guide from which that definition is taken is “The Definitive Guide to Scrum: The Rules of the Game.

The rules are what make Scrum, Scrum. If you don’t follow the rules you are not doing Scrum.

Now this is not a consideration uniquely tied to Scrum. If you want to play chess, you follow the rules of the pieces (the way they move), the board (8 x 8), and the other rules of the game. If you want to do something else (say, introduce a new piece, for example, the “jester” (moves 2 up, 2 over, and the player has to tell a joke) then you are no longer playing chess. There are many variations of a game with balls, bats, bases, and players, but there is only one set of rules governing baseball. And so forth.

Each of the agile approaches has rules. Extreme Programming (XP) has its Twelve Principles which establish the rules for XP. If you do not follow all twelve of the Principles, you are not doing XP. Feature Driven Development (FDD) has its processes. And so on.

The concerns of the Scrum elite are valid. They are trying to make sure that teams that only follow some of the Scrum rules and not others, and fail, do not blame Scrum for the failure. In other words, the belief is that if you follow Scrum exactly as it is defined in the rules of Scrum, the software development (or the product development) effort will be successful. If not successful, the rules were not followed, in the form of software development called “Scrumbut” (“we are doing Scrum, but [specify some rule that is not followed. e.g. we still have a project manager] ).

When asked if Scrum can be performed without various of the defined components, such as having a Scrum Master, or daily stand-ups, or a retrospective, the Scrum community is fairly unanimous is saying, “no.”

Here are some random comments from the Yahoo Scrum Development Group and the LinkedIn Agile and Lean Software development Group over the past several years.

When asked if it were possible to “do Scrum” without Scrum Master (names withheld):

“No, it is not possible to have Scrum without Scrum Master. Have a great day.”

“You can still go and do the development work without a Scrum Master, but you can’t call that Scrum.”

“If you do not have a Scrum Master on your team, you are not doing Scrum. If you do not have two bishops at the start of a chess game, you are not playing chess.”

Similar responses applied to doing Scrum without a standup and without a formal end of sprint retrospective: “It’s not Scrum, it’s Scrumbut.” So changing the rules should be avoided since no one likes to be called a “but” especially a “Scrumbut.”

What if the Rules Stop Applying?

But what happens when the team or the players find the rules constraining or restricting or decidedly non-Agile?

Is that possible?

Example:

The team had been together over three years, using Scrum as their software development approach. They were by any measure a performing team under the Tuckman model. They regularly made all their sprint commitments and performed at a high velocity especially when compared to the other Scrum teams in the department.

Over the years, in their quest for continual process improvement, they made a number of changes which affected the basic tenets of Scrum.

Because they were co-located and talked among themselves continually, they decided that their Daily Stand Up was redundant. At the Stand Up, they retold what everyone already knew from the day before. Basically, they all knew what each other was doing. They said that they didn’t miss the Stand Ups and liked the extra fifteen minutes a day the got by not having it.

They also decided that waiting until the end of the Sprint to review what they were doing was too late, making the Retrospective also redundant. They were making changes during the Sprint and adjusting and having ad hoc meetings to address issues. The Retrospective had become a review of what already happened and a waste of time.

They eliminated it.

Finally, they realized they were able to deal with all the obstacles and impediments themselves. They didn’t need to go to a Scrum Master to act as an intermediary. They ran their own Sprint Planning Sessions, and Reviews with the Product owner and they certainly needed no further instruction on how Scrum works.

Since they were functioning as a high performing team, they also worked out all their issues among themselves. They suggested that the Scrum Master could better spend his time with other teams. The Scrum Master did. (I talked to the Scrum Master, who voiced no feeling of failure or resentment at being relieved of his duties. He had more of a sense of a parent watching the child graduate from college and enter the workforce on his own. He expressed that he hoped other teams would ask that he be removed.)

Their velocity and output continued to be high in terms of both quantity and quality. But they were not doing Scrum because they were not following the Rules of Scrum. And this is all right. Certainly, the team was not concerned about labels and in any case they still assumed they were doing Scrum. The Scrum Sheriff had not arrived in town as yet to tell them to cease and desist.

First Follow all the Rules

You have to follow the rules because you need a baseline from which to evolve. Otherwise, how would you know you have improved? To paraphrase the comment from Seneca, how are you going to know the direction you want to take if you don’t have a point to start from?

If you improve your process and change one of the rules of Scrum to make it better for you, then you are no longer doing Scrum. You can call it something else. Maybe Cricket or NuScrum or Murcs (Scrum spelled backward).

What do you call it?

So if it is not Scrum then what is it? We can probably call the process whatever we want. The team mentioned above had just such a discussion. One suggestion was to call it “Elvis” (from an Elvis fan) because “We’re fast and we rock.” Other suggestions included “Super Scrum” (with appropriate uniforms), “Uber Scrum,” “Scrumptious,” and, of course, “Over Scrum” which the team member highlighted the double entendre by stating, “We are so over Scrum.”

What was their final answer? What did they answer when other developers or management asked them what they were doing? What did they finally end up calling their approach?

Nothing. They decided that they didn’t need a name. Or a title. Or an “Agile approach.” They decided that they didn’t even need to call themselves “Agile.” They were simply developing software the best way they knew how. And that was enough for them.

Agile is not about developing software or product

Maybe we have it wrong. Maybe “Agile” is not about better ways to develop software. Maybe Scrum isn’t really a “product development framework.” Maybe Agile is a way to get a group of software developers together and work as a team and then as a high functioning team. Maybe software development is just what is done while the team is forming and performing. All of the practices and indications of Agile, from pair programming to the Scrum Master, to collective ownership of code, and so forth seem to be about improving the collaboration of the team as much as producing software.

Perhaps if we view “Agile” as a team development method rather than a software development approach, all the issues with being one approach or another start fading away. When the focus is on developing a high-performance team, backlogs, refactoring, having only three roles, Feature Lists, prototyping sessions, and all the rest become methods and techniques for developing the high-performance team.

Graduation Time

In the public school system in the US during the 1950s (I don’t know how long it continued) a graduation ceremony was held when the children moved from kindergarten to first grade of elementary school. I have an old photograph of myself graduating from kindergarten, passed on to my wife from my mother. In sepia tones, I am standing in front of a school wall replete with suspenders (the dress of the day), mortar board and some kind of certificate in my hand.

Am I suggesting that Scrum is like kindergarten? In a way.

Just as Robert Fulghum said, “All I really need to know (about life) I learned in kindergarten” so we might say about Scrum: “All we need to know to be a highly productive software development team we learn in Scrum.”

Just as in kindergarten and throughout all school, the ultimate goal is to learn something and to graduate. With Scrum (and with all Agile approaches) our goal is to learn something (especially about being in a team) and eventually to graduate from Scrum. And it doesn’t matter what we call the process we use after we “graduate” from Scrum. We can simply call it “Agile,”

Your goal should be to start with all the rules of Scrum so that you are doing Scrum and then improve to the point where you are not doing Scrum and graduate to something better: your team’s own software development process.

As Tobias Meyer once said,” the ultimate goal of Scrum is to eventually stop using Scrum.”

[1] Schwaber and Sutherland, The Scrum Guide, July 2016, Scrum.Org and Scrum Inc.