Cross Training for the Curious Agile Coach

Software development is a long slog of false starts and frustration. It is different from other forms of construction. Stakeholders generate vague guidelines, and it is up to software engineers to transform them into working software on various platforms. As an agile coach, the complex process of building software must have an environment of psychological safety, mutual respect between team members, and a ruthless commitment to quality. I keep thinking about Alex Stoley's discussion about how we need to have a 'brain transplant' between members of an agile team. 

I first met Alex in 2018 at the Agile 2018 conference. We were both giving presentations, and I looked forward to his unique perspective. During his presentation, he used the metaphor of a mad scientist to describe the process of cross-pollination, which should happen between a scrum master and a product owner. He likened it to something like the Frankestines monster, with brains transferred between the two roles. To Stoley, only by living and working in the other person's role was it possible to improve the entire team's performance. I instantly converted to this message, and when I had a  chance, I decided to work as a product owner to improve my skills. 

Today, I continue to think about Stoley and his message. My experience in the software business has convinced me that teams perform better when members cross-train. Training like this allows team members to help each other during difficult periods and prevents bottlenecks from happening when one team member can only do work. Each team member can have a specialty, but each member is responsible for instructing the others on the team on how to do the basics of that specialty. Someone with object-oriented skills can help a javascript developer better understand types. That javascript developer can teach the object-oriented developer how a domain object model works on the web page. 

The cross-training process on your team will be hard work, and the go-go business world might need help understanding it. Still, the hard work done upfront will make the team more resilient and better able to code with the numerous challenges which crop up during a software release. 

If you attempt to explain this to an executive, use a metaphor from athletics. The next player steps in to fill a role when a football player is injured. The replacement player is good enough to help the team and will act as a sparkplug for the people already on the field. Crosstraining is also valuable because it defines the standards of excellence everyone on the team should follow. For example, everyone on the team should know how to write unit tests because a story is incomplete until someone writes a unit test. Thus, when new people join the team, part of the integration process is showing them how to write unit tests. It creates a common bond that all the team members share.

Brain transplants are the stuff of science fiction, but the benefits of cross-training are genuine. Team members who share a standard skill set are less likely to get stuck and perform better for the organization. That knowledge makes me want to cackle like a mad scientist. 

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. 

Beginning a Journey Into Healthy Ownership.

We will remember the end of the COVID pandemic as a combination of science-fiction, fantasy, farce, and tragedy.  I was on a plane to have dinner with a client while tanks began rolling into Ukraine.  The contradictions between my life and the peril of others were oppressive.  

Still, the business world continued to turn, and clients were looking for ways to do business smarter and faster.  I am a minor player in the global business story, but my role is to make a difference.  Part of that difference is to help improve product ownership in the agile reformation.  I have authored numerous blog posts about product ownership, and I have advocated for something called "healthy ownership," which began at the 2018 Agile Coaching Retreat in London.  Today, I am starting a series of posts on being a better product owner and developing beneficial ownership on your team.   

Healthy ownership began when I had a jetlagged rant about the quality of the product owners at my organization.  I asked if I could instill good habits among product owners and respect the developers.  Then, I found a group of like-minded individuals, and we got to work.  An agile team requires trust and interdependence to be successful.  The team then takes collective responsibility for its outcomes to have healthy ownership.  It is a goal I think each team should strive to achieve. 

Product owners should begin by having an open dialog with team members.  It would help to ask the teams what works and what does not.  Take time and listen to what they are saying.  What are the team's frustrations, and what do they need to overcome those frustrations?  Assume good intentions unless proven otherwise.  Finally, collect data from the group and make it meaningful.  

As a coach, teach product owners the D.E.E.P  model of backlog management.  Let new product owners write user stories and then get them to critique their work.  Have developers push back on user stories that are unclear or incomplete.  The trial and error approach may be more clumsy, but it will help develop more skill and confidence in the long run.  

Product ownership requires more than writing user stories and gathering estimates.  It is not an easy job, but it can be a force multiplier if done well.  It takes clear communication with the team and understanding the social compact, which guides agile, and it takes interaction with business partners and saying "no" when necessary.  

We will talk about being a better product owner for the next few weeks.  We will have a blueprint to create healthy ownership in your organization by the end of our journey.  

Next week, the D.E.E.P model of managing a product backlog.  

Beware the Temptation of "Dark Scrum"

Avoid the temptations of "Dark Scrum"

I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum since 2013.  I even finished up my master’s degree studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is a disconnect between those of us doing the work and the business people who depend on us.  When this happens, it creates a situation Ron Jeffries calls, “Dark Scrum.”  As a scrum master and agile coach, it is your duty to avoid this situation.  This week on the blog avoiding the temptations of “dark scrum.”

In my formulation, "dark scrum," is when the business users of Scrum use the methodology to enforce control over software development rather than use it to improve quality and customer satisfaction.  Jefferies gives plenty of good examples on his blog, but I would like to provide two more.  I consider them to be pathologies of a dysfunctional organization.

Dark scrum pathology – shoehorning arbitrary deadlines on to sprints.  

One afternoon, I was in the office of a Vice President.  I had been raising concerns with him that a project was going poorly and that I would need his support and intervention.  The meeting did not go well.

“I promised the board that this project would be done by X date,” he said.

I told him based on the stories we had and a three-week sprint cadence we could deliver by a later date.

“You are agile, figure it out,” the VP said, “I need it by X date.”

The executive violated the social compact of agile, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked bad.

Dark scrum pathology – why do I have to meet with the off-shore team.

Product owners write stories, but because of the time difference between the onshore and offshore components of the project, did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, and it would take over 24 hours to get them answered.  Product owners also complained that the team was not understanding the detailed requirements to get the work done.  When prodded to attend the stand-up call with the off-shore team a product owner indignantly said, “I am not waking up that early to talk with India!”

We were able to correct these pathologies.

To address the arbitrary deadline problem, bring in executives and product owners to level set expectations.  In the world of Scrum, the product owner is the person primarily responsible for the success or failure of a project.  The executives outside the team are responsible for funding and helping to remove organizational obstacles.  Knowing financing and deadline commitments provides the product owner a framework to write stories.  The scrum master can then use team velocity and the sprint cadence to let everyone know when a deadline is realistic and when it is not.  This way the social compact of agile is respected, and there are not secrets for all the parties involved.

We solved the next pathology by moving up the stand-up meeting by thirty minutes.  The product owner could take the call from home when they got out of bed but before they came into the office.  Product owners answered questions quickly and user stories improved.  Also, automated testing got better as product owners relied on the offshore QA professionals to streamline acceptance testing.  What was once a burden, became a win-win for the entire team.

The hard part about being a scrum master and agile coach is you are forced to come up with solutions like this each day to prevent your organization from falling into “dark scrum.”  Any situation where those in power ignore the input of the people doing the work is going to add darkness to the organization.  It is why the agile reformation is so important.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.

America the Disruptive

America is the story of disruption,
ask Molly Pitcher.

This last week has been a weird mix of anniversaries and events.  The Supreme Court expanded the rights of gay people with the over-turning of the Defense of Marriage act.  This happens during the same week as the 150th Anniversary of the battle of Gettysburg where this nation almost dissolved into a feudal Confederacy and technocratic Union.  We have a black president while our Supreme Court repealed election laws which made his election possible.  It is a mulligan stew of conflicting trends and directions.  I suppose that science fiction author William Gibson was right when he said, “The future is here.  It’s just not widely distributed yet.” This week the blog is discussing how this uneven distribution or ideas and technology is part of the American experience.

I began thinking about this subject when I read an article by Maria Bartiromo about the disruptive nature of software in the business world.  After a good read, it dawned on me that the entire history of the United States is the story of technological innovation and disruption.

America was discovered thanks to advances in ship building and navigation during the renaissance.  Since the first settlers landed on our shores, the American experience has been one of technological discovery and advancement.  One of our founding fathers, Ben Franklin, became the nation’s first Renaissance man and patron of science with his work on electricity, home heading and his improvements to printing.
This devotion to science and engineering is a unique part of the American psyche.  It led to the creation of the Erie Canal and the development of the cotton gin.  It made railroads possible and helped create the modern research laboratory for Thomas Edison.

Each of these technological advances caused huge disruptions.  The cotton gin made human slavery profitable for the south and railroads made it possible to defeat the confederacy during the Civil War.  Telephones and telegraphs made communications swifter and the world smaller.  Refrigeration transformed the way we eat and the web has altered the way we interact with each other.  I would argue that a solider from the Civil War placed in the middle of contemporary America would consider this a time of wonder and magic.

Each technological change has created social change.  The promises of the 13th, 14th, and 15th amendments to the constitution were only enforced 100 years later thanks to advent of national television broadcasts in the middle of the 20th Century.  The labor movement is an outgrowth of the industrialization of our nation.  Civil rights and the sexual revolution would never have happened without Motown and Rock and Roll playing over a new-fangled device called the radio.

So when I read Bartiromo’s article on LinkedIn, I just nodded in agreement.  Software is a new disruptive influence in America.  Software is changing business and society.  It is generating piles of wealth and if you have the correct skills you will benefit in this brave new world.  If you don’t there are going to be economic and social problems.

I do not know how to solve these larger issues but I do know how to help small and medium sized business adapt to these trends.  At E₃ systems we are creating disruptive software which can track your inventory.  Coming up later this month we will be releasing our fleet management software which will help you stay on top of fleet maintenance.  This is pretty powerful stuff and it is going to be disruptive.  You may need fewer clerks in your office or you may assign those people to sales or customer service roles which might improve your revenue.

The times are changing and everything can feel profoundly disruptive but change and disruption are part of the American experience.  Gibson was right, the future is not evenly distributed but at E₃ systems we will keep on trying.

Until next time.

Science Fiction Dreams and Travel Realities

Science Fiction Dreams and Reality this week on the blog

I have been busy with trade shows and travel this week and that makes it hard to stay on top of my business and blog.  One of the interesting things about travel is that it does move you outside your comfort zone.  I also got to see the best and worst trends in technology in their natural environments.  In this blog, I want to talk about how we are living in the best of all possible worlds right now when it comes to technology.

My flight was booked via an electronic system known as SABER which has been the backbone of the airline industry since 1960.  I traveled with a mobile phone running the android operating system with the Trackit application which allowed me in real time to follow my travel plans.  I also had a tablet which used Android with three books for me to read on my flight.  Throw in my laptop and I had more computing power at my disposal than many third world countries.  This was not out of the ordinary or unusual because many of the other business travelers I journeyed with were similarly equipped.

All of the airports I traveled through had Automatic Teller Machines but no pay phones because everyone had at least one mobile device to contact someone if they needed help.  Tweets were sent, Facebook status messages were sent and deals were negotiated in terminals while people were waiting for their flights.  There were even video chats taking place via Skype.  Again none of this was out of the ordinary or unusual.  The science fiction of my 1970’s youth had come true. 

This does not mean that everything was perfect.  American Airlines canceled my flight and their customer service was spotty.  Planes were on runways without crews and it was clear that some of the flight attendants were being forced to work extra shifts to deal with the traffic.  So a two hour trip to Atlanta turned into and eight hour adventure flying to Dallas and then to Atlanta. It was an example which illustrated even the best technology cannot stand up to bad weather, institutional inertia and poor service. 

I suppose this is why Voltaire spent so much time making funof Leibniz when he said that “We live in the best of all possible worlds.”  In spite of all the modern conveniences, which we enjoy, traveling still sucks.  It is also not made any better by the dysfunctional processes we have put into place to manage travel and airport security.  This has been mockingly referred to as a “First World Problem,” because this kind of thing is merely an inconvenience and does not have life or death consequences like cholera or malnutrition. 

We are living in a technological golden age; we just take it for granted.  We can communicate with anyone via our smart phones and computers but we find it hard to communicate with the people sitting next to us on the plane.  Social stratification, government short sidedness and corporate inertia make it difficult for us to utilize the utopian dreams of all the entrepreneurs who helped inflate the dot com bubble in the 1990’s.  I wanted to become an entrepreneur because I thought I could do something anything to escape the Kafkaesque world of software consulting.  I also thought that I could help small businesses play with the big dogs and better serve customers. 

It is a grandiose thought but one that still drives me and my business.  So we do not live in a perfect technology utopia which was promised twenty years ago but when I complained about my flight being late on Twitter no one censored me.  When I made a call to my bank to deal with an overdraft I was able to compare math with the customer service rep via a mobile application.  Finally, I made dinner reservations via text message and was able to update my boss via e-mail via my tablet. 

Travel still sucks but it sucks less thanks to technology people who like me who dream big and wish to make this the best of all possible worlds.

Until next time.