Welcome to the sequel of SAFe versus LeSS adventure! The first SAFe vs LeSS blog gained attention and we were able to pick more emphasized questions.
Q1: Any over-arching framework is wrong a priori, isn’t it?
Jari: Some may state that you can’t define a framework suitable for any Enterprise. This can be seen a priori being a false assumption, while no rigid process fits to all the enterprises. One may continue by saying that you can’t have a combination of “Agile” and “Framework”. Agile means freedom of choice, while Framework is a process. Framework stifles the change needed in the organization. Agile Manifesto states “Individuals and interactions over processes and tools”. So one may say that any predefined process is anti-Agile.
Q2: How to deal with the “Weaponized Agile”?
Jari: “Weaponized something” is where the management uses agile sounding words to get ahead of the change and stop it.
- The program management structure of SAFe might create a construction for abuse. A multi-level management structure provides a fruitful platform for narcissist powerplay associated often with heavy hierarchies.
- LeSS provides less possibilities for hierarchical powerplay. LeSS HUGE has roles of PO and Area POs. However, LeSS provides plenty of freedom. Freedom for each PO to selfishly develop what matters most for themselves.
In my opinion frameworks don’t hurt people. People hurt people. Corrupted people find their ways of working in any form of organization. Do not operate with bad people.
Q3: LeSS is difficult to sell toward higher management (who will get sacked).
Juhana: It’s true that the LeSS approach is more radical than the SAFe approach. While SAFe focuses on monetising the agile transformation process, LeSS reveals the real agile principles and values. There are a few patterns that help to reduce managers’ resistance towards LeSS:
- Highlight the ‘job safety, but not role safety’ rule of LeSS. Even in LeSS managers are critical for to the system to operate. The management turns themselves into system thinkers, learners, and teachers.
- Focus on teaching the principles. Show how the LeSS principles effect organisation policies, procedures, and structures. Show how the LeSS approach solves existing problems. Keep the Scrum and LeSS jargon to a minimum until the agile adaptation is thoroughly implemented. Point out the learning opportunities. Many former developers are excited by the opportunity to return to hands-on development.
- Is a surgeon more recognised than a hospital manager? The same mind-set should be applied in product development organisations. Hold unofficial mini training sessions for managers. Be open and explain the principles and values behind LeSS. Remember to include managers in the new organisation structure.
Q4: SAFe is program centric and doesn’t force the change. Adopting SAFe is a way of avoiding coming to terms with the inherent problems in the organization, isn’t it?
Stefan: SAFe has a clear implementation roadmap. The implementation roadmap starts with training the change agents and then addresses the executives and managers. Leaders will be involved in the change. Their role will be to provide sponsorship or to directly contribute to the implementation of SAFe. The adoption of SAFe requires that leaders embrace lean-agile mindset. SAFe will expose the impediments of the organisation sooner or later – also the impediments at management layers.
Q5: LeSS is more about Principles and less about Tutorials. This means that you need a highly skilled practitioner to be able to apply it into practice, doesn’t it?
Juhana: A change management requires the implementation, and the agile transformation is not an exception. You need an agile coach who has a strong knowledge of agile approach, coaching, and product development. The coach mentors and teaches core personnel of the organisation. Anyhow, motivated people learn agile rapidly. It is not rocket science. LeSS is anyhow easier to adopt compared to process-oriented SAFe, which even has its own glossary. The external agile coach role is also temporary. Scrum Masters and ex-managers will take charge fast.
Q6: SAFe is easy to sell. Executives like everything that comes in a box. SAFe comes in the box and hence is attractive. The reason SAFe is easier to sell, is that it doesn’t really require people to become Agile. Or does it?
Stefan: SAFe is a collection of battle-tested practices and operational models. It’s true that it’s attractive and easy to sell. But it also requires changes in how organisation works. The team level results will be visible after the first sprint. On program level the results are obvious after an increment. Thus, it should be fairly straightforward to judge based on the results. SAFe requires agility not just from developers and teams, but from the whole organization.
Q7: What is the business case for agile transformation? What is the cost structure? When would ROI reaches the tipping point?
Juhana: Shipping speaks louder than words. LeSS brings benefits of dramatically dropped cycle time, simpler organisation structure, and higher job satisfaction. SAFe might give you the same result, but much more slowly and painfully. What is the cost when the organisation won’t adapt faster feedback loops or benefits of the cross-functional teams? Go and ask from the competitors of Tinder, Airbnb and Amazon. Organisations don’t fail when they take risks. Organisations fail when they stop taking risks. LeSS takes effect from the first day. The adaption process is straightforward, as you can see from the previous post. The agile transformation is an investment which has a short payback time!
Stefan: Companies must find ways to tackle and conquer the ever accelerating market and technology changes. The goal of agile transformation is to accelerate the organization. To enable the organization to deliver more value in less time. With happier employees, increased productivity and improved quality. LeSS might seem like an easier and simpler solution, but actually it requires much more from the organisation that will adopt it when compared to SAFe. SAFe allows you to configure and scale it according to your needs. SAFe also provides proven implementation instructions, which help you to get started faster.
Jari: Both systems have been developed while using them in the real life business. The systems evolve all the time when more is learned about scaling Agile. According numerous case studies the impact of Agile transformation is visible from the day one and ROI is considerable. You can read the real life war stories from https://less.works/case-studies/index.html and http://www.scaledagileframework.com/case-studies/
Q8: Finally, as a summary. We can now clearly see that LeSS and SAFe aims to different markets and different kind of organizations. Where do you see that your frameworks would suit the best?
Juhana: LeSS is a product development framework for creating products with a high degree of variability. LeSS fits every organisation, whose core values are transparency, continuous improvement, and customer centricity. And unlike SAFe, LeSS follows these values!
Stefan: SAFe addresses the needs of small, medium and large companies. It does that by allowing organisation to select and configure the parts needed. SAFe allows jump start even for big companies, and you can start from top, botton and middle at the same time. With LeSS you would need to start from the botton and work you way up, which will take time.
While the comparison often tend to narrow down the vision, I would like to end the blog with a quote from the book Leadership and Self-Deception By The Arbinger Institute:
“Success (as a leader) depends on being free of self-betrayal and creating an environment of openness, trust and teamwork, where people work hard for the collective good, not individual accomplishments”
Thanks for reading!
Humans are naive. If something is written in black on white, they believe it. When a contract states that the project fulfils certain requirements and will go online on a certain date, they believe it. In reality, it does not matter what the contract states. The project still probably fails.
Pig in a Poke
I’ve seen numerous occasions where software is sold based on an unrealistic contract. The contract includes all one could ever dream of. Fast schedule. Cheap price. And all the killer features listed in the requirements. The dream come true is hard to believe, so the contract contains also penalties. The penalties calm everyone down; a dream come true is possible, because otherwise someone is theoretically being punished.
If a deal looks too good to be true, it probably is.
– Michael Douglas (FBI Public Service Announcement)
In reality, the contract paper is just being used as a catalyst to get the project started. When the project hits the deadline, there are no other options that just keep going. The business owner wants results. The project is almost there. A few extra bucks and the project will be finished. You can’t really use the penalties, because they would just slow things down. In the worst case the subcontractor would end up bankrupt. That would definitely kill the velocity.
All this can be avoided by transparency. The transparent win-win attitude starts from the first steps of the negotiations. Win-win culture and honest transparency are tools to succeed in software projects. If the negotiations are run in an old-school mode, where the doubt is tangible, the project will fail.
Picture: You don’t want your project to hit a deadline
Software purchase follows a process: top management comes up with a new business vision, middle management creates a list of killer requirements and the procurement department sends RfQs to a few software companies they know. At the sales end: a sales person forwards the list of requirements to a project manager, who ends up with a work amount estimate. The sales person sets a price for the work and returns a quotation. Finally, the buyer chooses the cheapest quotation. Being a project manager, I see three different paths for the sales process.
1. Sell Cheap & Bargain for Extension
This is the classic tailboard (deadline) trick. It will leave everyone disappointed. This model starts with an offer the buyer can’t refuse.
I’m gonna make him an offer he can’t refuse.
– Marlon Brando (The Godfather)
When the project starts, everyone writes a lot of code using low maturity ways of working. Because the schedule is so challenging, the documentation, integration and testing is postponed until the main killer features are being launched. The project hits the deadline when it is 80% ready. Quite a few features are still under the development. All the money and time is spent. The system is “not quite yet” up and running.
Now starts the most strenuous cycle. Everyone searches for a scapegoat. Usually the project manager gets the blame. The next step is to bargain for extension; just a short and cheap extension, during which the last 20% of the work will be finalized. “It doesn’t make sense to flush all the expensive code we have already written!”. Yet another offer one cannot refuse.
The cycle of blaming and bargaining extension projects until the functionality reaches reasonable level or the project is courageously killed. The final price and schedule will be huge compared to the original offer.
Picture: Fixed price often results low quality high cost
2. Sell Buffer
Quality software houses seldom make cheap offers. Instead they make realistic offers. The requests usually contain only a partial set of requirements needed for a fully working system. Functional requirements are forgotten. Crucial user groups are totally missing from the requirements, because the top management has described only the new killer features. Nobody has thought about the non-functional requirements.
You can’t handle the truth!
– Jack Nicholson (A Few Good Men)
Therefore, a quality software house adds plenty of buffer into the fixed offer to cover all the unknowns. This sounds like a reasonable approach. However, nobody knows how this model would work, because the realistic offer never wins.
Picture: An honest man never wins
3. Sell Agile
Mobile, agile, hostile!
– Denzel Washington (Remember the Titans)
The agile mindset assumes that nobody understands requirements up front, so the project is split into short sprints. During the sprints developers work in tight co-operation with customer representatives. Each sprint ends with a working demo. Methods of high maturity are followed; everything is documented and tested. Mostly automated. The cost and output of each sprint are transparent for all the parties. The velocity is transparent for everyone. If a sprint doesn’t demonstrate the new features, velocity is 0. No excuses. The sprint is the heart rate of the project. The customer can stop the project at any moment. The customer can transfer the work to another subcontractor at any moment.
Picture: Agile is transparent
The advantages of an agile mindset can be exploited even while buying a fixed project. The offer can be divided into a prioritized list of must have, should have, could have features. The few first sprints will foretell the velocity, which helps to fine tune priorities. Transparent communication regarding priorities and velocity is crucial.
Everything Starts with The Procurement Process
The bidding process defines project success. The process determines whether the buyer buys the right things. The process must not bind such variables that will derail the project later. The process must consider variables vital for project success. Not a single person obtains all the needed knowledge for a successful purchase. Success always requires co-operation. Co-operation inside the target organization and co-operation with subcontractor candidates.
Aim of the text was to encourage the agile mindset. The best way to reach a successful software project is to spar the project objectives openly with subcontractor candidates. Transparent communication increases knowledge of all the parties regarding objectives, needs and implementation options. The fastest way to sink a project is to start with a shoddy purchase process. The easiest way to make a quality purchase is to use an external consultant to run the process. Someone who has a long track record of successful project purchases. The external consultant has the guts to challenge both buyer and seller. Both on mindset and content.
Finally, numerous saved software projects exist. Projects where the work has been bravely transferred to another contractor at the event of deadline. Transparent and fact based agile decision making is the corner stone of modern management.