I played clarinet from fourth through twelfth grade. The manner in which I was taught was, to me, extremely disagreeable â a ruthlessly judgmental and competitive environment, with overly serious and intense teachers, brought about to weed out anyone who wasnât 100% serious about playing as perfectly as possible in an overpopulated New York Metropolitan Area student music scene.
I was very good, but I was unhappy. Mistakes were frowned upon at an early age. The training was intense, intellectual, demanding, and even demeaning. Music should bring joy, but performing it was decidedly joyless by the time I left high school. I havenât picked up the instrument since.
I still adore music, but not as a performer. Today, I enjoy it as a listener. There are many musicians I admire, both alive and deceased, but one who has long caught my ears and my mind â and who I have had the fortune to see in person many, many times is the great bass player Victor Wooten.
Please take five minutes to watch Victor share something that, upon its debut in 2012, made me cry with both disappointment and joy:
This is such a profound point. How I wish I had learned music that way!
But Scrum â ah, Scrum. Can we learn it that way? Why do we tend to treat Scrum as having essential rules that can never be separated or broken, even while learning it? Plenty of otherwise fine Scrum practitioners will let people have fun in the classroom, but once students proceed to apply Scrum in the real world, things change. This is just wrong.
If we can practice personal point kaizen via âOne Small Step Can Change Your Life,â then we certainly can practice Scrum sloppily and joyfully as we learn it. I think we would all be better off if we made an effort to introduce Scrum in the form of something Iâd like to call Relaxed Scrum.
Hereâs an interesting way to introduce Scrum to a group of the uninitiated. Iâm describing an in-person exercise, but you can easily translate it to a virtual world. At the very top of your teaching:
Ask your class to write down the missing word in the following sentence:
Initiatives that have _______________ are the ones that are best suited to being managed with agile practices like Scrum.
Have them write their answers and pass them to you.
Once you have them in-hand, read each answer aloud.
Next, ask the class to have a discussion about these answers, to pick one, and have them elect one individual to deliver the final answer at the conclusion of their deliberations, much like a jury.
With work and maybe a little luck, they will arrive at the answer: uncertainty.
You will have just demonstrated Scrum in the most elemental way possible: an uncertain start; an iterative trial-and-error exercise in the middle; and a completed sentence at the end. Your audience will have applied transparency, inspection, and adaptation. And, they will develop a first-hand appreciation for the significance of the very sentence they worked to complete. Scrum â Relaxed Scrum â doesnât have to be any more complicated than that.
A colleague of mine recently responded to his early Scrum training by noting that Scrum is really all about psychologyâŚitâs about finding a way to unshackle the mind when it is paralyzed about the uncertainty of a task that lies ahead. A truer observation could not have been made. Itâs really that simple, and if you make it more complex than that to the uninitiated, you will be as happy practicing Scrum as I was practicing clarinet.
When was the last time you read the Scrum Guide? In its fully-documented form, with a cover, a full-page table of contents, very wide margins, generous 12-point type, large repetitive footers, and a full-page end note and acknowledgements, itâs only 19 pages. You can read the bulk of it in about 20 minutes.
One of the most overlooked sentences in that guide is âScrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.â
Isnât this an invitation to play?
As you read the Scrum Guide, you will read the core values (commitment, courage, focus, openness and respect). If you were to create a Venn diagram of Scrum values with Progressive CIO values, there would be one overlap: commitment.
In my experience with Scrum (both Formal and Relaxed), commitment is the single most important value to focus on. You can do just about anything you want, so long as you make and keep commitments.
Relaxed Scrum is playful, and encourages learning by applying rules conveniently and selectively:
We can have a single Sprint where we commit to do some research (one or more Spikes), without having to have a real Product Owner. Such a Sprint might not have a formal backlog â it might just consist of one thing to do. This Sprint might not even have Daily Scrums, and yet it might even wind up resulting in a final release.
We can have a Sprint with no Daily Scrum at all. If a team is communicating well and communicating regularly, the intellectual exercise of a quality Daily Scrum might get in their way of feeling the liberation that Scrum should provide, especially early on.
We can have a Sprint with no Retrospective, most especially if things are already flowing well.
We can have a Sprint with no monolithic Sprint Review at the end, if people have mini-reviews as they roll along.
I am sure you can think of your own rules! The only things you really need to implement Relaxed Scrum are: 1) a problem you commit to work on; 2) time to do the work; and 3) a commitment to review the work at the end of a period of time. If you are able to find a subsequent problem to work on at the end, then you are cooking with gas!
As we grow to appreciate Scrum more â and as we jam with professionals â we will slowly get better and learn the value of its finer points and common practices. But we should not take ourselves so seriously en route! As Victor Wooten pointed out, we can laugh at mistakes, and even embrace them.
The point here is â
If your organization is not working to apply an agile practice like Scrum â Relaxed or otherwise â in some form, one of two things is happening:
You have no uncertainty in your business
You are missing something very powerful
In the case of item number two, if you are avoiding the power of doing something like Scrum because you are intimidated by it, then do everything in your power to think this way rather than this way.
As we proceed on our journey together, you will come to see that I am very fond of agile methods, and of Relaxed Scrum in particular. Relaxed Scrum happens almost organically in a culture that shares the foundational values we discuss on The Progressive CIO:
Vulnerability: An ability to admit something you did that was wrong, turning the shame into learning.
Humility: Remembering that we are human and learn from mistakes.
Empathy: When we seek to understand other viewpoints, we get the best of all possible worlds.
Patience: We are willing to put the time in to get to whatever is right even if we are unsure how long it will take.
Compassion: We understand that helping others on an uncertain journey requires us to be active in how we reach out to help them.
Curiosity: We are eager to learn new things.
Commitment: We know that doing something is hard, but doing nothing achieves nothing and actually prolongs our difficulties.
Willingness: We want to push ourselves forward to do something to effect change.
The three pillars of Scrum are underpinned by these values:
Transparency: A combination of vulnerability, humility, commitment, and willingness
Inspection: A combination of vulnerability, humility, empathy, curiosity, commitment, and willingness
Adaptation: A combination of empathy, patience, compassion, commitment, and willingness
If you create an environment with our eight values, you will have the essence of Relaxed Scrum without any other rules! Most critically, you will invent your own way to apply the principles of Scrum across a wider variety of initiatives. So why not find your own way of getting thereâŚand do it with a playful spirit, with as few rules as possible?
When you identify a leader, how do you invest in his or her growth?
My father was an electrical engineer of the highest order. A master bridge player and a director of electrical engineering at Hazeltine Corporation â one of the most significant electrical engineering companies in American history â he was a smart man who worked in the smartest of company. Dadâs colleagues over the years included not just Professor Alan Hazeltine himself, but Harold Wheeler of Wheeler Laboratories; Page Burr, co-founder of Burr-Brown, and who was my fatherâs classmate at Cornell; Bernie Loughlin, who co-invented color television; and Henry Bachman, who served as IEEE President and became an IEEE fellow. There were many others. I donât usually do this, but I encourage you to view the links to these individuals before you proceed, as they will paint a vivid picture of the fortunate magnificence of my fatherâs cohort.
What follows is not a hackneyed story about how my father was a great leader (although he was). It is a story about how the engineers of my fatherâs generation invented the idea of software, carving out the path to a new form of leadership. It is also the story of how he catapulted me along for the ride â with a swift kick in the pants.
Dad spent nearly 50 years at Hazeltine. My brothers and I all worked there at some point in our lives as well. My eldest brother Paul notably worked there for over 30 years in manufacturing, including time spent as part of the team that created the worldâs very first multi-layered PC boards. Hazeltine was a major force in the formative years of the electrical engineering industry.
I grew up in a fairly traditional household, where we shared stories over supper, every day. The children would discuss their schooldays, Mom would talk about what happened around the house and the news of the day, and Dad would share the latest goings on at Hazeltine. These would often include (generalized) stories about how the military changed requirements for the projects his teams were working on, how frustrating those changes were, and how this all threatened the due dates that they faced.
Above all else, these were stories about human beings and their struggles with change. I wish that I could recall many of them in great detail so that I could share them; I cannot. But they had a huge impact on our familyâs understanding of the world Dad worked within.
Less than a year and a half before he died at age 93, I was lucky enough to record Dad (during a car ride) recounting the following funny and fascinating story about the search for an aneroid barometer that was suited to solve a voltage issue his engineering team had at high altitudes within an Identification Friend or Foe (IFF) system for a Northrop aircraft.
Dad told these sorts of stories every night when we were growing up. Without really appreciating it at the time, I was deeply conditioned by the lessons and experiences of my father and his distinguished colleagues as related through these suppertime stories, right alongside their journeys to define the modern disciplines of their craft. It is all hard to believe in retrospect, but I had a first-hand seat to this era of engineering history, which became, no doubt, a significant component of my own education, outside of any classroom.
One of these old stories is easy for me to vividly recollect, no doubt because it was the seed that grew into my lifeâs professional focus. During one summer evening in the late 1970s, Dad introduced our family to the word âsoftware.â While I canât recall all of the details, one thing I do recall is him sharing how it allowed his engineers to make changes to things they made without having to redesign hardware. The fact that the very idea of software came about to mitigate the issues that electrical engineers of Dadâs generation faced is a lost story, yet it is critical to remember if we wish to understand the opportunities it represents. Electrical engineers designed hardware that could be programmed, elegantly enabling them to honor the human need for change while reducing their natural, personal frustrations when faced with that need.
The world would do well to remember that software is all about encouraging â rather than resisting â change. Many people wish to treat software as something to finish. Havenât we all heard people ask, âWhen will we be done with this software so we can move on?â How do you feel when you hear that? I enjoy tossing back this pithy response, which was borne of my suppertime story experiences:
If we want something that doesnât change, we should just build hardware.
Yours truly, on some hot summer night in the early 1980s. How about those socks?
When I was a young teenager in the early 1980s, I spent countless â undoubtedly thousands â of hours programming the 8-bit computers of the era, starting with the Commodore VIC-20 and moving on to the Commodore 64. One might describe me as addicted to programming, to the extent that Dad occasionally switched off the circuit breaker to my room so that I would better attend to my assigned chores and homework. During high school, I told him that I was eager to study computer science in college (software engineering degrees were more than a decade away at the time, and the term itself was probably not in common use, either.) His response to this was not what I expected.
âYou donât need a computer science degree to be a computer programmer,â he shared, with a brusque certainty. Dad was typically more demanding than I â or any young teenager â could bear. He would quickly and easily find the flaws in any system, argument, or idea that I might have. He went on:
âI will be paying for your education, and will not pay for you to do that. What you need in order to program computers is a background in liberal arts, because that experience will best equip you how to learn on your own on an ongoing basis, as computer languages, and the problems they are used for, change.â
That hit me like a ton of bricks, in the sense that I had no choice, unless I could find the money to pay for college myself. But it was also fair and gentle, in the sense that it was broad, with no specific direction other than to study liberal arts. I happened to be interested in studying journalism and publishing, and I was good in English class, so this all wasnât as horrible as it could have been. But it was certainly not what my other teenage programming friends were doing, and at the time it was hard to believe he was right.
You might recall this quote:
âWhen I was a boy of fourteen, my father was so ignorant, I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished at how much he had learned in seven years.â
âNot Mark Twain
I followed Dadâs orders.
The undergraduate program that I joined in 1986 at SUNY-Binghamton was focused on rhetorical theory, which, if you have read many of these pages before, you will understand as the ancient and philosophical study of persuasion and communication. Lucky for me, Dad didnât mind if I took a computer science program or two, which I did to my personal delight, serving to fulfill some of my science obligations. (We learned Pascal back then.) But rhetorical theory became my academic passion. It was the driving force behind my appreciation and understanding of empathy and trust. If you want to know more, I recommend you read Aristotleâs Rhetoric.
When I graduated from college, I landed a job as a software developer for a publishing company, oddly satisfying my broad desire to work for a publishing company while simultaneously satisfying my desire to program all day.
I never left the software industry after that.
In my careerâs first 15 years, software development projects were universally managed using traditional, deadline-driven waterfall methodologies, just like the very projects my dad managed in his career. In the mid 2000s, however, Scrum entered into my life â and the lives of many others. What occurred to me in the process of learning Scrum was that managing software development with Gannt charts and up-front planning was completely at odds with what software was supposed be. It felt remarkably more compatible with what Dad had shared at the dinner table over thirty years prior. With Scrum, we could finally develop software in a manner that embraced the sort of change that only software could deftly provide.
Softwareâs very nature doesnât merely involve uncertainty. It invites it. It is its raison d’ĂŞtre. Software is utterly pointless when there is certainty (I will repeat: otherwise, we should just build hardware.) What are we really achieving when we practice Scrum? We are offering a framework for human beings to help them manage the invited change and uncertainty, by taking one step at a time.
And, as the saying goes, herein lies the crux of the matter.
The Normal State, where we seek comfort and predictability (when we wake up and wish for a day without drama or surprises, and a pleasant evening to follow). We stick to the reactive, and not the proactive. As Quinn puts it: âTo remain in the normal state, refusing to change while the universe changes around us, is ultimately to choose slow death.â
The Fundamental State of Leadership, where we face the need to change with the world around us, eschewing our natural desire for the comfort of the normal state. To quote Quinn once more, âIn the fundamental state of leadership, we become less comfort-centered and more purpose-centered. We stop asking, What do I want? Since what we want is to be comfortable, this question keeps us in the reactive state. Instead we ask, What result do I want to create?â
The difference between supervision, management, and leadership might best be described as follows:
Supervision is the practice of overseeing people to ensure theyâre doing their assigned tasks.
Management is the practice of nurturing someoneâs career so that they can achieve what they aim to.
Leadership is the practice of taking people on a journey to an unknown place while managing their natural anxieties about this journey.
This is why good executives are fond of pointing out that everybody in an organization is capable of being a leader, no matter where they fall in the corporate hierarchy. Leaders drive change, and bring tools to the table to facilitate that change.
By definition, software engineers bring tools to the table to facilitate change â whether employing Scrum or not. Scrum just happens to make the journey easier for everyone involved. Donât leaders worthy of the label seek to do these things at every turn? When software engineers use frameworks like Scrum to assist them in their efforts to drive change, they are living the very highest form of leadership.
What are the consequences of this assertion?
For starters, we should make every attempt to recognize that software engineers are key leaders for the organizations they serve. To be clear: they are not future leaders; they are current leaders.
As a consequence of that, I believe that software engineers are worthy of being provided the very finest we can give them in leadership skills and trainingâŚthe very same skills we afford our best executives. We should do everything we can to groom their skills in:
Interpersonal communication
Group dynamics
Conflict resolution techniques
Emotional intelligence (EQ)
Yet, I canât think of too many organizations today that see how these are essential offerings for their software engineers, except perhaps as remedial activities once in a while. That approach is a mistake. Everyone worthy of being called leader needs regular nourishment in these skills, software engineers in particular.
In that sense, a good software engineering curriculum places significant emphasis on requirements elicitation, communication, human factors, and group dynamics. Over my decades managing software engineers, it has become apparent to me that the connection to the human condition doesnât end with the education provided by the software engineering degree. The degree itself is the foundation of a long arc of a leadership journey. Corporations who employ these engineers play a key role in this journey.
Dadâs opinion about the computer science programs of the 1980s was prescient. I think he would have liked Mike Lutz.
I would be remiss if I didnât offer that the generalized practice of IT is also, at its most vital human points, a form of leadership in the very same vein. While generalized IT folks donât generally develop custom software, they certainly select and configure off-the-shelf software solutions that enable change. These IT professionals â including the business analysts and project managers who serve both IT teams and software engineers â should be afforded the same sort of nourishing training that software engineers deserve.
At this point, you might wonder: what about those ISTJ and INTJ stereotypes? The propellerheads? Can they really be leaders in the way we traditionally envision that label? My answer? Itâs too late! You have no choice; they are already leaders. As my own coach, Dr. Jim Kestenbaum, has taught me, there is good news here. While we are born with our personalities and our IQs â and there is little we can do to change them â we have the ability to increase our skills in the four areas I listed above, EQ included. The investment will be worth it, if you choose to make it. But the first step is to realize that if you have software engineers in your organization, you have leaders â vital ones â who require care and feeding. To miss this is to shoot your proverbial corporate self in the foot.
Before embarking on the journey of reading this unusually long post, please take a moment to reflect on your organizationâs technology team.
Are the people friendly? Are they excellent listeners? Do they take the time to empathize with the people they are serving?
Do they work hard to fully unearth and understand peopleâs problems, designing and collaborating on solutions that reflect where your organization needs to go?
Do they help people feel comfortable with the rapid change that they face in business every day?
Do they exercise servant leadership at every opportunity? Do they exercise transformational leadership when called upon?
Does your company believe that, when you invest in software, you are investing in something that requires care and feeding and additional investment, in order to live up to its purpose, which is to reflect change in your ever-changing business?
Does your senior leadership understand that the answer to all of these questions needs to be yes?
Most importantly: Do you have an approach to address the ânoâ answers you have for any of the above?
In response to âSoftware Engineering Is a Form of Leadership,â a colleague shared that, âI once had the opportunity to have a conversation with Bill Gates. I asked him, âAmong your software engineers, how much of the job is technical versus nontechnical?â He responded that for leaders of software groups, the job was 80% nontechnical, and for his most technical people, the job was 50% nontechnical. Of course, you understand that very well! You have done a good job of identifying the leadership skills that are so important.â
Thatâs both a great story and a nice compliment, but one of my greatest challenges on The Progressive CIO is to engage folks who are not so lucky as I have been. To date, I have been preaching to the choir: my LinkedIn profile is filled with people who are a lucky and like-minded bunch. Very little of The Progressive CIO is news to them. âSoftware Engineering Is a Form of Leadershipâ was written to challenge conventional wisdom. But while I was writing, and even during my subsequent edits, I had a sense its message might not land in the right audience. This turned out to be largely true. Sure, I got a good handful of likes, atta-boys, and agreement from all of the usual suspects. But my network is filled with people who work in functional, healthy, and progressive organizations who already work within the sort of framework we talk about on these pages. I was preaching to the choir.
In my own industry (foodservice distribution), I can say with certainty that many organizations donât have great answers to all of the above. Those that do â and I like to consider the organizations that I work for among them â do well in no small part because we treat technology as a key investment in the human condition. We believe that all of our employees, including technology folks, have to bring gobs of emotional intelligence, empathy, humility, and compassion to the table in order to drive our organizations forward.
But why are we a (relatively) rare breed? Well, foodservice distribution is a pennies business. Many organizations try to spend as little as possible on technology as they possibly can. After they put in an ERP system, they want to be done paying for it, so that they can get back to doing what they do best: buying and selling food. What they too often fail to see is that they canât buy or sell food as competitively and strategically as possible if they put blinders on to the way the world around them has changed in the past 25 years.
Your business may be in a similar situation.
If your organization is one of those who would answer ânoâ to any or all of the lead-in questions above, you are the target audience for these pages, and this post is here for you. Read onâŚ.
Lucky for me â and for you! â âSoftware Engineering Is a Form of Leadershipâ elicited the sort of insightful dialog Iâve been hungry for since my earliest writing on these pages.
An adept, articulate, and perhaps even a little angry critical response came to me from one of my closest and longstanding friends. This response is more of a must-read than anything I have written to date on these pages. What pleases me most is that my friend is a fellow rhetorical theorist, as well as an excellent writer and author. That criticism is the focus here today. It sheds light on the very real â and very wide â gap that exists between what some might call my fantasy and so many other peopleâs realities.
Reality
There are literally thousands of companies â both big and small â that operate with, and even promote, behaviors that are self-defeating for their information customers, and that are at odds with the professions of software engineering and IT as they are currently being taught in schools and practiced in the most successful organizations.
It would be all too easy to say that these organizations work out of a sense of ignorance, or of austerity. Even though there might be some truth to that, it would be an unsympathetic assertion. I think itâs more appropriate to say that these organizations work this way out of a sense of experience, exposure, and habit. Engineers and IT people still generally have an awful reputation as propellerheads, and most people are conditioned to view us through the lens of that stereotype. There are still millions upon millions of people in the workplace who have never been exposed to well-trained and human-focused IT or software professionals, because most of the best technology professionals tend to work in a relatively small number of organizations. Universities are trying to change this, but it will take a very long time before that change is complete. Even then, just like in every profession, there will be bad apples who will perpetuate the stereotype.
Given the unfortunate wealth of this sort of experience, exposure, and habit, the questions we need to address are: 1) how do people help their organizations discover and explore alternative habits; and 2) who is responsible for initiating these alternative habits given the chicken-and-egg nature of the problem?
To begin the journey, letâs explore my friendâs experience with their companyâs experience, exposure, and habits.
So, at the end of it all, I guess my overall thought is WOW, we have had such different experiences.
Your post starts off with highlighting how great your Dad was, which was nice to know. What an amazing career he had. I loved that you called it âsuppertimeâ because that was what it was. I was amazed that your father expressed his disdain for a computer science degree, that really surprised me. (Just recently I have been reflecting on how important a quality liberal arts education can be.)
But where you start losing me is âSoftwareâs very nature doesnât merely involve uncertainty. It invites it. It is its raison dâĂŞtre.â Software doesnât have a nature. It is a bunch of code designed to get things done. It is a created response to the current perceived problem. Sure, software has to keep changing because the external parameters are changing (I am hesitant to say evolving). The software and the hardware fit together so that people can be more productive.
âSoftware doesnât have a nature.â I needed that. My friend is right. Only my choir would see it that wayâŚand every one of us would do well to think of this quite differently. Of course, a software engineering academic would want to assert that the code isnât the important part of the dynamic here. The code merely a single step in the broader context of evaluating and solving a human problem.
But the meta problem here is that the experience, exposure, and habits of many companies cause them to perceive that code is what the software engineer brings to the table. In that sense, then, my friend is completely correct: software itself certainly doesnât have a nature.
As a response, I offer a something vastly clearer: the situation that leads to software has a nature.
This leads me to something I have wanted to write about for a very long time. In 1968, Lloyd Bitzer, a rhetorical theorist at The University of Wisconsin – Madison, wrote a piece entitled âThe Rhetorical Situationâ that has become essential reading for anyone engaged in the modern study of rhetoric. Those of you visiting the Progressive CIO for the first time here might not know that my personal style in managing software engineering and IT is driven by a human-first approach that has its foundations in applied rhetorical theory. I believe that the problems in our profession are most effectively addressed through a comprehensive study and understanding of an audience and its attendant needs, calling for supreme skills in Aristotleâs rhetorical triad of logos, pathos, and ethos.
In âThe Rhetorical Situation,â Bitzer attempts to describe the sorts of situations that drive the need for rhetorical discourse. What exactly is that, you ask? Itâs something that is probably best defined as language that is employed to move or influence an audience, to bring about change. Traditionally, rhetorical discourse is the label applied to speeches and other overtly persuasive pieces of language. Modern rhetorical theory, however, acknowledges that a vast percentage of human communication can be considered rhetorical discourseâŚeven the simplest âSTOPâ sign.
Lloyd Bitzer, rhetorician. What in the world does he have to offer to the field of software engineering? Quite a bit.
Here are two key paragraphs, presented without ellipsis, from the midsection of Bitzerâs âThe Rhetorical Situationâ:
Hence, to say that rhetoric is situational means: (1) rhetorical discourse comes into existence as a response to situation, in the same sense that an answer comes into existence in response to a question, or a solution in response to a problem; (2) a speech is given rhetorical significance by the situation, just as a unit of discourse is given significance as answer or as solution by the question or problem; (3) a rhetorical situation must exist as a necessary condition of rhetorical discourse, just as a question must exist as a necessary condition of an answer; (4) many questions go unanswered and many problems remain unsolved; similarly, many rhetorical situations mature and decay without giving birth to rhetorical utterance; (5) a situation is rhetorical insofar as it needs and invites discourse capable of participating with situation and thereby altering its reality; (6) discourse is rhetorical insofar as it functions (or seeks to function) as a fitting response to a situation which needs and invites it. (7) Finally, the situation controls the rhetorical response in the same sense that the question controls the answer and the problem controls the solution. Not the rhetor and not persuasive intent, but the situation is the source and ground of rhetorical activity â and, I should add, of rhetorical criticism.
Let us now amplify the nature of situation by providing a formal definition and examining constituents. Rhetorical situation may be defined as a complex of persons, events, objects, and relations presenting an actual or potential exigence which can be completely or partially removed if discourse, introduced into the situation, can so constrain human decision or action as to bring about the significant modification of the exigence. Prior to the creation and presentation of discourse, there are three constituents of any rhetorical situation: the first is the exigence; the second and third are elements of the complex, namely the audience to be constrained in decision and action, and the constraints which influence the rhetor and can be brought to bear upon the audience.
Lloyd Bitzer, The Rhetorical Situation, 1968
Letâs see how that reads after a bit of search-and-replace:
Hence, to say that SOFTWARE is situational means: (1) SOFTWARE comes into existence as a response to situation, in the same sense that an answer comes into existence in response to a question, or a solution in response to a problem; (2) SOFTWARE is given ⌠significance by the situation, just as a unit of discourse is given significance as answer or as solution by the question or problem; (3) a SOFTWARE situation must exist as a necessary condition of SOFTWARE, just as a question must exist as a necessary condition of an answer; (4) many questions go unanswered and many problems remain unsolved; similarly, many SOFTWARE situations mature and decay without giving birth to SOFTWARE; (5) a situation is SOFTWARE insofar as it needs and invites SOFTWARE capable of participating with situation and thereby altering its reality; (6) discourse is SOFTWARE insofar as it functions (or seeks to function) as a fitting response to a situation which needs and invites it. (7) Finally, the situation controls the SOFTWARE response in the same sense that the question controls the answer and the problem controls the solution. Not the SOFTWARE ENGINEER and not persuasive intent, but the situation is the source and ground of SOFTWARE activity â and, I should add, of SOFTWARE criticism.
Let us now amplify the nature of situation by providing a formal definition and examining constituents. SOFTWARE situation may be defined as a complex of persons, events, objects, and relations presenting an actual or potential exigence which can be completely or partially removed if SOFTWARE, introduced into the situation, can so constrain human decision or action as to bring about the significant modification of the exigence. Prior to the creation and presentation of SOFTWARE, there are three constituents of any SOFTWARE situation: the first is the exigence; the second and third are elements of the complex, namely the audience to be constrained in decision and action, and the constraints which influence the SOFTWARE ENGINEER and can be brought to bear upon the audience.
The remarkable thing about Bitzerâs essay is how effortlessly interchangeable the ideas of rhetorical discourse and software are. The piece does not sound completely ridiculous with these simple substitutions. I believe that this is because software is itself a form of rhetorical discourse, in that it is language that is employed to move or influence an audience, to bring about change. I suppose you could argue this over several beers in any college town in the world, but I would still tell you that software is a form of discourse. In another way of looking at it, software is an expression of thought, and it is a dialogue. It is written for humans, by humans, to express ideas and thoughts, and it is changed in response to the needs of its interlocutors.
Unfortunately for me, a Google search for âis software a form of discourseâ (in quotes) as of this writing returns one of those sad âNo results foundâ messages. There are, however, three or four references to âsoftware is a form of discourse,â one of which seems truly interesting. I think weâre onto something. Letâs check back in a few years. I digressâŚ
In rhetoric, the person responding to the exigency and who creates the rhetorical discourse is known as the rhetor. The rhetorâs counterpart in our world is the software engineer. The most challenging work for both of these individuals is in the mise en place:
Listening
Empathy
Audience analysis
Situational understanding
Both rhetoric and software seek to drive movement and change. The rhetorâs ultimate product is the speech; the software engineerâs ultimate product is the program. The wordsmithing of these two products is significant, no doubt, but the magic is all in the mise en place. If that is done poorly, the end product will be irrelevant. Nobody will be moved, and nothing will be changed. In software engineering, there is a maxim: the requirements and the documentation are more important than the code. If you lose the code but still have the requirements documented, you can create new code to address the requirements. But if you lose the requirements and have the code, all you have is a solution to a problem that nobody understands anymore.
This is why the academic practice of software engineering pays special attention to the practices of requirements elicitation, group dynamics, and human factors. This is where the key elements of Aristotleâs Rhetoric â logos, pathos, ethos â come into play, every day, all day, for software engineers. In order to be successful, software engineers have to not only look at things from a logical perspective, but they also have to empathize (deeply) and develop a sense of trust in their approaches and their responses to the situation at hand. They will not be able to create the sort of durable and lasting relationships with the people they serve if they fail in these skills. And because software is always an ongoing journey (it is designed to change, constantly, relentlessly), if you do not maintain healthy relationships between those serving and those being served, you will wind up with what, in our industry, we would call a âlegacy softwareâ situation.
My friendâs cogent response continues:
Then you say Scrum is great because it allows us to âmanage the invited change and uncertainty, by taking one step at a time.â Well, not all change is invited, and it would really be nice if we could look ahead a little farther and anticipate what Hell this change is going to create when we are three steps down the line.
Side note: Several years ago, we had a âlunch and learnâ at our company at which the director of the IT department explained Scrum to all of us with PowerPoint slides and everything! Basically, it was their justification for why they worked on which projects/problems. At the time, there were eight people in the IT department, and they would meet every morning to discuss their priorities for the day. If an urgent problem or issue arose, they would have to evaluate what they could set aside so that they could refocus their attention. Multitaskers they were not.
Prior to them worshiping at the altar of Scrum, they had a spreadsheet list approach. All issues and problems from all departments were catalogued (it was a Jira system). As each department became more and more frustrated that progress was never being made, the IT department decided to call a monthly meeting with the people who had entered the Jiras. We were all supposed to review the list as a company team so that we could understand their overwhelming burden and conflicting priorities. What actually happened was they lost ALL control because the individual departments started organizing their work for them, and those groups were setting the priority ordering. We never had another meeting, and they found Scrum.
Friends, we need to listen to this; these are profoundly important points that illustrate key anti-patterns that our industry faces. For certain, not all change is invited. When we select to use software to address our problems, however, we are making a decision to employ something that was designed to be changed. Back to my fatherâs point, we use software because changing (electronic) hardware is just too difficult, and in all too many circumstances, we need to allow for change, because change is the natural state of things.
So letâs get down to some experience, exposure, and habits regarding Scrum. Scrum is one of the most abused, misused, and misunderstood ideas of the modern workplace. Iâm not a betting man, but I would bet that, in 80% of all implementations, Scrum is FUBAR. Is Scrum bad because itâs so easy to get wrong? Perhaps. But that would be like saying nobody should perform ballet because itâs so easy to get it wrong. Ballet is ridiculously hard to do well. But, holy cow, when itâs done well, itâs breathtaking.
The interesting thing to observe in the experience, exposure, and habits of my friendâs company is that they misunderstand who should be practicing Scrum. Itâs not the IT team! And the IT team is not the one to set the priorities for what they work on! Businesspeople are the ones who are supposed to set the priorities for the organization; businesspeople decide what must stop if something else must take priority; businesspeople decide how to invest in staffing the IT teams with the quantity and quality of people who can help them achieve what they require. If you ever find an IT team with this sort of control, it means that the businesspeople, all the way up to the top, have simply abdicated their responsibilities. In Scrum, the Product Owner for an initiative is not on the IT team. This is all a behavioral anti-pattern.
It is because of this that I very much appreciate that my friendâs IT team âlost ALL control becauseâ the operating departments âstarted organizing their work for them.â Good for those departments! Take control of what you are supposed to control! Unfortunately, from afar, the radio broadcast here seems to indicate that the IT team found a way to use Scrum to regain apparent control. I have no idea how this happened, but it certainly sounds like a horrible human mess. Thatâs not Scrum. At all.
Back to the post, now we are talking about the definitions of leadership. âSupervision is the practice of overseeing people to ensure theyâre doing their assigned tasks.â Okay, I can agree to that.
âManagement is the practice of nurturing someoneâs career so that they can achieve what they aim to.â That may be what it is supposed to be, but that certainly isnât my experience (and I really donât think I am alone here). In my experience, management is about the managers relying on other people to get work done and then taking all of the credit for themselves. Support, encouragement, and/or appreciation is not offered because âyou might think too much of yourself.â Management is concerned with protecting their position and their salary.
Also, the idea that management is interested in my goals is foreign to me. They are interested in their goals (see above: protecting their position and their salary). If I can help with that, then I will be included without being a truly engaged partner in the process because all information is on a need to know basis.
Iâm as guilty of throwing idealistic definitions of supervision, management, and leadership around as the next guy. Iâm lucky to not only believe in these definitions, but to work with others who do as well. But take a moment to absorb the above. Despite all of our best wishes, this is what happens at many organizations. Need proof? Why does Dilbert exist?
Dilbert is not just a comic: it is daily illustration of anti-patterns. If you prefer reality over cartoons, then refer to the above. Itâs real.
So, if your management behaves this way, what can you do? One passive-aggressive thing to do might be to print this article and post it somewhere. But stupid people donât read, so thatâs not going to work for you.
What can you do when you feel like a mere peon but are interested in making your organization better (ahem, being a true leader)? Letâs use an example from my friend:
Last month, we had an all-staff meeting. Our new Presidentâs big news was that our Board passed the budget. He thanked Percy, our new CFO, for what a great job he did putting the budget together, and what a great job he did presenting it to the Board. It was just so wonderful, and he did such a great job. What a testament to him that the budget was unanimously passed.
Hmmmm, interesting that it is his success. All of the managers worked on their department budgets (fussing about costs and ways to save), entering and revising all of the numbers in the budgeting software when they decided to cut all travel and training for 2021. The individuals in accounting also provided us with all kinds of reports and help.
But letâs be grateful to Percy, who, by the way, could/should have said, âI couldnât have done it without my teamâ or anything that acknowledged that it was a group effort.
Nope, nothing — no surprise there.
The best guidance I can offer you from the limits of this page is this: employ the power of the question to make your leaders think. Find an opportunity to ask a question like this: âDo you have any thoughts on why our department managersâ morale is so low?â Even though you are smarter than your organizationâs management, ask the question as if you donât know the answer. Then see how it goes. If you do this enough, over a period of time, the lazy people you are talking to just might want to know if you have any ideas. And itâs always your option to say, âI have no idea, I just wanted to explore.â If you do this enough, you will be able to get a more detailed picture of who feels what, and you will be able to do a lot with that information. Remember that human beings love to be given an opportunity to share their thoughts, and little bits of unexpectedly useful information will always come your way if you are skilled enough to shut up, sit back, and take it all in without offering anything in return. They call it âthe power of the questionâ for a reason: collecting all of that perspective gives you the power and time to figure out how to put it to good use.
Of course, this is only one option. Another completely valid option is to find a better job. You deserve it! But please do take an opportunity to experiment with the power of the question no matter where you work, because your ability to do this will help in so many situations, even in the very best organizations, under much better circumstances.
Back to my friend:
âLeadership is the practice of taking people on a journey to an unknown place while managing their natural anxieties about this journey.â Hmmmm, that hasnât been my experience either.
Friends, leadership is one of the most debated terms in all of business. I am going to tell you, unequivocally, that the very nicest organizations to work for all agree that leadership is the idea of moving a novel (and typically uncomfortable) idea forward, regardless of where you sit in your organization.
But remember my friendâs perspective. There are a lot of organizations that arenât the very nicest. These definitions donât mean much to them.
Back to software:
But next comes the real stunner: âWhen software engineers use frameworks like Scrum to assist them in their efforts to drive change, they are living the very highest form of leadership.â Wow, I read that I thought, are you kidding me? Because they code software, because they use Scrum, they are leaders. What? They arenât thinking outside the box, looking at the future, creating a path forward for the organization. They are solving the computer problem in front of them which has been tagged as a priority. You soften it a bit by saying âEveryone worthy of being called leader needs regular nourishment in these skills, software engineers in particular.â But still, WOW.
Maybe it is the person who comes to the software developer and says, this is what I am envisioning (beyond a reaction to an issue), this is what would make things better, this is what would move us forward, maybe that is the person who should be heralded.
Once again, my friend nails it. For many organizations, the programmers solve âthe computer problem in front of them which has been tagged as a priority.â
Is that what your organizationâs programmers do?
Software engineers are there to help with human, business problems. Not computer problems. In fact, well-trained and thoughtful software engineers will discourage the use of software when they think itâs the right thing to do, just as civil engineers will discourage the use of concrete barriers when visibility is more important than sturdiness. In many process workflows, human input is more important than automation. Software engineers who are members of ACM or IEEE have a code of ethics that underscores their responsibilities in this regard.
Software engineers are there specifically to collaborate with others to think outside the box, look at the future, and create a path forward for their organization.
To the very point of âSoftware Engineering Is a Form of Leadership,â software engineers are leaders in this context in the very basic sense that software, as a journey, has no known end (remember: if there were a known end, we would just create hardware). This journey is filled with uncertainty and anxiety, if nothing else. If this werenât the case, then ERP implementations would not cause nightmares and waste billions of dollars, year after year after year.
All of this brings us to Scrum.
Scrum â as difficult to get right as ballet â is a key tool to helping manage this anxiety. Scrum says: letâs take our uncertain journey one step at a time. Letâs be transparent with one another about our feelings and anxieties, and letâs commit to inspecting each step of our journey, and letâs commit to adapting based upon what we find after each step.
The three pillars of Scrum â transparency, inspection, adaptation â are Leadership 101. Weâre going to try something new. We donât know exactly whatâs going to happen, but thatâs OK. We will talk often, review whatâs going on and how we feel about it, we will make decisions about whatâs next, and there will be a person to encourage us along the way.
To be fair, Scrum isnât only practiced by technologists. Itâs practiced by everyone involved in a key initiative. But technologists are the ones who have such a colorful palette of solutions to the problems discovered through Scrum. As a bonus, they (today) learn Scrum in a university setting, and are practiced not just in employing it, but in teaching it.
All too often, however, these points are lost on so many organizations who hire these technologistsâŚall because of their experience, exposure, and habits.
What can you do about this?
Back to the power of the question: âAre we taking the time to learn the ins and outs of Scrum to our advantage? I hear itâs really difficult to do well, like ballet. What could we do to learn more?â Or perhaps, âDo we think that we are effectively confronting and addressing the problems we face today? What are our anxieties about what lies ahead, and what are we willing to do about those anxieties?â Or something like that. Youâre smart. Take it from there.
Finally:
So, what you describe is your experience; it certainly is not mine. Maybe I really donât understand what a Real software engineer is and how hidden beneath his exterior is a true leader waiting to be acknowledged — if only given the chance and âproper care and feeding.â So much for the rest of us saps, who toil at our tasks and arenât offered the six-figure salaries of those in the IT department. Did you consider that maybe these software engineers arenât interested in a leadership position? I just donât understand why they and using Scrum makes them so much more worthy than the rest of us.
But, like I said when I started this, we have just had such different experiences.
The best software engineers â excuse me, leaders â are trusted guides who we look forward to being with, because we know that they will get us where we need to go, and we return to them routinely to seek their guidance and help. If you have software engineers who do not appreciate this opportunity, then you have what we would call code monkeys. Code monkeys are fine. But they are not worthy of being called engineers, let alone leaders. The âprogrammersâ of 30 or 40 years ago who never kept up with the times would be considered the code monkeys of today.
If your organization uses code monkeys and not software engineers, do you care? If you do care, what can you do about it?
I hope you agree that my friendâs willingness to share their organizationâs experience, exposure, and habits was a real gift to our dialogue. I am sure, too, that when we have friends like this, that we do everything possible to help them either move their organizations forward, or move on to greener pastures. Sometimes, the problem is that you are the smartest person in the room, and the best option is to leave the room.
I posed a question earlier in this post that I havenât forgotten about:
Who is responsible for initiating these alternative habits given the chicken-and-egg nature of the problem?
You are! Yes, you. Itâs not a chicken-and-egg thing at all. While it might appear that nothing can happen unless your management takes the first move, there is always a chance that your management needs you to make the first move. Sure, if you are wrong, then you will need to move on. But: you already care enough to read about these things. You are smart. You can employ the power of the question to lead from wherever you are today. And if you never try, then you never lead.
This is something that you could put in a breakroom, and most anyone in your business would be enlightened after merely one cup of coffee. Great things come in small packages, indeed. Itâs so succinct that it made a pet peeve of mine more obvious: the use of the term âDeveloper.â When I teach Scrum to cross-functional teams of businesspeople, I substitute âImplementorsâ for âDevelopers.â Itâs simply more relatable, in my experience.
There are two women in my extended family born to mothers who were prescribed DES for the term of their pregnancies. DES was somewhat of a breakthrough drug for baby boom women who experienced miscarriages, helping them achieve motherhood. Unfortunately, DES-supported pregnancies had a downside: a vastly increased chance of cancer for the children born from them â including a 40-fold increase in risk of certain vaginal or cervical cancers for women exposed to DES in utero.
Both of these women spent decades worrying about the impact of DES on their lives. The worry of one woman â buttressed by an aggrievement for the inability of others to sufficiently relate to her worry â arguably contributed to her choice to isolate herself from the rest of our family.
The second woman â whose worry didnât contribute to a desire to turn inward â wound up getting cancer.
At a family get-together many, many years ago, that second woman inquired about the status of the first, wherein the topic of both womenâs worry arose.
âI used to worry about getting cancer as well,â she offered. âBut then I got cancer, and I realized what a waste of time all that worrying was.â
My fortune for being present for that conversation was one of the greatest gifts I was ever given.
A few years later, I had a cancer scare myself; doctors found a very large tumor in one of my kidneys that was likely cancer, and my kidney had to be removed. From the moment of my initial diagnosis through the pathology six weeks later, that conversation gave me profoundly useful perspective. Whether I had cancer or not; whether I had weeks or months or years to live; there was nothing good or productive that could come from time spent worrying about any of it. My time was best spent preparing for my surgery, and enjoying the time that I had available to me.
Life throws us unexpected challenges every day. We would do well to remember that our lives â or the lives of our loved ones â could be taken at any time, including today. If we choose to spend too much of the time we have worrying about all that could be, that time comes at the expense of appreciating what is.
None of the above is to suggest that we spend our lives being foolhardy. Worry is worthwhile when it causes us to slow down briefly to consider the pros and cons of a choice we are able to make. But once our worry runs up against a wall of things that we know we cannot control (including those things that we can no longer control!), we would do well to set that worry aside and spend our mental energy on other things. Our time is best spent being honest with ourselves about what we can control that might lead us where we want to go next.
This approach informs all things agile. When we start an agile project, we admit that there are many things we do not know. Donât obsess over them. If they happen, so be it. Allow yourself to be surprised about the things you find that you could never have anticipated.
Most of all, donât set yourself up to regret the time you wasted while worrying.
I donât think Iâm alone in feeling that the pandemic has made professionally-oriented content feel overtly trite. Families and personal lives are eminently more important than they have been in our lifetimes. Out of respect for my readers, Iâve deliberately reduced my blogging for several months, writing occasionally rather than prolifically. My sense here in February 2022, though, is that people are slowly resuming their interest in new things about our work lives, as long as these things are simple and refreshing. This is the first in a series of columns written in that mold.
Many years ago, when I was in the habit of interviewing software engineers on a regular basis, I would often ask:
Apart from the Sprint itself, what do you feel is the most essential âceremonyâ in the Scrum framework?
I never kept count of the answers I got over the years, but there is no doubt that the most frequent answer â by a long shot â was the Daily Scrum. In many cases, this was the only ceremony the candidate was familiar with, which was a handy sign that he or she really didnât have a full understanding of Scrum.
I recently shared a poll on LinkedIn posing this question, and received the following results:
Sprint Planning: 18%
Daily Scrum: 32%
Sprint Review/Demo: 32%
Sprint Retrospective: 18%
Is there a correct answer? Strictly speaking, of course not. But as a leader whose organizational responsibilities have included âagile transformationâ for as many years as I can remember, Iâve developed an opinion that there is, in fact, one ceremony that is particularly essential in delivering on Scrumâs âinspect and adaptâ principles. That ceremony is the Sprint Review.
The Sprint Review is where all of Scrumâs magic happens. Scrum without a Review is a tree falling in the forest with nobody to listen. The Review is the home of âinspectionâ and the springboard for âadaptation.â
The poll tells me that the majority of my readersâ brains are perturbed right now. Please allow me to elaborate.
First off: The Sprint Retrospective. Sprint Retrospectives are immensely powerful tools, and a place where inspection and adaptation â of process rather than product â takes place. Many Scrum practitioners are dogmatic about Retrospectives â but I like to say that the only place where dogma is acceptable is in religion. Woe be unto you if you treat Scrum as religion. As Scrum teams mature, with healthy self-empowerment and active daily conversations, Sprint Retrospectives are likely to decrease in relevance. Itâs perfectly OK â arguably, healthy â to skip a Sprint Retrospective or two in a Scrum team that has been performing consistently well for weeks or months on end. A high-performing team will always ask itself, and answer honestly: do we need a Retrospective? If not, itâs OK to move on.
Secondly: The Daily Scrum. Hereâs something controversial for you: Arguably, the Daily Scrum is the least important ceremony of Scrum. Why? Because high-performing and tightly-communicating Scrum team members are more likely to understand each otherâs progress, work to come, and barriers as artifacts of their interactions throughout the day. Daily Scrums are absolutely essential for new teams and teams that are not good at identifying and articulating barriers (which is, admittedly, a whole lot of teams.) The most mature Scrum teams I have worked with have incredibly short Scrums, and even occasionally skip them to no ill effect.
Thirdly: Sprint Planning. I know what you are thinking: How can you have a Sprint, let alone a Review, without Sprint Planning? Isnât Sprint Planning equally as important as the Review, if not more important? (More important? Letâs not get carried away! A planned and executed Sprint with no Review is a waste of time.) Hereâs the rub: It is entirely possible to start an agile initiative with a Review of work that was not borne of a Sprint Planning session: A Review that consists of a display of skunk-worked/hobby-level/unplanned work that a team believes has merit. I call this sort of Review a âBig Bang Demoâ; an âorigin of the universeâ kind of event. Once it happens, one of two things follow: a fizzle, or a proper Release/Sprint Planning session.
Of course, most Scrum initiatives start with some form of Release Planning, following up with Sprint Planning, so I can appreciate those of you who argue for Sprint Planning as the most essential answer in my little poll. But: apart from the very first Sprint Planning session, all subsequent Sprint Planning is informed by the outcome of a Sprint Review! Without those Reviews, there is nothing to adapt for subsequent Sprint Planning. If your Sprint Planning sessions donât incorporate adaptation from your Sprint Reviews, I would argue that you have enough certainty in your project to merit a waterfall approach, and that youâve chosen the wrong tool for the job!
This is why, to me, there is no doubt that Sprint Planning is a close second to the Sprint Review in terms of its essence. Scrum is a project management tool for uncertain initiatives.
The Sprint Review is where we learn. It is the fulcrum for all decision-making. If there is no Review, there is no learning, there is nothing for the Product Owner to approve, there is nothing to adapt from, and there is nothing that has been thoughtfully approved for release to the customer.
But all of this is more than a mere thought exercise. If your organization is on an agile transformation journey, you will do well to prioritize the quality of your Sprint Review culture over everything else in your Scrum process.
Make sure that your Product Owner attends and participates in every Review.
Do whatever you can to ensure that the Review grabs attention. Donât ramble; stay focused.
Condition your Product Owners to be honest â yet respectful âabout their feelings. Accepting work that the Product Owner is too uncomfortable to reject is a recipe for disaster â and arguably one of Scrumâs most frequent failure points.
Condition your implementation teams to avoid defensiveness. They should be ready to set aside all or part of a Sprintâs work if that is what the Product Owner decides.
Script and rehearse the Review so that there are no surprises. Donât review work that hasnât been reviewed and tested.
The team should strive to ensure that the Review is a learning experience, each and every time. If there is no learning, there is no point in employing Scrum.
Try to have as much fun as you can! Make the event something everyone looks forward to. Bring donuts. Or ice cream. At the very least, bring a few good jokes and a roomful of smiles.
The Review should feel like the point of Scrum. It should feel like Christmas morning, or the first day of Hanukkah, or any other day that you used to look forward to each year as a child. Done well, it is the âpushâ for the snowball that is your project, and each and every Review will see your snowball moving with greater momentum. If you get your Reviews right, your team will bring a positive and focused spirit to all of the other ceremonies of Scrum, from Sprint Planning through Daily Scrums and, yes, even to Sprint Retrospectives.
âWhat does it mean to be agile?â might be the most common conversation starter in agilityâs entire canon.
I donât really care what people do to achieve agility. Scrum, Kanban, XP, Scrum-banâŚwhatever you want to practice, itâs fine by me. So long as you are:
Trying different things rather than standing still;
Not afraid to fail;
Accomplishing something â even if itâs learning â rather than nothing;
âŚyou are being agile.
But Iâve come to believe that the entire point of an agile approach is to reduce the anxiety of analysis paralysis. If your agile methods arenât doing that, then they arenât serving the intended purpose. Be agile with your agility, and keep trying other things until your anxieties start to decrease. Then â and only then â will you be on the right track.
If you are scratching your head, continue below the graphic…
How do you mean, Drew?
Look at any of the prescribed techniques of agility, and each seems designed to chisel away anxiety in one way or another:
Scrumâs âthree pillarsâ
Transparency: people agree to talk regularly â and not hide or make mysterious â their issues, progress, concerns, deliberations and accomplishments.
Inspection: people agree to share regularly â and not hide or make mysterious â their progress, learning, and accomplishments.
Adaptation: people agree to change in response to lessons learned, thinking only as much as is necessary in the moment, making choices one step at a time.
The backlog to-do list
People agree to have a single place to record their needs so that they are always ready for review, never to be forgotten, and readily re-prioritized as needs evolve.
The user story
People employ this simple device that democratizes and simplifies the articulation of functional specifications, something that once was the domain of highly trained engineers.
Product owners are liberated to merely articulate the who, the what, and the why of their problem, without having to carry the sole burden of the how.
Meeting reduction
People employ agile frameworks with an aim, to one degree or another, to reduce the number of random and/or unnecessary meetings that they have to have.
Agile teams recognize that many meetings are a response to a lack of regular information sharing, and a âsmellâ of something awry. If meetings are an opportunity to âcatch upâ and allow conversation when everybody has been working separately for too long, something else needs addressing.
Slicing
People are asked to break large, abstract needs into small, approachable, and interchangeable chunks.
Waste
Each small step in an agile process provides genuine and meaningful value that addresses present needs. Even when a past solution is replaced with something else, all participants can appreciate the value it provided en route.
Prioritization methods
Whether a Kano analysis, Theme Screening, Risk/Value Assessment, or others, prioritization methods remove guesswork from the pressures we face when trying to be objective in determining priorities.
Other tools
Planning poker: An antidote to the dangers of groupthink, ensuring that each personâs unique perspective is shared and understood without bias from others.
Backlog systems like Jira, Azure DevOps, Trello, Digital.ai and others allow collaborative work on backlogs that significantly reduce or eliminate email communication, ensuring greater visibility into the conversation and progress behind each item in yourâŚahemâŚto-do list.
![[Logo]](https://theprogressivecio.com/wp-content/uploads/2020/07/ProgCIO-1024x1024.png)
