Source Control and the Rookie Software Engineer

The summer months are a strange time in the technology business.  Executives and project people take vacation time.  It creates an anxious, lazy experience where work stops while people wait for instructions from people in authority.  The profession floods with recent graduates eager to impress and begin their careers.  I am always impressed by the desire of these new graduates to do good work and make a difference.  Unfortunately, I do not think that colleges, engineering programs, and boot camps are doing a good job preparing these individuals for the work world.  Today on the blog, getting entry-level developers to understand source control. 

During a daily scrum meeting, I welcomed some new developers to the team.  The scrum master scheduled a knowledge transfer session.  The team also created stories so the new developers could pair program with the more experienced engineers.  It shows a level of maturity on the team to which most agile coaches aspire.  In that moment of supreme confidence, I made a hasty assumption.  I asked if all the developers were comfortable with the source control system.  The scrum master pulled me aside and said that none of the new engineers had source control experience and that the senior team members would have to teach them the basics.  After the shock wore off, I thanked the scrum master and pondered how it was possible to have newly minted computer programmers and engineers who do not know how to use source control.

Reflecting on my education and subsequent technology journey, it occurred to me we train people to work as individuals rather than on teams.  The reason developers out of college do not understand source control because their training does not require it.  Assignments are small and self-contained, where a student learns to master particular skills like looping code, decision trees, or variable arrays.  Instructs have hundreds of students to grade, and plagiarism is rampant as numerous code examples exist online.  Checking code into and out of source control is unnecessary in an academic setting.  When those students graduate, they enter the world of enterprise systems and interdependent code.  Source control becomes a necessary survival tool in your career. 

A good understanding of source control should be mandatory if you graduate with a computer science degree.  Universities and colleges should set up source control repositories using open source systems like .git.  Students check out repositories for assignments and check them back in.  A teaching assistant can act like a senior developer doing code reviews, and then grades can be based on how easily the instructor can check out code and run it.  More advanced classes can attempt to work on mutual systems and learn how to avoid overwriting each other's work.  

This approach comes with a few bits of overhead.  Address security concerns need to, so students don't deliberately sabotage each other's work.  The numerous branches in the student repositories will need maintenance at the end of each semester.  Finally, instructors will have to manage their course work like an open-source project.  More graduates would understand the importance and necessity of source control if these factors were accounted for, making them more employable. 

As a coach and scrum master, I want a rookie developer to succeed and avoid the mishaps I experienced in this profession.  To be a success, all developers need to understand source control. 

Until next time. 

A Few Life Lessons for the Class of 2022

I take a great deal of pride in what I do.  Over the years, I have gained competence as a scrum master, product owner, and agile coach.  It is not an easy path to follow.  My professional life contains many failures and setbacks, but it makes me better at my job.  Each day, I attempt to help others avoid the struggles and mishaps I experience in my life.  I am a veteran technical professional, and it means you take pride in showing off your earned scars. 

This week my alma mater, Illinois State University, is having its commencement ceremony.  I walked during my graduation for my parents being proud of my accomplishment and feeling overwhelmed by the rush of final examinations.  I was twenty-two years old and one hundred and fifty pounds lighter when I made that walk.  Today, I want to share a thing or two I have learned along the way with the class of 2022.  

Never Quit Learning – 

Technology moves so quickly that you will become unemployable if you do not keep your skills current.  Successful technology professionals must relearn their careers every eighteen months.  I seek out books, experts, and blogs when I don't understand something.  I still practice coding and the forbidden secrets of open source like .git source control.  

A man I respect, Craig Cutbirth, says that everyone should have an intellectual curiosity about the world.  Curiosity should guide you in your learning and your career.  Soon you will develop a humility about your knowledge and expertise.  At your worst, what you have gathered in your head is what makes you valuable to your fellow humans.  Never squander the gift of learning.  

Be Yourself –

The most surprising thing I have discovered working as a business professional is how much people sacrifice to seek the approval of others, especially those with power.  I have seen people change how they dress to better conform with others in the office.  Moral principles and values are sacrificed for promotions.  Finally, I have seen individuals kiss up and kick down to get ahead.  We have a word for people like this, who are called assholes.  Be yourself at work and be your whole self at work.  Some people may not understand, but it is their problem, not yours.  

Leaders are beginning to understand that bringing your whole self to work makes you happier, more productive, and provides value to the organization they could not imagine.  Ignore the trolls who say otherwise; diversity of background and perspective is a force multiplier in business.  I am very proud to work for an organization, CAPCO, which understands this and supports it at every organization level.  

Say No –

Many people in the business world want to exploit your youth and enthusiasm to bolster their wealth.  Taking on an additional thirty hours a week is wage theft, and a promotion is often an empty promise.  Say no, and say it to set clear boundaries.  Answering e-mail on your phone over the weekend is a symptom of a business that does not respect the people who work for them.  

If you are not learning and feel disrespected by your employer, say no and quit.  Life is too short to work with jerks and organizations who treat you like dirt.  The great resignation is the realization that work must provide financial and personal compensation.  Businesses that do not understand this reality are discovering they are having difficulty finding employees. 

Failure Happens –

Young people, since middle school, are taught that we must pursue success at all costs.  The reality is the business world is going to humble each of us.  Each of us will fail, which is the actual test of who we are.  Failure is pure, and it educates like no other experience.  When you fail, you will do everything not to repeat the experience.  Failure provides you with an incentive to show the people who witnessed your collapse that you are tough and can overcome adversity.  

My failures were like bruises that healed over time rather than tattoos which were marks of shame.  Each of us will fall down, but how we get up is more important.  

Currently, the world is unequal, cruel, and uniquely stupid.  I am doing my part to make it a better place, and I hope you join me in this endeavor.  Enjoy your graduation and take some time to think about what you believe and value.  The real journey begins now. 

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. 

  

Don't Make Hybrid Work a Pointless Exercise.

 

The world turns quickly.  What was the hot business trend a month ago quickly becomes obsolete.   Staying ahead of this changing landscape is a fool's errand, but the business community wants to replicate anything that might give it a competitive edge.  Behavior like this looks silly from an outsider's perspective, like something out of a passage of Gulliver's Travels.  It has considerable seriousness for people chasing profits and promotions.  This week, I noticed two articles that look like a trend but are an illustration of the values in the agile manifesto, which business leaders ignore at their peril.  

With the threat of COVID-19 subsiding, business leaders are arguing for a return to the office.  The demand that people physically be in the office has triggered a revolt among the junior bankers of Goldman Sacks.  The compromise of hybrid working is also backfiring because the workers who return to the office are isolated and have video conferences with those choosing to stay home.   We are looking at the worst of all worlds when getting back to work.  I suspect the reason why is that business leaders are ignoring the agile value of individuals and interactions over processes and tools. 

I can understand why business owners or executives want people back in the office.  Real estate rents are expensive, so each unoccupied desk or empty conference room looks like money drifting into the wind.  The other reason is that executives and entrepreneurs are builders by nature, and the office is a personal construction project.  I remember what keep me going during my failed entrepreneurial venture was the fantasy of opening my own office in a loft.  I only needed to close ten clients to start paying rent.  Today, I understand that I would never have that cool office of my dreams without venture capital and a better sales and marketing plan.  An empty office to a business leader means that they are failing.  

The COVID-19 pandemic made working from home a realistic alternative for many clerical workers.  The video conferencing software could connect remote offices and remote workers.  The business did not stop; instead, it shifted to coffee tales, bedrooms, and small working spaces.  Accounts receivable processed invoices, human resources did what it did, and the information technology department kept it all working from the comfort of home. 

Commuting time is wasted time, money, and gas.  Running household errands was now impossible, and spending time with children or the family pet was out of the question.  Finally, working in an office to attend conference calls and zoom meetings alone is self-defeating.  There was bound to be pushback when business leaders demanded employees return to the office.  Recruiters took notice and offered to poach employees from organizations that were not offering alternatives to the office.  It is one of the factors which keep the great resignation churning.  

As an owner, executive, or entrepreneur, take a look at the agile manifesto.  The first part says, "Individuals and Interactions over Processes and Tools." To run a modern-day business, listen to the people who work for you.  Find out what works for the team and then implement it.  The solution may not be what you want, but it will be what the people who deliver value to your business need to be successful.

Many offices have standing days for in-person meetings, Wednesdays or Thursdays.  If you must have everyone in the office, reach a consensus among the people you serve to have one or two days where everyone must be in the office.  Great days for something like this are client demonstrations or kickoffs for large projects.

Ordering people back into the office because you are in charge is not working; it creates ill will among staff and hurts the organization.  Listen to your workers and implement it.  Everyone wants to get back to work, but it has to work for the people delivering value; otherwise, hybrid work is a pointless exercise.

Until next time. 

Product Ownership Onward and Upward

Product ownership is the most demanding job in agile and gets the least attention.  I have created a series of blog posts to explain the skills necessary to become a great product owner.  Today, I want to summarize and provide some inspiration.

The first thing that a product owner should understand is the team succeeds or fails together.  The scrum master, product owner, and development team all hang together.  Rock stars, divas, or people seeking to punch their ticket to a higher position need not inquire into the role.  The agile principles plainly state that working software is the measure of progress.  The team creates working software and should receive credit because it is never about one individual.  If you are looking for glory, my recommendation is reality television. 

The next thing to remember is the social compact of agile.  The product owner must respect the estimate of the development team, and the development team must respect the priorities of the product owner.  The product owner sets the importance, and the group says how long it will take to do the work.  It is a difficult balance to master, but it will build trust in the team.  

Next, a product owner should adopt the DEEP model of backlog management from Roman Pichler.  The DEEP model is the blueprint of your backlog.  Having a backlog that is detailed, estimated, emergent, and prioritized will make everyone's life easier.  Sprint planning is easier when you have correctly detailed stories and the team estimates them.  Priorities help organize the social compact of agile, which builds trust.  

IF the DEEP model is the blueprint for the product you want to build, then to author good user stories are the individual bricks that make it possible to construct those products.  Stories that have clear descriptions of work plus acceptance criteria for getting the job done to speed up the development of the product and make it easier to test are what separate good product owners from great ones.  Thus, product owners need to practice writing better user stories.  

Finally, a product owner needs soft skills to deal with the "art" and the science of creating a product.  It requires saying not to others because priorities do not align.  Listening allows you to understand what needs doing and why.  Good listening skills also allow you to build trust with other teams.  Finally, diplomacy is necessary to deal with situations where there is a power imbalance of a stressful situation that requires navigation.  These soft skills help build professional credibility in the job.  

Most organizations do not understand the importance of quality product ownership.  The DEEP model, writing good user stories, and soft skills will set you apart from a run-of-the-mill product owner.  By embracing these areas of professional development, you will improve your career and your team's performance.  Product ownership is the most challenging role in agile but, if done right, the most rewarding.

Until next time.