![]() Again it is important that the same people are communicating and collaborating with each other in order to build trust and lessen miscommunications. There must be regular communication between legacy teams and the dependent DevOps teams. This is because new, innovative or agile systems are in fact dependent on legacy systems though the rate of change and conflict is less frequent. Continuity and consistency will promote collaboration, innovation and reduce human error.įourth, consideration for legacy systems and the people who support them must be considered. Likewise, supportive teams must be attached to the same primary teams, and not bounced around from this team or that team – that project or this project. To ensure collaboration is high, these supportive teams must be a defined and dedicated team and not a rolling roster of specialists. Third, recognizing that the workload of SAs, DBAs, and other SMEs may not lend itself to full workweek utilization, you can organize these roles into supportive or secondary teams that support two, but no more than three primary teams. The point is these teams should have within them the technical expertise to understand the scope and dependencies of designed changes, developing those changes (if needed), testing and validating the changes, performing dependant work such as database tasks, and have access to the target environments and be able to ensure compliance. Obviously other roles can be included – the app (or COTS) architecture will dictate the participants required for each DevOps team. ![]() This will include at least one developer, a QA engineer, a systems administrator and a DBA for each team. Second, these teams need to include the separate disciplines necessary to architect, develop, test and deploy the change. To implement a DevOps team, you need to organize a number of small, ‘self-contained’ teams that have the autonomy, authority, and credentials to warrant and promote changes into escalating environments-including production. Making this determination will be different for everyone company, but I hope the following guiding principles will help in making that determination.įirst, recognize that smaller teams are more effective than larger ones. ![]() Defining these teams by functionality, product line, micro service and so forth is, in my view, critical to success. I will begin by referring to these small, autonomous, and authorized teams as DevOps teams. I will offer a few points for consideration. How do you proceed if you are an enterprise? The supposed ‘unicorns’ – small companies or large tech companies that began within the last fifteen years – do not have the same combination of legacy systems, diversity of SMEs and technical debt that most enterprises do. DevOps demands a level of collaboration and coordination similar to what my IT Navy Seal teams enjoyed. Communication is much more fluid in smaller teams and it is cheaper and easier to acquire a few ‘A’ players than it is to find and pay top talent in bulk. Larger organizations will likely struggle to scale the Navy Seal team concept because one of the things that make Special Forces special is that they are small. They trust one another implicitly to get things done. Each person on the Seals team has a specialization, a dedicated role, and a particular purpose. They are all ‘A’ players-there are no ‘B’ or ‘C’ players. Navy Seals work as a tight-knit specialized team. And those parallels are as relevant to DevOps today as they were 20 years ago. Now, there’s a quantum leap between what we were doing as a DevOps team then and what the Navy Seals do - obviously. Years later when I was in leadership roles, I repeated this same team concept. It was DevOps, I guess, before the word was invented, but we referred to ourselves as an IT Navy Seal Team. We had authority and autonomy to make things happen. Stable systems were launched when the deadline was due. We worked closely with each other in QA, Staging, and PROD environments. We had a few developers, a couple of QA engineers, a systems administrator, and a DBA. Many years ago, as a young software developer in IT, I had the opportunity to work on a team of senior level professionals.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |