• Tag Archives agile

  • 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

  • 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

  • 3 Thoughts For Finding The Voice Of The Customer

    Posted on by Tim

    Teams creating products and services need the voice of the customer to inform their choices. Customers determine value. They will pay for what is an equal exchange of money for products or services.

    What happens when the customers can’t be engaged?

    Do their needs, wants, and desires get considered during development?

    I’m reminded of this simple line from “The Lorax” when I think about customers.

    ― Dr. Seuss, The Lorax

    Their insights are important. Customers are in the driver’s seat, we just seem to forget that fact, occasionally.

    Finding the voice of the customer

    I like simple lists. Easy to read, better for keeping in mind.

    • First, talk with customers
    • Second, survey customers
    • Third, represent customers

    Realistically, we can talk with customers without much trouble. But, sometimes we can’t talk to them.

    Instead, we can survey them. We have to be direct and not steer the survey to our way of thinking. Considering biases, this is tough, but not impossible.

    Once have enough information, we can represent the customer. We can create composite customers who represent many insights our actual customer share.

    It’s all “meta” beyond real customer interaction. Even then, we’re getting a sample of all current and future customers.

    For most of us, it all seems complicated. In reality, it’s not. It’s like deeply listening to family or good friends.

    Customers deserve our attention and time. Just like family and friends.


    📂This entry was posted in Agile Scrum 📎and tagged

  • Scrum Value #3 – Agree Or Disagree, Commit, And Act

    Posted on by Tim

    Part 3 in a 5-part series. This post covers Commitment. Agree or disagree, it doesn’t matter. What does matter is committing.

    The third value;

    People personally commit to achieving the goals of the Scrum Team

    Scrum.org

    One of my former IBM colleagues, says it something like this way.

    “We agree and commit, or we disagree and commit, we just need to commit to action.”

    Mo Shah

    At times, team members fail to personally commit to achieving a state goal. There are many reasons for this. It’s different for each person.

    More frequently, the team fails to set goals. That’s a bit of a “mic drop”.

    Agree or disagree just commit

    Problem-solving is never easy. It is a part of life that is unavoidable. As a result, it takes courage to tackle challenges.

    Gaining team alignment is challenging as well. Defining team goals is worth the effort to avoid friction.

    If there is disagreement about a goal, objective, or outcome then the difference can be worked out.

    A disagreement should not prevent team commitment.

    If Scrum is being properly applied, then changing goals in future Sprints is acceptable to address the disagreement. This goes to the heart of being transparent, inspecting the outcome, and adapting to get a better outcome.

    A wonderful, potential outcome is alignment as work is progressed. The act of moving forward can be a catalyst. As a result, commitment can help in getting past disagreement.

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


    📂This entry was posted in Scrum 📎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

  • Agile Value #3 – See Customers As Allies For Success

    Posted on by Tim

    Part 3 in a 4-part series. This post covers working with customers and clients. Part 1 is posted at this link. Part 2 is posted at this link.

    The third value;

    Customer collaboration over contract negotiation

    Manifesto for Agile Software Development

    Firstly, it is tough working with people.

    Secondly, it is tougher working with customers.

    Thirdly, toughest working with clients and stakeholders.

    Each group has a different investment in the success of a product or service.

    The first group may have a passing interest in the product or service. The second group has an interest in outputs, and maybe outcomes. The third group is the group that cares the most about outcomes.

    Working with customers and clients

    There is a real difference between customers and clients.

    In many cases, customers are “one and done”. They buy the product or service once, twice if it is really good.

    Credit: Merriam-Webster.com

    In fewer cases, clients are “repeat business”. They expect the business to protect their interests.

    Credit: Merriam-Webster.com

    Internal to the business, are stakeholders. In the absence of customers and/or clients, they serve as representatives.

    Credit: Merriam-Webster.com

    Since products and services are being developed for humans, it makes sense to work with the people who use them.

    Have you ever walked through a discount store? Many products that failed in the market find a home in discount racks before getting thrown out.

    Consider the waste created. Enough written.

    Value 1, Value 2, Value 3, Value 4


    📂This entry was posted in Agile 📎and tagged

  • 3 Reasons For Why Team Values Matter

    Posted on by Tim

    Below are the three reasons why team values matter. Just as waves destroy unanchored ships in the safest harbors, unexpressed values leave us disconnected.

    1. Act as a usefulness measure
    2. Serve as a north star
    3. Remind us to be our best

    Onboard the USS ARCHERFISH (SSN 678) we had an emergency underway happen. The squadron and group commander tracked a hurricane heading toward Groton, Connecticut.

    We were tied up to the pier. All the “boats” in port received orders to leave port quickly to avoid the storm.

    I recall getting to the dive point and spending about 48 hours rolling beneath the Atlantic Ocean. At below 400 feet deep, we still felt the power of the hurricane churning above us.

    Our commanders upheld U.S. Navy values. Those principles were “honor, courage, and commitment.”

    They showed courage by sending us to the sea. We honored their courage toward us. We committed to keeping our ship safe during the storm.

    For every team, values matter

    I have been writing this year on values. Agile values. Scrum values.

    This is a post on team values.

    The team can get lost if they don’t define their standards. They may not get lost immediately but over time.

    Actively writing out team principles helps to create a shared identity.

    As well, axioms help to shape positive behaviors. Additionally, they help influence outcomes.

    Anchoring, guiding, and reminding are actions a team can use to maintain objectivity.

    Since none of these are individual or personal, they serve the team. Indeed, the team decides how it wants to define itself.

    2022 is half-finished. I challenge you to look at your team’s values. If they don’t measure up to the team’s expectations, then change them.


    📂This entry was posted in Agile Scrum Teamwork 📎and tagged