What sustainable pace looks like

I own my own home.  It is a fantastic privilege but comes with plenty of responsibility.  The most considerable responsibility I face is maintaining the property and making improvements to make the home more livable for my family.  This week, after weeks of permits and negotiations with my neighbors, I had a fence installed.  It looks great, but one of the additional benefits is the installation crew taught me a valuable lesson about agile and sustainable pace.  

The principles of agile emphasize development should be sustainable.  Unfortunately, no one can agree on what a sustainable pace looks like in real life.  Business people often think technology is magic and created overnight.  Engineers and developers know the truth; software development takes time, concentration, and tremendous mental energy.  So when the principles of agile discuss sustainable pace, what exactly do they mean?

One morning, I learned what sustainable pace looks like in practice.  A crew of four people comes to my house with over 250 feet of cedar fence.  The foreman reviewed the outline with me.  He laid out string to show me the perimeter, and with one final check with me, everything looked good, and he began installing my fence.  I immediately noticed something about the crew; they did not have a sense of urgency about what they did.  The team dug the post holes at what I thought was a leisurely pace.  Each crew member took a break to drink water, and when it was lunchtime, they all stopped what they were doing and took a full hour lunch.  

Over the day, my yard had the fence installed.  It looked great and met my definition of done.  No-fuss.  I understand installing a cedar fence is quite different from writing enterprise software, but the work crew taught me about sustainable pace.  Here is what I learned.

• Take breaks – people get thirsty and need to rest; let them.
• A steady pace is better than being rushed – It is less stressful and reduces mistakes.
• Take lunch – The work will be there when you get back.
• Double-check the work before starting – It never hurts to make sure you understand what you need to do.
• Pay attention to quality -  The rest will take care of itself.  

More project managers should watch a fence installation crew work; they might finally understand what is meant by sustainable pace.

Until next time. 

The Business Analyst as Part of an Agile Team

It has to be said

From time to time, an agile coach needs to speak truth to power.  It often has career repercussions and creates more drama than an Anton Chekhov theater production.  A benefit is a truth-based approach to business, or anything else means you are confronting the reality of a situation rather than some other person's magical thinking.  I noticed something this week which bothered me, and I feel the need to call it out.  

Ananya Pani from the International Institute of Business Analysis posted a blog and info-graphic on LinkedIn, which explained that Business Analysts are a vital part of scrum and represent an active role in successful agile teams.  I am going to post the original blog here so you can read it yourself.  It is necessary to critique her arguments.  

If I were going to be prescriptive, I would point to the current scrum guide and highlight no mention of business analysts in it.  A scrum team is a Product Owner, a Scrum Master, and the development team – nothing more.  I realize for most agilists point to the scrum guide and saying that it is the only way to run an agile implementation is counter to the agile manifesto, which says, "Individuals and interactions over processes and tools." I need a better reason to object to Pani's role of business analysts in agile.  

The business analyst is a relic from many waterfall ways of managing projects.  A good business analyst knows about the needs of the business and can transform them into requirements.  It is the same skill set as a product owner, but it lacks the autonomy and authority of a product owner.  In my experience, I often see business analysts taking orders from project managers, and they generate documentation rather than working software.  The way most organizations use business analysts is degrading to the professional skill of the analysts and the power of the project to deliver value.  It is a position designed to create friction in an organization rather than help improve work.  

Additionally, Pani assigned the duties of a scrum master to the business analyst instead of the scrum master.  If I understand her correctly, a scrum master is not necessary on agile teams.  Observations like this point to her having excellent knowledge of Business Analysis but little understanding of agile and scrum; I look forward to her taking some PSM or CSM training and seeing if her perspective changes.  

I do not want to pick a fight, but I feel that the business analyst role is a square peg in the agile world, and we should not try to wedge it into the paradigm of a scrum team.  Instead, we should treat the business analyst as a member of the development team.  As part of the team, they can help with testing, documentation, technical writing, and pitching in with the developers.  Being a business analyst is an important skill and has value like testing, UX/UI, and coding.  We do not need to make a new role for it on the scrum team.  

The truth is the business analyst role is now just part of the development process and should not have any special privileges.  As coaches, we can fold business analysts into scrum teams and then prepare them to take on the role of scrum masters and product owners in the future because their skills translate into those roles.  We need to be honest with ourselves, business analysts are a legacy profession, and they have plenty of expertise to make agile teams successful.  We should take that expertise and fold it into our agile practices.  

Until next time. 

Ten Years Ain't What It Used to Be

Yogi Berra, the beloved manager of the New York Yankees, was a great baseball player and a reputation with the press for providing entertaining quotations.  Reflecting on previous Yankee teams, Berra observed, "Nostalgia ain't what it used to be." Once the joke sank in, everyone at the press conference had a good chuckle and moved on with their lives.  The quotation survived to be recycled in commencement speeches and by numerous writers, including me.  I have been thinking deeply about the past, and it occurred to me I have been blogging for the last ten years.  Along the way, I have learned a few things.  Today, I think it is good to examine this blog's long strange trip, and I have traveled.  

I started this blog in response to some sad events in my personal life.  I was going through a divorce with my spouse.  Confronted with career frustration and my personal life imploding, I decided to found a software as a service company E₃ systems.   The blog would promote the company, and in a few years of struggle, I would become a full-time entrepreneur and big shot.  I wrote some great software, and people liked it. The downside is everyone would not pay me for my services.  

If an entrepreneur cannot get paid for their efforts, they are behaving like an amateur.  My business would become another example of the over 90% of the startups who fail.  Along with the title of software developer and scrum master, I would distinguish myself as a failed entrepreneur.  The social media presence I created was promoting a company that had no paying customers.  The company still exists, but I now use it for personal consulting rather than a vehicle to become an internet unicorn.  

I have mentioned that failure is the best educational process a person can experience.  The adventures of the last ten years have exposed me to plenty of failures and given me the chance to share the wisdom I have gathered along the way.  As I see it, I have the battle scars so you can avoid injury.  The blog becomes a pivot where I shared information about agile, coaching, and technology.  It was a natural reaction to disappointment.  

I migrated from promoting my business to fostering more participation in the agile reformation.  I highlighted controversies and talked about my journey as I strove to become a better scrum master and agile coach.  If you pay attention to trends over the last ten years, you discover a few things.  

• Agile is not a fad:  It is becoming the dominant way to manage an IT business but suffers from bad agile implementations.
• Corporate environments are overwhelmed with fear:  Fear of failure and fear of change are the dominant emotions in corporate cultures.  Only the creation of psychological safety by business leaders will change these situations.  
• Technology is eating the world:  We don't have enough workers to feed the beast.  Something will have to give.  
• Microsoft has evolved from an evil empire to your cool uncle:  I am glad I got to witness this change.  
• Talented jerks still linger in this business:  If we want a better and more diverse technology sector, we need to expose these individuals to sunlight.  
• Finally, dedicated professionals will continue to lead change:  I have met plenty of great folks in the last ten years.  All of us committed to making work less awful. 

Failure and tragedy happen.  In business and technology, when a failure occurs, it costs people their careers.  The days of a straightforward career path up the corporate ladder are gone.  For people who make their living in this unforgiving world, each of us must share our experiences and help others learn from our wisdom.  It makes this blog a travel log of the emotional and technical labor it takes to keep the global economy spinning.  I hope you have learned a few things along the way.  I know that I have.  

Yogi Berra was right; nostalgia is not what it used to be.  Looking back at the past should be clear-eyed, honest about our failures, and ensuring we strive not to repeat those failures.  I have attempted to do that during the last ten years on this blog, and I am deeply grateful for everyone who has joined me along the way.

Until next time.  

How to Help Your Team Overcome Failure.

Software development is a tricky business.  The nature of the work is changing so rapidly that what worked eighteen months ago could fail today.  The mercurial world of software development is the reason why the agile reformation got started.  We do an outstanding job teaching the basics of agile to others.  Unfortunately, we take these essential skills and rub up against the reality of working in a contemporary business environment.  It is a recipe for disillusion and frustration.  As coaches and scrum masters, we need to do a better job helping people who join the agile reformation navigate the hills and valleys of the business's fallen world.  

I say failure is the ultimate teaching tool.  Each day, a business person confronts failure.  It humbles a person.  It pushes them forward to do better.  Finally, it educates in a way no success can.  We need a way to look at our failures dispassionately to create future success.  When the team fails, the best place to address it is the retrospective.  Create a safe and secure environment for people to discuss the challenge.  It also helps to remind everyone about the retrospective prime directive created by Norm Kerth,

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources, available and the situation at hand."

Talk frankly about what happened and how the team could have done things differently.  It is crucial to develop an action plan to address the things that the team can control. 

The next thing a team should do is ask if they are facing a constraint with the organ
ization.  For instance, if network services must schedule a time to promote code to production servers.  It is a classic constraint according to Eliyahu M. Goldratt's book, "The Goal." Understanding the condition of the network services team, the developers can devise ways to exploit the constraint and find ways to mitigate it later.  The process of exposing and mitigating constraints will empower the team and give them a sense of control.  

Finally, please write down your experiences and review them.  A coach or scrum master should keep a daily log of what they do.  It should feature the high points of each day and the low points.  Look it over each week.  It also serves as a contemporaneous memo you can provide your leadership to remain updated on your progress.  Over time, looking over these reports provides an oral history of the project, and you can apply the theory of constraints to help challenges you see recurring.  

Business is a fallen world.  As a person, you face failure and disappointment regularly.  Your team is going to disappoint you.  We do not say this enough in the agile world.  What defines a team that succeeds over one which suffers, in the long run, is the ability to recognize and overcome previous adversity. To deal with these disappointments, use the power of the retrospective.  Have the team apply the theory of constraints.  Finally, keep a journal of contemporary events to track progress and learning.  

Frustration and disillusionment are natural by-products of leading change.  Do not let that stop you.  The fallen world of business can get better, but only if coaches and scrum masters learn to face challenges with an approach that helps them improve. 

Until next time.