Dealing with Bad Processes

Bad business processes are crushing software development productivity. Here is the mistake I see over and over in all types of business genera. Sprint plans are made with good intentions. Development work starts and is progressing nicely. Then only days into the sprint management receives a call from a customer or boss ordering an immediate change of direction. Meetings are called and the current plan is back logged in favor of the change order.

Agile was made to handle this very scenario; however, not every sprint or every other sprint. This type of behavior from a business creates the exact opposite effect desired. Delays time to profitability, creates half-baked software, and grinds on the staff.

Here’s an important point:

“If the business can’t stay focused for more than a single sprint (2-3 weeks) failure is eminent.” 

The level of failure may be confined to one area of the business. Nevertheless, you will pay the piper in some form. Typical in wasted time and money.

This paradigm is especially true for start ups. They must have a solid understanding of what success looks like and what needs to be accomplished to generate revenue. My colleagues and I have seen first hand what happens to businesses that just “go for it” or “work it out on the fly”. The result is never pretty.

Cause and effect

The cause is sometimes legit. The company is going to lose revenues due to not taking action concerning a certain issue. However, why are we here in the first place? Bad processes, indecisive leadership, or quite possibly unanticipated market changes.

The cause needs to be examined and understood by all involved parties. Not performing this action will result in more of the same. Understanding will lead to solutions.

The effect of the business not having its shit together has ramifications. Unhappy employees, frustration from all sides, and fading stability are the start. Here’s another epiphany:

“Software development is only as good as allowed by the business.” 

Developers do not have this magic box from which they sprinkle fairy dust and everything “just works”. Write this one down:

“Great software starts with great business leadership.”

From great leadership comes support, planning, organization, and precise execution. Now developers are empowered to do what they were hired to articulate. Killer code that delivers business value.

Another effect is the development process itself breaks completely down. The current and possible subsequent sprints are crushed, all team metrics get jacked, and you have developers, analysts, and QA scrambling to understand what just happened.

Think of the sprint as the battle ground. If the army goes into battle with a plan they know will work and all the sudden some hot shot general decides to do something totally wack  Do you think the men will trust him? That’s a negative ghostwriter!

Well laid and executed plans lead to success in business and software development. Not planning or flipping good plans on their head, is no bueno. Below is a synopsis of what can happen when business throws a monkey wrench at a sprint:

  • Software quality suffers
  • Increased Production Support
  • Promotes a discouraged and confused development team
  • Good people will run from chaos and mayhem
  • Time to delivery and revenues just got extended

Stay out of the way

The best thing the business can do is be there when asked; otherwise, please get out of the way, so the staff can get their job done with minimal disruption. Meddling managers and business leadership will have a detrimental affect. If you want to know what’s going on come to the review at sprints end. You can have your say then.

Constant change is compatible to the Hawaiian volcano. It’s looks beautiful, but the devastation is not repairable. You just have to start over. 

All businesses will have the occasional unexpected turns and twists. That is a fact of doing business. However, constant change is typically a desperate act by a desperate business trying to find something that brings in revenue. Make no mistake the development staff is aware.

Developers today are freaking smart and business savvy. They want their businesses to succeed and want to aid in that success. There is little that compares to the satisfaction of developing good software that delivers on expectations. This happens when developers are allowed to perform and the result is a win for the business.

Managing Change

Change happens. In fact, change is good. Change means progress and makes us better. Change is going to happen with or without you. Developers by definition are “Change Agents”. The administers of change. 

With that said there is good change and bad. Unplanned changes are typically bad in the software development world, but are inevitable, so how do we handle these? Simply put… After the current sprint

This will allow time to turn unmanaged change into managed, organized process. In fact, it falls into our normal agile process giving us time to document the needed changes, define the best course of action, and examine the effect of proposed changes to the current systems. Now we are acting like sane professionals who invite change and handle it with grace. Not like some ‘insane clown posse’ reeking of rookie sweat!  

Conclusion

These are the facts. You can ignore them and keep “doing your best with what you have” or you can stop the madness, call a consulting firm who knows exactly what you need, and start down the path of righteousness.

Lean on their expertise. They will tell you straight up. “Your processes suck!”. They will also show you how to form good habits, practices, and teach your organization each persons role in the software development process.

Whatever you decide… Change is needed!

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: