Don't Go Fishing in Jira

I am currently working on a gigantic project with over twenty software development teams.  It isn't straightforward and contains numerous surprises for everyone involved. Projects like this are emotionally exhausting and require focus and attention to detail which can humble the best professionals.  Along the way, I have learned a few things about myself and the SAFe scaling framework.  Additionally, I have discovered an anti-pattern which I need to expose to my fellow coaches and scrum masters.  

One of the base requirements of any project is to have a source control system to manage code and a kanban board to track user stories and defects.  The board can be as simple as post-it notes on a whiteboard or as complicated as an elaborate software package.  Like many organizations, our project uses Jira.  The company uses the tool to keep track of the numerous teams and the thousands of product backlog items completed each iteration.  I will not waste my readers' time critiquing the merits of Atlantasan's project management software.  You can find better discussions about the subject elsewhere on the web. 

What I have noticed is an ugly anti-pattern that is taking place on this large project.  One of the technical leads called it "Jira-fishing," and if you want to deliver value quicker to customers, it needs to stop.  Jira can help an organization or transform it into a bureaucratic cesspool of evil like any software development tool. If software developers or product owners engage in Jira-fishing, you are fighting corruption.  

Jira has a powerful feature known as linking product backlog items.  It allows a developer or product owner to connect other product backlog items to the original story.  So if you are building out a web service and the front-end developer will use it, you can link your story to the front-end developer's story and say they are either dependant on each other or related.  The feature makes it easy to track dependencies and establish relationships between different pieces of work.  Things become evil when multiple teams in the same repository create defects and "analysis" tickets that block other work.  A product owner or developer is "fishing" around multiple tickets to understand dependencies and stopping a work item. 

For example, we have a team building APIs, but another team is working on the database, and a third-team is constructing the UX/UI for the customer.  The front-end developer on the UX/UI team has a story to edit a record, and they rely on an API to work correctly.  For the API to work, the developer on the API team needs to have someone on the data team properly update the database.  During testing, the front-end developer discovers the data is not updating correctly.  Naturally, the developer or the quality person on the team creates a defect, links it to the front-end development team, and then assigns it.  The Product Owner on the development team is then aware of the fault and assigns a developer to fix it.  During debugging, the API developer discovered a database problem and raised a defect to the database team, and the process repeats.  For the Product Owner of the UX/UI team to understand what is happening, they have to go fishing through a minimum of three Jira tickets.  Each defect can have a different priority for each group, and the original story for the UX/UI team will not get completed during the sprint because of those dependant defects.  Timelines slip, and the customer does not see any business value.   

The previous example is a simple illustration of the problem.  I see stories that have taken sixty days to resolve because of numerous dependencies between teams. Deadlines are out of the team's control, and work is held hostage by another team that does not have the same priorities. To anyone who works in the agile or SAFe world, it is a prescription for anxiety.  

The easy answer to this problem is organizing the development team, so a front-end developer, API author, and database person work on the same team to address the original ticket.  Dependencies vanish, and work moves through the system in a smoother fashion.  The practical reality is that splitting up teams and reorganizing them in the middle of a massive project guarantees the project will go over budget and be late.  The team's reorganization won't work because it violates Brook's law which says, "adding staffing to a late software project makes it later.  If adding a new person to a late project makes it later, I will expand that postulate and say reorganizing a software development team on a late project will obliterate any reasonable deadline.  I call it "Wisniowski's First Theorem of Project Management." 

What is a coach to do when confronted with Jira fishing and dependencies which resemble a series of Russian nested dolls?  I always return to the notions of empiricism and transparency, which are central to agile.  The Product Owner must explain each link or dependency in the story along with the acceptance criteria.  It should look something like this below.  

This story is dependant on story 123 from the database team >> which depends on story 345 from the API team >> which requires a change request 678 from the claims team.  

The point is that the Product Owner and the team can clearly see the dependencies and mitigate them.  

Each day I have a standing meeting with product owners who have dependencies with my team. Next, it will become apparent where the dependencies are happening.  It is then up to the Product Owners or scrum masters to create a steering committee or scrum of scrums to address these situations.  Finally, when all else fails, get executives and stakeholders involved.  Often these individuals get in the way of progress with micro-management, but when priorities do not align and work is stalled, they can step in to clear out a blockage.  In most organizations, the Executive Vice President of Development has more authority than a product owner, so when the Executive Vice President asks why something is lingering for sixty days, it becomes a priority for the organization.  

Jira fishing is an ugly by-product of a large project with numerous dependencies.  It is also a symptom of agile teams which are not cross-functional.  To mitigate these challenges, make sure all dependencies are linked to stories and are explicit.  Next, create a scrum of scrums or steering committee to deal with those dependencies.  Finally, have executives and stakeholders get involved to break down obstructions to work.  I enjoy going fishing.  I don't want to do it in Jira. 

An Agile look at the Olympics.

The Olympics bring out the sports nerd in me.  I can sit for hours watching events I never get a chance to see.  I fell in love with curling watching the Olympics, and I never miss an opportunity to watch fencing when the summer games come on.  My fantasies of being an Olympic athlete are unrealistic, but I learn lessons of determination, leadership, and character from these elite athletes.  Today, I would like to share a few of those lessons.    

As a coach, listen to your team members.

Simone Biles was having concentration issues when she was qualifying during the games, but something was wrong when she got lost in the air during a vault.  Biles talked it over with the coach and said she could not go on.  The coach listened and agreed.  When someone comes to you with performance issues or problems with focus, the best you can do is listen.  Once you have heard someone out, take the best action for that person and the team.  I believe Biles coach did that, and Team U.S.A. won a silver medal.  

Being a champion is more than finishing first.

Kevin McDowell ran the race of his life in the Men’s Triathlon.  At one point, he was leading the race.  The cancer survivor gave it his all and finished the race in sixth place, the best Olympic finish by any U.S. male.  While running the race, he grabbed water for other competitors who could not reach it.  His battles with cancer and the sportsmanship he showed on the course make him a champion to me.  A person like that on your team is going to inspire and elevate everyone around them.  If you had to choose between winners and champions – pick the champions.  

Leave everything out on the field.

I watched U.S.A. softball play Japan in the gold medal match.  Everything which could go wrong for team U.S.A did.  One player hit into a freakish double play to end a rally.  When it was over, the U.S.A. won silver instead of Gold.  Pitcher Cat Osterman’s interview moved me after the game.  She said she left everything out on the field and was proud of the team. She encouraged younger players to stick with the sport and aspire to become future Olympians.  Your team needs to take pride in their work and do their best each time, even if the results do not lead to immediate success.  

Excellence is everywhere

We often have a skewed version of success.  Top salespeople sell more than others.  Broadcasters with ratings are more respected than those with personal integrity.  We value the winners who are the most visible and public with their accomplishments.  A person has spent years perfecting air pistol at the Olympics, someone has been weight lifting anonymously in the Philippines, and a mathematician peddled 85 miles for a gold medal.  The quiet dedication to craft and excellence is everywhere.  As coaches and agile practitioners, we need to encourage and recognize this kind of accomplishment. 

I have another week to nerd out about the Olympics, but the lessons will last a lifetime.

Until next time. 

Find the Right People to Begin Your Agile Journey

I spent time away from work to be with family on the Alabama coast, and I am glad to be back.  Taking time away from projects is a healthy way to recharge and discover new perspectives mentally.  Unfortunately, it creates a backlog of work that you need to sift through when you return to the office.  While I was sorting through my e-mail to achieve the elusive inbox zero, it occurred to me agile is becoming more mainstream.   

When I joined the reformation, 2009, it was composed of misfits and developers who saw the old way of doing things as needing significant change.  Today, I talk with executives who ‘want’ agile.  The secret of agile being a better way to manage complicated projects like software development is now public knowledge.  As this information spreads, business leadership struggles to find people who can make it happen within their organizations.  Today, I will discuss the struggle to find good and great agile professionals. 

Speaking from my own experience, I had the zeal of a newly converted person and still look back at my embrace of agile as my “road to Damascus” moment. Early converts to agile and scrum were enthusiastic. We gained experience working as scrum masters, product owners, and developers.  Now, we are looking for the next steps in our career training and leading others to be agile.  

For business leaders new to agile, people in my cohort of agile practitioners are a large pool of labor, but the front-line scrum masters and product owners are scarce. The challenge is how do you find people to fill those roles. Often they have to train people internally or hire outsiders at a premium.  The challenge is how do you find good people to fill those roles.  

The first thing you must do is take an unflinching look at the organization’s culture.  Is conformity valued over results or delivery?  If it is, it will be hard finding internal scrum masters or software developers.  Agile professionals are iconoclastic and have an entrepreneurial streak.  Suppose the organization is crushing these traits out of the workforce. In that case, they will not spontaneously come to life because you rename a project manager or business analyst a scrum master after a two-day training course.  

Like people who resolve to lose weight or quit drinking, an organization needs to take small and concrete steps to transform.  The agile wannabe leaders must find scrum masters from outside the firm willing to buck the organizational status quo to get things done.  It also means abandoning micromanagement, rewarding people willing to question established ways of doing things, and creating psychological safety so people can try new things and make mistakes.  These are not easy things to do and could take years to complete successfully.  

Where leaders have an advantage is recruiting product owners.  There are plenty of people inside your organization with business knowledge and tenure.  They are the people who know all the secrets in the organization, and they make perfect material for craft product owners. Before you send them off to training, make sure they are empowered to set priorities and say 'no' to others in the organization.  Finally, make sure the new product owners are doing the job full-time. Product Ownership requires undivided attention to write stories, communicate with customers, and measure value delivered to the organization.  If you expect them to handle accounts receivable while acting as a product owner for the new accounting system, you deserve failure.  Pair these people up with an experienced scrum master or coach, and you have a recipe for success.  

Finally, look for people who are stoic and realistic.  The contemporary business world produces toxic people; either they are so optimistic it is alienating or so hostile they act like cancer on their work. Find people who are willing to look at a negative situation and say, “Wow, this is broken, might as well get started and fix it.”  If you find people like this and place them in positions of responsibility, your ability to become agile has a reasonable chance of success.  In the words of agile coach Michael de la Maza, “There are no solutions, just countermeasures.” Find people willing to implement those countermeasures.  

Finding good talent will be a significant challenge as we attempt to rebuild the global economy in the aftermath of the COVID-19 pandemic.  Agile is not something you can buy off the shelf and magically implement at your organization.  It will require organizational change, people willing to take risks, and finally, a commitment to being uncomfortable and hold oneself accountable.   

Agile is not easy, and your first step on your journey is acknowledging that you need the right people to help you make the trip successfully. 

Until next time. 

The known-known of Donald Rumsfeld and agility

I took some time away from the blog to be with family and friends during the American Independence celebration.  Unlike George Packer's stereotyping of the professionals like myself, I am intensely patriotic, which made it pleasant to watch fireworks and listen to a marching band.  I encourage people to take time off.  It allowed people to set work aside and concentrate on the family and friends we neglect during the workweek.  While I was away, former Secretary of Defense Donald Rumsfeld died.  His passing made me want to reflect on his leadership style and what that means for the people left behind.  

I'm not particularly eager to write about politics on this blog.  There are better voices about the subject on both the liberal and conservative end of the spectrum.  I also feel that if I am going to contribute to the conversation of making life better for others, I feel that concentrating on project management, agile, and business culture are areas where I can provide meaningful insight. I used Rumsfeld and his quotation about ambiguity and uncertainty to discuss what scrum masters should be looking for when they join an organization.  You can read the original post here.  

Now that Rumsfield is gone, it is time to take a serious look at his leadership style.  Secretary Rumsfeld is a formidable person; he graduated from an Ivy League institution, completed a Navy ROTC scholarship, and was a member of the house of representatives for three terms.  You do not accomplish those things unless you are intelligent and rugged.  I will also point out Rumsfeld is a fellow Eagle Scout.  

One thing that stuck out for me when I review his biography, he was a naval aviator and did not see any combat while he was flying.  He understood the reality of being a naval officer but never had shots fired at him by a communist in a Mig.  He also never commanded sailors at sea.  In most areas of his life, he had tremendous authority with little responsibility for the outcomes.  It is a crucial hallmark of his life in public service and private business.  It transformed him into an individual with tremendous arrogance and a shallow understanding of things unrelated to his advancement.

It drove Rumsfeld to fits of anger when asked about his motivations or influences.  Someone could not question him because he assumed he was always right.  Soon, Rumsfeld was surrounded by people who could not say no because their careers depended on making the boss happy.  It created a bubble where regular inspection and adaptation to changing circumstances became impossible.  Numerous generals risked their careers to point out flaws or nuance to Rumsfeld's decisions.  One general, Eric Shinseki, was relieved of duty when he pointed out the occupation of Iraq would take more soldiers than the ones involved in the actual invasion.  

The most prominent example of Rumsfeld's leadership style is the Freedom-class Littoral Combat Ship or LCS.  The U.S. Navy requires large crews of specialists to operate their combat ships.  Professions diverse as plumbers, mechanics, and fuel technicians keep the Navy afloat. Vessels have specialization with some sweeping for mines. Others are missile cruisers designed to shoot down enemy aircraft, and aircraft carriers are floating airports that could project American power anywhere in the world.  It is expensive in both people and money to operate a giant navy.  The LCS would work with a fraction of the crew, hi-tech computer systems, and a modular hull which allows the ship to be reconfigured in port depending on its mission.  It was the brainchild of Rumsfeld.

It became apparent the LCS was a bad idea.  Crew members would shift from cooking meals to operating weapons.  The goal was to allow the U.S. to have a bigger military punch with fewer sailors and ships.  The reality of the situation was a mess.  Since none of the sailors assigned to an LCS had engineering experience, no one checked the engines for oil levels or seawater contamination.  The modular system never worked in practice, and LCS ships spent more time in port than at sea.  Finally, the vessels broke down when on duty and were towed to port because no one on the boat could do repairs at sea.  The Navy learned plenty of lessons about the LCS; they were reluctant to act on those lessons because it was Rumsfeld's idea, and even though he was gone from the department of defense, his shadow loomed large over the project.  Currently, the U.S. Navy is planning to retire the LCS Freedom-class, considering the program a failure.  

Based on his biography and papers, Rumsfeld comes off as a traditional leader who never wanted to hear bad news and expected his ideas to be implemented magically by the people he was supposed to serve.  People who were not obedient to Rumsfeld and his ego would be swept aside as he moved forward with stubborn persistence.  It is the mindset of a naval aviator who never had someone try and shoot him down.  The entitlement and arrogance are clear to see.  

Toward the end of his life, Rumsfeld published his "rules" for successful leadership.  If you followed his process, you would achieve greatness.  The funny thing about technology and reality is it humbles your greatest ambitions.  I doubt he ever learned that lesson, and it is up to coaches and scrum masters to remind leadership not to follow Rumsfeld's example.  

Until next time.

Don't Estimate Spikes

One of the principal values of agile is individuals and interactions over processes and tools.  Each organization is different, so how they do agile is going to vary.  Coaches should be sensitive to this reality.  Unfortunately, as people learn how to practice agile at an organization, they often let old biases and ways of doing things obscure how they continuously improve.  It is at this point a coach steps in points out they are doing something wrong. So today, I am taking some time to correct a gross misunderstanding.  

Earlier this year, I wrote about a particular type of product backlog item known as a spike.  It is a helpful way to plan work where the team is uncertain of how to proceed.  A manager instructed a colleague and his team to provide estimates for spikes during sprint planning.  When I learned about this, my danger sense started throbbing like an infected paper cut.  A spike is not estimated.  People who ask for estimation on spikes are misunderstanding their purpose.  

A spike allows the development team to perform research and analysis.  If they do the job appropriately, at the end of the sprint, they will have a prototype, code which is proof of concept, or more user stories that they can correctly estimate.  The team is learning how to do something; to ask them when they are going to know it is foolish.  Imagine a high school teacher demanding a student estimate how long it will take to learn how to perform equations with two variables when they do not understand what they need. As a result, the student feels pressured and resistant to learning.  Software developers will do the same, or they will give the manage lip service to make them go away.  

I understand why some managers want estimates for everything.  These managers do not know any better and hate dealing with uncertainty.  It is a direct by-product of traditional project management training.  Waterfall project management depended on people knowing how long it would take to perform a task. For example, a concrete slab can be poured and cure in 72 hours.  If a project required four concrete slabs, then the math is four times 72 or 288 hours.  Thus, a project manager could estimate it would take twelve business days to get the concrete finished for the project.  

The approach does not work for creative activities like software development, marketing, or business processes.  All of these activities have too much ambiguity and lack easy answers.  Asking someone to guess how much it will take to do something they have never done before is insensitive. These managers desire to have control over a situation they have little understanding or influence over the outcome.  A manager is asking for believable fiction rather than the messy reality we exist.  

Let me repeat, do not estimate a spike.  It does not add value to the customer.  The development team does not know if they can solve the problem, and management will treat the estimate like a quotation instead of fiction.  

People wanting to find some predictability for the team can choose a different approach.  Instead of asking the team to estimate a spike, count the number of spikes in a sprint. For example, suppose a team completes forty story points in a sprint; when they spike the sprint, they only complete thirty points.  Thus, a manager can deduce the spike took up ten points of intellectual capacity from the team.  People who use a “no estimates” approach can subtract the number of spikes in a sprint from the number of stories attempted.  Both methods to spikes concentrate on problem-solving instead of providing estimates with dubious value.  

Leading a large project is challenging on the best days, so I understand why managers want to estimate spikes. Still, it is not going to provide value to the customer, and it is going to generated meaningless data, which is going to hurt decision making. Moreover, it is more painful than an infected paper cut. 

Until next time. 

 

Integrity and Agile make a difference.

Being a coach and scrum master is one of the most rewarding experiences of my life.  I have worked with many great people, and I had received plenty of support from total strangers when life at the office was painful.  We are a diverse and unruly bunch of misfits who think we can change the business world one project at a time.  The last eleven years since I discovered agile changed me for the better and helped me find a purpose.  We talk about plenty of topics in agile: from servant leadership, being authentic to how to write a good user story. Still, we don’t talk about personal integrity and why it is so essential for the success of the agile reformation.  I want to correct that oversight.  

The author C.S. Lewis said, “Integrity is doing the right thing when no one is watching. “  It is a strange concept in business because we judge people on how they impress their superiors or how much revenue they generate in an amoral world which is concerned about profit; notions like character and integrity get lost in the daily hustle.  

What gets missed in the conversation about business and amorality is that to lead others effectively, business people must have a type of personal integrity that makes others want to follow them.  Leaders do not lead because they have a title or authority.  A person becomes a leader because others connect with them and wish to follow.  The secret sauce to leadership is personal and professional integrity.  

Borrowing from C.S. Lewis, I define integrity as a code of conduct you follow in public and private spheres.  You treat others with respect at the office and home.  Someone with integrity will never ask someone to do something they would not do themselves.  When your staff is working late, you are with them, providing moral support.  It is not an easy way to conduct your life, but it is fulfilling.  

People with integrity win the respect of others and the hatred of those who are lacking.  A person with integrity acts as an example for others to follow.  When they make a promise, they keep it.  Those with integrity move through the world with a quiet poise that others will notice and does not require constant self-promotion.  

Having integrity saves careers.  After a business meeting, select scrum masters in the organization were not performing their duties and billing their hours to the firm.  Within a week, these scofflaws were gone, and the remaining people granted more influence in the organization.  People see who is doing the work and who is skating by on good looks and charm.  When times are tough, people with integrity are those others want around.  

Angela Dugan, the Chief People Officer at Polaris Solutions, said at an after-hours meeting, “Do your job the best you can and let them fire you if they have a problem with that.”  It is a bit of wisdom that has remained with me during my career and the best definition of Integrity I can find in the business.  Imagine if every business person conducted themselves in that manner and how much better it would be.  It is a lofty goal and one I hope others with integrity will pursue with me. 

Until next time. 

 

Remembering Larry Blankenship

I have been part of agile reformation since 2009.  I evolved from a voice in the wilderness to part of a growing cohort of professionals who make the world of work better. Unfortunately, this week our tribe got a little smaller.  Larry Blankenship died from a heart attack this week. I am feeling compelled to honor the man and his work.  

Larry, like many of us, came to the agile reformation as a frustrated technology professional.  Projects were long, painful slogs, which ran over budget and demanded superhuman efforts. So naturally, when someone suggested a better way, people like Larry gravitated toward it.  He preached a common-sense approach to agile and development.  He was mid-western friendly with deep insight into engineering and human nature.  You could count on him for some humor and a subtle jab if you started acting smug.  

He represents a common theme among the people I know online and in-person related to the agile reformation.  Each of us has a deep devotion to making work feel less like drudgery and more like a vocation.  We are intelligent people who have discovered that many problems in technology are not technology problems but human issues which need addressing.  

Larry epitomized that mindset with wisdom, kindness, and a wry sense of humor.  The agile community is going to be less interesting without him.  Fortunately, more people are coming to join and carry his memory forward.  

Goodbye Larry, we will miss you.