Skip to main content

Author: Kupe Kupersmith

Live at Agile 2017 with Kupe

Kupe is at Agile 2017, the premiere agile event hosted by Agile Alliance.

He is writing daily blogs on topics that relate to you, project managers and business analysis professionals. We know everyone could not make it to Orlando, so Kupe is bringing Orlando to you. This is going to be one magical blog series. Keep a look out for all the updates this week. 


Agile 2017: KUPE’S VIEW – DAY 4

Orlando, Florida, August 10, 2017:  Day 4 was my last day at the conference. In case you don’t know, my goal in life is to meet everyone in the world.  Throughout the week I was meeting people left and right.  If you are a connector like me, this is a fabulous event. I created a little collage of some of the people I met and longtime friends I connected with. 
Agile2017SelfieTileKupe

This is my last post from Orlando. I hope you enjoyed the series.

Linda Rising- Moral Foundations Theory: To Help Address Conflict

The 2016 United States president election was a transformational moment for Linda. She supported Hillary Clinton. Linda was very upset with the election result. She found herself trying to figure out who voted from Trump. She couldn’t stop judging those that did vote for him. She couldn’t understand why. Friends she had for years, where now almost her enemy. It was really bothering her. She wanted to put people in a box. If you voted for Trump, she’d close the box. This was not healthy. This is not who she is or wanted to be. This led her to begin researching how people decide what is right and wrong and dealing with conflict.

Linda shared a lot of evidence on how people make ethical decisions and how we communicate with each other based on those decisions. She explained that when we are faced with conflict a natural reaction is a fight. We want to win. We stop listening, and just wait to reply. We view the problem being with them, not us. So, the first step in any conversation should be to listen like Stephen Covey suggests. You need to listen with the intent to understand.

There were some good books referenced that I thought you would enjoy reading. These were a few publications Linda used in her research.

  1. Thinking Fast and Slow – Daniel Kahneman
  2. Predictably Irrational – Dan Ariely
  3. Fearless Change – Linda Rising and Mary Lynn Manns

A key message was you need to be open to changing your view point. Begin with levels of agreement and focus on the other’s values. This creates more receptive listening in others, and shows empathy, lowering the conflict.

With the polarity in views regarding political parties, if your goal is to persuade others to your view, you will be disappointed.  Instead go into a conversation as you might change and you want to learn something.  Then you have an attainable goal.

If you are completely closed to changing your own point of view and learning, then don’t bother having the discussion. Confirmation Bias will filter everything, That is what is going on in this country.  We only see what validates our own point of view.

Trump vs. Hillary is not the only kind of conversation where this happens. The lessons shared by Linda apply to all personal and work conflicts. 

For more about Linda – www.lindarising.org

Dave Bieg and Joy Beatty – Agile BA Practices using the Guide to Business Analysis

I arrived late to Dave and Joy’s session, but I picked up on the overall theme of their session.

The core concept is teams need to collaborate and determine what approaches are worth doing to accomplished the goal of the project. Their session was workshop style having teams think through what tools and techniques are appropriate for both traditional approaches and agile approaches. A nice twist they added was how may you alter a technique to work in your situation.  

The tools and techniques covered are based on PMIs work on “the Guide to Business Analysis” which includes the “Standards for Business Analysis” that will be published in late 2017.

The guide mentioned above, provides guidelines, not rules or policies. Nothing is a must. When tailoring your approach, you should always be asking what value does a task add to me, my team or the business.

I did have one question for Joy and Dave, but did not get a chance to discuss this with them. Joy shared, and I am paraphrasing, that inputs and outputs for tasks in both agile and waterfall are similar. You just use some different techniques.  My question is “do you do the same work in both methods, just use different techniques?”. 

It was nice to hear that the process the team used to develop the guide included using agile language first. Then adjusted to make sure it was clear for those that use a more traditional approach. Joy explained that many writings take a traditional view first, then tack on agile. They did the opposite.

I have not seen early drafts of the guide from PMI. I guess we’ll have to wait until the fall/winter!

To connect with Dave and Joy – [email protected], [email protected]

Elizabeth Ayer – Spreading the Love: 8 Ways to magnify the Impact of User Research

Agile2 17 Kupe and ElizabethMy first observation from this session was that Elizabeth is a fast talker.  I was surprised because she is from Los Angeles and lives in the UK now.  She clearly won the highest energy level at the conference award. Her session was very pertinent to many at the conference. Most discuss the need to get with the customer to listen and observe their behaviors and uncover their needs firsthand. Unfortunately, most people don’t get the chance to do it. 

There was a time in her company that the Product Manager did all the customer interaction and would feed that information to the team. This was OK, but not great.  The problem was the development team was not fully in touch with customers. They had a development view and focused on how they thought the product needed to be enhanced. This is not as good as enhancing the product like the customer needed it enhanced. So, they switched things up.

The team started to follow a key principle: Involve more people. Learn as a team, don’t hand something over.  Certain customer engagements needed to be done as a group. Here are the 8 concepts she shared.

For the development team: 

  1. Support existing priorities – Don’t forget about things that people are already worried about – address it. The team feels pressured for time already. Help them focus on the following information from the customer.
    1. How much is enough, how is the user solving the problem today, how should we test this?
    2. Her team created a column on their story board called “What we don’t know”. This gave everyone the ability to put up what they needed to learn so they can focus the calls with customers. This helped focus the calls.
  2. No more UX virgins – Everyone does this.  No one gets a free pass.  You need to watch your users use the system.
    1. Make it safe and easy for people not wanting to interact with customers. Example time…they had developers on calls sitting at their desk on a video call.
  3. Everybody is active. Everyone has a role to play in meetings. (Call leader, plan checker, wingman to leader, bingo scorekeeper (ha!), product expert, note-taker)
  4. Agree for interpretation – Get a shared understanding. After the meeting debrief and make sure everyone is on the same page.

Extending beyond the team:

  1. Make it available. Write it down.
  2. Publicize the work. Allow people to consume at their leisure – More of a pull method, not a push method. 
  3. Offer your sessions. Allow other people to join if they want to hear/see. Or they may need other information from the customer. Tack on their needs at the end.
  4. Name drop your users.  Bring in names to conversations to make it real. Don’t forget about the customer.

Wait…what about personas? Isn’t this enough?  Elizabeth made a great point. She shared many teams just think of personas or use the voice of the customer. Her point is why not actually hear the voice of the customer. And with personas, you can lose some of the finer points.  Not everyone is the same.  Maybe personas first…then get to the individuals.

To follow Elizabeth – @ElizAyer

Evan Leybourn & Shane Hastie – If you need to run a project, you’ve already failed – #noprojects

There were PMs in the room so I was excited to see how this one was going to go down. This was all about the No Project movement. Evan shared a long history of projects. The beginning started in 1698. I had no idea. A key lesson is that projects focus on the wrong thing. They focus on what is measurable and not what is valuable. Projects are temporary. On the other hand, products aren’t. Shane continued sharing that projects are expensive. There are typically overruns and opportunity costs. Studies show typical projects could be 172% over budget and 184% over time. This could show we are just bad at estimating!

What we need is a continuous culture. We need continuous delivery. To help with this approach, enter  #noprojects. The definition of #noprojects is the alignment of activities to outcomes measured by value. Constrained by guiding principles and (optionally) supported by continuous delivery technologies. The last part was optional because value is not always derived from a technology initiative.

A different line of questioning helped me understand where they were headed. Instead of asking “how much will it cost?”. Ask, “how much is it worth?” If you focus on cost then a project goes until all the features are done. And, as was stated earlier, projects go over budget all the time.  A #noproject should stop when you get to a point when value flattens out. By asking what is it worth gives you the guidance on how much to spend.

The concept is to have a value delivery team. This is a dedicated, stable, cross functional team that contain the required skills to achieve value. The team is trusted to make operational decisions, and value can be continuously created.

Full disclosure. This was a deep topic. A complete reframe for most. My feedback to the conference organizers is to put these types of sessions at the beginning of the week!

To follow Evan and Shane – @eleybourn @shanehastie


AGILE 2017: KUPE’S VIEW – DAY 3

Orlando, Florida, August 9, 2017: Day 3 had an interesting observation. Tuesday night (Day 2) was filled with many vendor parties. This resulted in a tired day for many. I saw more people hanging in the lobby areas than the days before. This may not have anything to do with those parties, but that’s my conclusion! I did not attend any of those parties as I was speaking at the Central Florida IIBA chapter. It was a great event.

First up for Day 3 was a keynote presentation with the main subject of DevOps. Let’s go!

Jez Humble – Continuous Delivery in Agile

Beware, this starts off with a technical topic. It ends with advice that applies to any change. What is continuous delivery? When you hear DevOps, think continuous delivery. The definition shared by Jez is, ‘The ability to get changes – features, configuration changes, bug fixes, experiments – into production or into the hands of users safely and quickly in a sustainable way’.

Jez explained that a high performing IT organization does the following things well.

  1. Lead time to changes – Keeping the lead time to implement changes down for the highest priority at a moment in time.
  2. Release frequency – Release as frequently as possible/acceptable.
  3. Time to restore service – If something goes wrong, get it back up quickly.
  4. Change fail rate – Reduce the amount of fails when released.

The first two have to do with deploying fast. The last two are about deploying with quality. You don’t have to have one without the other.

The challenge explained was that many organizations are not great at all four. Why can’t we do continuous development in a fast and safe way? Here are the stated reasons by teams.

  1. We are too regulated.
    Bad reason. Amazon is a regulated company deploying every 11.6 seconds. Not easy, but it can be done. Jez did it with the Federal Gov’t. What’s your excuse?
  2. We are not building websites.
    The division that manages HP printer firmware improved their deployment schedule. By the way, firmware is not a website.
  3. Too much legacy.
    You can do test automation with legacy mainframe systems. It has been done. Jez played a video from BMC Software that showed a team running automated tests with a mainframe system. They did not think they could do it, but they tried and it worked.
  4. Our people are too stupid
    It is usually not stupid people. Steve Denning says a bad system will beat a good person every time. Is it the people or is it the system/culture?

Jez wrapped up by saying those reasons are not the real reasons why deployment can’t be improved. The actual reasons are:

  1. Our culture sucks
  2. Our architecture sucks

I think this relates to most changes. As mentioned earlier, culture will eat good people and ideas for lunch.

For more about Jez – Check out his author profile.

Me – Radio show with Agile Amped

Kupe 08102017 2I was honored to be asked to do a 30-minute segment with Solution IQ’s Agile Amped Radio Show. Guess what I talked about? Improv and networking…who could have guessed? I will have a link in the next week or so. Or you can subscribe to their channel here, https://www.solutionsiq.com/agile-amped/.

Thanks to the great host, Howard Sublett!

Amy Silberbauer – Do we still need Business Analysts and Systems Engineers? Now more than ever!

Kupe 08102017 3

Amy had a 30-minute session and packed in a lot of great information. One of the main reasons for needing people with business analysis experience is that enterprise success is not just about faster delivery. It is about making a happy customer. Basically, you want to deliver fast stuff that makes customers happy. Not just delivery fast stuff. Amy uses the term “time to happy customer” instead of “time to achieving value”. In the end, the goal is a happy customer. Value can be different for different groups. This is a way to address success at a higher level.

A good example given was a customer needing something to mix food. Can that need can be solved with a spoon or a Cuisinart? The BA and systems engineer need to find out. A Cuisinart may be cool to deliver, but it may not be needed. The key to success is understanding the customer.

In today’s environment, we need designers to build the system. There are competing and disconnected interests and needs. The BA can help design a unified vision and goals. This is the synthesis of information and connecting the dots to design a complete system.

Organizations need design thinking. Amy urged BAs and system engineers to get in this space. She then shared a slide titled “BAs and SEs are the new sheriffs in town” The message: there are roles for people in these roles. It is just slightly different going forward. Here are the 4 options she highlighted.

  1. Customer Advocate – Be the “face” of the organization. Tease out the real requirements. Get continuous feedback, keeping the customer “in the loop”.
  2. As Designers – Define the solution. Understand roles and personas. Elaborate end-to-end solution use cases and activities within them.
  3. As Orchestrators – Take a Systems View. Apply economic thinking to define MVP and iterative delivery plan. Collaborate with engineering to determine best alternatives.
  4. As Engineers – Propose and evaluate alternatives. Explore and validate technological assumptions.
  5. As Architects – Define common architectural and technical vision. Ensure consistency.

Connect with Amy – https://linkedin.com/in/amy-silberbauer-3a102043

Angela Wick – Value – Perspective is Everything! @WickAng

Kupe 08102017 1How do we know we are delivering value, not just delivering things faster? That’s the question Angela was covering in her session.

Before I get into some of the highlights from her talk, check out this list of questions to ask about value.This is a great starting point.

Value is not just ROI (return on Investment), it is about the value to the customer. Does the customer love the product? The good thing is Angela and Amy are saying the same thing!

I really liked David Hussman’s Dude Law that Angela introduced to the group. It’s n easy formula to determine you are spending enough time on determining value. The equation is Value = Why / How

We should be talking more about the Why, then the How. So, the higher the number, the more time spent on value conversations over how we are going to build a solution. Use this as a good indicator of getting too deep in the weeds before you gained a shared understanding of the value you are trying to achieve.

Her next set of slides I am sure causes some good debates in a room filled with BAs. Not as much in a an agile world. The slide was titled, “Is a BRD valuable?”. The key takeaway is we should be moving away from big thick documents. Think about what documentation will help with. Don’t just document for documentation sake. A great point made was if your team is building things in smaller chunks, then you are dealing with less requirements. So, you can remember the requirements. Putting things up on visual boards making things visible for the team is a more effective way then packing things in a document that is harder to access.

I’ll end with a key message. I know his may sound simple, but it seems to get lost. You have to make sure you know who you are building the solution for. That’s the group you need to be considering when determining value. You should identify a primary customer or persona, secondary personas and tertiary personas. When designing a solution start with making sure it works for the primary persona. Then check to see if it works for the secondary and tertiary personas or can it disenfranchise those personas. Then make a decision if a redesign is necessary.

For more about Angela – http://www.ba-squared.com

I want to end with a random conversation I jumped in on discussing neuroscience and the impact when we are threatened. The basic concept is that if we are threatened, the thinking part of our brain shuts down. So if we are pressured at work to get stuff done we are most likely going to produce lower quality work. Yesterdays sessions talked a lot about safety. When in a safe environment, the thinking part of our brain is on fired.

Day 3 was awesome. Day 4 starts now…gotta run!


Advertisement

AGILE 2017: KUPE’S VIEW – DAY 2

Orlando, Florida, August 8, 2017: Day 2 at the conference was another success. I attended some great sessions and was the speaker in one. I’ll give a little recap of my talk, although Claire Moss was doing some great live tweeting. Her handle is @aclairefication and is also tweeting for Agile Alliance using @agilealliance. If you are on twitter you can keep up on some sessions in the moment by following Claire.

First up for Day 2 are some familiar names. Here we go!

Kent McDonald and Heather Mylan-Mains: How to Find the Real Need with Socratic Questioning

One thing that always comes up in our profession is “what questions should I ask?”. Managers need to know their teams are asking the right questions. Well, Heather and Kent to the rescue. By teaching attendees Socratic Questioning they were giving them an approach to get the true need for a project. Too often, the solutions built don’t address the real problem or opportunity. Example time – Heather told a story about a young boy being hit by a car on a street in the boy’s neighborhood. The solution implemented was installing speed humps which cost almost $300,000. You would think the real problem is people are speeding on the street. Nope. The accident happened at 9 pm on Halloween. The driver was not charged with speeding. It was just a tragic accident. Speed humps were the wrong solution. Something more like better lighting, blocking streets off during Halloween, and the like would have been better approaches. How often are you building “speed humps”?Kupe 08092017 1

The Socratic Questioning method is to help someone come to a conclusion by asking a series of questions. Great uses of the approach include identifying the real need and coaching. Here are the 7 questions they suggested asking to get to the real need.

This is a starting script. You don’t have to stick with it in this order…be ok adapting.

  1. What is the project Great question to get the conversation started?
  2. When did you realize you needed to do this project? Ask for scenarios to find out what’s happening. You want to make sure you know what happened that sparked this idea for a project.
  3. What problem is this trying to solve? Could cause uncomfortable silence. They may not know the answer. That can be revealing. If they can’t come to an answer, maybe the project is not worth it.
  4. What is the impact to your organization? Is it worth solving
  5. How much is that problem costing your organization? Is it big or small – how much should we spend to fix the problem?
  6. How should tomorrow look after we’ve solved the problem? What does success look like? You may be able to fix the problem another way or with less effort.
  7. What are the next steps? – What else do we need to move forward? Do we need more information? Do we create a business case, etc?

A great question asked was “what if I work for the company hired to build speed bumps?” Kent responded that you should still go through this process. It’s a hard pill to swallow, but you need to focus on the right solution, not just building a solution.

There was much more, but I ran to another session.

To contact Heather – [email protected]
For more about Kent – https://www.kbp.media/

Joshua Kerievsky and Heidi Helfand – High Performance via Psychological Safety

You may have heard of Joshua. He was the one that introduced me to Modern Agile. If you have not looked into Modern Agile yet, you need to. One of the principles of Modern Agile is Making Safety a Prerequisite. It was no surprise they were talking about Psychological Safety. For this talk they focused on the impact of conflicts in organizations. A quote they shared the book Crucial Conversations summed it up. “The health of an organization is measured by the lag time between when you feel it and discuss it.” Healthy organizations address conflict closer to in the moment than not. The longer you wait to address conflict the faster trust breaks down.

They gave the attendees an approach or mechanism to conflict resolution. To help have that critical conversation and reduce emotion an approach called C.O.I.N. is a great technique. Each letter represents a part of the conversation.

  1. Context – What are the facts of the context…what happened?
  2. Observation – What did you observe?
  3. Impact – The impact of the conflict on you or others.
  4. Next Time – What can we do next time to avoid conflicts like this?

Some may be thinking, why is conflict resolution so important at an agile conference. I think these types of sessions are critical. Agile teams get put together and not enough time is spent on how to interact with each other.

For more about Heidi – http://www.heidihelfand.com/
For more about Joshua – https://www.industriallogic.com/people/joshua

Kupe 08092017 2Me – A Conversation about Connecting and Building Relationships

My session was not a presentation, rather a conversation with the attendees. I had a great facilitator, Curtis Michelson. Here is the premise of my views on the need for all of us to do a better job connecting with others and build trusting relationships.

It’s 2017 and we are deep in the age of robots taking over ordinary jobs. This leaves us humans to focus on work that has us working with robots and yes, humans. The World Economic Forum lists the top 10 skills we’ll need by 2020. Seven of the 10 include direct human interaction.

They include Creativity, People Management, and Coordinating with Others, Emotional Intelligence, Judgement and Decision Making, Service Orientation, and Negotiation. Even if robots are not completely taking over there is still reason to have a clear focus on building your people network and building strong, trusting relationships.

In today’s environment, we need to move quickly. When you are working on an initiative, you need to know who the go to people are. You need to be able to access to them. Just think about your day. You most likely don’t have enough time to do everything you need to do. You don’t have enough time to meet with everyone that needs to meet with you. How do you prioritize who you will talk with? Most likely one factor is people you have a relationship with already. You are not paid for what you know; you are paid for who you know. Information is plentiful today. In a few clicks, we can get answers to almost anything. Begin to take pride in getting the right answers to everything, not having the answer to everything.

This means you need to take an uncommon approach to connecting with others. You need to step up your game if you are going to add value today and be ready for 2020 and beyond.

My goal in life is to meet everyone in the world. So, please connect with me on LinkedIn.
For more info about me – www.kupetalks.com

Permission, Trust and Safety – Tim Ottinger and Ashley Johnson

I decided to stick with the softer side and went to see Tim and Ashley talk about Permission, Trust and Safety. Now that I look back, most of the talk was about Trust and Safety. I can’t recall what was said, if anything about Permission.

Most of this session was the attendees talking through what teams look like when there is safety and trust. And what it looks like when there is no safety and trust. In Summary, Tim and Ashely defined trust as the firm belief in the reliability, truth, ability, or strength of someone or something. Someone says they will do something and you believe that to be true. The summary of the safety definition is team members feel accepted and respected.

A big win for me was the discussion on responsibility. That we must take responsibility for our actions and that includes being intentional about earning trust and providing safety. They covered some work done by Chris Avery and studies on the things we do before taking responsibility. When something goes wrong – we do the following instead of taking responsibility.

  1. We look for someone or something to blame
  2. Justify – We make up stories
  3. Shame – We fall on the sword and shame ourselves in hopes that everyone feels bad for us.

The key is trust and safety is a prerequisite for successful teams.

Day 2 was awesome. I had the chance to connect with others and learn a ton. Day 3 starts soon!


Advertisement

AGILE 2017: KUPE’S VIEW – DAY 1

Orlando, Florida, August 7, 2017: Agile2017 started off strong. If you have never been to Agile Alliance’s major conference, it is one of those conferences that has something for everyone. The conference Chair, Tricia Broderick, kicked things off at 9 am giving everyone, all 2,500 of us, the lay of the land. Since many of you could not be here, I wanted to write daily posts sharing some highlights. I hope you enjoy my daily recaps.

First up for the day was they keynote speaker, David Marquet.

David Marquet – Creating Leadership and Engagement at Every Level

David was the Captain of the USS Santa Fe, a nuclear submarine. This is where he really learned about leadership. His message was clear from the beginning, “Leadership is not for the few at the top.” He went on to talk about how business value creation and business differentiation depends more on people thinking and making decisions over execution and process discipline.

That is not to say execution and process is not important. You do need to get things done. The challenge is there is more doing than thinking in many organizations. David, said this gets people killed in the Navy. For most of you, no one may die, but money and time is wasted.

He explained this by showing the old way of leadership being 3 steps.

  1. Intent – The leadership defines the intent or the mission. (Thinking)
  2. Debrief – The intent is shared with everyone. This is your time to ask questions. (Some Thinking)
  3. Do – Everyone does their job.

In the doing mode, people look to leader to make decisions. David explained at a time, leaders where taught to know everything about the space they lead. In the Navy, if you were going to command a submarine, you went to school for a year learning every aspect of the submarine. You knew the vessel inside and out. So, if something happened, you could make a decision on what to do.

This is a flawed model. Leaders can not know everything about everything. Leaders today need to allow their teams to think and react based on what is happening in the moment and not rely on the leader at the top to make all the decisions. He summed up this concept by saying leaders need to help their teams prepare to win. Then when doing the work, give them the control. This image he shared sums up the concept. You give your team members more control by giving them the ability to their job and clarity of the goals.

Kupe 08082017 1

 

There was so much important information shared it’s hard to sum up his talk. But, I will try anyway with something he said. It is not about leaders making better decisions. It’s about making everyone better at decision making.

For more information, you can visit http://www.davidmarquet.com/

A Conversation with Ron Jeffries & Chet Hendrickson

If you don’t know these guys, you need to. These guys have been around before the beginning of Agile. Ron is a founder and was one of the few who created the Agile Manifesto. This session followed a Q&A format. Here is a highlight of their responses to some good questions about agile.

Ron was asked what he would change in the Agile Manifesto now that he knows more. Ron stated that he would not change anything. It was thoughts from a group of mostly like-minded people at a point in time. He did say he would push for a more diverse group. He did add that he would try to clarify language, especially the use of the word ‘over’. One of the values is “Working software over comprehensive documentation”.

The word ‘over’ was interpreted to mean, we don’t value it. So, everything on the left side was valuable and everything on the right was not valuable. He wishes they gave more clarity around that word. Chet added the true meaning is we put more emphasis on the left side. The right side is still needed.

Another question started a conversation around scaling agile. It was clear Rona and Chet are not big fans of sticking to set processes for agile teams. My sense was they feel things like SAFe and Scrum have been misused to allow management to control their teams.

One of the key takeaways from this conversation was to not make teams all do the same thing and follow the same exact process. When companies think of scaling they feel each team should follow the same process. Ron and Chet believe it is best to allow each team to act like they want. The one consistent thing is to focus on the outcome. If the team is delivering software and customers are happy, let them do what they do.

The last point I’ll share from Ron and Chet is their belief in team diversity. They feel teams need to be diverse. Have diverse skills, ideas, and behavior styles. That is how things get done. Ron shared this was something he learned over time. In the past, he would hire people just like him. That doesn’t work.

For more about Ron – http://ronjeffries.com/about.html
For more about Chet – http://www.hendricksonxp.com/


Kupe 08082017 4

Steve Denning

After lunch, I had the pleasure of sitting in a session with Steve Denning. He is a business pioneer and an author of six successful business books and a former director of the World Bank. There is more to his history, but I think that shows that he is the real deal.

Denning is a big believer that agile is a mindset, and it needs to be embraced throughout organizations and not just in software development teams.

He touched on three laws that will help teams and organization achieve and maintain agility.

  • The law of the customer: An obsession with delighting customers by continuously adding value for customers and users, as well as a recognition of the current need to generate instant, intimate, frictionless value at scale.
  • The law of the small team: A presumption that in a volatile, complex, uncertain and ambiguous world, work needs to be disaggregated into small batches and performed by small cross-functional autonomous teams, working iteratively in short cycles in a state of flow, with fast feedback from customers and end-users.
  • The law of the network: The entire firm functions as a fluid interactive network, not merely a top-down bureaucracy with a few teams implementing Agile tools and processes.

The third law is my favorite, since I am speaking about the value of your personal network on Tuesday. Denning uses the word adhocracies as the opposite of bureaucracies. Adhocracies are flatter organizations. By having the interactive network anyone can be connected with anyone. Anyone can get information needed from anyone. There are no prescribed channels to go through.

One of the greatest lessons from Steve Denning was to always be learning. He has written six books and has over 600 articles published. He is a smart, thoughtful man. A person this accomplished still says he is learning and adopting his thoughts every day.

For more on Steve Denning – http://www.stevedenning.com/site/Default.aspx

Angie Doyle and Talia Lancaster – Sketching outside the box: Visual Thinking for Teams

Kupe 08082017 3

This was the fastest 75 minutes of the day. Why? Because it was like we were in art class. Angie and Talia taught us how to use visuals to help when facilitating sessions or taking personal notes. Why draw and not just write down bulleted lists? Here is what they shared:

  1. Drawing helps see the big picture. Pictures tell us so much more than words.
  2. Drawing heightens engagement. People are more engaged in a conversation when someone is up drawing.
  3. Science shows that it helps you think strategically, tactically, and creatively.
  4. It helps you get on the same page faster. Maybe you can have faster meetings.
  5. It addresses all learning styles. Reading, visual, auditory, and tactile.
  6. A creative way to record a conversation. Pictures help more with recall.

Many people in the session were not artists. That was OK because Angie and Talia did a fabulous job teaching us simple tips to get started. Like most things in life, it takes practice to get better. This is one of the things we should all practice more.

To help show us that we could all do it, they lead us through a visual jam. Angie gave us 6 words and we had 30 seconds to draw something that represented each word. In 2.5 minutes, here is what I drew. Can you guess the words? By the way, no judging my lack of artistic ability!

Kupe 08082017 2

You can tweet Angie and Talia – @Doyle_Angie & @SketchingSM

I am off to day 2.

All the best,
Kupe

 

Lean Business Analysis: More About Decision Making

There are many discussions, theories, and great debates over different kinds of BAs.

There are people that perform business analysis in IT environments; there are ones that are not in IT environments. There are process BAs, waterfall BAs, agile BAs, data BAs, and teams that have multiple people doing analysis. Regardless of when and where team members perform business analysis, they need to perform lean business analysis. To explain what “Lean Business Analysis” is, let’s look at the definition of Lean. From the Lean Enterprise Institute, Lean is defined as such, “The core idea is to maximize customer value while minimizing waste. Simply, lean means creating more value for customers with fewer resources.” So, I define Lean Business Analysis as creating more value for customers with fewer resources.

How do you accomplish this? Some may say you do it by spreading the BA work to other team members therefore eliminating a person on the team. The problem with that solution is it only addresses half of the definition…with fewer resources. You need a solution that completes both halves…more value for the customer and fewer resources. This brings me back to my old friend, Decision Making.

I have written about Decision Making before in the following posts, Decision Making: An Underlying Competency or What A Business Analyst Does and It’s All About Decision Making. If you think about business analysis as the activities done to help others make decisions, you have started on your path to Lean Business Analysis. By first looking at your project as a series of decisions, you can then determine what just enough analysis is for each decision. When a decision is made, you are done and can move to the next one. For example, one key decision is what problem are we trying to address. Another can be prioritizing features or user stories. Another is a developer determining how to best design a solution.

There are three key components to decision making that I want to highlight.

  1. You need to define all the decisions to be made.
  2. You need to know who the decision maker is for each decision. This may be one person; it may be many.
  3. You need to know the criteria, or information, the decision maker(s) will use to make the decision.

Knowing the criteria, each decision maker has for each decision to be made is how you determine what information you need to elicit, analyze, and communicate. Once the decision is made, stop analyzing. Once a decision is made you have done enough analysis. Then you have created value for a customer and did it with the right amount of resources.

There is more on this process in my previous blogs, so I won’t repeat myself here. I do want to address a consistent concern I hear about this approach. When I talk about this with people over coffee, during or after a seminar or workshop there is a consistent pushback. “What if bad decisions keep getting made?” It’s a great point. You need to facilitate good decision making! My first response is the process needs to include decision evaluation points to make sure the decisions being made are helping your team meet the overall objectives of the initiative. The other thing is you need to help your customers avoid the four villains of decision making.

In their book, Decisive, Chip and Dan Heath, describe the 4 villains as:

  1. Narrow framing
  2. Confirmation bias
  3. Short-term emotion
  4. Overconfidence in the future

For this post, I want to cover the first two because they focus on how you present or communicate information to decision makers.

Narrow framing is the belief that you have two choices. Either you go out dinner, or you stay in. Do you take a job or not take it? Do we implement a project to go after an opportunity or not? You either do it “this” way or “that” way. There is no in between. People often talk about creativity in business analysis. By expanding the frame and looking at multiple alternatives is a way to get creative. Make sure you provide the decision makers with more than a this or that option. A way to check yourself is looking at the information you are presenting and seeing if one option looks like it really leaves the decision maker with no other choice then choosing the other option.

The second is confirmation bias. This is when you are evaluating options. Many people lean towards gathering information or listening to information that supports their view. Have you ever had a person come to you with the solution they wanted to be implemented? I know, silly question. People have ideas, thoughts and even look for information to help them make a decision. That information just happens to support their belief. The rest of the project team including you fall into the trap of confirmation bias. You are on the project you want it to succeed. It is a hard villain to combat.
One way to help combat this confirmation bias is to find a Red Team. A Red Team’s job is to poke holes in your thinking and/or your decision. They are used by the CIA, Army, news organizations, and businesses around the world. In our environment, we say stakeholders for a project are those impacted or can impact your project. A Red Team is a group of people that don’t have a stake in the project. They have no emotional connection. They have nothing to win or lose by your project. Your Red Team needs to poke holes in your logic and ensure you avoid confirmation bias.
The decision-making process is how you can do just enough business analysis or perform lean business analysis. Try it today and share your stories here!

All the best,

Kupe

Your Next Business Analyst Will Be a Robot

The advancement in artificial intelligence is mind blowing. So much so that teaching robots problem-solving skills is kicking into high gear.

I recently went to a science museum with my family, and one of the exhibits showed that robots are learning problem-solving skills. If you know about and/or believe in Singularity, this is no surprise. You can learn more about singularity here. For a quick reference, I want to share this definition. “The technological singularity is the hypothesis that accelerating progress in technologies will cause a runaway effect wherein artificial intelligence will exceed human intellectual capacity and control, thus radically changing or even ending civilization in an event called the singularity.” In Time magazine about 5 years ago, there was an article that predicted singularity would hit in 2045.

Related Article: Stop Calling Yourself the Bridge

When I read the sign at the museum stating robots are learning problem-solving skills it made me think about the impact to the business analysis profession. Problem-solving is what business analysis professionals do. They are problem solvers. Which led me to think the next generation BA will be a robot. I know most people reading this article will most likely be retired by 2045, so you don’t have to worry about your business analysis role. You may have to worry about how this impacts retirement, but you’ll have to talk to your financial advisor about that one. This took me down a path thinking about how technology is disrupting the BA profession. I landed on the thought that if robots can be BAs in 30 years, then humans half way around the world can be your next BA hire right now. Technology may not be sophisticated enough for a robot to take your job, but it is sophisticated enough to give companies the ability to hire a BA anywhere in the world.

Before I get into what you can do what this means to you and what you can do about it, I want to blow away some myths about having remote BAs.

  1. Distance: I keep hearing people say in the US that the BA role won’t be moved offshore. Well, too late, it already is. The companies I work with have BAs everywhere. I predict the number will grow. And I am not just talking about India or China. Why can’t your next BA peer be from the UK, New Zealand, or Ukraine? Why can’t the next BA on your team be from Los Angeles even though your company is in Des Moines?
  2. Time Zones: How can you possibly have a BA work in New Zealand if the business stakeholders are in the US? The time difference is too great, right? Not too worry. My father worked nights for as long as I can remember. People will work non-9 to 5 jobs if it suits their lifestyle.
  3. Language Barriers: Language barriers will become less and less of an issue every year. When I was in primary school, we started learning a second language in middle school. Now my kids are learning Spanish when they are 5. Younger generations are being brought up in a global world and are being prepared.

Now that I took care of that, you can look at this new reality in two ways. You can see it as a challenge and the fact that you will be vying for a job not only from people in your city but from around the world. Or, you can look at it as an opportunity. No matter where you are, you can apply for jobs around the world. Regardless of the way you look at it, there are things you can do to prove your value to any company.

I have written about valuable skills or characteristics before so I won’t repeat those here. If you have not read my blog post, The Four Chords of Great Business Analysts, please check it out.

For other characteristics to focus on, take a look at an article my buddy Hans Eckman shared from Fast Company, 4 Habits of Employees You Shouldn’t Wait to Promote. Get in the habit.

Oh, but there’s more. Robots may be able to be better problem solvers in the near future. Though, being a good problem solver does not help if you first don’t know what problem you are trying to solve. What good is it if you solve a problem that no one cares about? You need to start or continue to be laser focused on ensuring there is clarity and shared understanding of the problem or opportunity your team is working towards.

Next, you need to focus on remote communication and collaboration. Get really good at this. A recent survey by Meeting Professionals International shows that virtual meetings are expected to grow at twice the rate as live meetings. This is everything from large company meetings to one on one meetings. A large part of your role is to facilitate decisions. The people you are helping make decisions are not always sitting next to you.

Let’s face it; the barriers are broken. Technology has caught up to people’s desire to connect with others around the world. Organizations have options. I can easily connect with friends and colleagues in the UK, Spain, New Zealand, Australia, South Africa, Argentina, and so on. Organizations no longer need to hire someone that lives a commutable distance from an office. There are 2 key things you should focus on as it relates to remote communication and collaboration. One, you have to learn how to connect on a personal level with people in a remote world. This takes some work. In an office, you do this without even thinking. You see someone getting a drink, and small talk ensues. You see them at lunch, on the way to a meeting, or walking into the office and you can connect with little effort. You usually don’t have to make time to connect with them. In a virtual world, you need to schedule it. Work in time during your day to call someone, text someone, chat with someone just to say hello.

Next, you need to improve your virtual etiquette. When you are face to face with someone, you can eat and drink. When you do this on the phone, the noises that are heard on the other end of the phone are not pleasant. If you are eating while you are on a phone call, it’s like someone having their ear to your mouth as you are chewing. It’s rude and sounds gross! If you are a “slurper” when you drink, don’t drink while on the phone. And have you ever filled up a water glass from a water cooler or refrigerator while on the phone? Have someone try it and tell me what that sounds like. I’d rather you eat on the phone!

Technology will continue to change how you live and work. Will robots be the next generation BAs? Maybe. Until then, work on adding value to your organization regardless of where you live or where your team is located.

Virtually yours,

Kupe

Why How You Interact with Others is the New Black

I recently spoke at the Philadelphia IIBA Development Day. I was on a panel with Jodie Kane and Paul DePalma, and it was moderated by Ken Fulmer.

The organizers of the development day asked the attendees which BABOK knowledge areas they wanted us to discuss. Based on the areas chosen we each gave our key tip for that knowledge area and answered questions from the audience. One topic area was around elicitation. When it was my turn to give my tip, I decided to use an exercise I do when I facilitate my DISC® Assessment workshops. DiSC® is a behavioral assessment and helps individuals understand their behavioral style and that of others. This insight leads to better understanding and appreciating differences of others. This leads to more effective communication, which leads to higher productivity.

When you are eliciting, you are interacting or communicating with others. To do this effectively, you must understand how others want to that interaction to go. The Golden Rule states “do unto others as you want done unto you”. The rule for interactions or communication is “communicate with others as they want to be communicated with”. Use their preferred communication style, not yours. You can know every elicitation technique in the book. That’s not good enough. In addition, you also need to know how the people you are communicating with want to interact. Ideally, your company has gone through a DISC® workshop or one like it, and you know everyone’s preferred style. If not you need a way to quickly read people. At the development day with almost 100 people in the room I did a quick exercise to help the group learn how to read and get close to understanding other’s profiles. Here is how it goes. You ask two questions regarding the person you are trying to read. 1) Are they fast-paced & outspoken or cautious & reflective? 2) Are they questioning & skeptical or Accepting & warm? Based on the answer to the questions the person will fall into one of four behavior styles.

  Questioning & SKeptical Accepting & Warm
Fast-Paced & Outspoken Dominance Influence
Cautious & Reflective Concientious Steadiness

Here is a quick overview of the behavior tendencies of each style.

Dominance
Decisive
Independent
Results-Oriented
Straightforward
Influence
Enthusiastic
Talkative
Spontaneous
Demonstrative
Concientious
Orderly
Persistent
Detailed
Serious
Steadiness
Warm/Friendly
Supportive
Cooperative
Agreeable

Now that you know their tendencies you can start to think of ways to interact with them. Here are a few tips for interacting with each style:

  1. Dominance – Make efficient use of time, focus on the topic at hand, and expect candor
  2. Influence – Be open to collaboration and recognize their energy and enthusiasm
  3. Steadiness – Show warmth and concern for their feelings, take an easy-going approach, and work collaboratively
  4. Conscientious – Talk to them about the objective, avoid pressuring them to make a decision, expect skepticism

If you know your stakeholder’s behavior style, you can better prepare for interactions with them. For example. D’s like to focus on the topic. So tangents are not a good thing. S’s and I’s love collaboration. A workshop where they can interact and work with others is perfect for them. C’s lean towards being skeptics, so you can think ahead of time, what may they question.

The next time you are you prepping for an elicitation session first think of the behavior style of each participant. 

All the best,

Kupe

It’s All About Decision Making

In August 2013 I started out on a mission to convince the world what business analysis was really about. After long conversations about decision making with my colleague Kate McGoey, who first introduced me to the concept, I wrote this blog post “Decision Making: An Underlying Competency Or What A Business Analyst Does

It was my early take on the concept. Based on the positive reaction to the post, I knew a revolution started. Since that post, we started helping clients use this concept to improve their project outcomes. I created a 1-hour seminar to spread the message, and a workshop was formed to take a deeper dive into understanding how decisions help teams become more efficient. David Olson, a Senior BA, wrote a post on LinkedIn outlining the same message I was trying to spread. My views on decision making have expanded since this last post almost 3 years ago, so I want to share some of those thoughts here.

Related Article: 8 Steps to Making Better Decisions

Let’s look at how the IIBA defines business analysis:

“Business Analysis is the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders.”

They go on to say:

“Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders.”

For me, that definition is too abstract and maybe inaccurate. Is business analysis about defining needs and recommending solutions? I bet many of you can name many conversations where your business partners came to you saying we need to implement system “x” because we have problem “y.” I can often argue that is done without any “business analysis.” That says to me you can define needs and recommend solutions without knowing anything about business analysis or involvement from a person that practices business analysis. So what is then?

I think it is very simple.  Great business analysis is all about facilitating decisions. The goal is not just to enable change; it’s about enabling the right change. The practice of business analysis is helping other make decisions so the right needs are being met. I don’t think it is a secret that if a decision is not made, nothing happens.

I am going to assume you are with me at the conceptual level. Now, I want to cover a piece of the puzzle that answers the questions of why should you care at the tactical level.

Viewing your role as a facilitator of decisions answers the question of what is just enough analysis. There is plenty of talk that good business analysts need to do just enough analysis. Analysis paralysis is not an option in today’s fast moving environment. It’s easy to say, “just do enough analysis.” But how do you do it?

The first step is realizing everything that happens on an initiative boils down to a set of decisions to be made. Someone needs to decide on what problem or opportunity we are going to go after and someone needs to decide if that problem or opportunity is worth solving/going after. Once in the details, someone has to decide the priority of the features or stories or functions. The solution team has to decide how to build the thing that will address the problem or opportunity. Are you feeling it? Who’s with me?!

So if all these decisions have to be made, business analysis is the set of activities to help the decision makers make the best decision. Good business analysis is facilitating all the necessary decisions. There are three key components that pull all of this together.

  1. You need to define all the decisions to be made.
  2. You need to know who the decision maker is for each decision. This may be one person; it may be many.
  3. You need to know the criteria, or information, the decision maker(s) will use to make the decision.

Knowing the criteria each decision maker has for each decision to be made is how you determine what information you need to elicit, analyze, and communicate. Once the decision is made, stop analyzing. Once a decision could be made you have done enough analysis.

Easy, right? Not so much. There are many factors at play. For one, it is not always clear to decision makers what their criteria is for each decision. And when multiple people need to make a decision they are not always on the same page. Gaining buy-in from all decision makers takes some work.

The good thing is I’m excited to be delivering a 1-hour webinar via BA Times on this exact topic on May 17th. Please join in so I can get you to think about business analysis in a whole new light!

All the best,

Kupe