agile

Wanted: a New Set of Engineering Leadership Skills

June 30, 2019 by Greger Wedel

A while ago I did a series on how key roles in the engineering organisation changes as a result of introducing devops practices. I covered the software architect, the program manager (at that time I was at Cisco and some of the projects were huge), and the product owner, but left out the engineering manager and the product manager as other priorities called. In this post, I circle back to the key skills necessary for engineering leadership, independent of the role you have.

What makes good leadership is sometimes seen as magic. It is difficult to get it right. On the other hand, engineering leadership can sometimes seem like black magic! You typically don’t have the sales or the financial aspects, but you are supposed to lead people who are rumoured to be motivated by weird things regular people don’t even know what is, and technology development is so fast that it seems that last week’s new stuff is now old. And in software development, you are supposed to deliver a product that at best seems fuzzy, at a pre-defined time, and with a limited number of engineers where your most productive individual can deliver 10, 20, or even 30 times of the least productive individual.

One challenge is that you can bend pretty much everything: what is shipped, the quality of the features that are shipped, the quality of the code, and the technical debt you leave for later by cutting corners. And in addition you are supposed to be innovative and solve the customer’s problems in a “delightful” way. A good engineering leader understands the customers, the business, as well as how to solve the customers’ problem. Getting all this right is very challenging and why I love building things in code!

I did a quick review of various engineering leadership programs and found MIT’s Engineering Leadership Program to be one of the most explicit on what they believe engineering leadership is. They emphasise six core capabilities where five of them are common with general leadership: core personal values and character, relating to others, making sense of context, visioning, delivering on the vision, and technical knowledge and reasoning.

We now know that a key characteristic of high-performing teams is trust among its members, and humans are more capable of trusting others when they feel safe. Any change introduces uncertainty, which again can reduce the feeling of being safe. In an environment of developers used to code and solve problems in front of their screen, the introduction of devops can be a dramatic change. We know from the introduction of agile that tension can raise quickly. Devops is an even more dramatic change in how developers work. Thus, anything that can be done to increase the feeling of being safe is critical! Simon Sinek has done a lot of work on trust leadership and this quick introduction to his thoughts on creating a circle of safety is a good use of your time.

An interesting difference between Europe and the US is how management education in the US is seen as something separate from the professional degree (MBA or engineering leadership programs). In Europe, leadership is embedded in professional degree programs, and it is more often assumed that a manager has a professional education and then promoted based on merit to leadership positions. There are pros and cons with each model. In Europe, it is often a problem that the only career path is management and the best people in their area become managers. You risk loosing a great specialist and get a lousy manager. However, if the transition works out, you get a very efficient manager who knows what is important and can guide others in doing their best. Regardless of model, it is important to promote people to leadership positions who have a real passion for accomplishing great things through other people, not only doing things themselves!

Devops is an approach to software development that is only possible if your product is a service that you operate and control, typically from a public or private cloud. This is called Software as a Service (aka SaaS). One of the key characteristics of devops is that the team writing the code is also responsible for operating the service. This allows modification of code as an immediate response to issues, requests, improvement needs, learnings, and feature requests. Jonathan Rosenberg, CTO of Cisco Collaboration, wrote a very good post explaining what this really means.

However, what are the requirements of a good engineering leader when you develop Software as a Service? Let’s look at some of the relevant things that change with devops:

Classic project management becomes difficult as there is no project, just many small chunks of work being done in parallel
Realising customer needs and desired business outcomes become a more direct deliverable as the whole product development process is condensed into the devops process
The team’s responsibilities get much bigger, and the type of people and number of roles expands where QA, operations, security, and other functions need to be taken care of by an integrated team
It may make sense to organise product management, product marketing management, technical marketing engineers, as well as support into the same group
The architecture of what you build typically shift from one integrated piece of code into many smaller, loosely coupled components (called micro-services). This has an impact on how the teams are organised and how they work
The continuous deployment pipeline and your test infrastructure become critical assets
Reliability and uptime become important in areas where you earlier could be lax (like your build server)
The team becomes responsible for delivering on key business metrics

This list is by no means exhaustive, but offers a flavour of the type of changes a team experiences when introducing devops. There is one immediate thing that is obvious: the scope of the engineering leader’s work has grown tremendously, both in topic areas and type of people and deliverables. This calls for a very different type of engineering manager than the classic “first among peers” approach where the most senior developer also gets a manager responsibility.

In the new devops-centric engineering organisations, HR and senior leaders need a much more systematic approach to educating its engineering leaders and train, coach, and mentor people to reach a broad set of leadership skills, and who also thrive on the challenges of leading software organisations.

The Program Manager in the Agile/DevOps Organisation

March 24, 2016 by Greger Wedel

This is another post in my series on transitioning from waterfall to agile and devops processes. This post covers the program manager role, a rather unassuming role in some organisations, an important role in others, but nevertheless a role where the right person can potentially make a big impact. There are a few different types of program managers, so let me be clear on the type I will discuss here. Microsoft uses the title for product managers with a horizontal responsibility, i.e. functionality that should go into multiple products. Other organisations use the title for a role that is similar to a product manager tole. Typically, a program manager of this type has an independent responsibility for business results within a certain area. A very different program manager role is a project manager for a deliverable that crosses multiple independent products or teams. Often, a program manager of this type will work with multiple project managers, one for each product involved in the deliverable, but does not have an independent ownership of business results and thus becomes more like an advanced project manager. In Cisco, program managers are often of this last type (and clearly lacks the first type), and alas, some larger products may have their own program manager working alongside the project manager to manage and coordinate outside the product team.

I may cover the consequences for organisations not having the “program manager with business ownership” role in a later post, but here I will cover the “program manager as an advanced project manager” role.

Of the many roles in a development organisation, the program manager role may be the role that involves the most painful change in mindset and daily tasks when a large organisation moves to agile and devops. The traditional tools of a program manager is no longer of much use: defining deliverables, setting and tracking milestones, managing dependencies, measuring progress against the plan, reporting status and escalating issues to stakeholders… But why is that? The reason is that the traditional program management model and associated tools assume a planning horizon (e.g. ship within 6 months), a clear view of what is “inside” and “outside” of the boundaries of what is managed (e.g. we need to ship a and b and rely on c and d to deliver x and y for us to be successful), a desire and need for a pre-deterministic plan for what is “inside” (e.g. we are going to ship a,b,c, and d), and that any deviation from the plan, including “outside” changes, are bad and should trigger a corrective action or some kind of mitigation.

ALL of this is wrong for agile and devops! For one, changing plans is desired, that is called learning. Also, the boundaries of what is “inside” and “outside” may be shifting as the teams learns and gets feedback, and reacting to change is something that each member of the team should do immediately. Planning should be done iteratively based on learnings and changing requirements, and what is actually shipped is not fixed as teams commit to a prioritised set of tasks (backlog), not a fixed set of deliverables.

Alright, so the program manager role is dead, is that what you say?! Yes, the OLD program manager role is dead, really dead. However, the reasons for why the program manager was needed are still there: ensure that multiple teams and projects with independent execution paths coordinate priorities and execute efficiently so that real cross-product value can be delivered to the customers with the right quality!

Can program managers re-invent themselves? I really don’t know, some of them may be stuck in old ways of doing things. There are of course many flavours of agile that companies may choose to adopt, like SAFe, where you get clear definitions (http://www.scaledagileframework.com/rte/) of what a program manager is supposed to do. The problem I have with such frameworks and role definitions is that activities, tasks, and goals are often defined in terms of artefacts and ownership of activities defined by the framework. Thus, the role quickly becomes statically defined, which is contrary to the whole point of agile: constant improvements reacting to learnings. By the way, as a rant on the side: that is probably also the biggest problem with frameworks like SAFe in general. They capture some important learnings and concepts, but become stale and not a framework for change.

I really like to get to the core of what we are doing and what we are trying to achieve. E.g. “Manage risks and dependencies” is an abstract statement, and it involves too many implicit definitions of what a risk is, how you manage it etc. But looking at the problems I have seen in agile and devops, a typical program manager personality can contribute buckets to some of them (but constantly change HOW to contribute to them as the organisation evolves):

1. What do we want to deliver and when? In large programs, multiple product managers need to agree to a set of ordered business priorities. Without clear and shared priorities across the products that are to be delivered together, we get absolutely nowhere. This is the role of the product managers (or rather ironically the role of the other type of program manager in organisations that have those). As covered in the post on the backlog, I believe in a true and single owner of a backlog (delivering on the priorities), and the backlog being defined as the task list a development team uses in their iterations. When a team of product managers come together to define shared business priorities, the team of product owners need to come together to tie their backlogs together (as described in my backlog post). A group of peers with priorities outside the group has always problems with closing decisions because conflicting product-specific priorities will interfere. A program-level product manager (aka solution product manager aka that other type of program manager.. puh!) can be used to drive the program/solution priorities and resolve the conflicts between the program-level and product-level priorities. Likewise, a program-level product owner can work with the product-level product owners to tie the backlog items together so that co-development can be done (where co-development means actual coding done in the same iteration with developers talking to each other). This program product owner role can be filled by a program manager (assuming some technical knowledge).

Solution Product Manager ——— Solution Product Owner ——— Solution Program Manager

|| || ||

Product Managers Product Owners Project Managers

The flow is thus: define and prioritise shared business priorities —> define interlinked product-level backlog items to deliver on business priorities —> plan co-development where needed. I tend to talk about “backlog items that are flagged for co-development”, which basically means that there will be another (named) developer in another team (or more) who should be involved when writing and testing the code for that backlog item.

<Whining rant> When writing this, I really feel the urge to go back to a startup environment and the simplicity of making decisions and pushing things out the door… The less people who don’t code, the higher feature velocity you get. But then again, you typically have just one or a few products and limited coordinations needs… </Whining rant>

Another important thing in devops is metrics and A/B testing. This input should be continuously brought into the business priority process. Often there is a breakdown in communication between engineering (doing metrics and A/B testing) and product management (setting the priorities). I have yet to see program managers really making a difference here, strong architects and engineering leads tend to basically take ownership of parts of product/service improvement, but I believe this is an area of real value creation where a good program manager can make a difference.

Another important aspect of program-level work is to set the right targets and make sure engineers can focus on getting things done. It is important to go to the right level of detail on the program-level of what a specific program backlog item really means. Getting to the right level of detail on wireframes, prototypes, and requirements through demos, transfer of knowledge sessions, and white-boarding is important to make sure that the engineers from all of the teams involved in co-development have a shared understanding of what needs to be done. If there is one person responsible for driving this on behalf of the product owners, things seem to move faster.

Of course, another important part of this phase is to get the architecture right, engaging the senior engineers in each of the teams and preferably with a senior architect with program-level knowledge and ownership to lead the process. In Cisco, there is a separate technical leadership career path where director-level technical leaders (principal engineers) are expected to define and supervise architecture in larger programs and also across programs and business units (I’m btw one of those).

2. How do we tie together iterations to do co-development? Once the priorities have been agreed to on the program level, the engineering managers and product owners need to coordinate and identify when and how to do any needed co-development. This will include backlog grooming, developers planning an iteration together, sharing builds, and coding together possibly on a day to day basis. Two and two teams can manage this nicely on their own, but if three or more product owners and engineering groups need to coordinate, there is often the need for a facilitator. Again, this is more of a solution-level product owner type of role, not a program manager, but a technical program manager would fit nicely in this role.

3. How do we bring together the products, validate that iterations delivered planned outcomes, and qualify the process towards release/deployment? Once an iteration has been done, there is a need to bring builds of each of the products (or services) together to do testing and validation of the deliverable on a solution-level. In a true devops environment with continuous deployment, you will get this validation quickly, but if you deliver products and not devops services, you will need some solution-level live test environment. Solution-level testing needs to be done (again, preferably done as part of the iteration…), and if everything is ok, the builds can be deployed to a wider audience, either internally or to early trial customers. This is a critical stage as solution-level bugs will show up. There is a need for a strong person managing the maturity of features delivered and determining whether to allow the features to go beyond the initial solution test bed. In a devops approach, you will have developed features with #debug flags and feature-toggles, and features can be turned off if they are deemed not mature enough for deployment to a wider audience. The program manager can be an excellent watchdog in making sure that the right quality is achieved before releasing features to a wider audience.

4. Once a development cycle reaches an end and we want to ship, how to get things out the door? We want engineering to have a rhythm, a two-week pace that will give us some small, new improvements and features for every iteration. Ideally, engineering will not miss a beat when the products are released. However, more likely there will be a need for one or two hardening iterations at the end of a development cycle to clean up bugs, improve stability, and fix remaining issues. Once this has been done, all the code repositories should get a release branch, and the bulk of the team should pick up new feature development for the next release, while some time should be allocated to fixing bugs on the release branches and merging back to trunk. Dependent on the products/services, this final step before releasing products to customers can be long or short, but preferably it should be as short as possible. Typically, tasks will be final stress testing, solution-level manual testing, documentation finalisation, knowledge transfers to customer service people and sales engineers, release notes, bug scrubbing, as well as other steps to ship the software. This whole process play more to the traditional strengths of a program manager who is an obvious candidate to own this step of the process.

As you can see, with references to artefacts like backlog and list of business outcomes and to various roles, I get dangerously close to defining a framework of my own 🙂 The difference is that I here describe a(n ideal?!) system of people and deliverables that MAY work, but that must be adapted to people’s experiences, preferences, and beliefs through an agile process where people bounce off each other and change together. If not, the deficiencies inherently found in any human activity will settle and some important things will continue to be dropped, people will have overlapping responsibilities, and teams will work in slightly conflicting directions without the continuous improvement that agile promises.

But in sum, this post is an argument against the opinion that agile and devops mean that you don’t have to do any planning, documentation, or process management. On the contrary, some of your planning and process management need to be even more diligent than in traditional waterfall. So, don’t sack your program managers before you see how they can adapt…!

Using Pivotal Assumptions to Increase Velocity

August 29, 2015 by Greger Wedel

Pivotal assumption – “An assumption on business case, priority, minimum viable offer, or requirement that if false will fundamentally change designs, deliverables, or timelines.”

In my post on how organisational factors increase the bad impact of architectural debt, I referred to how the lack of clear business objectives and priorities slow you down and prevent important architectural decisions from being made. The result is that you need to plan along two or more paths in parallel, which obviously slows you down. Sometimes this double work is needed while you are waiting for a decision, and if all outcomes are likely to happen. However, very often one outcome is more likely than the others, it is just difficult to get consensus or a decision has a big impact on something else, so people want to avoid a rash decision.

In these cases, you will get dramatically increased velocity if you can make an assumption about what the decision will be. Teams will get more focus, people will stop doing double work, some things can get lower priority, other things float up to the top. I call this a “pivotal assumption” because a lot hinges on such an assumption, and if you make the wrong assumption, you have lost some time (though often less than you think, because executing on two things in parallel is very inefficient). But what makes a pivotal assumption different from the actual decision?

First of all, you need to make the decision and options explicit and clearly defined, and get people’s acceptance that this is a decision that needs to be made, but that it may take time. You also need to identify the things that do not hinge on the assumption by explicitly stating that “x, y, and z are not impacted by this decision, so we will plan these separately.” You want to do it this way as this will explicitly decouple x,y, and z from your pending decision and will get rid of uncertainty: is x impacted by the decision??

Then, you need somebody in a position to postulate the pivotal assumption. Let’s say you are making a new product for the 10-100 employee segment, and product management is not sure whether import of users from ActiveDirectory is needed in the first version of the product. A senior architect, engineering manager, or senior product owner needs to postulate that “we should execute from here on based on the assumption that ActiveDirectory import will not be needed in this phase.” All discussions and work related to ActiveDirectory import should then be put on hold.

There is one final, crucial element in using pivotal assumption. You need to avoid that it actually becomes the decision by identifying the facts or evaluations that need to happen before a decision can be made and pro-actively follow up. Everybody will be acutely aware that the longer you execute based on the assumption, the more costly it will be to make a decision that is not the same as the assumption. This is an incentive to get a conclusion. Also, I recommend that you actively look for indications that the pivotal assumption may be wrong, and that when it becomes clear that the pivotal assumption was wrong, you swiftly change course and treat throw-away work as sunk cost.

If you can systematically identify areas where people have different assumptions when doing their work, you can make explicit pivotal assumptions to get temporary focus, and then quickly close the identified decisions. This will dramatically increase your velocity. You may think that you get a lot of throwaway work, but truth is that without pivotal assumptions, you get double work, which has the same cost, but in addition you get also the unnecessary code into your codebase, increasing complexity and cost of maintenance. The psychological effect of not having clarity also adds to the cost of executing on two tracks in parallel.

I call this method “hypothesis-driven development” as you continuously identify assumptions, you gather facts and try to falsify your hypothesis. The organisation can get pretty good at identifying good assumptions and quickly close them. Be warned though, unless you pro-actively gather facts to try to falsify your pivotal assumptions, you end up adopting the assumptions as your decisions.

The Importance of the Backlog and the Product Owner

August 6, 2015 by Greger Wedel

In a previous post, I wrote about the challenges and strains on roles and processes when a traditional waterfall (or even agile) organisation introduces devops. Most people focus on the tools needed and how you must establish a build pipeline and support for continuous deployment to production. However, the success of devops is in the practices of the people involved, not the tools themselves.

After writing the post, I realised that I have to write something about the backlog and the product owner. The backlog because without one single, common backlog, your velocity goes dramatically down, and the product owner, because this role might be the single most critical role in both agile and devops.

I see quite a few people who do not really understand the backlog. Very often, we see multiple flavours of backlogs for the same product or service. Let’s look at the variations.

The product manager’s backlog is a list of customer features. Typically, these are prioritised based on a number of factors, like the business case for a new feature, the number of customers (or size) screaming to get it, deals being blocked by the lack of it, critical bugs found by customers, and so on. Truth is, this is what makes the product sell and pays for your job, but it is not a backlog! It is a feature or business outcome wish list.

So, what do you do? Well, you can go through a formal process, get engineering to estimate the effort, and get yourself an approved or committed set of asks. But just making a cut-off somewhere, “the rest goes below the line”, does not make it into a backlog. The reason is that engineering has a bunch of things it needs to do as well. So, when estimating the effort, they will be conservative, because they know that module X needs to be refactored before this new feature can be added, or they have a database scale issue they need to fix. So, some organisations add these engineering asks to the list. Do you have a backlog now?

Nope, because there are a bunch of things the senior engineers and architects believe needs to be done now in order to deliver features and quality code in the future. These can be based on the strategic direction of the company, on-going technical initiatives, or just re-architecting parts of the application. But, these activities will not deliver features in the upcoming release or cycle. I see some teams hide work like this by excluding some senior engineers from the priority and resource discussions, thus effectively creating a stealth team. Unfortunately, this means that some of the most important engineering investments into the future success of the product is not visible to anybody outside the team.

Some teams “partner” with their product manager and agree to a “backlog” of features, with some engineering asks added in. Then, they go ahead and track their work items through a post-it board or a kanban system where you can deduce to some extent what a work item is delivering into, but not always. The “official backlog” of features may be kept in a planning system like Rally, with user stories written for each feature. However, the “hidden” engineering activities may be kept outside the planning system.

So, you got the product manager’s backlog, the engineers’ backlog, and the architect’s backlog. How do you manage this in a good way? In too many cases, they are kept separate, and a lack of transparency and limited understanding of what is going on create frustration and friction for all parties.

It is my view that the only true backlog is the list of work items that the engineers have in front of them. You get up, choose the next task from the wall, the whiteboard or the tracking system, and you get cranking (as a team!). That’s the product or service backlog. All other lists are just input to the backlog, and unless you manage this properly, there will be competition to get stuff onto the real backlog. This is where the product owner comes in. The product owner is the undisputed gatekeeper of the real backlog and makes decisions on what gets in and when. If the product owner is only managing the “official backlog” or the feature list, then you don’t have a real product owner, just a partial owner. Typically, a product owner comes from engineering, but I have seen good product owners with product management background as well. But how do you identify a product owner? The title doesn’t cut it, so for some time I have asked “who writes the user stories?” But after I encountered teams where the official user stories were only written for customer features, my question is now “who prioritises the backlog items for the each development iteration?” This question reveals the true product owner.

A note on the more pragmatic side: roles are often combined and real life is more complex and based on real people and real relationships and experience of what works and what doesn’t. The most successful teams to manage a backlog seem to have a small group of people who together covers the product owner, the engineering lead (or project manager), and the senior engineer/architect roles, either formally through a backlog grooming meeting or informally. This triad is essential in managing a high quality backlog that keeps the team’s velocity and quality. I might later cover how successful backlog triads work.

If you have multiple teams and products, you have multiple backlogs. If you have a large number of teams working on the same product, you can split the backlog into areas (as described by Craig Larman et al in the LeSS framework). However, if you have many products that are interconnected and that deliver into multiple solutions with other products, this does not work. Only a small part of the backlog is shared with another set of products. What often happens is the “interlock” thinking. Representatives of each of the roles in each product group come together once in a while to interlock their priorities. Then they go off and develop their part of the priority and do another interlock late in the development cycle. This always fails, sometimes spectacularly. What is needed is a shift in mindset from shared planning to shared development. Each team needs to have a subset of the backlog that is shared with other teams and then the team members actually work with their peers in the other teams as if they work on the same team for the duration of implementing those backlog items. Design workshops should be done together, iteration planning, testing, and so on. If iterations cannot be aligned, APIs and flows should be stubbed and tested (with some standby support from the development team) to ensure that the other team can work on their part.

The Changing Development Organisation: The Software Architect

July 20, 2015 by Greger Wedel

(intro to this post on devops)

It has been a busy few months. Since my last post I have transitioned to a new role as part of day to day development (see linkedin.com/in/greger for more details) in the Collaboration Infrastructure Technology Group (UC, telephony, telepresence, conferencing, etc) in Cisco. Earlier, as part of Office of the CTO, I influenced the medium to long-term technology and architectural strategy, but as I had limited involvement in the day to day operations, it was a challenge to develop architecture that bridged near-term goals with longer-term strategy. Now, I’m less involved in long-term technology strategy, but on a daily and weekly basis involved in designs, decisions, and priorities made as part of development. Quite refreshing and comes with a bunch of interesting challenges!

If you have followed my blog, you have probably understood that I see architecture as something tightly embedded in day to day development, but more than just the sum of tactical, short-term steps. Also, you have probably detected my desire to see product management team and architects partner and work on the same thing: identify the whats and hows of building great products and services. Agile has for a long time changed my organisation and the last year or so, devops processes have really started to impact how we work. We have hardware projects, traditional waterfall product releases, and cloud services. This means that in my technology group we are currently using various flavours of waterfall, agile, and devops processes in parallel. It puts a strain on coordination and especially challenges existing roles in the teams. This post is about some of these changes.

Classic product organisations used more or less waterfall processes, and many so-called agile development organisations are using agile terminology to execute on a mostly waterfall mindset. However, with an increased focus on devops processes, the combined product/service organisation is facing another set of challenges in combining everything from hardware products and their software loads through legacy, monolithic, hosted applications to devops microservices. Tying these together to deliver robust, scalable services that offer great user experiences is a challenge along many dimensions: culture, people, competence, programming languages, tools, project management, goal setting, measurements, management, and roles.

One particular challenge is that not only does what we do change, our roles have to change as well. This is easy in a small organisation, but in a big organisation, the expectations other people have to what you are supposed to do is very important to your ability to get things done. So, let’s say I’m used to architects writing specs, then I will likely continue to ask for specs. Other people may not think an architect should write specs anymore, and they will ask for other things and maybe ignore the specs. This creates frustration and tension.

I believe most people in the industry are starting to understand the fundamentals of how devops are changing the roles of the development team and the operations team, and that they basically need to become one integrated team (with some new roles and new definitions of existing roles). However, the role of the product manager is also changing in the process, as is the project manager’s role, the engineering director’s, as well as marketing, sales, support, and partners. They no longer have releases to plan around and need to change how they work. I may cover some of these other roles in later posts, but in this post I will concentrate on the architect’s role.

First of all, a few words on what an architect is. In my understanding, an architect is a developer, a member of the engineering organisation, with a special responsibility for understanding the short-term and long-term business and technical requirements and making sure that the right technical deliverable is delivered at the right time with the right quality. Sometimes this is to get it done and deliver something less ideal from a code point of view. Sometimes this is to tell the product owner that some labour-intensive refactoring needs to be done in order to deliver a feature. My personal view is that a good architect also truly understands the value of the product to the end users and customers, and that he or she is a partner to the product manager or owner in defining and evolving the product. An architect can be a senior member of a scrum team (in Cisco, these are called technical leaders), or a more dedicated role that covers multiple scrum teams (senior technical leaders or principal engineers). In larger organisations, system architects typically span multiple products or services to create functioning solutions. In my view, regardless of scope, to be effective, the architects should be embedded in the engineering organisation. Some architects lead development teams, others have a more standalone role. However, the most effective teams seem to always three roles covered when decisions are made: the product owner (representing the vision and the problems to be solved by the product), the architect (representing how to deliver with the technical integrity of the product in mind), and the development manager (representing the developers, and making the trade-off decisions).

The architect is thus a member of the product leadership team. And with agile and devops, this role becomes even more challenging with the need to engage in more areas. Here are the some of the main areas of challenges:

Software architecture and code structure: There are two big challenges I want to mention here. First of all, devops requires a modularisation into micro-services, and getting the right grouping of functionality and defining clean, scalable APIs are critical. Second, the whole thinking of how you develop a feature or a set of features need to change. Every time you commit code, you cannot break anything. This influences how you architect the feature, how you test it, and you need to think in terms of A/B testing, feature toggles, and metrics, metrics, metrics(!), and not in terms of feature branches and unit and integration testing.
Software development processes: An architect needs to engage in code repository management, branching strategy, build ande delivery pipeline, test automation, A/B testing, feature toggles, 360 reviews, and much, much more. The architect needs to police the process and make sure that scrum teams working on various micro-services have the same view on the process and don’t break the builds. Very few other people will have the code knowledge and competence required to identify where the issues are and address them. The architect becomes critical to making sure that the devops machinery keeps working.
Requirements and product management: A shift from waterfall to devops is a shift in power from product management to the engineering organisation. Where product management used to ask for features based on market knowledge and research, a high speed of introducing features, doing A/B testing, and measuring the impact and quality relegates all product managers (except those who are very technical) to focusing on the go to market aspects of the service, not the requirements. The architect’s role in this becomes critical as the architects are instrumental in defining what to measure, and what you measure, you improve (whether this power shift has to happen, is a separate topic…)
Project management: Traditional project (or program) management should totally disappear. The software development process, the build pipeline, the metrics, the scrum standups, the scrum of scrum meetings, kanban boards, and the definition and usage of the APIs across the services, together with the automated tests together define and drive the project. The traditional tools of a project manager, like Gantt charts, dependency tracking, weekly project status meetings, read-outs to executives, escalations, and decision meetings based on analysis, are of absolutely no use in a properly executed devops process (note that badly executed devops processes will give ample room for such old tools and processes…). The architect needs to engage in the overall execution of the devops project to ensure that there is a constant evolvement of proper architectural frameworks, guidelines, automation, gates, micro-service designs, API/protocol designs, and much more.
Architecture: Devops does not mean architecture work is not necessary. On the contrary, as the architecture is constantly and organically evolving, the architecture that emerges can either be a disaster or a robust construction. However, the “ivory tower” architect is history as the emerging architecture emerges both with and without a plan, and it can only be shaped by having constant touch with what is being developed. A spec or design document will be obsolete within a week.
Management: I see a lot of very competent, senior architects who are brilliant at designing a flow or a new protocol, but who are lacking in managerial skills. Running efficient meetings with action items, pro et contra evaluations, closing decisions, setting deadlines and targets, chasing deliverables, and driving consensus are just examples of typical managerial skills that becomes more important for an architect.

There is so much more to how devops is changing an architect’s work, as always, the devil is in the details, but these categories have been helpful for me in understanding some of the challenges in evolving architects towards “devops ready.” The shift is similar already with agile development processes, but becomes more visible with devops.

Do you believe there are other important things that impact the architect’s role in devops? I’m happy to hear from you!

My next post covers the importance of one shared backlog backlog with all the actual work items visible, as well as the product owner’s role. Not directly focused on devops only, but relevant to devops as a good backlog grooming process is essential to getting anywhere.