• Category 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


    Agile 📎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


    Agile The Flow System (TFS)

  • 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


    Agile 📎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.


    Agile 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


    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


    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.


    Agile Scrum Teamwork 📎and tagged

  • Plan Vs. Act – Rise To The Challenge

    Posted on by Tim

    As humans, we want a degree of certainty day-to-day. We plan for how we want our actions to work. And yet, all the planning in the world fails if we don’t act. We have to act, to rise to the challenge.

    I wrote about a quote from Dwight D. Eisenhower last year. You can check it out here.

    2022 is nearly half complete. What actions have you taken professionally and personally this year?

    In the agile product and service development space, teams retrospect after completing timeboxed work.

    As humans being, we should do the same. Retrospective looks back help us evaluate our progress and tune our performance.

    Actions yield results. It takes courage to look at those results and begin asking questions.

    Time to rise to the challenge

    Normally, when teams perform a retrospective, three questions are asked.

    • First, what went well?
    • Next, what did not go well?
    • Last, what do we want to change?

    If the only action being taken is planning, what results or outcomes can we expect? Plans don’t magically happen to get executed.

    James Clear wrote about motion and action together in “Atomic Habits”. Importantly, know there’s a difference between the plan (which is motion) and the work (which is action).

    Cover of Atomic Habits by James Clear

    It’s not enough to get thoughts on paper. To clarify, follow-through is essential.

    As a result, action is required to increase or sustain momentum. Finally, consider this quote.

    It’s easier to act your way into good thinking than it is to think your way to good action.

    Bill Gove, the father of professional speaking


    Agile Scrum Teamwork 📎and tagged

  • The Magic of Business: It’s Local, Human, and Connected

    Posted on by Tim

    I’ve been sharing this concept for the past several months with friends and colleagues. All business is local business. Humans do business with humans. It requires us to build and grow trust to be successful in business.

    Business, by its nature, is both relational and transactional.

    Firstly, relational in that people do business with other people. I recognized technology is an intermediary in the business process. Amazon anyone?

    Business deals are made via human interaction, for instance.

    Secondly, transactional in that people are looking for an exchange of value. You have the money and I have the experience and knowledge to solve your problem. We exchange things of value like my ability to solve your problem with the money that allows you to get your problem solved.

    Given the advances in technology, business is now connected. And yet, business is also disconnected at times.

    I’ve learned, throughout 2020 and 2021, that technology is a double-edged sword.

    For some sales, it made work more challenging. High-touch, and relational sales have been tested. Trust is a key to relational sales and building it virtually is yeoman’s work.

    For other sales, technology is a blessing. More computers and home office materials were sold than in prior years using technology.

    Tiny Tesla technology

    Humans do business with humans

    Thankfully, we’re good at figuring out how to make business happen. When high value business deals get made, they’re done with other humans.

    We trust the people we do business with. Thus, much of the business being done is negotiated locally. As a result, people continue to build and grow relationships with other people to create value in business.

    Technology is an enabler to help people be successful in business. It is not the other way around.

    So here is my challenge to you. If you prefer technology over working with people, start taking steps to become more comfortable working with people.

    As an introvert, I know how tough it is to connect to people. I work at connecting daily with people. Connecting is a skill anyone can learn. You need to be willing to stink at it before becoming good at it.

    Believe me, it will be worth the effort and time!


    Agile Teamwork 📎and tagged

  • Agile Principle #5 – Motivated People Get The Job Done

    Posted on by Tim

    Part 5 in a 12-part series. This post covers motivated people.

    In part four of this series, Blake McMillian covers Collaboration can Prevent Waste. Rightly, he points out, “Businesspeople and developers must work together daily throughout the project.”

    Consequently, this is key concept teams need to understand. Also, those people need to be motivated in their work.

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    Principles behind the Agile Manifesto

    Work engagement is a challenge today. A Gallup article points to the prior statement.

    “Ways of working” and where work is done have changed. As a result, Principle #5 is more important today than at any time in the past.

    Truly understanding this principle helps teams navigate uncertainty. So, what does that look like?

    Enabling motivated people

    The last part of the Principle is key to granting the first part. It breaks down into three points.

    • “Give them the environment . . . they need”
    • “Give them the support . . . they need”
    • “Trust them to get the job done”

    If any one of these three points in bold is missing, then the team suffers. Consider these minimum requirements for motivation.

    What do these, environment, support, trust, look like to a team?

    The list is long and would take forever to fill in this post. However, I consider the following, for me.

    • First, low to moderate pressure (environment)
    • Second, genuine assistance (support)
    • Third, action on feedback (support)
    • Fourth, short, quick status reports (trust)
    • Fifth, fun and engaging (environment)
    • Sixth, open to feedback (trust)

    I’m curious, what is missing from this list? Please add your comments.

    Blake brings us to principle #6, in this post – “How We Communicate Matters“.

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


    Agile 📎and tagged