• Tag Archives context
  • 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


  • The Art Of Being Undiscovered While Adapting And Enduring

    Posted on by Tim

    One of the toughest courses in the U. S. military is Survival Evasion Resistance and Escape (SERE). The school forces students to learn the art of adapting and enduring. Are you forcing your customers to adapt and endure?

    A better question is, are you forcing your team to adapt and endure? How about the company?

    Being able to adapt and endure could be seen as a negative experience. Or it could be seen as a positive choice. If the company and team are shifting toward a more customer 1st, digital experience, then being undiscovered is can become an advantage.

    When headlines like this show up in the news feed, it begs the some thought about intent.

    https://www.dqindia.com/zebra-technologies-selects-tcs-to-help-drive-it-agile-transformation-and-devsecops-services/

    HCL Technologies to Enhance Euroclear’s Digital Landscape

    Kraft Heinz’s (KHC) Agile Portfolio Management Fuels Growth

    Getting back to SERE school, the intent is to learn how to evade an enemy. Businesses could take a lesson from the schoolhouse as they are quite literally telling their competition, “Hey we’re transforming our business over here because we want to move faster to meet our customer’s needs and wants.”

    More often than not, these press releases are saying enterprises are falling behind their rivals. The announcements inspire confidence. Alternately, the facts show a different picture.

    Hidden Strategy To Adapting And Enduring

    The New England Patriots football team has been in the headline for several reasons over the years.

    Like this issue and this issue. The Patriots do a great job of hiding their strategy.

    New England Patriot’s logo

    Cheating to win in sports is not acceptable. Equally wrong, is cheating in business. But does is make sense to show strategy in progress?

    Companies showing a playbook cannot complain when their competition beats them. Public relations announcements expose a part of the business strategy.

    Rather than show the plays, keep them hidden until game day. If there is a digital journey in flight, then keep that effort private.

    Keep stakeholders “in-the-know”. Avoid going public until the work is done. Win the market by beating peers.


  • 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


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


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


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


  • 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).


  • 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


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


  • Agile Principle #1 – Highest Priority To Deliver Delight

    Posted on by Tim

    Part 1 in a 12-part series. This post covers continuous delivery.

    The first principle;

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    Principles behind the Agile Manifesto

    For this series, think of software as products and services. Customers will not pay for crappy products and services, unless they perceive value.

    That might come as a shock.

    Allow me to provide a comparison. One of the first cars I was allowed to drive is shown below.

    Toyota Tercel Wagon

    One of the first cars I chose to buy is also shown below.

    Buick Regal Coupe

    For me, the better value was the Buick. It didn’t matter that the Toyota was a better quality product. At 16 to 17 years-old, I wanted a car that girls would ride in!

    Deliver Continuous Value

    Let’s redefine the conversation to cover more than just software. I suggest that we look at products and services based on value. Customers care about value and we have to as well.

    How do we get to continuous delivery of value? Look at Agile Value #1; Individuals and Interactions.

    First, we talk with customers and get their thoughts on value. Next, we create a small sample of what we understand from the conversation. If the sample doesn’t match the customers understanding, we fix it until we get is right. Finally, we adjust and scale to a viable product and service customers will buy based on value.

    Yeah, this is a simplified process. No disagreement on that feedback.

    What matters is the continuous delivery. Conditions will change. Preferences will change. As long as discussions are frequently happening with customers, we can deliver value and adjust as needed.

    This principle is uncomfortable to accept. I struggle with it because I want our team’s products and services to be perfect. The work done doesn’t need to be perfect, just have value the customer pays for.

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