• Tag Archives teamwork

  • 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

  • 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

  • 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

  • What Would Bob Ross Do, Say, Or Think?

    Posted on by Tim

    Have you ever pondered what Bob Ross might do, say, or think? I have, more than once.

    Bob was a creator and had a painting show on the U.S. Public Broadcasting System for decades. He was known for painting landscapes and spoke in a smooth baritone voice.

    Funko Pop Bob Ross
    My Bob Ross reminder

    Which brings me to the formulas:

    (intent + idea) x (belief + action) = creation

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

    Note, that I carry over “creation” from one equation to the next. As Bob would say, “There are no mistakes, only happy accidents.”

    Allow me to explain. I’m not a “maths” guy. I do see a correlation between creation as an individual act and creation as a variable in team performance.

    Do, say, or think

    Firstly, creators think a thing before they take action.

    Secondly, some creators talk about the thing to gain insight on what shape the thing might take.

    Finally, the act of doing to bring a thing into existence is step in a simple process.

    I’ll admit, it’s probably an oversimplification. If you want to provide more detail, you can comment on the post.

    By the way, my SEO analyzer and tendency to organize alphabetically placed an enabling constraint on the headings.

    When teams create, they should, collectively “do, say, or think” their way through their processes. It helps develop shared understanding of what they plan to create.

    Separately, it can help them sort teamwork from task work. The difference between work is a topic for a future post.

    To conclude, creation and be an individual and team function in my equations.


    📂This entry was posted in Formulas 📎and tagged

  • Agile Principle #9 – Focus On Technical Excellence And Solid Design

    Posted on by Tim

    Part 9 in a 12-part series. This post covers technical excellence and solid design.

    In part eight of this series, Blake McMillian wrote about A Sustainable Pace For All. He challenges us to expand the context to consider how sustainable pace goes beyond just the people creating the product.

    In this post, we’re looking at technical excellence and design.

    Continuous attention to technical excellence and good design enhances agility.

    Principles behind the Agile Manifesto

    For me, technical excellence and solid design cannot be separated. They go together like a peanut butter and jelly sandwich.

    Not like a peanut butter and ham sandwich. Although, that might be a combination somewhere in the world.

    So, what does technical excellence look like? Or even better, what is good design?

    The standard consulting answer is, “it depends.”

    Maybe there are better questions we should be asking. Notice, “continuous attention . . . enhances agility.”

    What could be removed? How can this be simplified? Can we streamline this workflow?

    The questions above, to me, seems to focus attention to enhance agility.

    Technical excellence and solid design

    In researching for this post, I found two websites worth reviewing.

    As a car guy, I’ve referred to Toyota and Porsche in past posts. In this instance, I’ll note them again. This time based on Agile Principle #9.

    First, Lexus and its design award. Since 2013, Lexus (a Toyota Motor Company brand) has sponsored the award and the entries are inspiring.

    Lexus Stories webpage

    As “Stories” on the Lexus website, you can look at the source page by clicking here.

    Second, Porsche Design which is a lifestyle brand. It takes the inspiration from Porsche automobiles and extends it to other products.

    Porsche Design U.S. homepage

    Click here for the Porsche Design website.

    Two approaches that build on the concepts of this blog post. Both building on their histories around their products. How did Lexus and Porsche get to where they are today?

    I assess it is continuous focus on technical excellence. They didn’t lose sight of their product and service technical or design aspects.

    Neither should we.

    You can learn more about Agile Principles in Part 10 of this series: Simplicity is not easy.

    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

  • Take Bold Action On Beliefs For Results

    Posted on by Tim

    Fear is a terrible thing. It paralyzes us from taking action on beliefs. But, without action, our beliefs are basically worthless.

    “It’s easier to act your way into good thinking than to think your way into good action.”

    This was a quote used to wrap up “Plan Vs. Act – Rise To The Challenge.” In the context of this post, it is part of the formula below.

    (intent + idea) x (belief + action) = creation

    Beliefs or mindsets frame how we navigate life. They influence how we connect with people. As well, they enable or inhibit our creative pursuits.

    Bold action on beliefs

    In a team context, action is what achieves outcomes.

    Action is also what serves as the “engine for creation.” In “177 Mental Toughness Secrets of the World Class”, Steve Siebold wrote,

    “The goal of world-class performers is to solve problems fast and move on to solving
    bigger, more complex problems. After all, the great ones know business and enterprise
    are based on problem solving. It’s the cornerstone of commerce.”

    Steve Siebold
    Cover of 177 Mental Toughness Secrets of the World Class

    This is true for teams as well. Problem-solving is action.

    Bigger problems take bolder action to solve. All written, this is where the rubber meets the road in the creative process.


    📂This entry was posted in Formulas 📎and tagged

  • 5 Steps For How To Develop A Confidence Stack

    Posted on by Tim

    Countering imposter syndrome is tough. The steps below are ways to develop a confidence stack and they are worth a read.

    1. Be willing to suck for a while
    2. Find a coach or mentor who will push you
    3. Do the reps
    4. Take small, measured risks
    5. Rinse and repeat

    The concept of stacking isn’t new. If you ever played with Lego blocks, you know how stacking works.

    Lego Technic BMW motorcycle

    By design, a stack adds up to form something out of parts. The saying, “the sum of the whole is greater than its parts.” reveals a result of stacking.

    When I was searching for a way to break from childhood to adulthood, the military provided a way. The process of becoming a Sailor is stacking by building confidence based on an old and new experiences.

    I understood American history from school. I stacked Navy history and tradition on my previous learning.

    Using the same process, the Navy stacked on physical education. As well, it stacked on basic math and added basic engineering.

    Develop a confidence stack

    We all have abilities and skills. Some we are born with. Others we develop over time.

    As we learn, we build or stack on basic structures. As a result, each new concept connects with a prior concept and triggers a neurochemical response.

    The five steps listed above acknowledge learning is tough. As we get older, we become risk-averse.

    Some avoidance might come from fear. Other exclusion might come from ego. It doesn’t matter where the response comes from, it has to be evaluated and understood.

    Our brains are conditioned to side-step danger when it’s possible. However, most of life in modern times is not dangerous in the pure sense.

    So, we have to make an effort to override survival instinct. In effect, we’re rewiring instinct with logic to build confidence by taking calculated risks.

    It all starts with willingness. Are you ready to suck at something new to build confidence?


    📂This entry was posted in Teamwork Training 📎and tagged

  • Agile Principle #7 – Progress Is Things Working Right To Delight

    Posted on by Tim

    Part 7 in a 12-part series. This post covers products and services that are working right to show progress.

    In part six of this series, Blake McMillian wrote about How We Communicate Matters. He explained how communication has changed over just the last few years. Highlighting effectiveness, quality, and richness of communication impacts team outcomes.

    Effective communication influences the theme of this post.

    Working software is the primary measure of progress.

    Principles behind the Agile Manifesto

    In the physical world, it’s hard to get away with manufacturing products or providing services that don’t work. Conversely, building software is a bit different story.

    Maybe it’s because software is intangible in a sense. The intangible nature of software is a post for another day!

    Yet, it doesn’t mean teams don’t build working software. It means that working software is a key measure for teams to assess themselves.

    For a moment, I’ll pick on Microsoft. I upgraded to Windows 11 and understood not all the features or functions would work like Windows 10.

    I didn’t expect my speakerphone to fail along with the “reduced functions” line. To be fair, I had the warning and accepted the risk.

    I’m sure updating plug-and-play drivers are in the backlog, somewhere.

    Things Working Right

    In general, many products and services join the market working right from their introduction to customers.

    But, this is not always the case. Sometimes, products and services are available working somewhat right.

    I recently came across an article about construction updates to Penn Station in New York City. The writer highlights a somewhat right change to the station; $1.6 Billion NYC Train Station Doesn’t Have Enough Seats (msn.com).

    Moynihan Train Hall @ Penn Station, New York City, New York, United States

    Think about the story above the next time your team proposes just releasing a product or service that “might” work or is “somewhat” right. Is it worth the consequences?

    Missed opportunities abound due to avoidable misses. When stuff works right the first time, we all win.

    If a working product or service is the measure of progress, then trying to avoid complicated solutions should be a target. At times, waste is created simply because the solution gets over-engineered from the start.

    Consider this when designing and building the next product or service, regardless of type.

    You can learn more about Agile Principles in Part 8 of this series. 

    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

  • A View Into You, You Are One Person Not Two

    Posted on by Tim

    Have you ever noticed that some people seem to be one person at work and another in their social life? I found it odd until I started reflecting on my behavior. I discovered you are only one person.

    How I behave at work, on my team, should be no different than when I’m at home with family and friends. I did some research on this and found a term to describe the behavior.

    The behavior is called “cognitive dissonance.” Feel free to read the article at your leisure.

    The “mind friction” between the differing behaviors leads to challenges that impact relationships.

    Teams are affected by the members’ interactions. As a performance indicator, it is worth looking at social and work behavior. There might be a weak signal that points to a degree of “mind friction”.

    One person, many adaptations

    It’s worth noting that team members do adapt their behavior to the support team’s performance. I don’t consider this a concern unless someone is miserable working on the team.

    Adaptation helps us to survive and thrive in our environment. We see it in nature with camouflage patterns. The tricky part is when the adaptation is a move to an extreme.

    Extreme adaptations can lead to “mind friction”. As a result, the team can help its members self-adjust if awareness is increased around behavior indicators.

    No one wants to be miserable on a team. It’s up to the team to look out for its members.

    Consider this, I’m not a carpenter. And yet, I wanted to work with my daughters to create something.

    I didn’t disagree with their ideas about how we would build a “rock box”. Instead, I accepted whatever came of the project.

    wooden box
    Finished rock box project

    I avoided trying to be something I am not. We owe it to our teams to do the same.

    Let’s not force them into changing against their will. Instead, help them adapt their abilities and skills to support team outcomes.


    📂This entry was posted in Teamwork 📎and tagged