• Tag Archives humans_being

  • 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

  • To Be Creative Nurture And Spark Psychological Safety

    Posted on by Tim

    During a coaching call with Ravi Verma, I shared learning from the field of neuroleadership. Given this field is still emerging, I perceive a connection between it and psychological safety.

    Being a life-long learner has certain downs and ups.

    • First, I find connections between concepts that may not be directly related.
    • Second, it requires a time to build connections.
    • Third, it comes with opportunity costs.
    • Fourth, it can serve to improve humanity.
    • Fifth, if no practical action comes of the learning, then it was all wasteful.

    Which brings me to this post. The post is about the fifth point.

    Without psychological safety, a business’ culture cannot reach its full creative potential.

    As a veteran working through life impacted by post-traumatic stress (PTS), I view life differently than most people.

    Drs. David Rock and Al Ringleb wrote about research on “social pain” in the Handbook of NeuroLeadership. Simply put, people will not risk their group identity or status because of social pain (along with other factors).

    Cover of the Handbook of NeuroLeadership

    If you or I inflict social pain on someone, we cannot expect them to be creative. Social pain can cause a degree of trauma and lower team psychological safety.

    For people like me, dealing with PTS, social pain can trigger a “fight or flight” response which can lead to more social pain.

    Nurture Psychological Safety

    Drs. Amy Edmondson and Timothy Clark have written about the need for psychological safety in the workplace. I say it goes further than just business, it needs to be in homes and the public domain.

    We can choose to create cultures that minimize risk of social pain. As well, we can choose how to respond to people who may not be aware of the pain they create.

    A starting point to consider is The Flow System. It brings concepts around complexity, leadership, and teamwork together in one place.

    A key component of TFS is establishing and enabling psychological safety at both the team and organization level.

    I’ll finish with this question. What can you do to minimize social pain and maximize psychological safety today?


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

  • Servant Leadership: The Essence Of Being A Navy Chief

    Posted on by Tim

    One of the hardest concepts for me to describe is the “how” being a U. S. Navy Chief Petty Officer transformed me. We have a saying, “Once a Chief, Always a Chief.”

    While browsing my LinkedIn feed, I saw a link blog post with a curious title.

    USNI blog post title

    U.S. Naval Institute Blog (usni.org) – blog post link

    The history of the Navy Chief (short for Chief Petty Officer) is rich. I don’t have enough time to cover all the bases, but it’s unrivaled by any other position in the U.S. armed forces.

    The author, Tony Palmer, noted content from the letter that former MCPON (Master Chief Petty Officer of the Navy) Mike Stevens wrote in 2014 which explains how I was transformed.

    In his December 2014 “Letter to the Mess” MCPON Mike Stevens defined the chief petty officer rate by stating, “A Chief Petty Officer is a quiet, humble, servant leader. We have the responsibility to establish and maintain the conditions that provide all of our people the opportunity to be successful and accomplish whatever mission we have been given. And we do this while treating one another with dignity and respect.” Stevens went on to quote the British writer and lay theologian, C. S. Lewis. “Being humble is thinking less of yourself and thinking more about others.” His final sentence reflects the essence of his vision for a humble leader, “Being mindful that the more senior you become, the more people you serve.”

    Tony Palmer (emphasis above is mine)

    For me, Mike nailed the “how”. I saw servant leadership modeled by Chiefs.

    As a result, I became the person I saw modeled. In the Agile product and service development space, we talk about servant leadership. I lived it before joining the Agile community.


    📂This entry was posted in Scrum Teamwork 📎and tagged

  • Coasting Versus Conquering: Getting The Most Out Of Yourself

    Posted on by Tim

    Gaining and maintaining personal momentum is really hard. I suppose it is harder today than say 10 years ago. Each day should be a personal challenge to get the most out of yourself.

    This is not about “toxic positivity” or whatever popular phrase is trending on the internet.

    This is about subtle shifts in doing and thinking that add up over time.

    Many of the world’s most recognized and respected brands have humble beginnings. Apple and Toyota are two examples.

    Apple started in a garage.

    Toyota started with weaving looms and moved into automobile manufacturing after World War 2.

    Books in my office

    Each of us is responsible for improving daily. You’re either growing or dying, the choice is yours.

    You might be thinking, “Where do you suggest I start?” My answer is, “What is causing you the most pain?”

    Pain is relative. I deal with a whole military career of pain each day. The list of challenges I work through is long and not worth writing about.

    Personal Challenge

    You need to ask yourself a question. Am I coasting or conquering?

    Is technology a hurdle for you? May I suggest you find someone you trust to help you learning about technology?

    If you’re an introvert, like me, then public speaking could be a huge hurdle. Toastmasters can help overcome that fear.

    Perhaps you struggle with learning in general. I wrote an article on “micro learning” that can help you get started.

    Once you lock in on the one or two things you want to improve on, choose people to be accountable to for taking action. Accountability is a catalyst for personal growth (and a follow-on post).


    📂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

  • No More Rainbows, Unicorns, Pixie Dust, And Wishful Thinking

    Posted on by Tim

    Technology will not fix problems. Problems come from processes or human relationships.

    I’m a recovering, well sort of recovering, tech geek. I see a new software tool or some tech hardware and I immediately start thinking I need it to make life better or easier. Over time, I’ve learned that it is a fallacy to believe this and it brings more challenges.

    How many times have you seen a new software or hardware tool get rolled out at work? One, two, three, or more times?

    Did that tool work flawlessly right from the start?

    If you answered honestly, you may have seen more sputtering starts to new tool adoption than zooming success. Blame the quick reference guides, the supporting instructions, the operating documents or whatever.

    A pile of satellite dish receivers and wiring
    Cleaning up a technology mess

    It’s time to stop blaming objects and start asking curious and honest questions.

    • Have we considered all the different ways the work might be done?
    • Have we asked for the HR department to work with us to understand how they do their work today?
    • What might we learn from watching Gemma, Mary, Ravi, and Ivan working together?

    As a technologist, I am scared when I consider the answers these questions might show.

    As a result, I am not foolish or naïve enough to believe anything can be fixed overnight. In fact, I’m reminded that Rome was not built in a day, a month, a year, or even a decade. Rome was built over 100s of years to what it is today.

    With that written, I’m going to get back to the opening. Again, technology will not fix problems. Listening and learning from the people who have the problems will go a long way to making better technology.

    Seems like yesterday

    Why do I say this? Because, it was a major issue over 20 years ago when the Agile Manifesto for Software Development was agreed to address the problems. We are better at building technology.

    I know we can be better still. And by that, I mean we can build better experiences alongside technology.

    We need to meet each other with empathy as humans being. We need to do more than hear each other, we need to deeply listen.

    Firstly, look at human interactions. Secondly, learn to understand how people work. Finally, build delightful products and services based on learning.

    Be bold, be courageous, be willing to fail (learning from the failure), and be humble enough to admit you’re wrong if you’ve acted on assumptions.

    I know that I have been wrong. As a result, it’s not bad to be wrong, it’s just humans being.


    📂This entry was posted in Agile Technology 📎and tagged