• Tag Archives scrum

  • Scrum Value #2 – Focus On The Work Ahead

    Posted on by Tim

    Part 2 in a 5-part series. This post covers Focus. Distractions and busyness slow progress. Being busy is not being productive. Creative teams must focus on the work ahead.

    The second value;

    Everyone focuses on the work of the Sprint and the goals of the Scrum Team

    Scrum.org

    Given the fact that Scrum is an additive framework, processes outside Scrum can be used to help focus the team.

    This means making changes to how teams work. It means creating and maintaining working agreements.

    Restoring focus on the work

    Discovering what improves team focus is important. Unfortunately, the focus is not generally considered a priority action or behavior.

    Here is an example of how refocusing might happen.

    Some companies start applying Scrum with teams that are spread across several projects.

    If transparency is supported, then context switching is revealed. As a result, a choice is on the table for leadership.

    In some cases, that choice leads to having dedicated teams.

    Additionally, fear can cause teams to refocus. It’s not preferred, but it is effective.

    Alternately, making work visible enables focus. Because having the work physically or virtually in front of the team helps improve focus.

    Finally, look for opportunities to help teams focus. As a result, you will be surprised at what you find when you look!

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


    📂This entry was posted in Scrum 📎and tagged

  • For Outstanding Results, Leverage The Power Of Intent

    Posted on by Tim

    Intent is a powerful tool for problem solving. In the hands of a focused, skilled team, the power of intent yields outstanding results.

    Returning to the formulas in my prior post, intent is one of the elements needed for creation.

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

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

    The basic definition of intent is a clear, formulated plan to achieve, do, or complete.

    When solving problems with technology, there is a focus on what the solution will do when it’s complete. Stating intent up front allows the team to focus on the work required in front of them.

    While I was considering how I could break down these posts, I focused on intent. I plan to provide examples of how the formula elements combine to equal something greater.

    Building on the words in the formula from definition to example was/is the start. It seems to be the most straightforward way of getting the concepts on paper for discussion and refinement.

    Power of intent

    In the military, the concept of the commander’s intent has been translated to the leader’s intent for the modern workplace.

    Two authors have tackled the subject with their respective book. Firstly, L. David Marquet with “Turn The Ship Around!” Secondly, Donald E. Vandergriff with “Adopting Mission Command.”

    Cover of Turn the Ship Around! by L. David Marquet

    When team intent is expressed, the team’s direction is set. As well, intent can also come from within the company or from clients and customers.

    I like to visualize intent as a compass. It points the team in the right direction. Yet, it doesn’t tell the team how to get to a specific result.

    Intent is the north star pointing toward creation.


    📂This entry was posted in Formulas 📎and tagged

  • Agile Value #2 – Make Solutions Work

    Posted on by Tim

    Part 2 in a 4 part series. This post covers making solutions work. Part 1 is posted at this link.

    Have you ever bought technology that doesn’t work? For instance, It could be a product or services that fails from day one. In fact, I’m not happy when technology fails.

    The Manifesto for Agile Software Development authors got this right. Generally, I don’t read the manuals for most of what I buy. That is to say, if everything works out-of-the-box, then they are not needed.

    Critically, we arrive at the concept of making solutions work.

    The second value;

    Working software over comprehensive documentation

    Manifesto for Agile Software Development

    Better documentation will not help me understand crappy products and services. As a result, my preference is just enough written down to help me understand how the work was completed.

    Reqs, Specs, Designs, Oh My

    As a former project manager, I recall the days where I was chasing down artifacts. To be sure, it was a pain to get all the documents together for review, approval and sign-off. Granted, that has approach changed over time and I’m grateful for it.

    There should always be documentation. And yet, it shouldn’t be 100s or 1000s of pages written to never be read again. To be sure, this is about making solutions work, not writing multi-volume epic no one will ever read.

    Foundationally, most developers like to solve problems. But, they tend to be uninterested in detailing how the work got done. There isn’t anything wrong with that approach. However, there needs to be a balance between the solution and documentation.

    Notwithstanding, different approaches are used so that the right information is gathered for solution support. For examples, see the short list below:

    • Wikis
    • How-to guides
    • Quick reference guides
    • Simple diagrams
    • Conversation summaries

    Remember, writing is a pain for some people. For others, they enjoy the art of capturing details on paper. Consequently, forcing work on someone is isn’t gifted for them will only make them miserable.

    Pursue Technical Excellence

    Firstly, understand that technical excellence isn’t perfection. It is about getting the work done with an eye on it being done well.

    Secondly, keep quality in mind. If the work can be done with minimal waste, make the solution work.

    Lastly, look for the simplest way to solve the problem. To put it another way, build it like a five-year old builds Lego.

    In conclusion, pursue technical excellence while minimizing waste and complexity. This goes for the solution and the documentation.

    Value 1, Value 2, Value 3, Value 4


    📂This entry was posted in Agile 📎and tagged

  • How Ideas Become Reality In A Formula

    Posted on by Tim

    I’ve been working on two formulas to explain how ideas become reality.

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

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

    If there is a scientific explanation to these formulas, then I welcome the help validating my hypothesis.

    As a “specialized generalist”, some concepts or ideas just pop into my mind. Thankfully, there are people who are smarter than me that can validate my work.

    You might be wonder then, what is the purpose of this post?

    It’s about teams, creative teams to be specific.

    There is a good bit of discussion on “key performance indicators” and “objective key results” in business. John Doerr wrote a book on the subject, “Measure What Matters.” Jeff Gothelf has written several articles on the topic as well.

    I’m not going to rehash KPIs and OKRs in this post. John and Jeff have already done an outstanding job on of explaining those topics.

    Instead, I’m going to start sharing my thoughts on how stuff gets created by teams.

    Ideas become reality

    Each person is blessed with creative instincts. I have to think these were developed for human survival.

    So, looking at the first formula, creation = idea + intent (belief + action), here is my take. Ideas build on each other, sometime based on improvement and utility. Sometimes novel ideas come to mind.

    I get inspired by elegant design. Minimal “flash” and maximum “performance” are concepts that really move me.

    In my opinion, two companies that do this well are Apple and Porsche.

    2022 Porsche 911 GT 3

    So, how does a team get aligned around ideas?

    • Firstly, getting them on “paper”.
    • Secondly, debating their merits.
    • Thirdly, assessing what is possible today versus what is possible in the future.
    • Finally, choosing the ideas that can be acted on quickly with low risk and low cost to test their validity.

    This is an over simplified list to kick start the next conversation point on intent. Enjoy and please share your thoughts with me!


    📂This entry was posted in Formulas 📎and tagged

  • Agile Principle #3 – Get Splendid Products And Services More Frequently

    Posted on by Tim

    Part 3 in a 12-part series. This post covers frequent delivery.

    In part two of this series, Blake McMillan covers Change as a Competitive Advantage. He covered this the point that stands out, ” . . .we balance the speed with the value by avoiding churning out things that no one wants. . .”.

    As well, “We are trading time for potential value. That intense focus on value is a differentiator even though it seems like common sense.” Blake hit on avoiding waste and time value, two concepts that we should and can maximize.

    This leads into the third principle:

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    Principles behind the Agile Manifesto

    This is one of the more challenging principles to execute. Frequent delivery requires a thinking shift for creating products and services.

    Now, conversations focus on what can be built in a short time to see if it meets customer needs. As well, it puts creative people and people who will use the product or service into an uncomfortable place.

    This place enables discovery. The process inspires learning.

    A result, is going back to what worked before. The ages old process of open chats and hand drawn sketches before doing work becomes new again. We seem to have lost touch with that fact.

    Doing a search of incremental product delivery show several drawings to show the point.

    Henrik Kniberg drew a picture that mostly captures the intent of incremental delivery. It can be found on his blog at this link.

    Frequent Boat Delivery

    The drawing below shows a different view of the point.

    Incremental boat delivery

    The boat is useful as built. The design is sound and will keep the customer dry. Given enough time and human effort, it will cross a lake.

    Look at how the boat is powered. The power method shows magic of frequent delivery. With each new increment, the boat gets closer to the customer’s needs and wants.

    The final increment is a boat powered by an inboard engine and an outboard propeller. As well, steering is also delivered incrementally.

    For a moment, consider the sketches above as concept prototypes. As a result of customer conversations, these sketches evolve one after another. A next step then is a physical prototype.

    Frequent delivery doesn’t have to be “the real thing in real life”. Smaller, less significant releases matter more than a new, full-size boat in the parking lot.

    Testing an idea before it reaches production helps to validate understanding of what the customer needs and wants. Better to make a small investment in time and money than build a hotel like the one below which is unfinished in North Korea.

    Ryugyong Hotel, North Korea – Photo credit Associated Press

    Blake moves us on to collaboration. He covered Principle #4 of the series at this link.

    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 Scrum 📎and tagged

  • Embracing Weakness Is The Essence Of Human Experience

    Posted on by Tim

    In high-performing teams, embracing weakness is important to team success. If everyone thinks they’re a star performer, then no one will be vulnerable in assessing their abilities.

    True strength is in accepting facts and asking for help to compensate for weakness.

    None of us are strong in every ability and skill needed to get work done. In fact, teams are created to bridge gaps in knowledge, skills, and abilities (KSAs) that one person can’t bridge!

    This is a hard concept for top performers to grasp. In both the military and business, more teams succeed than soloists in complicated and complex work. This fact does not diminish individual effort. It does highlight the need for cross-functional work.

    Inside AT&T Stadium in Dallas, Texas, USA

    A struggle teams have is getting out of denial about weakness. That’s why people fail at recovery programs. Separately, teams fail at achieving high performance for the same reason, denial.

    How To Begin Embracing Weakness

    The following list is “thought food” and it is not comprehensive. It is a starting point for transparent conversation and a driver for outcomes.

    • Firstly, get out of denial. Confront reality and add up team strengths and weaknesses.
    • Secondly, start planning ways to minimize or narrow gaps.
    • Thirdly, ask for outside assistance if the team’s weaknesses can’t be narrowed by the team.
    • Fourthly, find and remove work that the team can’t be completed by the current members.
    • Fifthly, communicate success and note learning. Do this early and often around finished work. Communication includes stakeholders, customers, and clients.
    • Finally, celebrate success, build on strengths, and shore up weaknesses through continuous reflection and improvement.

    Make sure every team member is heard. Often the quietest people have the powerful ideas and an ability to find gaps.

    Focus on listening to what is said and what is left unspoken. Be a detective, look for clues, because weaknesses change over time.

    Remember to have fun! The joy is in the journey, not the destination.


    📂This entry was posted in Agile Teamwork 📎and tagged

  • Need A Creative Spark? Pursuing Excellence Is Better Than Perfection

    Posted on by Tim

    While browsing my LinkedIn feed I saw a post by Daniel Pink. I can relate to what Daniel is saying. Pursuing perfection is not the same as pursuing excellence. I’m a recovering perfectionist.

    The associated article unlocks a concept that I didn’t have words to describe.

    Striving For Perfection, Rather Than Excellence, Can Kill Creativity – Research Digest (bps.org.uk)

    For me, this quote says it all:

    The results revealed that the more participants strove for excellence, the greater originality and openness to experience they showed. In contrast, the more perfectionist participants were, the fewer original ideas they had and the less open to experience they were. This suggests that an element of flexibility not present in perfectionism can improve our creative thinking.

    Emily Reynolds

    In product and service development, teams need to be creative. I encounter the “perfect” conversation weekly. There is a magnet on my dry erase board to remind me, Done > Perfect.

    Pursuing Excellence Over Perfection

    Engineering is an exacting profession. As engineers, people strive for perfection due to many factors. If lives are at stake, then it could be argued that perfection is needed. And yet, nothing is ever perfect.

    We live in a complex adaptive system the pulls toward chaos. We strive to order chaos and fail. So, if we can’t control the weather to create perfection conditions, why try to perfect every product and service going to the customer?

    This is where excellence steps in. In my opinion, excellence is knowing perfection cannot be achieved. And yet, excellence brings creators close to perfection by help them keep open minds.

    Taking this one step further, excellence help frame answers to questions. Instead of saying “it’s impossible”, excellence says, “what if it were possible and how might that look?”

    If focusing on excellence is a key to creating quality, shouldn’t that be the focus? It’s something to think about.


    📂This entry was posted in Agile Teamwork 📎and tagged

  • Scrum Value #1 – Courage To Tackle Tough Challenges

    Posted on by Tim

    Part 1 in a 5-part series. This post covers Courage. Problem solving is never easy. It is a part of life that is unavoidable. As a result, it takes courage to tackle challenges.

    The first value;

    Scrum Team members have courage to do the right thing and work on tough problems

    Scrum.org

    Courage takes different forms in varied contexts. When I was in the military, it was doing work I was afraid to do. I chose to sail onboard submarines. As well, I chose to deploy to Afghanistan.

    In business, our context is different. Courage is overcoming the fear of speaking up when an observation could be unpopular. It is telling the team to stop work to fix a defect that leads to unsafe conditions.

    The examples above cover doing the right thing.

    Working on tough problems is less clear.

    I’ve heard teammates tell me, “It impossible to solve.”

    My response, “You’re probably right. If it weren’t impossible, what might the solution be?”

    That response take courage as I’m committing myself to exploring options and asking for ideas. It is painful to get past resistance and reaction.

    How To Find Courage To Tackle Challenges

    In my observation, finding courage is a series of small steps. I resolve myself to stink at what I’m seeking to find. I commit to doing small acts that require courage then build from one action to the next action.

    For example, Toastmasters meeting have a section called “Table Topics”. For two minutes a speaker talks about a random topic base on a card picked by another club member. It is a way for new members or visitors to act courageously and face public speaking fear.

    As well, Toastmaster clubs promote psychological safety for new public speakers. The clubs are gears to overcome fear through positive feedback. It is an amazing way to, step-by-step, exercise courage.

    Consider example above the next time the team is faced with a challenge. Use it as a starting point for developing courage to tackle challenges.

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


    📂This entry was posted in Scrum Teamwork 📎and tagged

  • How To Spark And Sustain Humane Creativity

    Posted on by Tim

    Right before the Thanksgiving (US) holiday, I had a fantastic conversation with an Improving colleague. Lemont Chambliss and I were discussing Norm Kerth’s “Prime Directive” and wandered onto the concept of humane creativity.

    I want to give credit where it is due. Lemont mentioned humane when we were discussing how we arrived in the Agile product and service development. I mentioned creativity, so this is how I arrived at the concept of “humane creativity”.

    To be clear, Lemont and I met on our professional journeys in a similar fashion. The result has been, for me, eye opening and consciousness expanding.

    In my opinion, we pursue technical solutions to complicated and complex problems without much thought for the people who solve the problems. I might be wrong, but this is the impression I get while reading the Manifesto for Agile Software Development.

    As well, I get a similar impression from Toyota as well. It has an entire section on its website the outlines the philosophy and vision behind the company. Much of Toyota’s focus is on how humans build for humans.

    Humane Creativity Is The Ideal

    First, I’m not naïve enough to believe any business can create a culture where humane creativity is pervasive. Second, company culture changes over time. It may start as ripe for innovation and then become toxic and then get shifted back with tremendous effort. Finally, culture that support invention can be quickly destroy as it requires elements of positive intent, mutual trust, psychological safety, and other factors.

    My encouragement is work hard to create and nurture positive culture. If it’s at the team level, great. As an executive responsible for a business unit or department, wonderful. As well, board members or senior executives have power to sustain the right environment.

    Culture is everyone’s responsibility to build and support. In conclusion, take charge of making the culture ripe for humane creativity.


    📂This entry was posted in Agile 📎and tagged

  • Agile Value #1 – People And Tools

    Posted on by Tim

    Part 1 in a 4 part series. This post covers communication and collaboration.

    To start 2022 off right, I’m writing a series on the Manifesto for Agile Software Development. Given that the Manifesto is quickly reaching 21-years-old, I wanted to cover my learning and reflection on its impact.

    Two disclosures:

    1. I am not a software developer
    2. When this was published, I thought it was a fad

    The first value;

    Individuals and interactions over processes and tools

    Manifesto for Agile Software Development

    Communication and collaboration. Keys to positive and productive human interaction. For each of us, this takes on different meaning depending on the context of the interaction.

    As I wrote in my first post of the year, tools don’t fix problems. People fix problems. The Manifesto signers understood this in the context of software development.

    And yet, this also applies to other pursuits as well.

    If a team doesn’t know what the problem is, let alone how it might be solved, do processes and tools matter?

    For me, the answer is a simple ‘no.’ No, processes and tools alone will not identify the problem. I am writing from experience.

    If I have a bent nail I need to remove from a wood board, would I use a screw driver to fix the problem? No, I would need to find a claw-head hammer to remove the bent nail.

    Houston, we have a problem (communication and collaboration)

    Stepping back, if the financial health of my company is failing, do I know what the points of cause are for the problem? Maybe, maybe not, it depends. Discovery is required to figure out what may be cause the money loss.

    Can a tool determine the cause, not knowing what the problem is?

    Can a process define the problem?

    Simply answered, no. It takes bright, talented people working together (individuals and interactions) to define the problem. Then those same people set out to solve the problem.

    In life, there is no certainty from one day to the next day. It’s time to embrace the uncertainty and get down to working on today’s problems.

    The key is using communication and collaboration to solve the right problems.

    Value 1, Value 2, Value 3, Value 4


    📂This entry was posted in Agile 📎and tagged