“80’s rule man, best time ever! Then that Cobain had to come around and ruin it all.” is a funny quote from the movie Wrestler. Today’s software experts might also yearn for former times. In the waterfall model, the role of architecture was clear – it was designed up front, after requirement analysis and before the implementation phase. In the current Agile era, architecture is often evolving without clear goals and objectives.
Yin and Yang
According to “Clean Architecture”, the purpose of architecture is to support the lifecycle of the system. The ultimate goal is to minimise the lifetime cost of the system and to maximise programmer productivity. Traditionally, dedicated experts have been accountable for this function. In this blog, these experts are called software architects, but technical leads and stack leads are also commonly used titles. Typically, software architects have a strong technical background and good leadership skills.
One of the Agile core values is the development teams’ autonomy. Teams design, implement, test and deploy independently. Traditional Agile methodologies, such as XP (Extreme programming) and Scrum, do not mention how architecture design should be led in practice. XP advises, for example, that architecture design just emerges alongside other design.
The larger the project (i.e. multiple teams), the more complex is the product’s software itself. This means that architectural decisions will have a bigger impact. The question then arises how architecture design is led and what responsibilities software architects versus teams have?
Make your system visible
Systems thinker and the father of the quality evolution, W. Edwards Deming has said that 96% of organisational performance is a function of the organisation’s structure. Only about 4% of an organisation’s performance is attributable to the people. Part of the structure is to understand how collaboration works in the system.
The following table makes collaboration between architects and teams visible. Every row of the table represents a potential point of leverage. The columns represent different options as to how collaboration can be implemented. Left columns represent a more distributed and emerging architecture mindset (i.e. Agile) and the right columns a more centralised and formalised approach. Organisations are different, and therefore leverage points and options vary as well. Rows are also independent, so for example “Architects are part of the teams” and “Architects are dedicated mostly to architecture topics” can be used on the same project.
<– more distributed more centralised →
Point of leverage
|Hierarchy levels||One level – no special roles, just team members||Two levels. Developers and architects||Three levels+. Team members, architects, chief architect|
|Scope of software architects||None||Architecture principles (e.g. standards, concerns, styles)||Architecture principles and infrastructure & operations||As option 3 plus enterprise architecture|
|Alignment||No architects. Team member is the only role||Architects are part of the teams.||Architects work as free agents||Architects form a team or department|
|Decision making||No architects. Teams make architectural decisions||Teams and architects make architectural decisions together||Architects make most of the architectural decisions|
|Division of Work||No architects. Teams share responsibilities dynamically||Architects and teams share their responsibilities dynamically||Architects have predefined responsibilities|
|Capacity||No reserved capacity. Teams use their time on architectural topics if needed||Architects/teams have reserved capacity for architecture topics||Architects are dedicated mostly to architecture topics|
No “one-fit for all” solution
After the current collaboration model is defined, the next step is to decide the future direction. Organisational systems are determined by their context, so “one-fit for all” solutions aren’t appropriate. Nevertheless, some conclusions can be drawn.
Typically, the long-term goal should be to move to the more distributed and self-organising collaboration model. When people understand the collaboration strategy, it is much easier to take actions toward it. Unfortunately, organisations underestimate the amount of work that the transformation requires. People have different skills and expectation levels and unlearning at both the organisational and individual level is required.
Agile is also a highly disciplined method. Business people and team members must work together daily; the cross-functional team structure is mandatory and software delivery must be frequent, to name just a few principles. If the organisation won’t bend to these demands, a more centralised collaboration model might be the valid option.
Sub-optimising is also a risk in bigger organisations. A team might violate architecture principles thoughtlessly, just to finish their sprint backlog faster. The other team might implement a similar service that has been already created by another. Architects see more easily the whole and are able to make holistic decisions.
Many organisations’ technical debt is huge as well. Products suffer wrong technologies or bad programming practices and an enormous amount of refactoring work is needed. Painful architectural decisions are often made more efficiently by a more centralised collaboration model.
A hero is required
Software architecture is not the hottest topic in the software development field. In addition to this, it is very abstract and hard to lead. However, all software has an architecture regardless of if the architecture is managed or not. Smart organisations understand that the organisation structure should be optimised for the most crucial paths of collaboration – and collaboration between teams and architects is part of it.
The Clean architecture – Robert C. Martin
Technical leadership and the balance with agility – Simon Brown
By now, it has become an annual tradition at Gofore to conduct a Project Radar survey at some point of the year to gain better insight into our presently running software projects. The 2018 Gofore Project Radar builds on two previous Project Radar iterations, conducted in fall 2016 (in Finnish only) and spring 2017, containing a set of questions relating to currently employed tech stacks, development practices and projected (or hoped-for) technological changes. Most of the questions from last year’s Project Radar made their way into this year’s Project Radar to allow for year-on-year variation detection. We also added some new questions that were considered important enough to warrant their inclusion in the survey.
So with the 2018 Project Radar results in, what can we tell about our projects’ technological landscape? What can we say has changed in our technological preferences and project realities over the past year?
The Gofore Project Radar survey results for 2018 are in! [Click on the image to enlarge it].
Over the past few years, the frontend development scene has shown intermittent signs of “framework fatigue” as a steady stream of new frameworks, libraries and tools has flooded the scene, challenging developers to work hard to keep pace with the latest developments, current community preferences and best practices. A look at our Project Radar data tells us that at Gofore there has been no significant churn when it comes to primary frontend technologies employed by individual projects. Instead, the results indicate a distinct consolidation around React, Angular and Vue.js, the three major contenders in the JS framework race. All these three have gained ground on older frontend techs (AngularJS, jQuery etc.) and ratcheted up their project adoption percentage, React being the top dog at a near-50% adoption rate among projects represented in the survey. If given a chance to completely rewrite their project’s frontend, most respondents would, however, pick Vue.js for the job.
The fact that there was no major change from last year in preferred frontend frameworks is perfectly in line with developments (or lack thereof) on the frontend scene over the past year. While last year saw major releases of both React and Angular roll out (with Vue.js 3.0 still somewhere on the horizon), there were no new frameworks to come along that would have been able to upset the status quo and catch on big time in the community (regardless of distinct upticks of interest in at least Svelte.js and Preact). This stability comes in stark contrast to the unsettled years in the not-too-distant past when the balance of power between different JS frameworks was constantly shifting as new frameworks and libraries appeared on the scene.
Looking beyond the battle of JS frameworks, a significant trend with regard to frontend development is the ever-increasing share of single-page applications among our projects’ frontends. Around 64% of this year’s Project Radar respondents reported to be working with single-page applications, up from 57% in last year’s Project Radar results.
Node.js on the rise
Moving our focus to the backend, where Java has traditionally held a predominant position among our projects, a somewhat different trend emerges. While the Project Radar data clearly brought out a tendency toward consolidation around the three major frontend frameworks, the picture on the backend side, on the other hand, looks a little more fragmented. Last year’s Gofore Project Radar pegged Java usage at nearly 50% among all projects represented in the survey, trailed by Node.js and C# each with a 15% share of the cake. While Java still came out on top this year, it was reported as the primary backend language in only 32% of the projects, down a whopping 15 points from last year’s results.
This drop was fully matched by an upward surge by Node.js, which more than doubled its share of the overall pie, up 17 points from last year. While C# stood its ground at close to 15%, a crop of new languages, missing from previous years’ results, entered the fray in the from of Kotlin, Clojure and TypeScript. Regardless of there being only a handful of projects where they were reported as being primary backend languages, they contributed to the growing share of minority languages in our backend landscape, a group previously comprised of Scala, Python, Ruby and PHP.
Similarly to how respondents were asked to choose their hoped-for replacement tech for their frontends, we also asked our developers what was their preferred language for rewriting their backends if given the chance to do so. Last year most respondents would take the cautious approach and stick with their previously established backend languages. This year, however, there was considerable interest in rewriting backends in Kotlin, particularly among respondents who reported Java as their primary backend language (55% of all respondents were eager to switch to Kotlin from some other language).
Before drawing any conclusions from these statistics, it should be noted that upwards of 55% of respondents reported to be working with a microservices-type backend stack, suggesting that potentially multiple languages and server-side frameworks might be used within a single project. Still, the appeal of Kotlin, particularly among Java developers, is clearly apparent, as is the shift toward Node.js being the centerpiece of most of our backend stacks.
The popularity of Kotlin, on the other hand, has been picking up ever since Google enshrined it as a fully supported language for Android development. Considering its status as one of the fastest-growing programming languages in the world, its increasing presence in server environments is hardly surprising.
Now where do we run our project infrastructure in the year 2018? According to last year’s Project Radar results, more than two thirds (68%) of all respondents were still running their production code in a data center that was managed either by the client or a third party. This year, that number had come down to 59%. While this isn’t particularly surprising, what is mildly surprising, though, is the fact that IaaS-type infrastructure saw an even greater decline in utilization. Only 47% of all respondents reported to be running their production code in an IaaS (Infrastructure as a Service) environment, as opposed to 60% last year.
As the utilization of both traditional data center environments and IaaS services fell off, PaaS (Platform as a Service) and, especially, serverless (or FaaS, Function as a Service) platforms were reported to take up a fair portion of the overall share of production environments. While still in the minority, PaaS services were reported to be used by 12% of all respondents, tripling their share of 4% from last year, and serverless platforms by 16.5% of all respondents (no reported usage last year as there was no dedicated response option for it).
As our projects’ production code is more and more removed from the actual hardware running it, containerization has also become more commonplace, as evidenced by the fact that Docker is now being used by 76% of all respondents (up from 43% last year). Despite Docker’s increasing adoption rate, there wasn’t much reported use for the most popular heavy-duty container orchestration platforms: Kubernetes, Docker Swarm, Amazon Elastic Container Service and OpenShift Container Platform were only reported to be used by 14% of all respondents.
Since running our code in cloud environments enables shorter deployment intervals, one could think we’d be spending more time flipping that CI switch that kicks off production deployment. And to some extent, we do: we have fewer projects where production deployments occur only once a month or less often (10% as opposed to 20% last year), but, somewhat surprisingly, fewer projects where production deployments are done on a daily basis (10.5% vs 12% last year).
- Key-value databases doubled their reported project adoption (32% vs 16.5% last year)
- Jenkins was the most prevalent CI platform among represented projects, with a 57% adoption rate (its closest competitor, Visual Studio Team Services/Azure DevOps well behind at 17%)
- Close to nine percent of all respondents reported to be using a headless CMS (Content Management System)
- Ansible was being used by 71% of respondents who reported using some configuration management (CM) tool, clear ahead of any other CM tools (Chef was being used by a little shy of eight percent of CM tool users, while Puppet had no reported users)
- Development team sizes were smaller than last year (57% of dev teams had five or more team members last year, whereas this year such team sizes were reported by 52% of respondents)
- The reported number of multi-vendor teams was smaller than last year (41% vs 47% last year)
- Most respondents reported to be working on a project that had been running 1-3 years at the time of responding
- Most project codebases clock in at 10k – 100k in terms of LOC (lines of code)
- Scrum was the most favored project methodology, being employed by nearly 51% of all represented projects. Kanban, on the other hand, saw the most growth of any methodology (22% vs 12% last year)
Some closing thoughts
Once again, the annual Project Radar has told us a great deal about our preferred programming languages, frameworks, tooling and various other aspects of software development at Gofore. While the survey is by no means perfect – and I can easily come up with heaps of improvement ideas for the next iteration – the breakdown of its results enables us to more easily pick up technological trends in our ever-increasing multitude of projects. This year’s key takeaways are mostly reflections of industry trends at large, but there are some curiosities that would be hard, if not impossible, to spot if not for the Project Radar. The usefulness of these findings is debatable, as some of them fall under trivia, but still they come as close to a “look in the mirror”, technology-wise, as one can get at a rapidly growing company of this size.
Running a software development project is complex and scaling it is even more difficult. Typically, scaling means multiple teams, roles and processes. In the worst scenario, ‘metawork’ such as meetings, coordination, handovers and over planning kills the development efficiency totally.
A common root cause is the wrong organisational structure. Often, organisations are based on specialised teams which are focused to deliver only one thing. A specialised team is also called a component team and is accountable, for example, for requirement analysis; front-end development; user experience; architecture design or deployment. This structure might feel rational, but the reality is different.
In the component-based organisation, the development process is slow, complicated and contains a lot of handovers. Typically, a new feature is created and planned by the requirement team. When the feature is written, the first development team (i.e. backend team) will implement the feature and assign it to the next development team (i.e. frontend team). When implementation is ready, the testing team will test the feature. Finally, after the feature is tested, the system team will deploy the feature to the production.
Features are rarely the same size and they often overlap. For this reason, some teams create queues and other teams become bottlenecks. This is the textbook example of the sub-optimisation that creates a lot of waste (i.e. partially ready features) and causes priority and resource fights. Multitasking is also very frequent in the component-based organisation.
A feature typically consists of multiple components which generate dependencies between component teams and make integration painful. The feature’s programming code is separated into different components and continuous integration turns into “delayed integration”. A typical pattern is to introduce a coordinator role, such as an integration manager, whose responsibility is to integrate parts together.
The feature ownership is also vague in the component-based organisation. Should the frontend team, database team or user experience team take on the responsibility of the feature? The solution is a new coordination role such as feature manager or product manager. The larger the project, the more coordinator roles are needed.
In the component-based organisation, every team knows only one part of the system. This reduces learning and makes the product vision unclear to team members. Component team’s “customers” are other component teams, not real end-users.
The end result is a waterfall development model where completing one feature can take from months to years. Agile practises on the team level won’t help because impediments are at the organisational level. Luckily, there is a solution available and it’s called the ‘feature-based organisation’.
Cross-functional and cross-component
In the feature-based organisation, teams are cross-functional and cross-component. Cross-functional means that the team completes end-to-end features independently. Typically, the team consists of developers, testers, system specialists and designers. Having said that, the individual team member does not need to know the whole system or have all the skills.
Teams are also not organised around specific components but can work on all modules. Components still exist, but they are not used as an organisational structure.
Dozens of benefits
The feature-based organisational benefits are clear. According to ‘Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum’, advantages include:
- increased value throughput–focus on delivering what the customer or market values most
- increased learning–individual and team learning increases because of broader responsibility and because of co-location with colleagues who are specialists in a variety of areas
- reduces the waste of underutilized people
- simplified planning–by giving a whole feature to the team, organising and planning becomes easier
- reduced waste of handoff–since the entire co-located feature team does all the work (analysis, design, code, test), handoff is reduced
- less waiting; faster cycle time–waiting is reduced because handoff is eliminated and because completing a customer feature does not have to wait for multiple parties each doing part of the work serially
- self-managing; improved cost and efficiency— The team has responsibility for end-to-end completion and for coordinating their work with others. Feature teams are less expensive–there isn’t the need for extra overhead such as extra managers and coordinators
- better code/design quality–multiple feature teams working on shared components create pressure to keep the code clean, formatted to standards, constantly refactored, and surrounded by unit tests.
- better motivation–research shows that if a team feels they have complete end-to-end responsibility, and the goal is customer-directed, then there is higher motivation and job satisfaction
- simple interface and module coordination— the feature team works across all components; no need for inter-team coordination.
- change is easier–changes in requirements or design are absorbed by one team; multi-team re-coordination and re-planning are not necessary.
There are a few boundaries in the feature-based organisation which must be tackled. The organisation could have special contracts with vendors, for example, infrastructure and development contracts are separated. Nevertheless, a feature-based organisation is possible, teams would just be a mixture of different vendors.
Team sizes might also be bigger in the feature-based organisation. Scrum guide recommends a team size of less than nine. Although, working with larger teams has much fewer side effects than working with component teams.
Keeping the quality consistent and how to share best practices are challenges in large projects. These risks can be reduced by creating communities or guilds with responsibilities for example, for architecture, user experience or testing. Communities or guilds are run by the team members and their communication and coordination is informal.
Sometimes the feature team lacks skills. A shared team member is a quick fix, but not the optimal solution. In the long term, the organisation must support the team e.g. with training, finding the best team-sets or hiring new people.
Culture follows the structure
The component-based organisation is based on the assumption that one person can only do one specific job. In contrast, an Agile mindset is based on learning, cooperation and the team’s self-managing abilities. Agile and the component-based organisation is a contradiction that cannot be resolved. The organisation must choose which road to take.
Graphic Design Ville Takala
A Decade of Descaling with LeSS:
The Scrum Guide:
Further reading from the Gofore blog
Agile Transformation in Action – Part 1
Agile Transformation in Action – Part 2
What’s the point scaling Agile
We are always on the lookout for skilled developers to join our award-winning team. We have exciting projects running throughout 2018 in Helsinki and Tampere – get in touch to find out more
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!
First of all. Ahoy, all you “Why agile” and “I don’t need scaling, I already have Scrum” people. Please start here.
I’ve followed the growing interest towards methods of scaling agile for the last decade. Personally I faced the idea of scaling Agile, whilst working as a subcontractor for Nokia. Back then two very different kind of frameworks were born. Ari and Ran explains the history of these scaling frameworks, so I won’t go there. I’ll just want to find out, which approach is better. The fastest and most entertaining way is to take our two of the most experienced scaling agile gun men Stefan and Juhana and start shooting. Whilst the gun men are warming up, let’s make a quick generic comparison of the frameworks.
We’ve blogged earlier about SAFe (in Finnish) and LeSS in rather positive tone – now it’s time to get some friction between them. Like in all the unforgettable shootouts, the tension must be built gradually from introduction and rising action towards climax.
I must say, if I created a scaling framework, I wouldn’t name it either “Safe” or “Less”. The “Less HUGE” makes things even more paradoxal.
There is a clear winner on the field of naming the Scaling Agile framework. The Recipes for Agile Governance in the Enterprise aka “RAGE” wins the fight between names.
Never, ever design usability restricting cr*p on any media in the name of copyrights. It is a lose-lose deal.
- The hippie drawing style of LeSS will make all the wave riding, new age developers feel warm and fuzzy.
- The engineering style, mind-blowing-in-details drawings of SAFe will make all the managers feel super important. However, the copy-paste restriction of SAFe portal sucks, while it also disables for example text search of browser.
LeSS wins the fight between the portals.
We live in a colorful world. Use them.
- Both books are the same diameter and around 330 pages.
- Both books come from Addison-Wesley.
- SAFe book has more pictures and colors, otherwise they are rather similar.
SAFe wins the fight between books with flying colors.
Introduction of The Gun Men
Question #1: Tell us a little bit about yourself and when you became a fan of SaFE / LeSS?
I’m a business manager and consultant at Gofore. Currently I’m focusing on our customers in health technology, healthcare, social care and wellbeing businesses. Throughout my professional career I’ve been interested in all development methods – from SW development to business & customer development. I was first exposed to SAFe whilst working at Nokia a decade ago, but the real revelation of SAFe to me happened at GE Healthcare in 2014. We had 16 teams, nearly 200 professionals scattered across globe with a goal to create multiple new products together. We applied SAFe to align the goals, sync on delivery and to optimize flows.
I’m a lead consultant of software development at Gofore. I have a background in software engineering and have been in the IT field for more than decade. I’ve taken part for some of the biggest public sector digitalization endeavours in Finland. For some reason, I’ve always been the guy who’s removing obstacles and trying to improve everything. So, the Scrum Master’s duty was a natural choice for me. Lately, I’ve focussed on transforming entire organisations to Agile mode. In the latest project, I was consulting a large software program that required Agile transformation. I needed a powerful and straightforward solution for the transformation. The LeSS approach caught my attention very quickly; the LeSS principles and rules were understandable and simple. The challenges confronted in the target organization were tackled intelligently with the LeSS method. This would not have been possible if using a one-size-fits-all format such as the SaFE.
SAFe interest people in management type of roles and LeSS fascinates adventurous problem solvers.
Question #2: Imagine a 40 person project working in waterfall model. How would you deploy SAFe/LeSS?
Educate everyone into Agile mindset
SAFe provides the best practices from industry also for the deployment of SAFe. The things to conside in deployment are:
- Train everyone: a) train the leaders, b) train the internal change agents, and c) train project personnel.
- Split project to 2-pizzas-serves-them teams. Select team level development methodology, e.g. Scrum. Make sure that teams have the right set of competences to work as feature teams.
- Define the way of working for the organization. For a 40 person program the two lowest level of SAFe framework serve the purpose: 1) Team level and 2) Program level.
- Then it’s about start your Agile Release Train to develop in common cadence according to commonly agreed increment plan. The increment planning and demo sessions are where the magic happens – the whole program planning, resolving and agreeing together in the same room and at the same time.
The LeSS creator Craig Larman’s advice for large, multi-site, and/or offshore programs is just ‘don’t do that’. Instead pick the ten best developers. If you must scale, here are the adaption principles:
- You should educate everybody. The easiest way is to sign people to the Scrum and LeSS trainings. The formal coaching is followed up by a team, organisational and technical coaching.
- Define the product as broadly as possible. A broader definition tends to be more customer centric and creates simpler organisations.
- Define the ‘DoD (Definition of Done)’. A better and stronger DoD eliminates groups, roles, and positions.
- Have appropriately-structured teams. One team member belongs to only one team, and the teams are stable, long-lived, cross-functional, and co-located. Only the Product Owner provides work for the teams. Keep managers away from the teams.
Both approaches aim to educate and engage everyone.
Question #3: Our current organisation has 3 team leaders, 1 architect, 1 project manager, 1 product manager and 1 UX/AD specialist. What would these persons do in SAFe/LeSS?
When using Scrum on team level then there are roles of the Scrum Master, Product Owner and SW developers. On program level you’ll find Product Management and Business Owners. Note, that the role of leaders in SAFe is different from traditional management – the roles are Lean-Agile leadership type of roles.
- The old team leaders from the legacy organization could become developers, Scrum Masters or Product Owners depending on their capabilities and desires.
- Architect and UX/AD specialist could continue working across the teams in program level roles.
- Project manager could be promoted to the role of Release Train Engineer.
- Product Manager could continue with same title, but in a modified role at product management.
Specialised roles are forbidden in LeSS.
- The team leaders can become Scrum Masters. They should follow the servant-leadership-mindset such as putting people first, coaching, removing obstacles, and creating the community. One Scrum Master can serve one to three teams.
- The Architect and UX Designer will each join a team. In addition, the architect can lead or be part of the architect community, and the UX Designer can lead or be part of the user experience community. The communities ensure the cross-cutting quality and are run by the team members.
- the product Manager can take the Product Owner’s role and responsibilities.
- The project Manager could focus on increasing the capability of the organisation’s value delivery with using techniques such as ‘Go and See’ and ‘See the Whole’. The Product Manager role is also temporarily needed if there is a weak Definition of Done.
Tune-down way of SAFe makes it easy to sell towards legacy management. SAFe has built-in program management process and roles. Build-up way of LeSS asks “How to simplify the organization, and be agile?”.
Question #4: Okay, now the program is working according to SAFe/LeSS framework. How does the model scale when you add two more teams?
SAFe’s program level guidelines make this rather easy. Assuming the teams are feature teams then it’s rather easy to add new teams – just invite them to the common Release Train Planning event and share the prioritized increment backlog across the teams. SAFe can scale up to multiple release trains and multiple value streams, but at that extreme we would be then talking about thousands of developers, and that’s a bit scary anyway.
LeSS scales easily – you just add two more teams to the structure. Avoid creating component-based teams such as front-end, integration, or operation teams. If the number of teams exceeds eight, use the LeSS Huge framework. It’s based on the same principles and rules, but adds a few extra practices.
After reaching Lean Agile organization scaling is easy.
Both models require the Enterprise to change. Agile is about mind-set, not about roles or processes.
It seems that the path for agile scaling is rather similar, no matter what framework you are using. After the first hour of shooting, there is yet no clear winner.
Thanks for reading! Please, throw in any additional questions!
We will tackle those in the Shootout Sequel, where we will finally find out, which one of these two frameworks is the best.