Abstract
This article focuses on the use of the ‘Architect’ role within Agile environments by taking into consideration the experience of the author, as well as objective opinions from other Software professionals who have found their own version of successful software architecture via different means in the agile environment. The consideration of using the ‘architect’ role within an agile team is discussed along with how the architect can ensure the software does not become fragmented as well as ensuring architectural governance and accountability.

Architecture for any software project is the glue and foundation that keeps the software together, keeps it stable, keeps it maintainable, and keeps it performing well, among other things. How you “get to the architecture” depends on many factors, including, the structure of the project, the methodology used, the people on the project, and other factors. This article is going to focus on architecture as it is used specifically within Agile environments.

In addition to my own background and insight having worked in Architecture in Agile (as well as waterfall and others), recently, I put out a few questions to the architecture and agile communities hoping to gain additional opinions from those working with Architecture in Agile environments and how architecture is used and influenced in these different cultures. The response and encouragement has been overwhelming. Because this article is part opinion and part research, I take into account the experiences and opinions of myself as well as other top professionals. My goal is to be as objective as possible while sharing the experiences and opinions of other professionals weather or not I have shared similar experiences, use different methodologies, or agree or disagree.

Using the waterfall methodology, many software projects try to nail down all of the requirements up front, and these include both functional and non-functional requirements. Architecture documents are also created to various levels of detail describing the architecture. Waterfall typically can’t account well for variations in business or technical requirements along the way, so trying to get it right the first time (never happens) is typically important for many organizations. So typically, lots of time is spent up front tying to nail this down as best as possible.

Agile teams handle architecture differently, and depending on the team, there may be an initial iteration (or two, or three, etc) to nail down the initial architecture. Some agile teams will try to at least nail the most significant decisions as related to architecture (see, Introducing Significant Architectural Change within the Agile Iterative Development Process) hopefully trying to mitigate future architectural changes while understanding the costs associated with it. Other Agile teams let their software grow organically, as many Agile proponents promote YAGNI (You ain’t gonna need it), or also verbosely explained as “let’s not write anything until we actually have a business or technical reason to do it – aka, let’s not over-architect). So, YAGNI is great for a lot of things, but it doesn’t go far enough to account for significant architectural decisions that need to be baked into the software without significant cost down the road. The “Last Responsible Moment” principal tries to address this as well, and it works great for some teams, but it’s up to teams to determine when the “Last Responsible Moment” for creating and implementing the architecture is, and that becomes very subjective with the prospect that if you wait too long, the more re-engineering work is required.

So, how are Agile teams doing Architecture out in the field? My experience tells me how I’ve done it, as well as what has worked in the past for me and my teams. How does everybody else do it? Do they do it like me, do they have a better way, do they do it worse? Are they successful? Knowing that “the team” makes all the difference and what works for one team won’t necessarily work for another team, I have compiled what I think are the best responses, along with my commentary, to the questions put out to the community.

Dani Mannes – Agile Modellers & Developers

Dani Mannes is the Founder and Chief Architect at ACTL Systems Ltd. His work focuses on the defence industry where he is as a consultant and trainer to helping this predominately waterfall industry adopt agile.

In Dani’s approach, he uses the terms “agile developers” and “agile modellers” to define agile team members which do either development or design. He runs into a typical problem that I have seen in many Agile environments, and as Dani puts it “The teams are supposed to refactor, but they often don’t do it because of time pressure. This leads ultimately to spaghetti code/architecture and the velocity will eventually drop dramatically.”

The modellers will use a modelling tool to sketch out and ensure architecture documentation is up to date. “So in each sprint you have an architecture description of the sprint scope. But the architecture should not only focus on the current sprint but also take into consideration stories that will most probably be tackled in the next 2 sprints”. Dani emphasizes that taking into consideration the future stories is essential, but these should not be modelled at this point since “taking into consideration means only to think about them but not actually find a solution for them”.

In Dani’s world, ”the team acts as the architect”, and he states that there is no need for the architect role. But, he does keep one person in the role of architect, or “architect champion” just to keep discussions short, and to monitor the need for architectural change during each sprint.

“Our experience has shown that when the team applies a model based design process during first days of each sprint where focus is set on the sprint scope and attention is given to the scope of the next 2-3 sprints, the team is capable of coming up with a good architecture that serves as guidance during implementing the sprint scope.”, says Dani, and “Since the team has come up together with the architecture, all members are aware of the modules”.

Lee Fox – Architecture as Part of The Team

Lee Fox is a Software and Cloud Architect, Agilist, and Innovator, and he ensures that the architect is always a contributor and a team player. In his experience with waterfall projects, the architect is isolated from the rest of the team and isn’t necessarily even part of it, “As part of the team, I preach that the architect MUST be a contributing member and with some degree of consistency even contribute to team deliverables.”, and “the architect needs to really enhance the idea of empowerment and encourage the team to make architectural decisions.” Lee Fox also values that the architect must have the teams trust and maintain the big picture vision. This is a recurring theme in many agile processes when it comes to working within an agile team.

Lee’s vision is that “Agile architects work both in the low level with the team as well as the high level with the business. They use their broad exposure with the business to help guide a team’s decisions in the right direction. “ He is fine with architects working on multiple teams, but cautions that the “the architect must contribute to each team he is a member of and keep up with the big picture”. What Lee has seen through his approach and coaching is an increase in both velocity and code quality.

The Need for Governance – Dan’s Thoughts

In Agile, teams are self organized where there is no one on the team who should have additional responsibilities than anyone else as everyone is working together to achieve the same goal. Work is picked up and worked on by any team member and the expertise that is created is shared amongst all team members. However, I believe, as well as other respected Software Professionals, such as, Simon Brown, author of Software Architecture for Developers (https://leanpub.com/software-architecture-for-developers), that you need someone responsible for the Big Picture of the Software, and that includes the architecture. This creates accountability and governance for the architecture and all non-functional requirements (NFRs).

There are multiple ways to approach this, but ultimately realizing that having that architect who is responsible for the big picture can help ensure that the architecture is continually in-line with the functional and non-functional requirements. The architect will have increased access to both the technical side and the business side to ensure that the team(s) are continually aligning to not only the business/functional requirements, but the architecture is in alignment with both short and long term functional and non functional requirements, and that the existing architecture is followed, revised, and re-worked as necessary.

Ok, so I know some agile purists out there are thinking “Long term requirements are very subjective. Until a user story gets chosen by a ‘Product Manager’ and moves from the backlog to being actively worked on during a sprint, it’s not really a requirement yet”. Ok fine. I get that, and I understand the advantages here which is makes agile a process which helps you to change direction or add new to the project features midway through a development phase. User stories are (should be) always functional requirements though. When considering the architecture, we need to understand what is in the backlog or the general type of functional items that are in the backlog which helps the architect to create the technical vision. The technical vision can change as the project progresses, but ultimately understanding the grand vision will help ensure an architecture that takes into account current requirements and ensure it meets future product functionality with minimal re-work.

A drawback of Agile teams without architectural governance is that the system tends to fragment or suffers from too much rework and often non-functional requirements (such as performance, scalability, and others as related to architecture) get tossed out the window. Imagine a team has estimated a total of 20 points for the upcoming sprint. They have to consider, how can they get it done? Among these considerations is what is needed now, and unfortunately what is needed now, is often at the expense of technical accountability. Fragmentation of the system (or of the architecture) occurs when the now becomes the most important piece rather than ensuring we are adhering to sound architectural principals an meeting our NFRs as well as the long term architectural vision of the software. This is why architectural governance is important.

In agile planning meetings, the team will typically talk about design and may also discuss architectural changes. Ultimately, the team may still be on their own to make these decisions and ensure that the architecture they have will meet the existing business and technical requirements of the sprint, but it’s up to the architect to ensure that the decisions and approaches undertaken by the team are in fact in line and consistent with the architectural vision. The architect is accountable, and accountable for the team’s decisions related to architecture and any architectural changes that come about.

The architect is also a team member who may also code but ultimately has responsibility for the continuous evolvement of the architecture. Typically the architect needs to work in the trenches alongside the development and business teams to ensure constant technical team and business communication. The architect should be involved in all of the agile processes from planning, development, to retrospectives. If the architecture has failed, or we spent too much time on a sprint worrying about “the now” and compromised our architecture, it needs to be brought up and addressed (think retrospective). The whole team should be able to come up with reasons why it failed and how we can improve.

In Summary

When using agile teams, the need for the role of the architect needs to have a high level of consideration. It’s important for this role to work alongside the team and have a very sound vision of how the architecture will meet short and long term objectives with minimal re-work. The architect should be part of all regular agile processes and held to accountability while allowing the entire team to propose and come up with architecture, but ensuring the architect is accountable. Having the architect maintain accountability provides a level of governance to the project from a technical architecture perspective that would otherwise get lost and lead to fragmentation in most agile environments.

The ongoing consistency of your software architecture depends on its alignment with your business objectives, how suitable the technology choices are, and that your team has bought into and is following the architectural vision. This article demonstrates key factors in determining how suitable your software architecture is in being able to sustain a collaborative long term vision and growth of your software along with the difficulties of trying to ensuring business value without a shared vision or collaborative team input. Real world examples from the field are used to demonstrate successful scenarios, the thought behind them, how buy-in was attained, and how they complemented the QA testing strategy of the business objectives. An approach is given on how to recover failing projects where there was no consistent strategy and to turn chaos into a coherent strategy that is aligned with the business objectives.

Your Team’s Ongoing Vision Will Determine the Long Term Consistency and Alignment of Your Software Architecture

One of the problems that the architecture of your software should address is consistency. Consistency with technology, design patterns, approaches, layers, frameworks, etc. As software projects evolve, it’s important to ensure that the architecture, especially as aligned with your business objectives, remains consistent. Functional requirements can certainly change along the way, but the key is to do enough architecture work, and ensure consistency, for those big design decisions that need to be made as early in the game as possible.

Ensuring consistency in this capacity isn’t about guidelines for best practices such as re-use of existing components and developing components that are decoupled from one another. These best practices should be part of most (all) development projects. Ensuring consistency of the architecture is about ensuring that the guiding principles of your core-architecture have buy-in, are clear, are being followed, and are driving the long term success of your software in relation to your critical business objectives.

Ensuring consistency can require a certain level of control in some scenarios, however more often than not, very little controls are required when you have team buy-in, and a shared vision from the beginning as to how the business value is being provided. This is especially true once you have a team that is consistently delivering business value with the software. Enforcing too strict controls on teams can be demoralizing for most, and I’m very opposed to forcing development teams to do things a certain way or dictating how work will be done. I’m all for ensuring consistency and a good architecture across the application, but this can be done without forcing, controlling, and dictating how it will be done.

To help ensure consistency and buy-in across the board, it is important to consider the following when coming up with your architecture:

How crucial are the recommendations at hand to the business?

Will we see a business benefit by evaluating and following guidelines set around our evaluation?

What is the long term detrimental impact to the software of not doing this or doing it too late in the game?

Will following these recommendations eliminate refactoring costs and technical debt later on?

These considerations will help ensure buy-in and ease collaborative agreements with the team as the team will have a better understanding and vision as to the importance of the architecture to the business. Having a consistent vision of the business value helps ensure consistency with the architecture moving forward.

Be sure that team members who want to participate can help collaborate on the architecture or guidelines. This provides ownership by the team members which helps drive and ensure continued consistency. I’ve said many times that architects should not dictate requirements, rather they should create recommendations facilitated by understanding the software, technology, business, customers, etc. These recommendations should involve collaboration and review with the other team members before final architecture decisions are agreed upon and finalized.

Let’s look at some real life examples from the field

Example 1) The sales team had trouble in the past selling to some large customers who used primarily Oracle database servers. The architect discussed the scenario with the business leaders who made up a business case for supporting both Oracle and SqlServer. Collaboratively with the development team, the architect determined that the code base of the entire application could remain the same, but the data layer could be swapped out to support different platforms. The business case helped ensure buy-in of an ORM mapping tool to be used as a data layer that supported both platforms. The team collaborated and evaluated different options finally selecting a tool that met all of the business requirements for performance, scalability, and multiple platforms. In fact, the tool selected would work easily with SqlServer and Oracle platforms with little overhead. It was clear to the entire team how important the ongoing use of this ORM framework throughout development would be to the business and that deviating from this could cause considerable damage to the product and business model. The team was completely onboard with the vision. In addition, this drove the QA testing team to put controls in their testing processes to ensure compliance with this business requirement. The QA testing team made sure, as part of their process, to test the software on both SqlServer and Oracle platforms and multiple platform testing environments were created.

Example 2) Another scenario allowed customers to pay for specific application modules , but not others. It was evident that the architecture needed to adhere to this business model that consistency of the architecture throughout the development process would ensure ongoing compliance with the business objectives. Collaborative team buy-in of the business benefit of this along with the dependency injection and inversion of control framework ensured that the components being built were modular were able to be swapped in and out of the application easily. This would also drive QA testing initiatives that would ensure test plans accounted for and tested this modularity as it is a core part of the business model. From a development standpoint, the team came to a shared vision as to the business reason components are built using this approach. Teams understand that by not doing this or by deviating from this approach that they are creating a refactoring and technical debt cost to fix this later on. Of course, teams are free to improve upon this when new functional requirements are added within the iterative development process.

In these two examples, it was clear to see that team buy in and a shared vision were established because the architectural approaches were well thought out, evaluated, aligned to the business requirements, and had a huge cost to change if we got it wrong. Importantly, the entire team had an opportunity to be involved collaboratively in coming up with the architecture which further strengthened their commitment as they implicitly took ownership among themselves in coming up with the architecture.

It is much more difficult to ensure consistency across development teams without a shared vision about the value being delivered. For example, dictating certain design patterns to be used over other patterns is a subjective decision that will likely fail buy-in as the business value isn’t clear. A forced buy-in approach which will likely fail and will likely lead to team demoralization.

Guidance, recommended patterns, approaches, and coding standards can all be put in place. In reality, it means very little unless we are leading by example and have shown through practice, team buy-in, and business value why we are using said approaches and what the business advantage is. Instead of working on aligning architecture with business requirements, I’ve seen teams spend weeks coming up with coding practices (how to declare variables, which variable naming pattern to use, etc) for new projects. The problem is that most people don’t read or care to look at the documents created from these team sessions, and ensuring compliance for compliance-sake can be difficult and is a waste of time. Even if there is a little bit of value in ensuring how code is written and that variable naming is consistent across the board, I don’t believe documents standardizing the approach provide the value or incentives to do this.

Sometimes, to rescue a failing project, you may need to assert more control and constraints in order to get to a point where the software is coherent and beginning to meet the business objectives. This is a state that we are trying to avoid by doing our up-front architecture work and ensuring consistency with a shared vision. However, as consultants, sometimes we are brought into the project too late in the game. If this happens, trying to fix the solution may require short term measures and controls, but don’t lose sight of the fact that the real value is in ensuring consistent business value through architecture and a shared vision. There may be a lot of refactoring that needs to be done, but the teams still need to share a vision as to the business value of what is trying to be accomplished. My experience is that dictating control will only work in emergency scenarios in the short term just to get to a stabilization point, but for the long term, the team needs to work with a shared vision and understanding of the business value to make consistent progress.

Getting the team’s buy-in and creating a shared vision may be a bit challenging and may take longer in failing projects where the vision wasn’t there from the beginning, but it’s the best bet for the long term success of your software and for the consistency and sake of your business objectives. Once the team has a shared vision and is consistently contributing to the business value, less controls will be required. Your software will be continuously aligned with your business objectives as both the development and testing teams work together to ensure that your software is adhering to your critical business objectives.

Dan Douglas is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Architecture. His professional experience represents over 12 years of architecting and developing highly successful large scale solutions. Dan has been the architect lead on over 15 development projects.

(this new version of this article has been updated as of 11/26/2012 with additional changes and more clarified content since it’s first release on 10/16/2012)

Abstract

Organizations that develop software often succumb to working the way they know how. This article explores non-technical aspects of software that can be put in place in an organization that will create exponentially better results. Essentially, software organizations need to change how people are working together to ensure long term viability of their software products and their people. Organizations may need to first flatten their hierarchy a little to start to empower people at all levels. Following that, organizations need to ensure the architects are working collaboratively with the organization to ensure the developers are focused in the right areas and that the architecture of the product will be sustainable in the long term. The accountability brought into team members through self-organization and the right leadership will act as a motivator for teams to function at their highest level. Introducing multi-cross functional teams will further increase communication and knowledge sharing across the organization while creating a platform to easily identify future leaders for the organization’s success planning initiatives. Once formal and perceived constraints are eliminated and people become more empowered your organization will be better suited to create better quality systems that are executed with high performance.

Creating Enterprise Software Success through Organizational Change

Organizations centered around software often succumb to working “the way we know how” or by following supposedly best practices without considering better practices. Changing how people are working together, how organizational standards and new initiatives are created and collaborated on, and removing invisible walls can go a long way to greatly improving your effectiveness as a software development organization and essentially create better architected software with better execution while ensuring long term viability.

People tend to work within the constraints of the organization weather the constraints are a formal policy or a perception of how things operate. Changing how things operate and the beliefs of the people in the organization by empowering them can be a long process, but your organization will be highly rewarded in the long term.

The over importance placed on a hierarchy of people, each responsible, for those below them, can work, but there are many better ways to create a world class software development organization. Partly because of the hierarchical structure of many organizations, silos and invisible walls are created, and communication isn’t flowing as well as it should be. Collaboration is usually there, a little bit, but it isn’t as extensive throughout the organization as it could be. Flattening your structure to an extent that allows for the creation of multi-cross functional teams where people are encouraged to step up, lead, and collaborate on key decisions leads to very effective results and helps the organization to succeed. Naturally, more collaboration will lead to better communication and more innovation throughout the organization which ultimately leads to better results for the organization.

There are many ways to improve enterprise software development and prevent enterprise software development failure. This article is going to focus on a few people and organizational issues that can be addressed and improved to help create tremendous enterprise software development success. Important things like development process, agile methodologies, testing, pairing, code reviews, enterprise architecture strategy, etc, are all an extremely important part of a successful enterprise software organization, but are out of the scope of this article.

What happens to software with poor communication?

There are too many invisible walls that are preventing communication every day. People who don’t know each other well, don’t normally communicate very well either. This is very evident in enterprise software environments where teams of 50+ developers may only know a few of each other very well. They could be eight feet away in an office, or 2000 miles away in another country, but there is a slight discomfort with developers to voluntarily work together when they don`t know each other well. Especially, they will be less likely to collaborate, and much less likely to ask for help when working in the same area that the other person is much more familiar with. Even when they do work together, it isn`t as effective as it should be. This leads to inferior quality code and product, because the time being spent on development isn’t as productive as it should be and knowledge transfer isn’t happening as it should be.

Limit The Hierarchy

A limited organizational hierarchy approach helps flatten the structure a little bit and open up doors for communication and for more decisions to be made collaboratively. Structure is still important, and ultimately you need specific people who are each responsible for their specific areas, however flattening it a little bit allows good decisions to be made at all levels. It helps teams to become more empowered to make their own decisions and to work and collaborate the way they need to. This still keeps some much required structure and focus in place, but promotes good decisions to be made at all levels. Bottom up and top down.

The Architects

Consider removing traditional Software Development Managers and Software Development Team leads and replace with well-rounded Software Architects. The architects are the ones that need to drive execution of the software and are ultimately responsible for the design, roadmap, and value delivered by the software developers. The architects will have the most exposure to developers and senior management, as it is a requirement to collaborate with executives, product management, development, and other areas in order to properly drive execution.

Ultimately, this level of collaboration by the architects will ultimately benefit the organization by allowing them to come up with the best approach. This will yield a much better and thought out, future-proof technological decision than if the architect was to come up with the technology requirements individually, which often occurs in ego driven organizations.

You don’t need the title “Software Architect”, but the role should be as described here. It’s not only a senior developer who understands software architecture, design patterns, etc – and has architected systems or features in existing applications. To me that implies a great skillset for a senior developer and a skillset that is sometimes difficult to find. But to be an architect working with large software projects at the enterprise level, you need a broader range of skills. The architects also need to be able to motivate and lead a team. By leading a team, I mean encouraging process improvements upon the team, but leaving the team to decide the organization and completion of the work, letting the team work collaboratively to get things done, but constantly raising the bar of the team so that they continue to excel and so that they don’t fall into a mediocre cycle of maintaining or lessoning their current level of productivity. The Architect has to be able to lead in such a way that allows the team to understand direction, priorities, and to allow the team to focus on the right objectives. In the end, if you call this role a “Manager” or an “Architect”, it doesn`t matter – the role of the position is what is important.

Self-Organizing Teams and Accountability

Even within teams there are often invisible walls or silos. Self-organizing teams go a long way to help ease this and improve software greatness as well. For a self-organizing team to function at a high level, you need to ensure that people are working together as a team and focusing on winning as a team and accepting losses as a team.

Self-organizing teams work best when they are empowered to work as a team and there isn`t a feeling of an established hierarchy. There aren`t dedicated team leaders, as leadership will be shown within the team and everyone on the team has a voice and has a chance to step up and lead on decisions. This greatly improves knowledge sharing as well as the team is working together very closely and knowledge gets shared throughout the team more easily. Typically a well-functioning self-organizing team operates at a very high level. They fail as a team and succeed as a team, and therefore work together to do what it takes to improve, succeed, and meet their goals the way they need to while collaborating and helping their fellow team members. Members of self-organizing teams feel accountable to the rest of the team.

Self-organizing teams are great and highly recommended, but ultimately they still need external motivators to make sure they are continually raising their own bar and to ensure they are focusing on the right things. Architects along with the rest of the leadership team need to play a role in this. While the Architects are ultimately responsible for the delivery of the software product from a technical perspective, the accountability for getting the development done comes from within the development teams themselves. This accountability that comes from, and grows from within, a functioning self-organizing team greatly encourages individual team member productivity and responsibility for getting the work done the best way possible. This is why Architects, in the definition for this role, can’t just be regular senior development guys who understand software architecture. They have to understand how the aforementioned things, along with execution, are really important if you want a successfully architected piece of enterprise software.

Key Software Decisions

When making key decisions that will affect the software, try to involve a small team to discuss. Get the biggest experts across your organization, preferably from all business areas impacted, and gather around and discuss ideas. Having a process dictated by a group of senior level individuals without adequate consensus can completely demoralize a development team and lead to gaps in the process or an ineffective process altogether. I am not saying to eliminate leadership from making key decisions, because your leadership essentially should be very qualified to make decisions. However, the best leaders draw on the experience of team members across the organization to make the best decisions. Enough feedback must be solicited from the organization to ensure that the decision or initiative is the best approach and will have the biggest impact. Without talking to the team, getting input, a consensus, and feedback, even good leaders will make bad decisions or create useless initiatives and processes.

Certainly, there are sometimes quick decisions that need to be made solely by those that are qualified to make them. This is ok as well when it is necessary and doesn’t necessarily warrant the overhead in getting others involved, but always make sure that when this happens that the door is open for improvements and ensure that any member of the organization is welcome to help improve the process or help remove the existing barriers which lead to the process to begin with. This is why we need a culture of open communication. Typically, when decisions are made this way, they have an impact from the get go, but because they didn’t necessarily have the buy in from the organization, suggestions and alternatives drawing from the experience of others in the organization were not considered which could have an even bigger impact. Don’t form a committee or introduce unnecessary overhead, but just make sure you get the required input you need to make the best decision.

Once new processes or process improvements are in place, the rest of the organization needs to know why they are in place, what they are trying to solve, and know that anyone in the organization is welcome to further discuss this openly with the stakeholders. Inviting that communication goes far in helping establish trust and helping the people of the organization understand that every process is open for discussion and improvement by anyone. It removes tension that many people feel when a process was jammed down their throat without any collaborative input from them.

Rewarding Change and Improvements

When someone takes the initiative to change a process or suggest a process improvement, make sure that that individual feels rewarded. Even saying something like “That’s a great idea and I think it will work well” goes a long way toward building further trust and showing the rest of the organization that this is a company that takes pride in the collaboration, input, and improvements lead by any team member. Ignoring input of contributors, good input or bad, is the absolute worst thing an organization can do. It creates tension, inhibits growth, and absolutely ensures that the people trying to contribute will feel unvalued.

Also, consider giving random rewards to team members who are continually contributing and stepping up above and beyond their required responsibilities. This is important, so that your key people are always rewarded and feel important, and it will help to motivate others as well.

If you’re a thought leader (or want to be) in your organization and someone sends you an email asking for advice or offers an improvement suggestion, talk to him or her. Or at least send out an email suggesting you meet to discuss in the future. It shows appreciation and it decreases invisible barriers. It really doesn`t matter what your position is, if you don’t want people to communicate with you or suggest improvements, change your attitude because you are creating a new invisible wall and it will slowly drag down those people around you. This goes for any form of communication – don’t create invisible walls – work hard to remove walls and increase communication and collaboration.

The Right Leadership

Architects and your other senior people need strong specific knowledge in the technologies being used and they need to pick up, learn and understand business requirements quickly. They need to be able to form solid relationships with Product Management, Sales, QA, and Executives to get the big picture and to use that to help create a solid architecture, foundation, and technology roadmap with the rest of the team.

Understanding, learning quickly, team leadership, and strong technical knowledge need to be in place. So, if you have a software leadership team that just talks, manages, dictates, or doesn’t collaborate, they may be better suited to another role or kept on to help them grow into a role where they are working better with the rest of the team. However, the point is clear that they aren’t ready and they wouldn’t be effective leaders in the organization. Notice how I mentioned “just manages”? I purposely used “manages” as a term relating to managing people. Aka – making sure “their people” are working, giving reviews related to their performance, checking their attendance, ensuring processes are being followed and all of the things that “managers” do. The point is that successful product and development teams need leaders and not managers. Managing doesn’t improve process, but leadership can drive improvements. Some management may be required by a leader, but leadership should be at least 10:1 the responsibility of management.

Multi Cross Functional Collaboration

I’ve created the expression “Multi cross functional collaboration” as a way to define how to make cross functional teams more collaborative, and even more engaged with other cross functional teams and other parts of the organization.

When people in the organization don’t know each other, it’s a problem. In fact, it’s a bigger problem than most organizations realize.

In order to remove barriers to communication, start by getting everybody to know each other. In Agile environments, Agile teams should already be cross functional teams. You need developers, quality assurance testers, business analysts, product managers, and potentially others, all working together on the same team. This allows the process to flow smoothly from product inception, development, to testing. However, even in this environment you tend to still create silos where communication becomes blocked as there are typically barriers of communication between members of this team and members of other teams. This needs to be addressed, because in software, especially enterprise software, a siloed team still needs open doors to the other teams and to the rest of the organization.

If you expand on the idea of cross functional teams and create the multi-cross functional team, essentially, cross functional teams across your cross functional teams, you are helping to bridge the communication gap by exposing people within existing teams to people in other teams. You are bringing together people who are experts in their specific areas to work together and come up with the best solutions. You are having them work together more closely, sharing knowledge, collaborating, and building new inter-enterprise relationships. You still keep the original teams intact, but you create other permanent or temporary teams that work together to help improve process or solve different problems.

Multi Cross Functional Teams In The Real World

As an example, you could have five software teams that are cross functional – three developers per team, one QA tester, and a business analyst. This is great, because the teams involved in delivering pieces of the software product from end to end are working together as a team. But often the teams still aren’t working with the rest of the organization that well, and this needs to be addressed.

Think about this real world example. You want to implement a new extension to your product and want to figure out the best approach or brainstorm ideas about it. You don’t want to develop a solution yet, but you just want to gather ideas and determine architecturally what is the best approach to proceed, what technologies could be used, and how to improve existing standards to better facilitate future development. This new potential product extension will reach across several software disciplines in the organization and across the functional areas of many existing cross functional teams. What do you do? One approach would be to ask the architects or leadership how to proceed, but a better approach is to create a team comprising of individuals across different existing cross functional teams at all levels (not just leadership).

To create the new team, invite a few key people who definitely will be able to provide big value to the team. Encourage others to volunteer to step up and join. Now you’ve got a new cross functional team that spans multiple existing cross functional teams. And you’ve got a handful of people most likely who are now working together who haven’t likely communicated much in the past due to existing barriers to communication and also because they just don’t know each other that well. The team can work together to come up with solutions to the problem they are trying to solve and also help share their progress with the rest of the organization. It also gives people who wouldn’t normally have a chance to step up and be a leader to step up and help collaborate and lead direction on another team. This is a huge step for an organization for relieving communication problems over the long term while getting new and important side projects started and finished, and exposing team members to new people in the organization (internal or remotely).

Organizational Growth Through Engagement and Empowerment

Think about how engaging and empowering individuals to step up and contribute in more areas of the organization will allow your people to grow, and in turn allow your organization to mature. It will help prevent boredom or developer burnout by exposing people to new people, ideas, technology, and teams. Now, think about this. This is a tremendously huge opportunity for the organization to fuel their succession planning. Now you can see who is working on different teams, who is stepping up, who is taking on a leadership role for certain initiatives – even where it wasn’t even a requirement for their current role. This is huge for an organization trying to figure out who their best people are and help them figure out where they can fit them in to the succession planning process. You don’t want your best people to leave to pursue greater opportunities in other companies, so empowering people with a chance to step up, collaborate, and lead, will leave them with an avenue to be recognized in the organization as a leader or potential leader, collaborator, and asset to the organization.

This also helps go towards the problem of developer boredom which plagues software development projects. If you think developer boredom is caused by bad developers, think again. Boredom creates mediocrity and inevitably even extremely talented people become less productive. Unexciting or repetitive work typically creates the kind of boredom that can usually be relieved by leaving the organization and starting fresh on a new project. Get my point? Elevating boredom is huge for a company, and even allowing your people to spend part of their days exploring new ideas and projects (maybe as part of another team) that are not directly related to what they have been doing day in and day out for six months is a huge step for morale and will make their regular work much more productive as a result.

Other examples where creating a new multi-cross functional team is beneficial to the organization include: Nailing down some pairing and communication processes, R&D on potential new technology to incorporate into the project, exploratory research projects, defining new architectural standards or approaches, new development initiatives such as unit testing or code reviews, etc.

The point is to get the ideas started and then make sure that everyone in the organization knows what is coming up in terms of new initiatives or teams.

The Best Part – Employee Retention & Succession Planning

Great developers work hard, great developers get excited about new technology, product creation, and innovation. Great developers generally have a spirit of entrepreneurship towards their work in the sense that they love to try new things, fail, learn new technologies and try them out. This excites the majority of developers and ignites a passion in them. By including them in different projects, and giving them the opportunity to step up, they also gain a sense of importance to the organization. Think about how great this lends itself to employee retention.

Exposure to new technologies, people, and helping define processes shakes the work day up which helps prevent the mundane problem of boredom when working on the same things for too long.

Remember the fantastic side effect? Succession planning. This helps create a roadmap for succession planning in your organization. Now, multi-cross functional team member’s have an even bigger opportunity to shine by stepping up and joining (or better yet, starting) other new cross functional teams. In these teams they can prove their ability to work in different facets of the company and communicate, lead, and collaborate with different teams and people all while increasing their own technical, and communication skills. This helps management decide who should, let’s say, become the next architect, or lead a new software development initiative while also raising the skill level of everybody else who has been involved. It puts sustainable succession planning into motion within your organization.

Finally

Ultimately, the role of leadership is to create a vision and have buy in with the organization so everyone has the same vision, recognize the contributions of the rest of the organization, ensuring that people are collaborating to the best extent possible, eliminate invisible walls and silos, all while sustaining long term growth and evolution of the organization. The accountability brought into team members through self-organization and the right leadership will act as a motivator for teams to function at their highest level.

Using mutli-cross functional teams, and encouraging decisions and improvements to be made at all levels while getting the input of the people across the organization before implementing big initiatives will be valuable in ensuring that the best and most thought out decisions can be made. This helps empower people and leads to much better succession planning.

The right people are key, so having very smart people at all levels is a requirement to correctly implement the ideas presented in this article. It`s hard to build a relationship of trust and empower people within your organization if you do not have the right people who are intelligent, will step up, contribute great ideas, and open up doors of communication. Eliminating the formal or perceived constraints that people are working within in the organization can be a long process, but once you empower people your organization will be better suited to create better quality systems that are well executed. The advice and topics discussed in this article can go a long way to assist in achieving these goals and to help create an even more successful software organization.

Dan Douglas is a professional independent Software Consultant and an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture. His professional experience represents over 12 years of architecting and developing highly successful large scale solutions. Dan also believes that properly empowering teams with trust and responsibility yields the greatest results, and that creating better software goes well beyond just writing better code.

The opinions expressed in this article are my own and are based what I have done, what I have seen, and what I have learned while leading and working in many different team environments.

Follow Blog via Email

Dan Douglas is based in Toronto, Ontario, Canada and does consulting work for both small organizations and large global organizations through his consulting company, Douglas Information Systems Corporation. He is an experienced and proven subject matter expert, decision maker, and leader in the area of Software Development and Architecture.

With over 16 years of experience, Dan has been the Architect Lead on over 15 development projects and has successfully delivered large scale “best in class” end to end solutions. Dan has developed and architected solutions across a wide vertical, including, government, medical, automative, hr, manufacturing, technology, consulting, and software firms.
Dan writes a lot of code as a hands on developer and is passionate about delivering the right solutions to customers through better code, better architected solutions, better business alignment, and better process.

"My articles are inspired by what's possible. My experience in my software consulting practice has given me the inspiration to write about what I've seen and what I've done, and to write about 'What's possible in software'." - Dan Douglas