Posted on

Part III – Organizational Transformation – Challenges and Strategies

Transformation Priorities  

We talked in Part II of this blog series about elements of agile transformation with a focus on two main initiatives: process and technical agility. We laid out some ideas and details to consider and to understand approaches to scaling. But one question is still not answered – in what order of priority do you tackle these initiatives? Does it even matter?  

There are a lot of changes in the “trenches”, at the engineering level with adoption of technical practices, changing how we build, test and deploy the code. And at the time these changes are happening, the organization can be changing to support release trains, engineers are moved around, and new teams are formed. By doing so, release trains may start breaking up existing organizational entities managed by directors and executives.

Let’s look into some scenarios, link them to organizational culture types and discuss outcomes that we may expect, at least based on our humble experiences. 

Process Changes as Higher Priority

In this scenario, priority is given to process transformation over technical transformation to align engineers around scrum teams and form release trains. This obviously requires lot of preparation at the leadership and executive level as existing organizational entities and silos are broken. All this is done while teams and leadership still have a commitment to the business and customers. For example, we can’t stop on these promises while reorganizing in an effort of creating a better delivery model. This can be challenging and creates a lot of stress and potential burnout. Developers are under the gun to deliver, fix issues, deal with escalations, and yet the world around them is changing.  

At the leadership level, this can start creating “antibodies” and “non-believers”. Reasons for this could range from just not understanding how breaking established organizational models will create better value, to extreme situations where it may even be political. To understand the latter, we need to reference our Part I blog where we discussed Westrum’s organizational culture model where the first two models mentioned are power-oriented (pathological) and rule-oriented (bureaucratic).

Both models are basically based on a siloed mentality with often unhealthy relationships where either information is withheld, collaboration is low, or scapegoating is present. With a rule-oriented organization, each organization protects its own “turf”, where they have their own rules and any attempt for cooperation means others need to adopt those rules which may create friction. 

Leaders in these types of cultural environments often push back on changes since their “turf” is changing, and the rules and processes they created are not valid anymore. In some cases, some leaders may see breaking up existing teams as a loss of power and control. With this, they become demotivated or even they challenge process changes as they don’t see evidence of immediate positive impact on product quality or time-to-market. 

So executing big organizational changes first, changes which may not provide immediate tangible and measurable results, have some risks and may result with “antibodies” within leadership and teams themselves that may slow or sabotage the transformation. Thus, it becomes important to have the right strategy defined to turn these into forerunners of change.

In our experience we also see the HiPPO [1] effect emerging in these organizational cultures with top engineering leaders with authorities giving up on transformation efforts and falling back to old practices for doing business, which in return puts the company behind against the competition and the market pace. 

Technical Agility as Higher Priority 

In this scenario priority is given to technical transformation over big processes and organizational transformation forming release trains and values teams. Just to make it clear – we are not stating that process transformation is not done, but just that effort and energy is first put into work on “low hanging fruit” – fixing code quality and improving delivery capabilities. In this approach, the organization recognizes the existing technical challenges, long release cycle, or inadequate testing and agree on prioritizing these challenges first before doing bigger organizational changes. In this approach agile and technical coaches and DevOps engineers are typically hired to drive most of technical transformation:

  • Agile coaches will start helping teams embrace Scrum, help them understand how to break problems into smaller increments and how to deal with flow and apply lean principles. They will help limit work in progress (WiP) to allow a percentage of the capacity to address technical debt such as manual testing, complex branching, or slow, infrequent builds, to name some.
  • Technical coaches will pair with developers and help them start refactoring code and teach them how to embrace proper unit testing and advanced methods such as TDD and BDD frameworks for example. They will examine their branching strategies and teach how to move from long lived isolated branches to a more trunk-based model with CI and daily merges. 
  • DevOps engineers will start helping with a tools ecosystem, help automate build and release processes, and help with environments setup automation to enable continuous code integrations and deployments.

Above are typical examples of technical transformations which, when combined and well executed, will start demonstrating evidence of continuous deployment capabilities improvement.

In order to see the evidence of progress, monitor the changes and make sure to address any negative trends of teams falling back to old practices, a set of engineering metrics unified across teams must be established. These metrics mainly provide answers to two key questions:

  • What does my code quality look like?  The expectation is to see positive trends with regards to defect reduction, security issue reduction, increased unit test code coverage, and increase overall test automation.
  • How well are my teams transforming? This means teams embrace fast CI/CD with a reduction in build-cycle-time and increased number of builds, a positive trend with regards to pass/failed builds, story-cycle-time shows positive trends and so on. 

It becomes almost obvious that with proper adoption of technical practices along with coaching and servant leadership support to ensure teams have what they need, then positive results of the transformation become very measurable quickly. Ideally, key metrics are automated and updated on a daily basis (ideally by each integration build run) and displayed and visible within team spaces.  


We looked into two prioritization cases, one where priority is given to organizational changes over adopting technical practices and fixing teams first. There is a risk with this approach, if an organization’s culture is power or rule oriented. While organizational changes are important to set the organization for success long term, they are quite disruptive for leaders and engineers and there is no immediate return on investment – by changing the organization we don’t improve code quality or time-to-market immediately. In this scenario, it is easy to see that people in doubt will become vocal and undermine the efforts and in extreme cases, division can be so deep that transformation efforts may fail. 

However, when we put priority on technical transformation first, and staggering organizational changes until we start seeing benefits of technical practices and DevOps we put in place, we are minimizing risks of disagreement and friction. Those potential non-believers or antibodies will not have arguments if we start seeing better code quality, more automation, less security issues, reduction in delivery cycle time and happy teams. Once we start seeing an indication of these key benefits (metrics are so important here), we can start executing organizational changes to set scrum teams around common goals, create release trains and focus on delivering value faster to customers. We focused these recommendations for organizations that may have experienced symptoms of those two Westrum’s cultural models, i.e., power or rule oriented. However, if an organization is supporting a generative culture with good information flow, high collaboration, and with servant leaders focused on eliminating impediments for teams, then transformation can be much easier to execute. These organizations see transformation as a business change and not just an engineering experiment.  

[1] Highest Paid Person’s Opinion

Posted on

Part II – Organizational Transformation – Challenges and Strategies

Transformation Strategy Elements and Their Priorities  

In the previous blog (Part I) we discussed organizational transformation and organizational culture as a factor that is often overlooked, yet is a factor that can greatly impact the outcome and  success of the agile transformation. But before we analyze that impact, lets briefly discuss key elements of a successful agile transformation.

Elements of Agile Transformation

There are articles and books written on this topic discussing process, business agility, change management, and technical agility. But for this blog, lets focus on a few that really matter.

Process Transformation  

  • Organizing teams for continuous delivery and self-efficiency. The most popular framework to achieve this is Scrum.  In Scrum teams are organized around the ability to deliver features quickly and desired level of quality. Adoption starts with reorganizing teams into smaller groups (versus a big monolithic development organization) with right skillset mix to achieve the above mentioned  objectives – speed and quality. Changing and reorganizing teams is a disruptive process (“Change is good…you go first”),  and there will be developers that may not embrace it at first. While talking  to a  bigger group of engineers about organizing into small teams, and the notion of shared responsibilities and collaboration, we experienced more than once, push back from at the back of the room with comments such as “coders like to work alone…”as they express their disinterest. But these instances are really outliers and for most part, engineers do tend to see benefits of scrum and with proper coaching, they start embracing it.

For small companies with a simple organizational structure, the transition to Scrum can be fairly straight forward. People know each other, often they are all collocated and they are used to dealing with frequent changes, comfortable with direct communication and may already have a “just do it” attitude. 

On the other hand, for larger companies with a complex structure and equally complex processes, these changes are much more challenging and may take time to fully transform across all departments and geographical locations. But even in this case, engineers can often see the “good” in the change. They embrace it, over time they improve it and ultimately become better at it. 

  • Beside teams of developers organizing in scrum teams using Bezos’ two pizza size rule[1], next process related change that is important to highlight here, is the ability to scale Agile in big organizations. This means organizing multiple scrum teams together to continuously deliver meaningful value to customers. Hence, the concept of a Release Train may be introduced to align scrum teams and other functions (development, DevOps, test, product and program management, service, etc.) in logical grouping with shared business and technology objectives. Release train may have up to 150 developers in large organization, with multiple release trains running concurrently.  Members of a cross-functional release train should seamlessly work together without traditional organizational boundaries or impediments (or “silos”) to complete all activities necessary to deliver value continuously, fast and with quality and security built-in. Further, the set of release trains’ activities can be organized around value streams where value is a content the train is delivering.  The value stream is also a reflection on how business is aligning a key product or portfolio strategic themes delivered  to customers over period of time. By definition, a value stream may include activities across multiple release trains. 

It is obvious that scaling Agile with release trains, value streams and associated changes, may require modifications of the existing organizational models especially if they aligned around technology, architectural components or existing product components. These organizations may have developers, test engineers and other functions working on these components that alone may not be releasable customer values. This is important to remember as we will later discuss organization culture models relationship with organizational changes introduced by implementing release trains. This may require reorganizing teams around the value they would deliver to customers.

[1] According to Bezos, ideal size of the team is the one that can be fed with two large pizzas 

Technical Transformation or Technical Agility 

Beside organizing teams and aligning organization around value streams where value is delivered by release trains, another element of successful transformation is technical transformation or adoption of advanced engineering practices. 

As we said earlier, the ultimate goal is to deliver valuable product increments to customers continuously (in frequent deployments), with quality and security built in. To do this, teams need to change the way they produce code. In waterfall-like models, developers will write code, pass it to test teams who will open defects for any bug they found during testing. These defects will go back to developers to fix them. When code is ready, software executables are built and provided to operation teams to deploy to a sandbox environment to do more integration testing . This process keeps going  until predefined release readiness goals are reached and software is finally ready for customer deployments by operation teams. All this takes time, promotes silos and isolates developers from software delivery process,  and ultimately from accountability for product quality.  Because it takes time and deadlines are tight, this often causes burnouts and stress conditions for people involved. 

Hence it is important that along with agile transformation, teams embrace engineering practices that sustain agile and ensures quality issues are fixed fast, when they actually happen. . This reduces turnaround time for delivering value to customers and makes developers accountable for a code quality. Some of most important technical practices teams need to learn are:

  • Automated Unit Testing – Teams should adopt xUnit test framework within which developers create unit tests pretty much for each line of code they write. One of the most popular models for embracing unit testing with full code coverage is adoption of Test-Driven Development (TDD). In this model, unit tests are written prior the code that is tested. Another good extension to TDD is Behavior Driven Development (BDD) which allows automation of acceptance tests that can be considered a contract between developers, product owner and business stakeholders. Adoption of these test frameworks, requires often mindset change,  but with proper technical coaching engineers quickly see the benefits and adopt.  
  • Continuous Integration (CI) – Teams need to have the ability to run fast CI builds that are triggered each time they commit their code which, if done properly, means running CI builds many times a day. Developers are encouraged to run their unit tests during these builds along with performing other analyses to discover code anomalies and security vulnerabilities. The feedback CI provides is critical. It is important developers act and fix these issues immediately, not wait for downstream testers to discover and pass information about code  issues in the form of a documented bug or defect. 
  • Automated Continuous Deployment (CD) – – While each developer is running CI builds on their code and cleaning it up as they get unit test feedback, it is important that code is continuously built and tested for integration between key components of the system they are building. To do that, a means of automating environment setup and code deployment are required. These days this is often automated by adopting infrastructure as a code paired with use of cloud platform and its related services.
  • Proper branching strategy –e.g.  Trunk based development. Developers tend to keep their code isolated from main or release branch in private or feature branches for a long time.  These practices prevent code integration and timely discovery of integration issues. Hence in trunk-based development developers are encouraged to integrate their code branches into the main daily (and after passing their unit tests) 
  • Security analysis – There are many tools available today that help with threat modeling  and finding timely security vulnerabilities in a developer code or open source they use. But, remember these tools must be properly integrated into CI/CD pipeline and developers are must look for their feedback and be accountable to fix issues. 

To make this technical transformation happen, two main things need to be provided: coaching and a proper engineering tools ecosystem that supports developers by seamlessly automating most of the process overhead.

There are other elements of successful transformation and other technical practices, but what is described in this blog is a good starting point helping us understand transformation priorities and risks discussed in Part III blog. 

Posted on

Project Portfolio: Planning Under Pressure

As market dynamics increase, the selection of projects, which are important to align enterprise operations and strategy, face challenges from cost-benefit related conception, to criteria for project completion. Nearly all organizations have more project work to do than people and money to do the work. Trying to do too much causes all projects to suffer from delays, cost overruns, or poor quality.

Focus On Portfolio Performance

Common business pressures that serve as a catalyst to evolve a focus on portfolio performance can include:

  • Smaller or greater demand from your customers
  • Lack of available skilled resources needed for projects
  • Increasing risk exposure across project portfolios

In any of these cases, you may have to adjust your priorities for the next few months. Or, you may have to adjust your spend, where to spend more, where to spend less. Also, you may have to rethink your business strategy for the long term.That means adjusting your project portfolios. Some projects must be stopped, some paused, some adapted, some accelerated and some newly created. These are difficult decisions, which must be made with little certainty about the future, and, hence, potentially with more risk. The decision-making process can generate positive results while leading a company, or make a significant damage to an organization.

Project portfolio managers need a well-facilitated and structured approach to assess, reprioritize and effectively deliver the project portfolio that is needed in a tumultuous world. A process of analysis and judgment must occur in business on a day-to-day basis, and is an important component of managerial work on various hierarchical levels in the corporate environment.

Planning Under Pressure

Being compelled to select the “right project(s) next” is a most important opportunity, especially during crisis circumstances, that can:

  • Reduce the number of low-value projects, which will reduce the overhead of keeping track of them all and, even more importantly, increase the availability of resources for other high-value projects.
  • Better align project investments with your organization’s business strategies, e.g., growing overall revenue, and with your organization’s cultural values. Facilitated discussion among executives about better alignment will entail broader agreement on overall business objectives and strategies.
  • Improve balance and diversification of projects along key dimensions, which will entail broader agreement on such dimensions (such as, perhaps, revenue growth, product innovation, maintenance and compliance)

Follow A Two-Pronged Approach

In our experience at Group Atlantic, our clients enjoy best success by taking a two-pronged approach that emphasizes:

Top-down development of mindset, governance, and process—but not (software) tools—alongside education of relevant stakeholders, so that gradually a common enterprise-wide process for project approval, diversification and tracking is practiced. Purposeful organization development emphasized several important aspects:

  • Shared vision and mindset: (e.g., breaking down silos, alignment with strategies and business goals) rooted in our Business Value Points matrix approach.
  • Governance: where to house portfolio management responsibility and accountability in the organization, who can (not) make decisions about what, and related issues.
  • Process: working with top leadership (e.g., to formulate the “burning platform”, develop sponsorship and communications, develop policies and model desired behaviors) and working with other executives and managers (e.g., to communicate the change(s), cascade the change down the management hierarchy, identify and manage champions and resisters, develop training, and change incentives and performance appraisals).

Quarterly exposure of executives to strategic projects, their dependencies, and their value and impact on overall strategy and results, so that executives start to appreciate interdependencies, strategic (non-) alignment and (non-) effects on overall results. This second prong follows, at least informally, a rolling 12-month plan (perhaps with a multi-year look ahead), updated every three to six months, to better exercise strategic agility.

Achieve Lasting Value

It’s certainly not trivial to reprioritize a wide ranging project portfolio, with many projects already in process and multiple influential stakeholders seemingly inseparably connected to project. The pressures of time and resource constraints, along with uncertainty about the future, can add to executive stress. Reacting chaotically could lead to a disorganized response and an inefficient use of finite resources.

A systematic project portfolio management approach, expertly facilitated, is about getting the best outcomes despite planning under extraordinary pressure. Decision-making meetings are more collaborative, effective and efficient. Better ideas come with facilitated attention to proven portfolio principles, process and reliable techniques.

With a structured and well-facilitated approach, one can move quickly and carefully to build/rebuild and manage the project portfolio your company requires to face challenges today—while also laying the critical next steps for prosperity tomorrow.

Posted on

Agile versus Waterfall, Business Analysis and Project Management …?

Our clients regularly ask us about Agile versus Waterfall, Agile versus Business Analysis, or Agile versus Project Management.  Our answers come from our perspective that system development and the management of it have a different life cycle, each with several variations, that are combined into a specific approach, e.g., for a particular project.

Agile versus Waterfall

Our view is that whenever systems are developed, or parts of systems, the System Development Life Cycle (SDLC) is relevant.  Basically, the SDLC lays out the various activities that result in a system, e.g., Analysis, Design, Code, Test.  Agile delivers (small) pieces of a system frequently (say, once every two weeks), and thus traverses various SDLC activities repeatedly, i.e., in each Sprint.  Waterfall delivers the system in one go (“big bang”), and traverses SDLC activities one time through, one after the other. 

Our version of the SDLC is depicted below:

In our perspective, we don’t see Agile versus Waterfall.  Agile and Waterfall are similar in that they traverse the same SDLC activities.  In our view, Agile and Waterfall differ in their frequency of delivery, and thus how often they traverse the SDLC.  In certain situations, Waterfall may be more relevant; in others, Agile.

Agile versus Business Analysis

In Agile, say Scrum, the attention is focused on the Sprint.  The functionality that is to be delivered is typically brought into the Sprint as stories by way of Sprint Planning or Backlog Grooming.  Sprint Planning and Backlog Grooming start with stories that are (almost) ready to be worked on by the development team.  Stories are, in effect, specifications for the functionality that is to be developed.  The specifications should be based on Requirements.  Requirements and specifications should be developed using Business Analysis.

In our perspective, we don’t see Agile versus Business Analysis.  Agile is one approach to system development, which requires Business Analysis to take into account Requirements and to come up with good specifications for the functionality to be developed.  However, Business Analysis takes place before the Sprint.  Consequently, Business Analysis is generally not part of the Sprint, and Business Analysts are generally not part of the Sprint team.  But, they are needed.  So, in our perspective, it is Agile and Business Analysis.

Agile versus Project Management

With Agile, it is often not clear at the outset which exact functionalities will be delivered eventually, because requirements may shift over time, as users get more experience with the system.  Therefore, it is not clear how long such functionalities would take to deliver.  Consequently, it is argued that Project Management, with its focus on Scope, Schedule and Budget, is not relevant for Agile, i.e., Agile versus Project Management.

But, system development, when done with Agile or otherwise, still needs to be managed.  Decisions about what kinds of functionalities should be delivered, and when, must be made, along with how many people to have on the team(s), how much money to allocate, and what risks should (not) be taken.  Our view is depicted below:

In Agile environments, such decisions are made by the development team and the Product Manager (in Sprint Planning and Backlog Grooming). Scrum is often the approach that is used to manage each Sprint.  Sprint Planning and Backlog Grooming generally implements decisions, types of systems needed or business strategy, that are made by executives above the development team and Product Manager. So, in our perspective, it is Agile and Project Management.

Posted on

Seven Traits Good Project Managers Share: Do You Have Them?


Who’s the best project manager you ever worked with? This question, posed in a Q&A discussion after one of my recent corporate workshops, stimulated some fond reminiscing about all of the project managers I’ve respected through the years and what made them so good. It also probed into some comparison about what they all had in common. If you take nothing else from this post, do that … take some quiet time perhaps while sipping that second cup of morning rocket fuel, and develop a list of the project managers you’ve respected through the years. Then think about what traits they all had in common.

I’ve had the good fortune for decades to work with project managers in successful Fortune 50 companies and rapid-growth startups, ranging across many industries, including aerospace, telecommunications, finance, insurance, retail, information services, and manufacturing. From these experiences, the best project managers I’ve worked with seem to have the following traits:

They think for themselves. They have the self-confidence to make their own decisions. This isn’t to say they don’t coordinate with others when needed, or disregard other people and don’t heed advice … quite the contrary. They will make their own decision, factoring in their skills, their team’s skills and their assessment of the situation. For example, during a project problem-solving gathering where there may be some questionable risk factors, they’ll listen, engage, and attempt to facilitate to get a full range of ideas. And in the end, while factoring in what the group is doing, they’ll make their own decision.

They understand what the business domains value about the projects they manage. This knowledge helps them make good decisions, and when unusual things happen, they have an extra bit of insight that helps them out of a jam, whether it’s a difficult project launch, an unusual stakeholder demand, or a perceived mid-project crisis. Somehow their projects seem to deliver value more reliably, and fellow project managers around the “neighborhood” will peek over to see what/how they’re planning and tracking.

They take quality risks. Project success demands risk management. It’s about good decision making, a hallmark of good project management. The best project managers I’ve worked with have surprised me on both ends of the risk spectrum, sometimes with a very conservative decision, and other times with a decision that seemed to involve more risk than I would have accepted. An in-depth conversation with them usually revealed a deeper level of analysis than I had undertaken, and I usually walked away with a few more strategies to put in my risk management toolbox.

They welcome questions about their decision-making process. Of course, this can be influenced by how you question their decision. If you approach them in an accusatory or judgmental way, you may not find them receptive. However, if your intent is to understand the analysis and all they were thinking about, you’re likely to find an enjoyable and enlightening discussion; one in which they probe you back for your assessment of the situation, and what you would have done and why.

They are brutally honest about evaluating performance and maintain a focus on improvement. When you work with them, you’ll hear them acknowledge missteps or errors. In project post-mortems or sprint retrospectives, they don’t seem to brag much; they seem most interested in analyzing their mistakes and seeking knowledge or techniques that might help them. They didn’t become one of the best project managers you know by glossing over their weaknesses.

They enjoy gaining knowledge about project management. It’s been said, “Do what you love and you’ll never work a day in your life.” The best project managers I’ve worked with delighted in quenching their thirst for project management knowledge. Maybe it stems from their love of getting valued things done, so it’s not work for them to read up on the latest developments, or spend an evening after a long, difficult day in the office by attending a presentation by a thought leader at a professional gathering. They routinely stay abreast of project risk taxonomies that accurately mirror the concerns of real-world project managers.

They’re calm under pressure. Perhaps it’s a culmination of all of the above, but the best project managers almost seem to have been waiting for the critical moments. They don’t panic; they aren’t shocked. They seem to go into a zone where they just matter-of-factly take care of business.

Are you on your own list of best project managers? Are you on anyone else’s list? What is needed for you to master the skills and thought patterns to get there? Embark on the rewarding path to becoming one of the best project managers you’ve ever worked with.