Some Thoughts About the Holiday Rush

A little holiday rush

It is the final rush of 2017.  The business is pushing to squeeze as much profit out of the holiday season while the technical professionals are scrambling to bring on-line systems promised by the executive team.  It is a busy time and filled with pressures both personal and professional.  I find it hard to cope with this strain.  You spend time keeping the commitments of others and struggle to use the difference supporting family and friends.  This week I want to make sense of the holiday rush. 

For as long as I have been a business professional, the one motivation I have seen in business is fear; visceral, cold, unforgiving terror.  It is the anxiety that you are not hitting your sales figures.  It is the panic of the payroll system not interfacing with the accounting software.  It is a shame that comes with a sixty hour work week not being enough to deliver what your manager promised. 

The reason I became so enamored with agile and scrum is I wanted to work without fear.  I have been fired the week before Christmas.  My spouse left me because I finished up a consulting contract early.  Each meeting with quality assurance or my manager triggered spasms of fear.  There had to be a better way.  Agile and scrum provided a means to do things differently and escape that fear.

I have been in the agile practice for eight years.  I have had tremendous successes and bitter failures.  I have lost countless hours of sleep and overeaten junk food.  I have struggled against organizational inertia and corporate indifference.  I would not change a thing because the changes I have made mean that one less developer is living in fear.  That makes it a worthy goal. 

So as I fight crowds to get my shopping done and stay up late to ship software on time; I understand the sacrifice and frustration I put in for 2017 is worth it.  There is a little less fear in the office.

Until next time.

How do you fund these Agile projects?

Software professionals are not Lego bricks.

I had the good fortune to finish a training course by Benjamin Day about scrum master skills.  I highly recommend you visit Pluralsight and take his course.  One of the more interesting things about his training was the conversation about how to do annual budgeting with Agile and Scrum.  This week I want to discuss my observations on the subject.

Isaac Socalich wrote a blog post taking about “Legacy thinking” holding back agile adoption at organizations.  He cites the way projects are funded saying accounting practices lead organizations to fund and allocate resources only once around a product, project, or process improvement.  In short, a project has a start, middle, and end.  The people, funding and output of the project are cells in a spreadsheet which manages the project.

This legacy financing model is short sided, counterproductive and the antithesis of the agile movement.  The Agile manifesto stresses “Customer collaboration over contract negotiation,” with legacy financing of projects every activity is reduced to contract negotiation.  The project is conceived with unrealistic expectations.  The deadlines for completion do not reflect the opinions of those doing the work.  Customer considerations are ignored and the funding is at best a guess done by an accountant.  It is no wonder so many software projects fail.  

The most aggravating part of legacy thinking is that treats consultants and people who do the work as machine tools which can be replaced when they are no longer useful.  Teams are created and disbanded based on funding formulas rather than business needs.  This means technical professionals are being treated like mercenaries to build software.  This also creates technical professionals who have no personal investment in the products they are creating.  They are temporary workers billing hours and doing work with no real concern for quality.  

For example, an off-shore team is working on software and because of a lack of funding they are disbanded.  Four months later, the finance department restores funding and a new team is spun up.  The original developers are gone along with the two years of experience they had on the project.  The organization now has to spend the first six months of the project training the off shore team about the business and navigating the legacy code.  The remaining six months of funding is spend attempting to do a year’s worth of labor.  Quality suffers, deadlines are missed and the customer is dissatisfied but the project was correctly funded by the business.

Software teams should be professionals invested in the business and each other rather than disposable Lego bricks.  Projects should be spun up and spun down being given to these project teams.  These teams should remain constant while the projects come and go rather than the other way around.

This is why I like Benjamin Day’s approach so much.  Instead of setting arbitrary deadlines and features to be done by the development team which has no investment in the success of the project, the team is permanent with growing business knowledge and technical skills who take on projects as they are funded.  The business people also concentrate on setting priorities of what gets done.  The project is not thrown over the wall for IT to figure out or fail.  Finally, the business has the right to cancel the project if it is not working.  The team remains to take on the next challenge.  The business either discovers it has working software for the customer and does not need as much funding saving money or has been making a poor investment and can cut its losses.

Over the last fifteen years the Agile Reformation has made great strides in making software development better but it appears that business suites and finance teams are not changing their processes to accommodate this new approach. They do so at the risk to their own business.  Survival is not mandatory and these legacy finance issues will be a cancer in many businesses in the future.  It is up to us in the agile movement to try and help those worth saving.  Otherwise, technologists will be condemned to careers of temporary employment, failure and frustration.

Until next time.

You can't fight mother nature.

The flooding is pretty bad in Chennai

This has been an unusual week.  My off-shore development team have been off-line because of horrible flooding in Chennai, India. I have been worrying about the health and safety of my teams which include a few newlyweds and new parents.  This natural disaster also gave me pause to think about the things we can’t control.

A common theme in Western literature for the last two hundred years is the struggle human beings have over nature.  We have fought it on land, sea and air.  We have endured terrible cold and withering heat.  Authors from the naturalistic period of writing have been very honest with their readers.  People struggle against nature and sometimes nature wins.  More contemporary writing has ignored this wisdom and has championed human engineering and willpower.  Some books pioneer the bogus notion that we can use our willpower to transcend reality.

This kind of magical thinking has crept into the business world. It is not uncommon for project managers to think that if people work harder, faster, or smarter that can overcome the constraints of time and nature.  It is true that we can manage time better, but we cannot change the fact that you cannot force twelve months of work into five months of time.  Each day project managers and scrum masters are asked to do this and it undermines the very nature of our profession.

There are contingencies which can be made and allowances which can be incorporated into a plan.  Unfortunately, real life gets in the way and projects slip.  As Mike Tyson used to say, “Everyone has a plan until they are punched in the mouth.”  People get sick, snow falls, and entire cities and engulfed in flood waters.  People who make software are not tools to be used up and thrown away.  Software developers are not resources, they are flesh and bone people; so asking why the project is not on track is not only stupid but insensitive.

My heart goes out to the development teams, their families and the citizens of Chennai, India.  I hope all of you get through the catastrophe safe and sound.  Some things are more important that project deadlines and this is one of them.

Until next time.