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.
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.
- Thinking Fast and Slow – Daniel Kahneman
- Predictably Irrational – Dan Ariely
- 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 – Dave.Bieg@pmi.org, Joy.Beatty@seilevel.com
Elizabeth Ayer - Spreading the Love: 8 Ways to magnify the Impact of User Research
My 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:
- 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.
- How much is enough, how is the user solving the problem today, how should we test this?
- 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.
- No more UX virgins - Everyone does this. No one gets a free pass. You need to watch your users use the system.
- 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.
- 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)
- Agree for interpretation - Get a shared understanding. After the meeting debrief and make sure everyone is on the same page.
- Make it available. Write it down.
- Publicize the work. Allow people to consume at their leisure - More of a pull method, not a push method.
- 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.
- 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.
- Lead time to changes – Keeping the lead time to implement changes down for the highest priority at a moment in time.
- Release frequency – Release as frequently as possible/acceptable.
- Time to restore service - If something goes wrong, get it back up quickly.
- 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.
- 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?
- We are not building websites.
The division that manages HP printer firmware improved their deployment schedule. By the way, firmware is not a website.
- 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.
- 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:
- Our culture sucks
- 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
I 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!
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.
- Customer Advocate – Be the “face” of the organization. Tease out the real requirements. Get continuous feedback, keeping the customer “in the loop”.
- As Designers – Define the solution. Understand roles and personas. Elaborate end-to-end solution use cases and activities within them.
- As Orchestrators – Take a Systems View. Apply economic thinking to define MVP and iterative delivery plan. Collaborate with engineering to determine best alternatives.
- As Engineers – Propose and evaluate alternatives. Explore and validate technological assumptions.
- 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
How 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.
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!
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"?
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.
- What is the project Great question to get the conversation started?
- 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.
- 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.
- What is the impact to your organization? Is it worth solving
- How much is that problem costing your organization? Is it big or small - how much should we spend to fix the problem?
- 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.
- 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.
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.
- Context – What are the facts of the context…what happened?
- Observation – What did you observe?
- Impact – The impact of the conflict on you or others.
- 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.
Me – 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.
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.
- We look for someone or something to blame
- Justify – We make up stories
- 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!
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.
- Intent – The leadership defines the intent or the mission. (Thinking)
- Debrief – The intent is shared with everyone. This is your time to ask questions. (Some Thinking)
- 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.
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.
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
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:
- Drawing helps see the big picture. Pictures tell us so much more than words.
- Drawing heightens engagement. People are more engaged in a conversation when someone is up drawing.
- Science shows that it helps you think strategically, tactically, and creatively.
- It helps you get on the same page faster. Maybe you can have faster meetings.
- It addresses all learning styles. Reading, visual, auditory, and tactile.
- 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!
You can tweet Angie and Talia - @Doyle_Angie & @SketchingSM
I am off to day 2.
All the best,