Resilience Now!

It is easy to become cynical when you write about business. The professional world contains mediocre people who get by on connections and charm. Global capitalism's daily grind can often destroy people as it makes decisions in amoral and bureaucratic ways. A cynic or nihilist would snidely chuckle at these realities and say that nothing can be changed and we must accept this adverse situation.

I come from a pragmatic point of view. Business is also a tremendous engine for wealth and good. Under the correct management, I have seen businesses transform communities and improve countless people's living standards. One of those people was me, and I dedicated my career to making business more sustainable, satisfying, and sane. It is a mission of mine. Today, I want to continue my series on changing our perspective on business transformation. 

Since the founding of the Chicago School of Economics, a dominant theory has overcome business leadership. The approach is called the shareholder value hypothesis. It says that the only purpose of a business, especially a multinational corporation, is to generate profit and provide it to the shareholders who pay for the business. In its most simple formulation, the demands of customers, employees, the community surrounding the company, and the environment are less critical than shareholders.

It created plenty of wealth but was not shared equally, leading to the migration of manufacturing jobs to countries with lower wages. It also put power in the hands of people who knew accounting and sales. With a few changes in the accounts receivable report, or a budget cut, share prices would improve without a significant improvement in sales or customer satisfaction. It explains why Southwest Airlines neglected its primitive flight scheduling system until it failed and why a company like iHeart Media is canceling its 401k match. None of these things improved the business of helping customers; instead, they saved money to pay more significant dividends or buy back company stock to juice the share price. 

We find ourselves amid an economy in recession and still generating record profits. The COVID-19 pandemic showed the bankruptcy of this approach because as the world slowed down, thanks to people getting sick and dying, the ultra-efficient networks of supply chains sputtered, and the economic principle of supply and demand began to drive up prices. These efficient systems could not handle disruption, and soon businesses are scrambling to find the raw materials they need to keep operating. People who warned that something like this might happen were shunned in plenty of corporate boardrooms because they were right. After all, there is nothing a potential master of the universe wants to hear less than they were wrong.

Consultants see this situation, and it is evident that we need to focus on making businesses more resilient and responsive to customers. Supply chains need to be more redundant so they can handle disruptions. Information Technology systems need less technical debt and better reliability. The decision-making process must focus on what suits customers and revenue so shareholders get paid with real profits instead of Two Olive solutions. Customer delivery will help fix many self-inflicted wounds that business has created over the last thirty years.

Agile plays a role by allowing people to measure more than dollars and cents. It holds a mirror up to the business; their leaders must be wise and humble enough to act on what they see. Resilience is a verb, and the professional class must practice it. It requires discipline and a sense of hard work, but it is possible. 

Until next time. 

Turning the Ship Around Requires Trust

Software development is a grown-up activity. It requires intelligence, focus, and the ability to overcome massive frustration. Despite the hype surrounding Artificial Intelligence, only humans can write scalable software that delivers real-world value. It is why developers, in their idle moments, often lapse into childhood playfulness. The focus and mental energy it takes to write software requires a release, manifested in Nerf gun fights or an activity that business people might consider childish. It creates the illusion that knowledge workers are overgrown children. In truth, knowledge workers are the most adult people in the organization, and it is time for business leaders to treat the professionals who generate profit like adults. 

We can see this behavior within the business community as CEOs demand that workers return to the office. Most of the requests are tone-deaf and focused more on power than the benefit to the business. I have written about this tug-of-war between the workers who produce the wealth and those who oversee them. I will side with the workers in this case because the COVID-19 pandemic proved that remote work is not only possible but profitable. 

Old habits die hard in the business world, and micro-management of employees is the hardest to extinguish. For decades, businesses trained managers to ensure people followed policies and procedures. To ensure employees were productive throughout the day, managers scrutinized them to ensure they weren't wasting company time in a factory or traditional office. Instead of fostering teamwork or innovation, middle managers enforced compliance. It worked briefly but was deficient as the global economy became more competitive. Customers demanded value and innovation, so mindlessly stamping out parts or filling out forms would no longer work. As software and technology began to eat the world, it was evident that some other approach was necessary.

My mission throughout my career has been to ensure that work delivers value to customers and employees. This week Fortune magazine pointed out that old-fashioned management styles hurt productivity and treat workers like children. My experience in the business world confirms this theory. The new approach was the birth of lean manufacturing, Agile, Kanban, and digital transformation. 

Treating employees like children boils down to a lack of trust. Managers do not trust the people doing the work correctly, and employees often feel they cannot trust their leadership to treat them respectfully. It is in this situation of mutual distrust where many of us work. We can do better. 

I am a big fan of L. David Marquet's book "Turn the Ship Around." In the book, he talks about his experience as a United States nuclear submarine captain. When he joined the USS Santa Fe was the place where sailors had their careers go to die. Morale was low, the Navy rated the submarine at the bottom of the fleet, and senior enlisted people were retiring or quitting at an alarming rate. Over a year, Marquet helped transform the crew from people afraid to make mistakes to leaders who chased excellence. It wasn't an easy journey, and it had plenty of false starts, but the Santa Fe began practicing something called "intention-based leadership," and I am a convert. 

With the help of senior enlisted people and buy-in from the crew, Marquet transformed a low-performing submarine into an example of the Pacific fleet by treating its sailors with respect and providing them with a sense of pride and responsibility for their work. Since a nuclear submarine costs an average of two billion dollars and has the firepower to extinguish an entire civilization, it is an impressive accomplishment. 

Changing a global company is a difficult task, but if Marquet can do it on a nuclear submarine, then as  Agile coaches or scrum masters, we can lead change in our organizations. The first step is changing the behavior of managers who would instead treat the people doing the work like children instead of the grown professionals they are.

It is a small ask, but the road to psychological safety and intentional leadership begins with one step. 

Until next time. 

Going with the Flow of SAFe 6.0

Working as a technology professional is a mixed bag. Some days you feel like the most competent person in the world. Others, you are brutally humbled in ways that threaten to question your self-worth. The key to survival in this industry is ensuring the highs are not too disorienting and the lows do not undermine your self-worth. Since it is the Christian season of Easter in the United States, I had time to concentrate on professional development. With time to study and prepare, I upgraded my SAFe credentials to 6.0. I was also fortunate to earn my Leading SAFe certification. I skeptically endorsed SAFe 6.0 in a previous blog, and something has occurred to me now that I have upgraded. SAFe 6.0 is all about flow, and we need to discuss it. 

I posted a rather jokey video online about SAFe 6.0. The good folks at Scaled Agile revamped many of their training materials and revised a SAFe principle to emphasize the importance of flow. The critical takeaway from the upgrade is the concentration on improving how work flows through the organization. So what is flow? According to this great article from the BBC, flow is a unique state of concentration where we can focus, time distorts passing quickly, and you feel part of something bigger than yourself. When I program or write and am in a flow state, I liken it to my creator placing their hand on my shoulder and nudging me to do better work. I get lost in the act of building something new and different. It is an intoxicating feeling. While in a flow state, I can write hundreds of words in one sitting. Otherwise, putting together a well-formed paragraph is a significant accomplishment.

Fortunately, the folks at scaled agile have provided some good resources for measuring and managing flow. These practices seem commonsensical to people working in Agile for a while, but it is still nice of them to spell it out clearly and concisely. I am particularly impressed with the metrics section of SAFe when they talk about flow. I also appreciate that the folks at Scaled Agile point out that metrics measure progress instead of acting as guidelines or quotas. Goodhart's law looms large over SAFe 6.0, and it is encouraging to see other agile professionals embrace that understanding. 

Is SAFe 6.0 perfect? No, but it is improved, and that is enough. It isn't straightforward, and the 5.1 and 6.0 materials talk about achieving perfection in the organization. No organization is going to be perfect. We should strive for excellence in word and deed rather than perfection because the standards of excellence will continually improve, but perfection is a mythical and unattainable state. It is easier to be in a flow state when striving for excellence rather than attempting perfection.

So SAFe 6.0 is about flow and achieving it as a leader. It's an excellent addition to the agile canon and a helpful concept to understand when helping organizations achieve excellence. So go with the flow and SAFe 6.0.

Until next time. 

 

My Skeptical Endorsement of SAFe 6.0

The philosopher Heraclitus said you could never enter the same river twice. He observed that change is so prevalent in the world that even though we are crossing the same river, its properties are consistently changing, so it is never the same each time we cross it. The same could be true about the technology business and agile. The last three years have been a whirlwind of change. Many of us in the industry are grappling with these turbulent gusts and making sure our systems continue functioning regardless of which way the wind blows. The Scaled Agile network announced changes on March 14th to its certification process and frameworks. I sat through the demonstrations so that you do not have to, which is the topic this week on the blog. 

The big news was the announcement of SAFe 6.0 from the scaled agile network. In a YouTube video announcement, the Scaled Agile network talked about the changes and how they would make SAFe better adapt to the business world and exploit technologies like Artificial Intelligence, Big Data, and Cloud Computing. Color me skeptical because these changes make sense but appear to be additional complexity to a system difficult to implement and achieve buy-in from technology professionals. I am more credible with technology workers when I  talk about agile in SAFe environments rather than the particular teachings of SAFe. 

What was also grating was the nature of the presentation about the new release. Instead of rolling out to an audience of supporters or press the way that Microsoft or Apple does with its products, Scaled Agile produced a perky infomercial with the glossy sheen of an infomercial promoting nutritional supplements or pressure washers. Was the leadership of Scaled Agile afraid of being heckled by its practitioners? What were they afraid of? I am not sure, but now I want to attend the Scaled Agile summit to get a less party-line response to these new improvements to SAFe. 

According to Dean Leffingwell, one of Scaled Agile's founders, "The future deserves a better SAFe." I agree, and some of the improvements do look encouraging. First, there is an emphasis on getting business people to adapt to the needs of agility. Those in the trenches of software development have said this for years, but it is nice to see the acknowledgment. Next, the belief that a business should be a continuous learning culture is now a core value in 6.0. Business leaders will resist being graded like technology professionals, making implementation difficult. Technology people build things that work. Managers and Executives are judged by how likable and persuasive they are in the organization. As a result, business people are good at reducing costs and creating paradoxes, such as the two olive paradox, but could be better at providing customer value. The value delivery is much more complex and nuanced than reviewing an excel spreadsheet. Finally, Scaled Agile is putting together standards for objectives and key results for competency, flow, and business outcomes. The benefit of this initiative is that I can measure something instead of relying on hearsay to effect change.

I will upgrade my credentials to the new standard and adapt to a changing situation. It is easy to look at scaled Agile as the consulting version of a multi-level marketing scheme, but I will give the organization the benefit of the doubt. They still support SAFe 5.1, and their efforts to better train its members are reasonable faith efforts. SAFe does need to change, but it could have been a minor improvement instead of a splashy overhaul. It is the only agile thing to do. 

Until next time. 

Attack of the Scrumzilla!

As a child, I was a big fan of monster movies, from the classic Universal horror films, the campy gore of Hammer horror films, and the unbridled fun of Japanese kaiju films. My favorite was Godzilla because my ten-year-old self identified with the lumbering lizard, and I spent my Saturday afternoons watching UHF television and enjoying these edited television treats. A pre-teen boy has all the properties of a Japanize movie monster. The limbs are unresponsive, the impulse control is lacking, and in moments of stress, you roar for attention. Godzilla was both an inspiration and friend on those lonely Saturday afternoons.  

Plenty of time has passed since those Saturday creature features, but I still see the tropes of those films in my consulting work. The most disturbing is the appearance of a monster that terrorized the cubicles of every business – the scrumzilla! A scrumzilla is a recently minted scrum master or SCP who, with the discipline of a guard at a POW camp, attempts to enforce the rules of scrum or SAFe with an iron hand. These people are the avatars of a dark scrum. These individuals understand the letter of the scrum guide but not the spirit or intent.  

A scrumzilla will stomp over the empowerment of the team because they are experimenting with a new way of working which does not align perfectly with the Scrum Guide or the SAFe specification. These individuals ignore the agile manifest because they follow processes and tools more than they trust individuals and interactions. Without early interventions from management or a coach, these monsters will destroy your digital transformation efforts faster than Rhodan.  

For agile to work, the most important thing you can do is to lead by example instead of by authority. I speak from experience because I was a scrumzilla. It would take me a year with the direction of a patient manager and agile coach to get me to the point where I could get a team to self-organize without being prescriptive. Let people make mistakes and then use those errors as learning opportunities. The approach is not the spit and polish of a military drill team but rather the technique used by bomb disposal units. If you have met anyone involved in Explosive Ordnance Disposal, you know they have a light approach to discipline and a deadly serious focus on learning. It is because a lack of knowledge can get someone killed when working with explosives. 

Just because someone takes a test and passes a training course, they do not become an expert. It takes practice and time before they have the correct temperament to serve others and guide people through the agile process. I have seen plenty of damage done by lousy scrum masters and product owners. Terrible agile coaches are more destructive. If we are going to lead change in organizations successfully, we need to be on the lookout for these scrumzillas before they crush us underfoot. 

Until next time. 

Radical Candor is the New Way of Leadership

My mentor at CAPCO Financial says, "Each day, everyone gets up and delivers value." This aphorism provides me with the desire to persevere in my darker moments. As a leader and agile coach, it has become apparent that most of my job is helping others navigate difficult moments. The pressure of working in the global economy is enormous, and everyone cracks under strain. Their ability to deal with daily adversity during work makes people and teams successful. Today, I want to discuss why you should learn the techniques of Kim Scott's popular book "Radical Candor." 

Scott has a simple thesis in her work. For a leader to be successful, they must care personally for the people they serve and challenge them directly to do the best they can. It is not a difficult concept to understand but hard to put into practice. Mistakes cost money, and careers rise and fall based on small details. The demanding needs of customers are exhausting, and business relationships years in the making can disappear overnight. Being a business person requires a certain amount of toughness. The challenge is to exhibit this mental toughness without inflicting it on the people who work with you.  

It is apparent when you challenge people to improve performance or adjust to changing situations. Speaking up is problematic because many people want to be well-liked by others, and telling someone they are failing risks rejection. Scott understands this, so she comes up with strategies that help leaders correct the conduct of the people they serve. In my experience, people want to know if they are doing good work or how to do a better job. To make this approach relevant, you need to care about the people working with you.  

When we talk about caring for people, it means learning about their families, what they enjoy off hours, and listening to what they have to say. I struggled with this skill, and only in retrospect did I realize that not caring personally about the people under my care creates a toxic type of management known as obnoxious aggression. It is when you challenge others but do not care about them. After some time, I had one team member in open rebellion and another dissociated from the work. I was determined to be different in my next leadership role. 

This humility is hard-earned thanks to numerous failures and false starts during my career. Today, I accept my failures and use them as valuable lessons for my next leadership role. Vulnerability is a superpower in today's business world because it helps you connect with other people and proves that when you must be firm, it comes from a place of empathy instead of malice. The world contains plenty of talented jerks, be the radically candid leader. 

Until next time. 

Saying Yes and No a New Way

The seasons are changing, and the chill in the air represents a sense of urgency organizations have to meet their financial and project goals. I am one of those people who accomplishes these goals and helps organizations succeed. Over the years, I have discovered that the most challenging part of the job is not the engineering but the interpersonal and political skills necessary to get work finished at large bureaucratic businesses. This week I want to look at a skill I learned that had become an essential tool for my success in the weird business world of business.  

I feel strongly that a Liberal Arts education is valuable in business and technology. You can teach anyone to write software and perform basic development tasks, but the real skill is communicating with people via the written and spoken word. Putting yourself in another person's shoes and spotting spurious arguments are also valuable business skills. A liberal arts education helps teach these skills, and the business world is better because of people with liberal arts backgrounds. I am biased on this front because I am a liberal arts graduate, and exposure to philosophy, theater, literature, media, and writing traditions has given me a competitive advantage in my career.    

In high school and community college, I took theater courses. Each student learns how to improvise on stage. It was a great experience, and I had plenty of laughs, but I did not realize the presentation and speaking skills I developed in a theater would stay with me for the remainder of my life. As I began meeting facilitation, I remembered a technique I learned in improvisation. Performers know to be unselfish with other performers and internalize the maxim of "…yes and." During a strange situation or when you are stuck on what to say, you look deeply into the eyes of your fellow performers and say "yes and…." At that point, the other performer, if they are paying attention, will pick up the performance and move it in a different direction.  

As a coach, in meetings with people who are reluctant to talk, I often use the "yes and…" technique to elicit more feedback and information. It is a great way to break the tension, and it helps remove the responsibility from one person speaking to the group. It transforms meetings into a more participatory experience because, as the facilitator, you lead them to say what needs to be understood instead of dictating to the group.  

We often have deadlines and other challenges which involve conflict. That conflict can be acknowledged if we use language that is a little less violent. Lately, I have been using an additional phrase: "no, wait…."  For example, I had someone demand that I deliver a user story. I said, "No, wait, I understand this is important, but where does it fit in with the release schedule."  After some thought and waiting, the person making the demand backed down. Another example is saying, "No, wait, do I understand you correctly?" The approach makes the conversation more participatory and helps facilitate a more profound understanding.  

We all have to say yes or no at work. Using theater improvisation techniques makes the process easier and allows people to feel involved in creating value. Feel free to give it a try.  

Until next time. 

Learning to Lead in Strange Times

The current economic situation is strange. Inflation is increasing, and at the same point, the employment market looks strong. Prices are rising, but at the same time, employers want to recruit and retain talent. It is enough to make an economist feel like they are being drawn and quartered. What is going on as an agile leader, and what do you do?  

It is easy to be gloomy in the present economic times. Forecasts say a recession is coming, and the price of everything has taken a colossal spike. We even see layoffs at companies like Meta. As much as I like seeing Marc Zuckerburge receive a dose of reality, scratch below the surface, and you will see that the job market is more robust than it has been in my lifetime. According to the Bureau of Labor Statistics, there are over 10 million open jobs or 1.7 jobs per person looking for work. It is the best it has been in twenty years. 

Workers are gaining power and can afford to be picky with who and where they work. We can see this in the public conversation about hybrid work and returning to the office. It also includes the discussion about quite quitting and the equally awful practice of quite firing. When you think about it, the debate centers around trust. Workers want to work to be productive and fulfilling, while employers demand their labor dollars to generate a profit.

Employees want to do work that provides for their families and generates some form of fulfillment. Employees also want to take pride in what they are doing; do the widgets they produce help the environment, are the customers thrilled with the gadgets, or do they help improve communities? I do not know an individual who wants to sell a product that causes cancer or is flammable on children. Workers also realize that with modern technology, they can work anywhere. Long commutes to the office are unnecessary, and saving time allows people to look after their kids and aging parents. I also think it eliminated a form of theater where office workers looked busy to their managers because those managers were outside their doors, snooping on the employees in the cubicles. With the charade, gone employees could do their jobs and be authentic without playing games in an office. 

Amy Chow, the former CEO of AT&T Business, this week in Forbes magazine says as business people and leaders, we need to be aware of the “…what, where, when, and how” of work. The ‘what’ is non-negotiable. Accounts receivable need to be collected, sales calls need to be made, and new products need development. Thanks to COVID-19, the ‘when’ and ‘where’ of work do not need to happen in an office during business hours. Not it can occur in coffee shops around lunchtime or late at night after story time with the children. The ‘how’ was always up to employees, and technology makes creating high-quality results that deliver customer value easier. An old line manager wants to control three of these parameters. Agile leaders must respect that they can only handle one of them. 

Business people love fancy offices and corporate campuses because they represent the physical manifestation of their company. The coffee bars, ping-pong tables, and minimalist architecture are all a façade to entice workers and customers. The last three years have shown that image as empty because innovation can happen anywhere. It might be time for business leaders to review their construction and lease plans. 

These economic times are strange, but one clear thing is that workers are growing in power, which is changing the office. If we are serious about agile, we must respond to the change instead of following the old plan. 

Until next time. 

Don't Hate Agile, Hate Bad Agile

The internet is awash in pixels about the trend of “quiet quitting.” Plenty of talented people have sounded off on the subject online.  I do not think I can contribute anything more substantive to the debate.  Instead, I want to talk about another trend popping up on the web.  Many people are talking about poor agile implementations, and I think we need to discuss it.   

Agile is a growing paradigm in the business world, and as an early adopter, I have seen a few bothersome trends.  Allen Holub on the Continuous Delivery YouTube channel gave some strong opinions about agile and how it is failing organizations.  I am an outspoken critic of poor agile implementations and dark scrum, so when I heard Holub bemoan the state of Agile, I found myself chuckling along in agreement about most of the things he had to say.  

The first trend is the shift from technology professionals becoming agile advocates to project management professionals advocating agile.  It is a standard survival strategy for business people to pivot when they see changes in the market.  The cohort of PMP-certified professionals witnessed the changes in the market and then retrained to become scrum masters and SAFe professionals.  It is not an alarming trend, but they took the values from traditional project management and business leadership and attempted to dress them up with agile terminology.  The effect was the worst of conventional project management combined with the frantic nature of iterative development.  Not to over-generalize, but these people are dogmatic and accustomed to enforcing rules instead of the pragmatic delivery of solutions.  These people enforce laws and generate outputs, but customer value is an afterthought rather than a central focus.  

Next, business leaders feel that their problems will evaporate if they do agile instead of having an agile mindset.  Jeff Sutherland points out that agile and scum hold a mirror up to the organization.  It is then up to the organization to effect change based on what they see.  Often problems are hiding in plain sight.  Philosopher Slavoj Zizek calls this unpleasant part of human nature Unknown-Knows.  We can ignore evidence when confronted with it.  I have witnessed many business leaders act this way because they cannot effect change or feel the necessary change might impact them negatively.  A manager loves the rapid cycle times, feedback, and transparency that agile offers but only sees accountability pushed down to the teams as valuable instead of accountability, which percolates into the organization as part of the agile mindset.  I liken the situation to someone who wants to get into better shape but can’t seem to quit smoking.  

Finally, the licensing and training for agile professionals are creating what Holub calls “a priesthood that does not understand the scripture they are professing.”  I am a big supporter of formal training in the technology business.  The pace of change requires any good professional to relearn their job every eighteen months.  The proper training and curriculum by the various organizations like SAFe, Scrum.org, and the Scrum Alliance are exceptional at teaching the formal theory of Agile, but in the trenches work of delivering software is often ignored.  It creates a situation where people trained in this manner fall back on the processes they were taught instead of concentrating on the individuals and interactions necessary to get work done.

A classic example is my recent interaction with an agile coach with a PMP certification and SPC credentials.  This person never wrote a line of software or delivered value to customers.  The only experience they had was providing reports to upper management.  Suffice to say; they failed spectacularly.  

The agile reformation is over twenty years old and is starting to show growing pains as the initial enthusiasts become supplemented with careerists and ticket punchers in organizations.  Don’t hate agile; instead, let us hate the people diluting and undermining its effectiveness.  I fight that lonely fight each day. 

Until next time. 

Organize Development Teams to Deliver Value

I am working on a large software development project.  By my estimate, we have over one hundred teams working on this project.  Since it is a significant financial client, we use Scaled Agile Framework for the Enterprise, or SAFe for short.  It is a complex process with lots of moving parts and little room for error.  I am also experiencing a common problem with large SAFe implementations, and I want to discuss it today.  

SAFe is the de facto standard for large software projects.   For executives, it helps standardize the process and is a reasonable attempt to coordinate numerous agile teams.  Unfortunately, most business leaders do not understand how value flows through the organization.  The larger the organization, the more difficult it is to know how the firm generates value for customers.  Thus, teams are organized not around value but by technical specialty.  Front-end developers work on one team, database specialists on another, and middle-ware experts on APIs are on a different team.  It is a logical way to organize technical professionals, but it makes delivering software on large projects a headache.  

Specialized teams are fantastic if you organize your business to embrace the status quo.  Still, suppose you are attempting to innovate or build new services to help customers.  In that case, you need cross-functional teams because specialization means no individual team is accountable for getting work finished.  It becomes a deranged relay race where work passes to others, and no one is sure it has reached the finish line.  

For instance, if you are a clothing company offering a new mobile application for customers to customize their styles.  You could do the following: hire a design firm to build the mobile application and take an in-house technology team to hook into the current sales and invoicing system.  Finally, you have a group of manufacturing engineers take that data to reconfigure the factories to address the customer demands.  As an executive, it makes perfect sense, but the reality is that the mobile application developers do not understand how to communicate with the sales system.  The manufacturing team does not have what they need from the mobile application or the sales system to create high-quality products on demand.  They are traveling a logical path along a road to ruin.  

What makes the situation more troublesome is that SAFe has the concept of release trains which says these three teams above should be able to work together, hand off work, and get things done.  The trouble is the decision maker does not understand how the software and system should work, so they do not know how to construct the teams.  A team of mobile specialists, a team of sales and invoicing specialists, and manufacturing engineers is a straightforward way to break down the groups.  Alas, these teams will not work well together.  Instead, reconstitute the units, so mobile developers, sales and invoice specialists, and manufacturing engineers work on the same team.  Condense these three teams into two.  

What will happen is when a mobile developer has a question about the data they receive from the sales and invoice system, an engineer with experience will be able to help on the spot.  Likewise, the manufacturing engineers will understand what the sales and invoice system is doing because they will be working side by side with the necessary technical professionals.  Finally, the three teams blended into two sections, one for standard sizes and the other for children's; they can share solutions to make each group more efficient.  Instead of work being passed around like a hot potato, people work together to deliver value.  

Some of the biggest problems in SAFe happen when work passes between teams.  As a coach and agile professional, it is your responsibility to reduce this dysfunction as much as possible.  Organizes teams around value to the customer instead of technical proficiency, ensuring work when assigned can be taken from beginning to end with zero handoffs between teams.  It will make your release trains more efficient and save you from unnecessary headaches.  

Empathy is Superior to Self-Confidence.

Some of the biggest mistakes a person can make are those made with absolute enthusiasm is confidence.  Blissfully they indulge in activities that they are going to regret significantly.  In my experience, alcohol is involved, but the more toxic substance is ego.  Nothing is more dangerous than a leader with a messianic vision and the self-esteem to match.  These people lack self-doubt and emotional intelligence and are responsible for destroying millions of dollars in wealth and countless organizations.  This week, I want to have a necessary discussion about humility.  

The web is crawling with numerous research papers talking about the Dunning-Krugar effect and how we promote incompetent people into positions of authority.  Unfortunately, I have witnessed this dysfunction firsthand, which undermines your confidence in the business community.  The leader promoted on looks and charm becomes a high-priced disappointment as a rule rather than the exception.  Treating confidence as a force multiplier often eclipses competence, empathy, and experience.  The harsh truth is the best leaders need the above mixture of skills to be successful. 

A leader who listens with emotional intelligence and empathy is superior to those who only exude self-confidence.  In the face of challenges, these two tribes of leaders differ significantly.  A charismatic leader will see an obstacle as something which must be trampled or bludgeoned into submission.  This approach works in the short term but often creates more problems down the road.  A leader with emotional intelligence sees an obstacle as a means to pivot and change directions.  The ability to adapt and shift focus when necessary makes these leaders superior. 

Edward Deming said survival in business is not mandatory.  The world of commerce requires us to be adaptable to change.  Thus, being flexible is a powerful business trait.  Another reason the emotionally intelligent leader is superior to charismatic leaders is the ability to change.  When confronted with a compromise or trade-off, a charismatic leader will become stuck, while emotionally intelligent leaders will focus on a pragmatic way to accomplish work.  

The business world is a chaotic place.  It feels like you are traveling in a run-a-way train, and no one can ensure it does not fly off the tracks.  We have plenty of passengers on the train and people willing to shovel coal into the boilers, but a steady driver is hard to find.  The person who asks, “who is driving this train?” is often conscripted to take charge and attempt to bring order to the chaos.  It takes an extraordinary leader to take control of a run-a-way train.  These reluctant leaders approach their jobs with humility and pragmatism because they know mistakes could cause the metaphorical locomotive to plunge into a bottomless cliff.  

The ability to listen to others, exhibit emotional intelligence, and put themselves in the shoes of others is a necessary skill to be a successful leader in a complicated world.  It is not the traditional form of leadership but one we need today.  

Until next time. 

Don't Make SAFe Tool of Mass Destruction

The last week was a whirlwind.  I muscled my way through Sprint planning with my development team.  Then, I studied for and passed my Lean Portfolio Management test from the SAFe organization.  Finally, I found myself reading David Foster Wallace and spending time with my family in the Wisconsin Dells.  Yes, it was exhausting, but it was worth every moment.  Since I have earned credentials from SAFe, I feel compelled to say a few words which will contribute to the debate about scaling agile at large organizations.   

It is no secret that the agile community has some deep schisms.  The no-estimates and the estimates cohorts are bitterly divided.  The debate has become so toxic that people who used to be colleagues no longer speak to each other.  People have closed Twitter accounts, and attacks between the two factions are personal and filled with abuse.  It is a shame because most of us involved in the debate want to deliver better software. 

The other major fault lines in the agile reformation are those who practice the Scaled Agile Framework for the Enterprise, or SAFe for short, and those who use a different approach to apply agile to large organizations.  The debate between these factions is just as toxic as the no-estimates debate.  I understand why so many people are hostile to SAFe.  First, SAFe lacks credibility in the engineering community, with software engineers in a survey saying they are dissatisfied with SAFe.  Next, credibility with the Agile community is low because none of the original signatories to the Agile Manifesto have endorsed SAFe as a way to address agile for large organizations.  Finally, the popularity of SAFe in large organizations creates a counter-cultural backlash.  

These three factors combine to create a powerful feeling of contempt and resentment in the agile community.  It is rare to hear SAFe people speak at either the Scrum Alliance Gathering or the Agile Alliance conferences.  Instead, they have their conference separate from other organizations.  It is a clear division that is reinforced by money and pride. 

I have embraced Agile since 2009.  I earned credentials in Scrum in 2013 and SAFe in 2017 before letting them expire.  I know enough about agile to realize it is not a magic bullet to cure the dysfunctions at large corporations.  As Aristotle said, there is a difference between right and wrong, and people will choose the right path if they know the difference and are educated about it.  Over twenty-five years of working in the business world have provided me with numerous counter-examples to Aristotle's thesis.   People can be callow, selfish, uninspired, and destructive; a toxic culture will defeat even the best agile implementation. 

I feel a similar way about SAFe.  In the hands of a newly minted SPC who only worked as a project manager, SAFe is a tool for mass destruction.  However, with skilled scrum masters, trained and knowledgeable product owners, and an executive team willing to learn new ways of leadership, SAFe is a tool that can improve a business's ability to deliver value to customers. 

Agile is growing.  The growth means that there will be debates and disagreements about how to help organizations do it properly.  I am not arrogant enough to proclaim one authentic way to help organizations achieve agility.  I am sufficient enough as a servant leader to understand that at the end of the day, success is not following a set of rules but rather delivering value to customers and helping the people we work with improve.  Anything else feels like a toxic debate.  

Until next time. 

Leadership as a Way to Defeat Tragedy

The last week has been particularly brutal if you follow current events.  It is relevant to me because my life partner is a teacher, and I cannot imagine her sacrificing her life to protect children from a shooter.  The news and social media are awash in hot takes and lurid details.  It is overwhelming and tragic.  Amid all of this grief, we need to ask ourselves in the Agile community what lessons we can learn and how we can help others. 

I have been adamant that I would not write about politics on this blog.  There are plenty of people who have opinions on the political left and right.  I will defer to them.  When I talk about politics, it is often in business law and policy—being a professional as long as I have gives you a unique perspective on how a business succeeds and fails.  A lifetime of experience colors your opinions.  A kaleidoscope of people dominates the world of business.  The foremost thing I have observed is that strong servant leadership is a force multiplier in the success of an organization.  Outstanding leadership makes the difference between slogging away at a job and finding purpose and camaraderie at work. 

I pointed out last week that mental health is a serious concern and business environments actively undermine mental health.  Violence in the workplace is a symptom of deep sickness.  It shows a failure of leadership and collective vision.  It should not be this way.  

A school or workplace should never drive a person to violence.  It is up to people like me to help others be heard and understood.  People want to work and learn with others in situations where they can succeed and thrive.  The agile reformation was born because the business world was failing to deliver value to customers.  That failure was impacting the lives of millions of people around the world.  

I do not have easy answers, but I want to make the world less unequal, cruel, and stupid.  I intend to do that in the context of the business world.  First, I try to do my best to be a servant leader each day.  I am an example of behavior, and it is the best teaching tool for small teams.  If you have the back of your team when times are tough they will have your back.  Others will either model the behavior or understand the norms accepted on the team. 

Next, radical candor should allow you to communicate effectively with your team and others.  Care personally about your people and challenge them directly so they can grow and develop.  Not everyone will succeed, but you should allow everyone to try.  

Finally, we need to stop treating people like “resources.”  Each person is a unique individual with hopes, dreams, and families.  Grinding people down like pencils is bad business because it will drive good people away from the organization.  Burning out people will also turn potential customers into vandals against the firm.  In the worst case, they will resort to violence.  

Leadership is complex and a lonely road to travel, but it can make the world better if done correctly.  It gives me a little small comfort as we attempt to make sense of the death of nineteen students and two teachers.  

Be safe and kind to each other; until next time. 

A Few Words About Mental Health and Agile.

The month of May is mental health awareness month.  In many businesses and cultures, discussing mental health is a death sentence for your career.  Business leaders are afraid to trust people who struggle with symptoms of mental illness, and the stigmas associated with being mentally ill stretch back hundreds of years, forcing people to mask and self-medicate their problems.  I speak from experience because I have witnessed too many neurotic, damaged, and plain mean people placed in leadership roles to hurt others.  These are people with the self-awareness of small furry woodland creatures who then inflict harm on the people they are supposed to serve.   

I have written about mental health before on this blog.  My primary thesis is that the pressures of contemporary business combined with poor leadership create a cycle of abuse and illness in industry.  The situation is made worse with alcohol and other drugs to self-medicate.  It is a prescription for a decline in mental health and business success.  As agile coaches or scrum masters, we need to be frank with ourselves and others when we see this cycle perpetuated. 

Many of the worst environments I have worked in have leaders who are not accustomed to hearing no and possess deep wells of rage.  These individuals were also good at something called gaslighting.  I have had serious moments of doubt about my competency and sanity working for these individuals throughout my career.  Each lay-off or termination became a liberation as time and distance taught me that working someplace else was a good career move.  

It is deeply dispiriting to work for an organization that sets you up to fail.  It could be unrealistic deadline pressures or workloads that require more people than the organization is willing to hire.  It could also be giving people responsibility for situations without the requisite authority.  You have not been in technology until you have seen an IT director in the cardiology unit receiving a phone call from the CIO about a software system before they experience an angioplasty.  The organization demoted that person when they returned from the hospital because he did not deliver the software on time.  Ironically, his replacement received more people to do the work and money to get the job done.  

Organizational dysfunction requires people to work together in good faith to attempt to fix those problems.  Do not drive yourself insane for organizations or people who do not care.  If the organization does not care, neither should you, and you should work elsewhere.  As my mentor, Monica Gilroy, says, “do not run yourself ragged for a ragged organization.”

Work should be sustainable, satisfying, and sane.  If it is not, then walk away for your mental health.  Life is too short to wallow in madness. 

Until next time. 

Small Changes Can Work Miracles

I am working on a monstrously large project.  Hundreds of developers, project professionals, quality assurance people, and executives are involved in the daily grind of releasing the product.  Being a small gear in a giant machine that builds software is humbling.  You spend much of your time waiting for others and making sure you are being helpful rather than a hindrance.  It is easy to become discouraged because you are an alone person lost in an army of developers.  Today, I want to point out where everyone on a project makes a difference, continuous improvement. 

Large enterprise projects are an endurance exercise.  You are toiling away, hauling huge stones to fit in place for the benefit of others.  The work carries on for years, and while you have deadlines to meet, you do not receive an opportunity to view how the collective group is doing.  I feel like the numerous extras in the Cecile B. DeMille film "The Ten Commandments." It looks like the antithesis of agile, with ponderous progress dictated by supervisors and pharaohs from afar.  

From a distance, gigantic projects look ponderous and top-down.  The agilist comes into the picture when they motivate groups of smaller teams to work together more closely and individual units to improve.  Pyramids take time to build, but the stones can fit together more efficiently, the joints can be tighter, and the worksite can be safer so that the workers eventually have a chance to return to their families.  It happens when you concentrate on making minor improvements often.  

For instance, the most significant delay in my team meeting the definition of done was waiting for test data creation by quality professionals.  After some discussion during a retrospective, the group agreed to create test data without relying on the quality professionals.  It took two sprints of effort, but the development team is moving faster and improving quality because they do not have to wait on other groups like quality to complete their actions. 

Small changes make a massive difference if they happen regularly and over time.  Eventually, these changes act like compound interest over time, increasing the product's value and the team.  For example, if you have a three-week sprint cycle and the team improves its throughput by one percent each sprint by the end of the year, the team will have cumulatively enhanced by 17%, which gets people promoted in the corporate atmosphere.  

The agile focus on empirical measurements of progress and attention to improvement is how big projects succeed.  If each area improves, it acts as a multiplier across numerous teams.  Managers will copy the success of others so that others adopt your improvements to become the improvements of the entire organization.  

Yes, giant projects feel like being one of the many enslaved people building the Egyptian pyramids.  However, if you focus on continuous improvement and helping others succeed, the toil is more pleasing.  

Until next time. 

Send Talented Jerks Packing with Agile and SAFe

One of the biggest stereotypes in the business world is the talented jerk who leads by pure force of will.  Through bullying behavior, intimidation, and promises of advancement, these individuals create an environment of fear to forward their business goals.  It is often an exploitive process where your enthusiasm and eagerness to please often are transformed into a weapon.  I have spent plenty of time working with these individuals as a professional.  As a coach or scrum master, it is up to you to call out the toxic behavior and strive to do better.  The contemporary office should be less “The Devil Wears Prada” and more humane. 

The Agile manifesto principles and the SAFe Lean-Agile principles explicitly state that domineering jerks are not the way to lead teams.  The Agile manifesto recognizes that organizations should “build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done.” SAFe says, “Unlock the intrinsic motivation of knowledge workers.”  These statements are an open repudiation of the top-down command and control approach championed in popular culture. 

I have had plenty of misfortune working with awful people.  They were emotionally erratic, and you spent your time in the office waiting for an explosion or a well-directed torrent of abuse.  Power is misused, and when something goes wrong, they are the first to deflect blame.  You are right if it sounds like abuse.  Office workers and blue-collar folks suffer through the experience of potent jerks, which changes them.  Instead of enthusiasm and professional pride in what they do, abused workers slog along doing the bare minimum to collect a paycheck.  

Forbes magazine points out four possible paths to power in organizations:

• Dominant-aggressive Behavior: using fear and intimidation.
• Political Behavior: building alliances with influential people.
• Communal Behavior: helping others
• Competent Behavior: being good at your job 

I think organizations that promote based on helping others and being competent will be more successful than those that concentrate on power and politics.  It is also why both the Agile manifesto and the SAFe lean-agile principles use similar language to describe how organizations and teams should operate.  

I have rallied against talented jerks my entire career.  It is a natural response to being their target for most of my life.  As I have grown older, I have discovered there is not much intellectual difference between the mean girl who treated you like a grub in geometry class and the marketing professional who expects the web developers to write content for the website with multiple revisions.  It is best to sideline and expose these people because they will undermine the organization in the long run. 

We see plenty of cruelty, inequality, and denial in media, business, and politics.  The only way to fight it is to be kind to others, competent at what we do, and provide an environment where those traits are discouraged.  I am not perfect at this, but I strive to get better each day and be an example for others. 

I joined the agile reformation because I felt there was a better way to work.  Today, I feel just as strongly, and the first step is to create an atmosphere of kindness, cooperation, and competence at the office.  Next, it is exposing talented jerks.  Finally, breaking the cycle of abuse we all experience in a typical business environment.  I will take that any day over a Prada suit.  

Happy Easter and until next time.

Be the Glue That Holds Agile and SAFe Together.

Like many professional people, I spend plenty of time retraining for my job.  Technology is one of those activities where you have to relearn your career every eighteen months, or you will become unemployable.  It is a tricky tightrope to walk.  My firm sponsored a training session, and it was for the Scaled Agile Framework for the Enterprise, or SAFe for short.  It is the most popular format for scaling agile at a large organization.  Still, numerous critics see it as a disingenuous approach to helping an organization become more agile.  I have written about these disputes before on this blog.  Today, I want to discuss something which does not change between SAFe and traditional agile, and that is the necessity for servant leadership to make either successful.  

Simon Sinek released a great TED talk about leadership.  He talks about how leaders can inspire trust among the people they serve.  Anyone can be in charge, but a true leader is someone who inspires confidence among the people who get the work done.  Leadership is not a title bestowed by others, but something earned.  A boss will give orders, while a leader will outline a vision and intention to let teams figure out what needs to get done.  It is a very different vision of leading others, but I believe it is truly effective. 

Agile has twelve principles that guide how a team should develop solutions; SAFe has ten.  If you create a Venn Diagram of these two sets of information, they have significant overlap.  Both principles stress working in small chunks, so it is easy to change direction.  Next, both require rapid inspection cycles to determine whether we deliver the work with the most value—finally, both believe in self-management and individual initiative among technology professionals.  

I am a big proponent of the notion that software is eating the world.  If a business is going to be successful, it must conduct itself like a software business.  Instead of a command and control approach to doing things, it requires collaboration and compromise.  Finally, it demands a different kind of leadership where you serve others instead of promoting your selfish agendas.  Sinek says that officers in the Marine Corps eat last because any Marine officer must look out for the well-being of the people they lead.  Often, they do not get to eat, and when they do, the food is cold, but it creates a level of trust with fellow marines, allowing them to function in the most desperate of situations. 

People like having plenty of authority, but being a servant leader, requires you to assume responsibility for yourself and the people you lead.  SAFe and Agile need leaders who put the goals of the team and the project ahead of their selfish agendas.  It is looking out for others and focusing on outcomes rather than busywork.   

Servant leadership is always a work in progress and will constantly challenge you throughout your life.  Some days will feel like an abject failure, and others will become a moment of triumph, but to be successful, you need to show up each day and do the best you can.  Teams worldwide use SAFe or Agile to do better work, but the glue that holds both together is servant leadership. 

Until next time. 

  

Disagree and Commit is the Agile Way to Resolve Disputes

Presently, I am working on a gigantic project.  It is the replacement of a forty-year-old enterprise system.  Teams reside over three continents, and conference calls have hundreds of participants.  Projects like this require millions of dollars and the patience of Job.  I exist as a product owner who intersects with the organization's remaining units.  It is a tremendous amount of responsibility.  Today, I want to discuss a vital work component on a gigantic agile project. 

When working on a massive project, the biggest challenge is making sure the work is completed quickly and with sufficient quality.  Teams hand off work to each other, and those are usually the pain points as one group takes over the work of another.  It is why scaling frameworks like SAFe, LeSS, and Scrum at scale have become so popular in enterprise-scale projects.  The additional artifacts and rituals of scaling frameworks are supposed to prevent botched handoffs and production environment problems. 

Disagreements are going to happen.  Large agile projects are strange because there is a tension between the need to manage hundreds of people to get a job done and the desire for those people to be empowered and autonomous to get the job done.  How we handle those disagreements can make the difference between success and failure.

I received a directive from an executive to do something, contradicting over twenty years of my experience as a technology professional.  I objected and said it violated both the letter and spirit of agile.  The response was terse, "We are a SAFe project, not an agile project." At that point, I had some choices.  I could be insubordinate and not carry out the order.  My other choice is to follow the directive unquestionably.  I chose a third path that agile coaches embrace called "disagree and commit."  I explained the foolishness of estimating research spike and then said, "You are in charge of this project, so to save time, I am going to disagree with you but commit to this course of action."  You are not being insubordinate, and you are pointing out a future complication or challenge which the team can resolve when deadline pressure is not severe. 

Six years ago, Jeff Bezos, in his letter to shareholders, said the disagree and commit approach is how Amazon was able to create Amazon studios.  It is also a decision that can easily be reversed.  Any discussion about the merit of a process can get vetoed.  Fortunately, you can change most decisions, so the quality of a decision is not what matters but the speed.  

In my brief tenure on this project, I have delivered software and improved the process for the team.  I believe that my approach will be vindicated, but for now, I will commit to the other one because it is easy to reverse when the time is correct. 

The manifesto says working software is the accurate measure of the progress of an agile project.  Disagreement is a natural part of creating working software.  Saying you disagree with someone is not insubordinate; it is sticking up for your development team, quality of work, and professional ethics.  Committing after disagreement means you want to get the working software into production sooner.  It keeps the bills paid and ensures a massive project does not collapse into a big ball of mud.  

Until next time. 

SAFe is More Agile Than You Think

People who work in the agile world have two common characteristics.  The first is we are deeply committed to making work more sustainable, satisfying, and sane.  We also have strong opinions about how to make work better.  Like any other growing movement, you have a few splits between various camps about multiple practices.  I have spoken about the gulf between the no-estimates crowd and other agilists.  I also pointed out that the agile community often ignores the agile manifesto's admonition to put individuals and interactions over processes and tools.  Today, I will step into the debate between those who hate Scaled Agile Framework or SAFe and those who are more nuanced. 

Background –

I was exposed to SAFe when I attended training with Andrew Keener in 2017.  Agile worked on small to medium-sized projects, but a big challenge was getting it to work on a considerable scale.  Projects with thousands of developers and collaboration between numerous specialties, including hardware, mainframe, and legacy data systems, did not fit neatly into either scrum or kanban.  SAFe provided the answer with two key innovations.  

The first was the concept of a release train which made it possible to take numerous agile teams and coordinate them. Groups part of the same "train" would inspect and adapt merging code and sanding off the rough edges to create working solutions.  The other innovation was called product increment planning or P.I planning.  P.I planning is a series of meetings where the product owners and scrum masters would collaborate to eliminate dependencies and plan.  To coordinate these activities, SAFe created three new positions; a release train engineer, a program manager, and a software architect.  SAFe also provided a means for executives, and the rest of the organization to collaborate with release trains without interfering with the work.  

Backlash –

As SAFe grew in popularity, it spawned a backlash in the agile community.  Soon, SAFe had a reputation in agile circles similar to Nickelback in rock music circles.  The cool kids did not think it was good that this music and agile scaling technique became popular.  It spawned a backlash.  The web contains plenty of blogs and Twitter threads filled with earnest and lazy criticism of SAFe.

The best article about the criticism came from Gianpaolo Baglione, who pointed out that most of the criticism of SAFe fell into ten familiar categories.  I recommend you give it a read.  Many of the lazy arguments against SAFe are personal attacks on its authors or pointing out that it creates unnecessary layers of bureaucracy.  I have heard many of these arguments firsthand, and I want to acknowledge the more credible criticisms versus the lazy ones.  

Nuance –

I believe SAFe is an imperfect solution to the real problem of scaling software projects.  Being unable to deliver large software solutions hampered the Affordable Care Act's implementation and had deadly consequences for Boeing.  It provides a valuable starting point for managing massive projects.  I believe SAFe has three principal shortcomings; customer focus, poor leadership, and the P.I. sprint.

The agile manifesto says that customer collaboration is superior to contract negotiation.  If you look at the infographic on the SAFe website, it is tough to find the customer and relate them to the release trains.  I also notice that many conversations on agile teams are focused on meeting the goals of the release train rather than the customer.  I think more emphasis should be on the customer instead of less.  We should adopt the same attitude toward the customer which NASA did during the Apollo program.  Everyone, including the janitor who cleaned the bathrooms, said they were working on putting people on the moon.  When they crop up, conflicts should center around how the customer would be affected instead of personal agendas.  Once the focus is back on the customer, most agendas fall away.  

Next, we need to expose poor leaders within organizations and hold them accountable.  Instead of credible action, people who provide lip service are corrupt in many institutions, and SAFe is just as susceptible.  I remember being told by a Vice President that I could not discuss our challenges with DevOps with other departments because he did not want the "dirty laundry" of I.T. exposed to other groups.  I took a vow of silence instead of being transparent with others.  I left the company, but the V.P. still has his job, and the company filed for bankruptcy and laid off half of its people.  I consider this poor leadership and lack of transparency to be a factor in the companies failure.  Agile and SAFe have numerous feedback loops to fight poor leadership, but it requires people to set aside the status quo and commit themselves to something greater than themselves.  SAFe is nominally part of the Agile reformation, and so it is necessary to inspect and adapt everything in the organization to make things better, especially leadership.  

Finally, SAFe has what is called a P.I. iteration.  While leadership, scrum masters, and product owners prepare for the next increment during product increment planning, the development team coordinates to make sure code is ready for release.  It is supposed to be a training and development period.  In reality, the P.I. iteration is a frantic rush to release with plenty of "crunch time" and late nights making sure everything works.  SAFe must recognize that the development cohort must embrace software artisanship and DevOps if hundreds and thousands of people work on a project.  Otherwise, P.I. week is nothing more than a glorified hardening sprint, a severe anti-pattern in agile.

Conclusion –

The use of SAFe as a scaling method in business is imperfect.  It is up to people like me to help make SAFe behave more responsive and agile.  Let us start from the agile manifesto to make sure everyone is practicing the values and principles of agile.  SAFe needs more customer focus, and poor leadership needs exposure as part of the inspection and adaption process.  Finally, SAFe needs to do a better job embracing DevOps and software artisanship.  

Even though I'm not too fond of Nickleback, I am still open enough to listen to a song when the situation requires.  Scaled Agile Framework is not Nickleback, and with the work of skilled coaches, it can be a better tool if we are honest about the framework's shortcomings.  

Until next time.