Are you an implementor? Or, A decision maker to have it to be implemented?

Are you an implementor? Or, A decision maker to have it to be implemented?

Introduction

In this article, within the framework of some of my experiences so far, I will give a holistic idea to the reader about software development teams and some processes about forms of these teams. My notes here will give an idea about individuals, team setups, the hierarchical structure of these teams and their integration with each other, and the issues that companies should give importance to. This article will be about how a software development habitat can be achieved within the framework of soft capabilities, not budget and resource considerations.

What are the key difference between implementing and decision making ?

Practically, if we need to evaluate what are the meaning of decision making and implementing:

Decision making begins with stating the decision that needs to be made, continues with researching the options, making decision/preparing a design about the most appropriate option to be implemented.

Implementing phase begins with accepting the design of the solution, and continues with having alignment with the decision maker for possible gaps, implementing it and delivering.

What does making decision require while developing software?

One of the most repetitive processes in software development, consciously or unconsciously, is decision making.

Individually, what the developers are doing all the time is actually passing a given decision into the app with code. In fact, the software is the whole of a meaningful business blog that has been transferred to the application with pieces of code.

On the other hand, there are decision-making processes that take place in the process of developing a new feature, for example, when working on a large-scale product. These processes may be more related to the general functionality of the application or may be reflected as a brainstorming due to architectural reasons. Also, here, how to develop this new feature, how it will be applied architecturally and its impact on the product are evaluated. By the finalisation of decision making process, the technical design of the new feature is made by people who have business domain knowledge and architectural knowledge. These kind of decision-making processes are experienced in the development of new features that will bring a large set of changes. It basically includes the following phases below:

1. Problem/Requirement description

2. Relevant part of the system evaluations

3. Relevant inputs

4. Alternative Solutions

5. Infrastructure related changes

6. Decision making phase

7. Preparation of the technical design/technical spec/blue print

8. Transfer technical design to implementer/implementation team

In this level, we can also mention about some ownership. The feature/business owner is designers/approvers of this process within blue print and/or technical design once it is approved/agreed with stakeholders. Implementor can be owner of what it is implemented based on technical design.

Developing Solutions with Individuals

Let’s assume:

• If you have no idea how many developers are working on the same solution

• If contacting a different developer almost every day is a regular activity

• If there is no planning or being tied to a process within the framework of the team

• If you are retrieving a task from kinda a technical manager

• If it is progressing irregularly

• If you are making deliveries to individuals

You are probably working on a project where individuals are working independently. It is very likely that the project is in maintenance mode.

Editing tasks are often worked on within the framework of minor improvements and the application needs to be able to maintain its current features.

On the other hand, there are also products that continue to be developed with freelancer developers. We can assume that this approach is similar. This application/product, which is systematically automated (especially for deliveries, business case coverage by automated tests etc.), will be able to respond to requests and survive with this development family.

While there are advantages brought by the independent working order, there are also disadvantages. The difficulties here are generally encountered in the following headings.

• Delivery automation/issues
• Instant and periodic testing of the delivered feature / regression problems
• Clarification requirement in regression processes
• Feature ownership/Business domain expert for possible questions

Developing Solutions with Development Teams

Software development teams work together to build an application or product. Teams should be organising and cross-functional.

Well-organised and structured work at an individual level brings the overall effectiveness of the development team.

While building a software development team, for sure there are some key factors that needs to be considered. To be able to name these factors, let’s evaluate what a team does practically?

• Know and share the interests of business.

• Rather than directly criticising individuals, evaluate ideas and try to give different perspectives.

• Trust each other.

• Leave the codebase cleaner than how it was found/experienced before.

There are different types of team structures as well.

• Flat Structures: Flat structures are also called as self-managed managed teams. As an example, development teams in Startups.

• Hierarchical Structure: A hierarchical structure refers to a company’s chain of command, typically from leadership executives to general employees. Could we call this as “separation of concerns for the positions” ?

What is offshore team?

For some reasons such as budget (most likely), SLA requirements (7x24 support) and/or time zone related reasons, companies may need to build development teams in another locations far from company central location. These teams are called as offshore teams.

Integration between distributed teams (offshore teams)

Imagine that one central team in HQ and rest of the teams are distributed offshore teams. We could call this setup as distributed teams structure. Remoteness and Work from office are mixed based on people locations. Here there are some other things that has to be covered by company to achieve equality within this diversity.

• Have local Team Lead for each groups

• Keep in communication with local Team Lead as People Manager in any moment.

• Give importance for Visual Communication

• Provide regular Trainings

• Have a stable and standard Onboarding processes

• Align on 3 months, 6 months and 12 months goals with a reality.

• Plan regular business trips

• Encourage teams to visit HQ

• Have Automation part of company culture

• Track Performance individual and team level

• Have possibility exchange between teams

Are you an implementor or a decision maker?

Of course, this question is in the area of software development and its delivery. Along with this question, what I also want you to answer is whether you have implemented your own solutions. However, I think you can see your role, the role of your team, or the role of your organisation more brightly.

Most software companies basically come under 2 categories. One of them is Consultancy/Outsource companies, the other one is Product development.

• Developer in implementation

• Consultancy in specific area/technology

• Consultancy with implementation on defined/designed solutions

• Consultancy/Architecture design and define solutions

• Developer in offshore team

Some of the separation advantages of the Solution design and Implementation teams are to obtain optimum output and to be able to start production in the most appropriate way by clarifying the design. Of course, there are reasonable reasons for this in terms of budget and resource management.

Final Notes

Here, I am finalising this article with some recommendations here.

• Give importance while making decision on your product development way. Try to get benefit of human centric and agile architectures such as micro services architecture.

• People makes things complex first then separate it to small pieces. For each piece becomes complex in time. if you experience difficulty and complexity, it doesn’t mean that things were wrong but it means, something (you, your business or both) grows. And this separation to little pieces should be repetitive whenever it requires.

• Yes, experience is important while hiring. But don’t forget that character business ethics are important, too.

• As a company, invest on technical design and blue prints. If you don’t, you will lose more while developing your need.

• Make documentation required as a part of delivery. Automate if possible with some documentation generator.

• Ownership, this is something important for company. Build trust and qualified teams first if you expect ownership on things.

• Evaluate “change-sets” with your architects, technical decision makers and/or domain experts.

• You may think that you do agile, that is ok. But, are you sure about your teams are agile?