Avoid Agile Transformation Pitfalls #8: "6 bad habits of Software Development"
With classical or hybrid waterfall/agile approach, there's a common issue across industries, many senior leaders and developers have become
No. 1: slaves to the tyranny of the Urgent with unrealistic timelines
It's really hard to fulfill requirements, no enough resource / budget to get things right, overloaded with numerous customer's requests, lack of enough investment in architecture, overtime, the accumulated flaws throughout the entire software development process create inadequate performance in production, very low customer satisfaction and snail-slow speed to meet rapid market changes. When urgency meets importance, unfortunately the former often wins. To be fair, there's never enough time to do anything, but it worth to spend the time to build incremental foundation for the long term success by adopting model based software engineering and scalable technology.
NO. 2: wastes
In the book "Implementing Lean Software Development", written by Mary and Tom Poppendieck, there were 7 wastes (muda in Japanese) identified: such as partially done work, extra processes, extra features, task switching, long waiting time, motion moving data from one location to another, ignore cost of defects. Leaders must understand that any of those patterns create more damages than benefits. There is no such thing called 80% done in software development projects, it is either working software or not, it's either completion of feature or not
NO. 3: The Loudest Voice wins over understanding Cost Of Delay
Software product development is a highly unpredictable process, it involves a constant evaluation of cycle time, value, product cost, development expense, risks. How are software development decisions actually made? Honestly, how often do you experience "HIPPO" (Highest Paid Person's Opinion)? We obviously must value their thoughts, but the final decision is a scientific approach.
“If you only quantify one thing, quantify cost of delay.”
“In Product development, our greatest waste is not unproductive engineers, but work items sitting idle in process queues.”
(Donald G. Reinertsen)
One of most successful approach is called WSJF, Weighted Shortest Job First, it is a prioritization model used to sequence jobs (eg., Features, Capabilities, and Epics) to produce maximum economic benefit. Cost of Delay (CoD) divided by job size. Capacity utilization doesn't always lead to more efficient delivery, if the bottleneck is not removed, that leads to high queue time, resulting in high cost of delay and huge waste, with little or none value for business. High utilisation of resources will NOT make the department more efficient.
NO.4: bad meetings habits that delay decision-making
CEOs spend the equivalent of two work days each week in meetings, according to a study by Bain & Company. At one organisation, Bain found that attendees spent 7,000 hours a year in the weekly senior leadership meeting, and subordinates spent 300,000 hours in related meetings and prep time! By the time when decisions are made, it's too late. But why does it happen? Why are meetings so ineffcient? And how to solve it? This happens if there's a lack of ownership, everyone has something to say and no one takes responsibility, there're lots of unproductive energy and people start to blame each other when no progress is made. Overtime, the culture becomes toxic.
One of the biggest benefit of introducing SAFe, is to align a common language on portfolio management, ceremonies and cadence, EPICs, features and user stories, especially in very complex decision making process, would it be great if the useless meetings can be eliminated so that people can actually working on things, and make progress? How great would that be? There's no such meeting that is not time boxed.
NO.5: treat software development as manufacturing process without value the variabilities
Manufacturing is repetitive and predictable, teams need to faithfully follow their development plan, any variability are bad and needs to be eliminated from the process. Because the variability can cause delays dramatically as utilization increases. But in software product development, requirement constantly changes, tasks are unique, the output can be anywhere, The plan should be treated as an initial hypothesis that is constantly revised. The traditional managers believe that deviations from the plan is poor management and execution. However, many events can disapprove the initial assumptions of the original plan. They also believe that works started early means it can finish early, this is non-sense if bottleneck is not properly understood, and system efficiency is not managed but just simply through more work to people. Variabilities in product development have a lot of value if is chosen wisely, and this can only be justified through testing, failing, learning and retest. Innovation comes from variability, innovation encourages and motivates people to explore and create something even better.
No. 6: Repetitive Technical Debt even with new Technology
A good architecture rarely happens through architecture-indiferent design. Agility is a quality attribute, a good architecture enables Agility (S. Brown). Even microservices doesn't help a bad archiecture.
Considering the triangle of successful software development in modern age: we need to create an organization with small, agile, autonomous cross functional teams, the process shall encourage continuous deliver, while architecture enables both processes and organization to work towards a fast time to market scenario. This doesn't mean that everything needs to become microservice, but it must be an architectural design concept.
The problem is however, people tends to become overly excited when new technology or concepts come alone, they don't want to be left behind and join this hype, consultant companies pack their slides with fancy words around those new terms, the challenge with new concept, is lack of understanding where boundaries are. Where is the balance between traditional monolith, Service Oriented Architecture? Overtime, new applications, technologies and interfaces become the new technical debt and everything just gets way more complicated. So before adapting new technology, first come up with a plan with solid root cause analysis what problem is behind legacy systems, later create a hypothesis to test in order to find out the ultimate solution to solve that problem, maybe it is the development process.
In general, software development is a complex and creative process, the better we understand how it works, the better we can steer the success, learning from mistakes is a good start.
Source: devoteam.com, agility.im, scrum alliance, S. brown, Scott W.Ambler, threedeep marketing, dilbert
Avoid Agile Transformation Pitfalls #1: "Consider Agile is Agility, Agile is Scrum"
Avoid Agile Transformation Pitfalls #2: "wishful thinking to change culture"
Avoid Agile Transformation Pitfalls #3: "start starting, stop finishing"
Avoid Agile Transformation Pitfalls #4: "incomplete view towards incentives"
Avoid Agile Transformation Pitfalls #6: "Taking shortcuts on change management"
Avoid Agile Transformation Pitfalls #7: "Surrender to Impediments"
Avoid Agile Transformation Pitfalls #8: " 6 bad habits of Software Development"
Avoid Agile Transformation Pitfalls #9: "Waterfall in Disguise"
Hao, this was a terrific blog and could not agree more with your thinking. While you hit on it above, the agile principle of Simplicity, the art of maximizing the amount of work not done, is essential! Resources (i.e. people, time, and money) so often spent on features and functions which are rarely used and/or delivery little to no business benefit.