• Technology Triumph – Family, Food, Fun, And Video Games

    Posted on by Tim

    Over the Thanksgiving (US) weekend last year, we drove to a town nearby, McKinney, TX. Each year the town host a “Christmas on the Square” event. It’s a big draw for local business and families alike. What is not to like about family and fun?

    This year was different as the weather did not cooperate. It rained most of the afternoon and into the evening. For me, the conditions were perfect as I don’t like crowds.

    For my wife and daughters, they made the best of a wet situation. By the way, “Christmas on the Square” has become a tradition for my wife and girls, not so much me.

    Since none of the stand and few of the stores were open, it turned into a short experience. Or so I thought. The girls grabbed desert and we started for home after 20 or so minutes in the square.

    As we returned to the parking garage, I asked about a place I knew was open; Arcade 92.

    This looks like fun to me!

    Video games connect family and fun

    Since I had not been to Arcade 92, I only could imagine what I was suggesting we do. Given that our daughters are in the teens, I thought this might be a good way to make memories. Boy, was I right!

    So, this brings me to the heart and purpose of the blog. As well, it brings me to the mission statement for Arcade 92.

    From Arcade 92’s website

    For me, the mission statement ties together my intent for this website. Just like gaming with my kids, my hope for this blog is similar. The wording is just a bit different;

    Bring people together by providing a website to connect through experience

    TimDickey.com’s mission

    Here’s to 2023 and beyond!


    📂This entry was posted in Personal

  • 3 Critical Thoughts On Design, Indicators, And Quality

    Posted on by Tim

    Design, indicators, and quality are connected. When we don’t think about them, they are doing their job well.

    I was headed into the Dallas Improving office in June. The photo below is what showed up a short distance from home.

    So, indicators and warnings. Yeah, I considered ignoring the tire pressure light.

    But, I didn’t. I drove back home. Checked the pressure. Inflated the tires. Back on the road.

    This brings me to a question on the first of the three thoughts.

    What indicators or warnings are you ignoring from your teams?

    warning light
    Tire pressure warning light

    Building on my thoughts above, I wanted to pose a different question.

    Working in the product development space, I enjoy having a good experience. While the low tire pressure indication might be annoying from time to time, it is important.

    When I consider user experience (UX) and experience design (XD) I want people to note important information.

    Do you appreciate the value of having clear messaging from the products you use?

    Another angle I considered with the original post was quality products or services.

    Simple Theme – Design, Indicators, and Quality

    My car is 14 years old. It has passed the average age for vehicles operating on U.S. roads.

    The story on product quality is the car is still operating well and has very few noticeable defects.

    Since I bought the car used, I don’t know its full history. I can share that for as long as I have owned it (since 2014) it has spent more time on the road than in the repair shop.

    When quality is builtin, products last. Services are relatively easy to access and use. Routine maintenance keeps them operating well.

    What is your experience with quality?

    To tie this together, good design leads to timely indicators and solid quality. When products and services lack good design, they may fail to deliver indicators and quality.


    📂This entry was posted in Personal Technology

  • Agile Principle #11 – Better Products From Emergence and Self-organization

    Posted on by Tim

    Part 11 in a 12-part series. This post covers how emergence leads to better products.

    Of all the agile principles Blake and I have covered, simplicity is the one I ponder the most. It’s my “most and least favorite”. Why?

    Because of what it suggests in the process of creating products or services. Here’s a good question.

    How do we simplify this release so that it has a value that our client or customer will appreciate?

    The answer lies in the work not done. An outcome of not doing work allows for emergence because there is time to consider the point below:

    The best architectures, requirements, and designs emerge from self-organizing teams.

    Principles behind the Agile Manifesto

    Consider when a painter says, “The canvas compelled me to paint this.” Or a sculpture states, “The rock spoke to me about its ideal form.” In essence, the artist allowed emergence and beauty was created.

    Similarly, products emerge when teams are allowed time to ponder their options. What is notable is the authors mention “self-organizing”.

    In a practical sense, a self-organizing team has experts in different technical and non-technical fields. Emergence can occur when there aren’t external influences or constraints on how the team choose to work.

    Photo by Zoe Schaeffer on Unsplash

    Power of emergence

    For example, when developing software, a business analyst may assist with reviewing a user interface design. Quality assurance testers may work side-by-side with developers. The possible combinations for how a team supports each other are potentially limitless.

    Ideally, the entire team could be engaged in solving the problem at hand. Then they could work in pairs or triplets to bring working pieces together as a solution. The goal is to make sure the pieces fit together to create the whole.

    Additionally, the structures supporting development come from the team instead of being imposed on the team. Architectures and designs flow from requirements as understood by the team working alongside the customer.

    It serves not purpose to work independently of the customer. As well, it is counterproductive to impose structure on teams, as it stifles creative focus.

    To summarize, the people closest to the work learn the right ways to complete the work as it emerges.

    You can learn more about Agile Principles in Part 12 of this series: Reflecting to Improve.

    Principle 1, Principle 2, Principle 3, Principle 4, Principle 5, Principle 6, Principle 7, Principle 8, Principle 9, Principle 10, Principle 11, Principle 12


    📂This entry was posted in Agile 📎and tagged

  • Powerful Stories – What Do Your Battle Scars Inspire?

    Posted on by Tim

    On LinkedIn, I shared a post about battle scars. In the comments, the discussion took on a novel life.

    One response was related to job search –

    Another response was directly related to the original intent –
    A third response hit on using battle scars for motivation –
    The final response touched on my original intent and scaled to writing books –

    Here’s a link to that post LinkedIn post.

    This link takes you to the YouTube video.

    My battle scars

    I use my experiences, and the scars I have acquired, to help teams be better. Better is subjective. For me, it’s simple. For you, it might be complicated.

    One of my favorite phrases is, “God never wastes a hurt.” It’s the same with experiences.

    A powerful tool I learned while dealing with “survivor guilt” from Afghanistan was reframing. Simply, reframing is looking at an experience differently with an objective lens.

    None of us can change the past. We can choose to remove negative emotions from the experience in the present. Once the negative emotion is removed, we can move toward the future with different expectations.

    I’m not going to lie to you.

    For me, it’s been a long journey to get to the point where I could post about this experience.

    My sense is development teams can benefit from reframing after “creative conflict” or moments of “creative friction”.

    There’s more to unpack in a future post.


    📂This entry was posted in Teamwork

  • 4 Concepts That Lead To Better Outcomes

    Posted on by Tim

    Better outcomes are a combination of elements. In Scrum transparency, inspection, and adaptation are the pillars of empiricism. Add in “talk straight” and you have the basic concepts for this post.

    Don’t take my word for the definition of empiricism. You can find it in the Scrum glossary at Scrum.org.

    I value transparency, which led to this post and a #lifeatimproving moment.

    During a quarterly town hall, our CEO Curtis Hite asked for us the lean into the company’s vision. He was transparent about our needs, and he issued a “call to action”.

    Better outcomes and questions

    Here’s my challenge. Ask yourself the following questions.

    • First, does your CEO “talk straight”?
    • Second, do you know what is needed to execute the company’s vision based on transparency?
    • Third, can you inspect the results of progress?
    • Fourth, if the results don’t align with the vision, are you empowered to make adaptations to achieve the desired outcomes?

    When you know the expectations and needs of the organization, you are positioned for planning. Planning then flows into building hypothesis which can be tested.

    Enabling a “fail fast and learn” culture is what Scrum scaffolds and empiricism reveals.

    In effect this creates a feedback loop. You have critical information available. This supports crafting “safe to fail” experiments. As a result, the organization “sees” the results (transparency), inspects them, and adapts them for improvement.

    Alternatively, the company can stop actions that don’t achieve the desired results. This is due to “talking straight” and maintaining transparency.

    About “talk straight”

    In Stephen M.R. Covey’s book, “The Speed of Trust“, he writes:

    “Talk Straight” is honesty in action. It’s based on the principles of integrity, honesty, and straightforwardness. As I said earlier, it means two things: to tell the truth and to leave the right impression. And both are vital to building trust.

    Stephen M. R. Covey


    📂This entry was posted in Personal

  • Scrum Value #4 – We All Need A Little R-E-S-P-E-C-T

    Posted on by Tim

    Part 4 in a 5-part series. This post covers Respect. When we respect each other, we acknowledge our humanity as a team. Each of us is different. We have different experiences. As well, ideas about how to work. This is the space where regard is essential.

    The fourth value;

    Scrum Team members have respect each other to be capable, independent people

    Scrum.org

    When our daughters were young children, I would say to them the following about their friends’ behavior.

    “It’s not right, it’s not wrong, it’s just different.”

    The same applies to our teams. Also, it extends to the organizations where we work.

    Respect each other

    Sometimes we will disagree. That’s OK. In my post about Scrum Value #3, I covered disagreement.

    Never forget we are all human and each person deserves respect. As capable, independent people, we can inspire esteem in our teams.

    How we act toward each other is a key indicator of how much we value our teammates. The language we use is important and how we treat each other inside and outside team interactions.

    We have the power to increase or decrease trust. This is based on how much or how little we appreciate each other.

    To conclude, I like how Stephanie Ockerman lays out this value on the Scrum.org blog:

    Credit to Stephanie Ockerman

    Value 1, Value 2, Value 3, Value 4, Value 5


    📂This entry was posted in Scrum

  • How To Filter Input And Create

    Posted on by Tim

    I don’t know about you, but I struggle to filter input. Especially when attempting to create.

    At time, it’s easier to be distracted rather than focus. Yet, if I want to achieve a goal, I have to get into the zone where I can be creative.

    One thing I enjoy is music. But it’s a specific type of music. For me, I find I can filter out distractions when I’m listening to electronic dance music (EDM).

    I can sense your skepticism. EDM is probably not your thing. That’s OK with me as this post is not about EDM.

    This post is about the formula.

    (creation + input) x (output + outcome) = goal

    Insert EDM themed photo here

    For Focus, Filter Input

    For me, there are so many things that can distract my creative flow. I don’t know about you, but it’s probably similar.

    The needs of my family. The tasks at work. The challenges of my teams.

    It can get overwhelming. Frustration can set in. And yet, there are ways to wrangle the distractions.

    Our brains do it automatically. We’re unable to consciously manage the amount of information radiated around us.


    📂This entry was posted in Formulas 📎and tagged

  • Agile Value #4 – Embrace Change Like Life Depends On It

    Posted on by Tim

    Part 4 in a 4-part series. This post covers responding to change. Part 1 is posted at this link, Part 2 is posted at this link, and Part 3 is posted at this link.

    Have you ever felt stuck? To the point, where there didn’t seem to be any optimal choices, only suboptimal ones? Me, too.

    Often, we want to plan our way out of VUCA (volatility, uncertainty, complexity, and ambiguity). We want to know what we’re doing. As well, how we’re going to get it done.

    When building a new product or service, we can’t plan for how our clients, customers, markets, or stakeholders will respond to what we intend to offer. This brings us to the final Agile Value.

    The fourth value:

    Responding to change over following a plan

    Manifesto for Agile Software Development

    A toolbox for responding to change

    Planning is still essential. Plans help people organize around work. But we cannot afford to waste energy, money, and time once plans are outmoded.

    Ideally, we plan in a way that allows us to respond to emergence. As well, we have a toolbox that helps us be more effective in working through VUCA.

    This is where The Flow System (TFS) is powerful.

    The TFS is like a boat with a competent crew. They have a compass, map, and skills to navigate challenging seas. They are always planning their voyage from one leg to the next, while responding to change.

    TFS equips organizations with the tools that include approaches, methods, and techniques that enable and scaffold change.  Additionally, all tools have utility, but some limits need to be identified before using them.

    Think of a hammer, nails, and screws. Using a hammer to pound nails works, but not so much for the screws. The concept in operation here is bounded applicability. Choosing the right tool for the right job.

    It is equally as important to know how to connect tools for a multiplying effect within an underlying context. This helps to curb the enthusiasm for prescribing a common framework and shifting the organizational design to all teams.

    Another way to frame this might be TFS is enterprise-level DevOps! Like DevOps, TFS eliminates, mitigates, and resolves constraints to optimize the flow of value through the entire organizational system. Based on where business is today, TFS should be a part of future conversations.

    To conclude, TFS aligns with Agile Value #4.

    Value 1, Value 2, Value 3, Value 4


    📂This entry was posted in Agile The Flow System (TFS)

  • Show Me The Money With Value Streams

    Posted on by Tim

    Back in mid-April of this year, I was talking to Nigel Thurlow about the future of Agile and value streams. We were catching up as he has been assisting a European client and had returned from spending some time overseas.

    As a student, I like talking with Nigel. I learn more about Lean, The Toyota Production System (TPS), and other concepts that inform my work in the Agile space. At times, we even agree to disagree!

    One of the challenges enterprises face is making their value streams visible. Another way of putting this is “getting from quote to cash.” Hat tip to my sales readers!

    If you aren’t familiar with the concept of value streams, I have a couple of references for you to consider (shown below).

    Learning to See by Mike Rother and John Shook
    Value Stream Mapping by Karen Martin and Mike Osterling

    Teams and value streams (VS)

    VS’s help teams see where work is delayed. Hand-offs waste time and the mapping process make those delays visible.

    When teams can see where work is constrained, they can fix the constraint. The result is an increase in workflow.

    But workflow increases are a part of the story. Teams must go deeper.

    They must explore the contexts that influence their work. This is where The Flow System (TFS) assists.

    Linking the philosophy of the Manifesto for Agile Software Development and TFS is critical as well.

    In future posts, I will cover the triple helix of TFS. Writings on complexity thinking, distributed leadership, and team science will follow!


    📂This entry was posted in The Flow System (TFS) 📎and tagged

  • How To Forge Teams By Deliberate Discomfort

    Posted on by Tim

    Using deliberate discomfort to make teams is what makes the U.S. military. Since I served in the U.S. Navy, I can only speak for my service branch.

    The more elite or special a unit is, the more difficult the process becomes for a trainee to join the unit. Most people think physical exertion is a hurdle to get over.

    In my opinion, the mental challenges are far tougher than the physical barriers.

    To join the submarine force, I need to have a psychological evaluation for mental fitness. Again, I was evaluated for mental soundness to support special operations units in combat.

    Yes, there were physical components involved in the qualification and selection process for both areas. For me, those were not the same as a special operator who would go through Basic Underwater Demolition School (BUDS).

    The “shared suffering” involved in my inductions into these communities left me wanting more. Not in a sick, twisted way, but wanting for closeness that comes with the processes.

    My deliberate discomfort

    After initial training at the Basic Enlisted Submarine School (BESS), I was assigned to the USS ARCHERFISH (SSN 678). Fun fact, I was filmed as part of the documentary, Submarines – Sharks of Steel.

    Screen grab Submarines Sharks of Steel
    Submarines – Sharks of Steel video

    My toughest test was on the ARCHERFISH. It involved two years of qualification and training.

    Qualifying is a “make or break” choice. You either thrive or dive. You can’t tread water.

    I chose to thrive. I completed the process in a year; by putting the time in, studying for hours in my off-duty time.

    I finished the work at sea. Oh, the stories I could tell! As the saying goes, “What happens in Vegas, stays in Vegas.”

    Submarines are a crucible that test adaptability and I passed. I learned to perform under pressure.

    Deliberate discomfort as a non-useful body (nub) turned to shared suffering as a qualified submarine Sailor. Diving and driving submarines are not for the faint-hearted!

    Bringing discomfort to business

    I’m working on how to simulate the identity forging process for business.

    This post frames my experience. More will follow!


    📂This entry was posted in Teamwork Training 📎and tagged