Monday, August 29, 2022

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. 


Monday, August 22, 2022

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.  


Monday, August 15, 2022

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. 


Monday, August 1, 2022

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.