RELATED CONTENT: How you organize your development teams matter

According to the report, the five challenges managers are struggling with are:

1. Maintaining productivity and velocity. As more development moves toward microservices and serverless structures, development teams are struggling to make technologies visible and troubleshoot their applications. “The complexity they bring demands a steep learning curve, and one of their main value points — namely, the abstraction they provide between the application code and the hardware the application is running on — also raises new challenges when attempting to troubleshoot the application without access to the hardware they run on,” the report started. 
2. Resolving customer issues in a timely manner. Engineering teams that are not properly equipped to handle customer issues become apathetic to problems. They need to clearly put a face and a name to an issue, see how much the issue is impacting the bottom line, and align with the business. “Once engineers are equipped to help the customer, they start seeing benefits to the business and end customers. It is becoming much more motivating to help resolve those issues and ties the loop back in to focus, understand and align with the business,” said Liran Haimovitch, CTO and co-founder of Rookout.
3. Balancing speed and quality. When working in a distributed development environment, it can be hard for developers to balance velocity and quality. Leaders are measuring development on their ability to meet deadlines, make customers happy, and find as many bugs as fast as possible. 
4. Teamwork and collaboration in a distributed environment. Teams are having trouble debugging and developing efficient code in a distributed environment. They need tools where they can collaborate, have access to the same information, and share knowledge. 
5. Remote debugging: Traditional debuggers don’t work in a distributed environment. “The solution is adopting the proper tool: a modern debugging solution that’s built for cloud-native applications. Developers will be able to get the data they need from their code, no matter where it’s running, and while their code is running live,” the report stated.

The post Top five challenges development managers are facing today appeared first on SD Times.

“We have business objectives and we need people to fulfill them. The goal of an organization design is to group the skills necessary to deliver value in the most efficient way for the business overall,” said Jeremiah Lee, an engineering manager at InVision, a digital product design, workflow and collaboration company.

Add COVID-19 and remote work into the mix, and things get even more difficult for development managers. 

Assembling your development teams
There are different ways to organize and bring developers together on a project and work toward the business’ success. For instance, there is the traditional development team structure or a squad approach.

A squad is a term that came from audio streaming company Spotify’s engineering culture. According to Spotify, it is a “small cross-functional, self-organizing team usually less than eight people” that “sit together and have end-to-end responsibility for the stuff they build, design, commit, deploy, maintenance, operations, the whole thing.”

RELATED CONTENT:
Developers reflect on challenges, feelings about remote work in pandemic year
Top five challenges development managers are facing today

The company explained they started as a Scrum company, but once they started to introduce more development teams within the organization, it found the Scrum practices were getting in the way. “We decided that Agile matters more than Scrum, and Agile principles matter more than any specific practice,” the company said in a video. 

Typically, a squad includes a squad leader that acts as a lead developer or Agile coach, and six to eight developers who are split up into pairs. There are also support squad roles such as a designer, product owner, and application architect who come in for a period of time to help with the overall design or UX, explained Chinh Vo, CTO and practice leader for IBM Garage.

According to Ravi Lachhman, an evangelist at the CI/CD software company Harness, “squads are more organized around a problem set to deliver functionality on and members of a squad can rotate in and out much more frequently than changing teams. Squads are typically problem- or functionality-based, bringing together several members from different teams to solve and deliver on a particular problem or build specific functionality. When those goals are accomplished, squad members can realign to different squads while continuing to grow their skill sets.”

Squads can, however, have a negative effect on the human aspect of development, according to Liran Haimovitch, CTO and co-founder of debugging company Rookout. He explained that in a squad model, developers are required to change teams frequently and work with different people, which can hinder the development project because developers have to take time to get to know one another and how they will work together.

However, Harness’ Lachhman looks at changing teams as a good thing because the only way he says a software engineer can grow and expand their skill sets is to experience and embrace new challenges and changes. 

“Squads can regroup and spin up and down quicker than changes in the team/management structure, allowing for individuals to solve problems they are passionate about and the squad can focus on the goals set forth,” he said. “Modern teams should focus on skills and domains of the ‘bench strength’ of the development organization and then allow development members to work on different projects/squads. This allows for development members to rotate around and work on fresh problems while building domain skills in the firm/organization.”

Lachhman explained that in order for a squad to work, there needs to be a strong platform engineering culture in place. “The biggest part of the learning curve when switching team to team is that no one ever deploys software the same way,” he said. “Common engineering efficiency tools such as those that enable the CI/CD pipeline and similar confidence-building steps teams take to reach production are crucial for squads to work.”

IBM’s Vo recommends the following best practices: implementing pair programming, rotating programming pairs to spread knowledge, having standup meetings, and co-locating squads.  

According to Mark Cruth, enterprise solutions architect at the software development company Atlassian, the best practices engineering managers can take from the Spotify model are: 

• Not to copy the model, but to try to understand the structure, practices and mindsets, and then tailor it to fit your own organization and needs.
• Autonomy and trust to empower teams to pick their own tools and make their own decisions
• Transparency with community by building trust, being transparent, providing inclusive ways to gain feedback and aligning with how your organization wants to work
• Encourage mistakes to constantly be learning and improving 

“Although it may look like a matrix organization, the key cultural elements of the model need to be in place to allow the structure to thrive, such as trust and autonomy. If an organization doesn’t shift its behaviors (and ultimately its culture), the benefits of the Spotify model will never be realized. If you simply rename teams to Squads, you’re just putting lipstick on a pig,” Cruth wrote in a guide about squads.

InVision’s Lee  believes Spotify’s squad model falls short of its promises. He explained while Spotify’s idea of squads was to basically have teams working as autonomous mini-startups with all the skills necessary to do their job without having to rely on another team, matrix management solved the wrong problem, he said. It was too fixated on team autonomy, collaboration was an assumed competency, and mythology became difficult to change, he said. 

Stream-aligned teams
Instead, Lee recommends a stream-aligned team approach, which is an evolution of full-stack, multi-discipline product engineering teams or Agile feature teams. 

“Stream-aligned teams perform better than teams organized by discipline because coordination effort is reduced to coordination within a single team instead of across team boundaries,” he explained. 

IBM’s Vo finds that while ideally you want to have full-stack team members, there really aren’t any true full-stack developers. They either have more expertise in the front end or back end of software development.. He explained forming teams into squads helps because you can pair different types of programmers together to get them more up to speed on the technology or in an area where they may not be as strong. 

Stephen Deasy, head of cloud engineering at Atlassian, explained that what engineering managers should really be focused on is organizing teams around customer impact. “Our first frame of reference is always we should organize the team to be most effective to deliver that value and how you organize changes,” he said. “What we found was being able to connect to the end user and really understand the domain and problem space the end user is having, the team can really develop a deep understanding in there and build really good solutions.”

The way you organize and execute that will be different depending on your project or team size, but Atlassian believes in the triad model where you look at the development, market and operational aspects of a solution. “We think of products as really being the what and the why, building that roadmap and understanding the domain, what outcomes we are trying to drive. Then, the engineering teams are trying to drive how we will build it, owning the schedules, delivery, execution and operations,” he said.

As far as how big the team should be, generally Deasy says you want to make sure you can control and understand the growth of a team at that size. “Really trying to connect the team to the what and why, building a balanced team so they are set up for success with skills, level and size, and try to get out of the way and let teams win,” he added.

As you start to grow the amount of developers you have, you will have to revisit how you organize and execute your teams. Deasy explained what works for say 40 engineers may not work once you scale to 200+ engineers. 

“The most optimal combination of team types changes as the organization size changes and the business needs change. Many organizations today start with several stream-aligned teams and expand to include the other types as the organization grows” Lee said. 

Lessons learned working in a remote environment
Traditionally, you would form a development team and they’d have their own physical space to work together, but the COVID-19 pandemic really forced development teams to rethink how and where they work. A year later, many businesses are actually seeing increased productivity and happier employee work-life balance as a result of working remotely that they are starting to consider a remote-first approach. It wasn’t an easy year, but organizations have started to work through the kinks and find what really works for their business in a remote world. 

One of the biggest disadvantages development teams faced in the pandemic and in the new remote world was the camaraderie that came with being co-located, according to Harness’ Lachhman. Managers have the extra task in a remote setting to make team building and skill-sharing a priority. “Setting up co-working time, virtual lunches and happy hours are also important to foster ongoing collaboration,” he said. 

What Lachhman found was that while, even when employees were still in the office they would typically “ping” or message someone before getting up and going over to their desk to ask for help. “You can still collaborate this way virtually and instead of walking over to someone physically, you can start a screen share,” he explained. 

According to InVision’s Lee, the success or failure of a team in a remote environment has more to do with team interaction than team structure. “Working remotely means embracing asynchronous work. There are a million ways to collaborate and almost as many tools to help. When you are remote, you can’t look around the office and infer norms. You also can’t get everyone in a room at the same time to build consensus every time. You have to find another way of getting alignment,” he said. “Companies have to increase intentionality to work effectively remotely. That means creating and explicitly communicating an agreed upon set of practices and investing in people being able to self-serve their way to success.”

Remote camaraderie, team building, and human connection really requires good video and microphone setups so people can put a face to a name, look at each other, and see their emotions, according to Rookout’s Haimovitch. “Once you move to asynchronous communications, you can reduce costs and have more flexibility on who and how you hire,” he said. 

One of the things Atlassian tried to implement to keep the human connection was to try and organize a social event every week. However, the company found that this was challenging in the beginning because not everyone was available at the same time and it was taxing for them to have to add another meeting on their calendar. The company found that replacing a standup meeting with a social event and consolidating the number of meetings really helped alleviate some stress of their team members. 

Managers also really need to listen and learn from their team members, according to Atlassian’s Deasy. Some ways to gain feedback is to run regular polls at the team and individual level to find out what is working, what is not working, and how the organization can help. 

Deasy also found that the company had to reallocate or increase development team budgets so they could get their remote offices properly set up. Since the company found that every individual has different requests and needs, the company gave managers the anatomy to overwrite budgets and work out what was needed for each individual case. “It’s hard to come up with a single global approach to this because the individual situations are so different and it changes over time,” he said. 

When offices start opening back up, Atlassian plans to retain office spaces, but use them more for collaborative workspaces or as an option for those who need a physical place other than home to work. “We believe the distributed manner in which we are working now has a lot of advantages. Diversity, improvement, engagement and flexibility for people to work in the ways they are most productive while still connecting to their team,” said Deasy. 

Rookout’s Haimovitch found that the pandemic really highlighted the importance of independent engineers. “It is even more important that engineering managers provide team members with the right tools and guidance to allow them to work efficiently and independently,” he explained. “You need to make sure your  engineers can do whatever they need to do alone by themselves because that is how they are going to spend their day. You can’t rely or allow silo knowledge or lack of privileges. Give them the tools to deal with their own day-to-day tasks independently.”

IBM Garbage’s squads worked on a co-located model in a physical space before the pandemic because they found it provided a faster turnaround for mission-critical development projects. When the pandemic hit, the company had to move to more virtual ways of working. According to IBM’s Vo, video was key to making sure there was still that personal connection. The challenge in the beginning was dealing with people’s Internet connection and bandwidth. 

It also adopted new collaboration tools to maintain interaction and engagement from all participants.

Vo doesn’t expect to change much of the work environment post-pandemic, unless it’s a request from a customer. “There will still be a combination of going onsite with customers and teams coming into the office working together, but it’s not a requirement anymore,” said Vo. “It actually opened up the possibility for us to form more efficient squads. Instead of restricting us to one office location, now we can have people from the West Coast, East Coast, middle of the country, and get the right type of folks to be more efficient or more specialized to execute on the project. It gives us a little more flexibility.”

The post How you organize your development teams matters appeared first on SD Times.

Change and growth can also cause cultural issues that, when not managed correctly, may impede innovation and efficiency. Tammy Perkins, chief people officer of Fjuri, recently sat down with me for a Q&A to discuss strategies for recruiting and hiring that can manage these issues and help build a future-proofed engineering team. Her insights are below.

Duffy: At sodo we talk about diversification of the roles and ensuring that hiring addresses existing weaknesses and empowers change. From your view, what does diversification in hiring mean?

Perkins: One of the key factors to success is making sure that you don’t hire people just like you. Instead of hiring for a culture fit, look for a culture add: the missing voice at the table, someone that will add different skills or credibility to the team. That will help drive innovation and new ideas as you continue to evolve.

Hiring to your weaknesses, not your strengths, is a very introspective process. Finding where the team is weak and where it can improve is an exercise that not many people are deliberate about.

Hiring for individual strengths will help the team because people will be inspired to perform. When you’re doing something that’s in your sweet spot, it is motivating. From an employee perspective, you’re amplifying that person’s superpower. From a team perspective, you’re leveraging the strengths of others, and focusing on what makes everyone unique will bring more to the team.

Another thing you have discussed is empowering the people you bring on. This speaks to the superpower you just mentioned. How do you ensure that people will be empowered once they come on?

Sometimes a fear of failure prevents people from being successful. So you want to empower people to make decisions and drive forward, while creating a culture where you’re asking for feedback. That way, it’s not all top-down. It’s bottom-up.

What are some ways you can do that? You have talked before about continuous learning and being open to change. What are your thoughts there?

In terms of learning, it’s crucial to avoid groupthink and encourage people to continue to learn new skills and bring new ideas to the table. You want to model that and have different types of processes within the team or mechanisms where you’re sharing out “here are some new things that I learned this week.” It can be something that’s outside of the particular project that the team is working on. It can be something that is sharpening their skill set as they continue to evolve.

Flexibility is also critically important to growth. If you have people who have a learner mindset and they’re agile, they will be able to scale with new ideas for the future. So you can look at that through the hiring process and hire for the future, versus hiring for the particular role that you have. Also, through your development process, ask the team, “What are some ways that we can be better?” Continuous feedback and improvement is important for a team to be able to scale.

I often find that when I’m building a new team, I have an image in my head of what a role is going to be. I sell someone on that role, then they hit the ground, and within the first two weeks everything changes because what I envision the role was going to be is different from what’s actually needed. How do you deal with those shifts?

First of all, make sure that you hire people who are scrappy and agile enough that they can evolve. If the role changes or you triple in size or sell a new product or do something completely different, those type of people will be able to evolve and adapt. My biggest piece of advice is, don’t hire for a particular role, hire for people who can scale with your company.

Also, when thinking about building for the future, look at some of the long-term strategies that you have. I would recommend selling candidates and your existing employees on the future and the values that you have for the company. If you get really narrowly focused on a particular role, you may miss out on some of the great things that are going to happen in the future. I think tech is uniquely positioned in the fact that the roles change and ebb and flow. It’s almost like pouring water in a cracked floor. The water tries to find where the right opportunities are. I think that’s the same in tech. An organization evolves and different things become important over time. I think setting those expectations upfront is important.

Sometimes the culture within a company is weaker than the strength of the opinions that are being brought in. What are some things that a company can do to make sure that the minds meet?

That’s when you anchor the leadership values as a part of your organization, not just what they do but how they do it and how they deliver. That becomes a key success factor. It’s not just words that you have in your handbook or something that’s on your website. You live it, you breathe it, you own it, and that’s how you define success. Experienced leaders come in, and while they bring great depth of experience, they’re also a part of the leadership values. And they need to role model that as well. Have those values written down and internalize them first, and then you can bring that person on board and say, “This is how we do things.”

The post How to future-proof your software engineering team appeared first on SD Times.

“If you are unfamiliar with Power-Ups, they are additional features and integrations that can be enabled on boards to provide a custom-fit Trello experience for your specific use case. For instance, Power-Ups can be used to add a calendar to your board or custom fields to cards, create automations with Butler and Zapier, or pull in up-to-date information from apps like Evernote, InVision, and Dropbox,” the Trello team wrote in a post.

The new Power-Ups directory will feature more than 80 public Power-Ups designed for popular applications such as Slack, Google Drive and Bitbucket. Developers can also custom build their work Power-Ups for their specific business needs, and share it privately.

The new directory will also include a featured section to highlight some favorite Power-Ups as well as articles on how to maximize Power-Ups capabilities. Developers will be able to search the directory by categories such as analytics and reporting, automation, developer tools, and IT and project management.

“This year, we more than doubled the number of Power-Ups on the Trello platform, and we hope the redesign of our directory will attract even more top developers to build for Trello,” said Hamid Palo, head of platform at Trello.

The post Trello boards get a “Power-Up” with new directory appeared first on SD Times.

Not funny? I agree. The sad part is the word “database” in the story could variably be replaced with operating system, application server, VM platform, etc., and the story would ring true with just as many people. If you’ve worked in the trenches of software half as many years as I have, you know that things like this are the hidden friction in software. Often, the teams outside of an application are coupled together by shared dependencies as much as the code inside the application.

Lister and DeMarco famously observed that, “The major problems of our work are not so much technological as sociological in nature.” But I wonder if anyone has considered what technology (especially software) and people might share in common? Consider Conway’s Law, which makes such a connection: “organizations which design systems . . . are constrained to produce designs which are copies of the communication structures of these organizations…”

Conway’s insight is that software built by teams will be comprised of pieces roughly corresponding to those teams. This is a powerful observation, with the obvious application that software companies should organize into teams congruent with the software they want to build.

But I think we can extrapolate further. We all agree that software with certain properties is easier to change. Its components should have low coupling, high cohesion, well-defined interfaces, clear contracts, and so on. Extrapolating from Conway’s Law, we get a new observation: if we want to produce software with these properties, our teams must also have them. Teams should have strong separation of concerns, few dependencies, clearly defined boundaries, etc. Teams like that are able to evolve their piece of the system independently, making the entire organization more agile.

Another way to say it is that efficient communication between units is crucial to success, whether those units are modules of code or teams in companies.

Does this connection bear out in reality? For one example, take the rising popularity of the “platform” team. Ironically, organizing teams within a software company around an internal platform produces a sociological problem that mimics a classic software design paradox almost perfectly. It encourages reuse, which is good, but it also enmeshes the platform team in far too many decisions. They get coupled to every team, because they’re like a class imported into every other class in an application. Whenever it changes, every dependent class must change as well.

Another example can be seen in “vertically siloed” companies, where teams are organized by role: finance, product, engineering, support, operations, etc. In this scheme, how many different teams need to be involved to deliver a single customer feature? What does attendance in a project kickoff meeting look like? It reminds me of having a class with ten parameters in its constructor.

I think it’s worth asking how many dependencies your team has, even if it is cross-functional. You may be surprised how many there are. Try making a “Conway system diagram” of your company. Take a normal system diagram and mark each component with the team or teams that have responsibility for it. Connect all the teams required to enhance, support, or maintain a single customer scenario.

Minimizing team dependencies isn’t the only application, though. An analog to the Single Responsibility Principle might be that teams should have only one reason to change focus. If a team has too many customer concerns, maybe their attention is fractured and the resultant context-switching is killing them.

A final example might be seen in how adding a security review phase to a project always results in inadequate security in the product. The “bolt on” nature of such an approach violates the software design principle of “secure by design.” Teams that care about building secure software should place that knowledge in the team itself and it should be present throughout the project lifecycle.

I’ll leave further examples as an exercise for the reader. By thinking of team organization with a software lens, you may find key insights leading to better ways to organize. Conway’s Law is practical, not merely theoretical. Independent and de-coupled teams, like independent code modules, will be better positioned to produce software that can evolve, and software with evolvability allows the organization to deliver customer value more quickly and effectively.

The post Guest View: Software reflects teams that build it appeared first on SD Times.

“Gone are the days of having your issues cluttered with discussions or your pull requests flooded with lengthy conversations that aren’t related to your code changes. Team discussions give those conversations a home and a URL on GitHub, so they can be shared easily across the platform or saved to reference later,” Katie Sipos,  GitHub staffer, wrote in a post.

MariaDB announces open source analytics solution 
MariaDB has announced new product enhancements to its analytics solution MariaDB AX. The latest version aims to provide a modern approach to data warehousing with fast, scalable analytics. Features include: improved data ingestion, bulk data adapters, a streaming data adapter for MariaDB MaxScale and Apache Kafka, custom analytics, and improved disaster recovery.

“MariaDB AX is a powerful, open source solution for performing custom and complex analytics,” said David Thompson, VP of engineering at MariaDB Corporation. “In order to fully realize the power of big data, our customers need the ability to gather insights in near real time, regardless of where the data is coming from. With MariaDB AX, it’s easier than ever to ingest and analyze streaming data from disparate sources, while ensuring the highest level of reliability through new high availability and backup capabilities.”

MapR releases version 6 of its Converged Data Platform
MapR is taking on DataOps with MapR Converged Data Platform 6.0. The latest version features new solutions for security, database and automated administration across every cloud.

Key enhancements include: a new MapR Control System, database indexing, real-time data integration, single-click security improvements, self-service data science, artificial intelligence and machine learning for data analysis, and a new MapR Container for Developers.

“In 6.0, our platform’s unique capabilities focus on three key areas in support of DataOps: automated cluster health and administration, security and data governance, and faster time to machine learning and analytics,” said Anoop Dawar, vice president product management and marketing, MapR. “DataOps is an important movement, ultimately letting organizations turn their data into value as quickly as possible. We continue to evolve the MapR Platform to accommodate the needs of everyone involved with data: data scientists, operations personnel, and security practitioners.”

Google Play Referrer API
Google is introducing a new API to help developers track and measure app installs. The Google Play Install Referrer API provides a reliable and secure way to retrieve install referral content, according to the company.

“Understanding how people find your app and what they do once they’ve installed it is crucial to helping you make the right product and marketing decisions. This is especially important when you’re deciding your advertising strategy and budget,” Neto Marin, developer advocate for Google, wrote in a post.

The post SD Times news digest: GitHub team discussions, MariaDB AX, and MapR Converged Data Platform 6.0 appeared first on SD Times.

“Agile software development alone can’t solve all your problems,” said Doug Dockery, global sales engineering leader for CA Technologies (CA). “If you’re serious about competing in your markets, you have to change your definition of ‘business as usual.’ Agile can’t succeed as an island.”

The inefficiencies result in budget misses and stalled innovation. Agile ROI is falling short of expectations because it’s much more of a team sport than organizations realize.

“Agile teams and agile businesses are two different things,” said Dockery. “Development teams are being blamed for building the wrong things, but it’s not the team’s fault. Companies haven’t created an environment of alignment, autonomy and trust.”

Alignment ensures that the teams build what matters most to the business. Once the business and development teams are aligned, the development teams have the autonomy to decide the best way to build the product.

Bilateral trust is also important. Without it, companies can’t deliver their best value to customers. The business must trust that developers will build what’s in the best interest of the company.

Conversely, developers need to trust that the business knows what should be built. The result is products that deliver better business value.

Scrum isn’t a silver bullet
Agile development efforts often focus on team structure, workflows and planning. Scrum teams stay busy adopting new technologies, creating user stories, refining processes and estimating the value and cadence of a sprint. Still, their efforts lack positive business impact because the organization
operates in an entirely different manner.

“Companies are approaching agile myopically,” said Dockery. “They think Scrum teams are going to solve all their problems and then they discover they’re worse off than when they were doing waterfall.”

For example, one company’s annual plan included more than 70 BI projects, all of which were active simply because the managers needed “to see progress.” Half of the projects bled over from the previous year. The other half would bleed over into the next year. None of the projects would be com-
pleted that year.

“You might think that Kanban would solve the problem, if you just prioritize work and finish it in order of priority,” said Dockery. “That way, you’d have a steady stream of accomplishments. But what we find is those accomplishments don’t always align to businesses strategy.”

The importance of agile business practices
Change is a constant that businesses have to master in today’s fast-moving economy. Their very survival and relevance depends on their ability to sense and respond to change.

“Markets change and customer demands never stop,” said Dockery. “If you want to lead, you have to anticipate new business realities, including your customers’ shifting requirements. You can’t do that if your strategy and execution don’t align.”

The best way to bridge the gap between the business and its development teams is to decompose initiatives into smaller parts so teams can adapt to changing priorities. Metrics should drive continuous improvement.

“The most successful companies meet quarterly to align strategy and execution,” said Dockery. “If you do this right you can ensure that software development aligns with business strategy. Development teams need to understand what they’re building, why they’re building it and the impact it will have on the business.”

Agile culture requires commitment
Truly agile businesses realize changes to both their strategy and culture must occur to deliver maximum value. They’re focused on continuous improvement, training their employees, measuring performance, and learning from retrospectives.

“You can’t do agile, you have to be agile,” said Dockery. “You have to think in terms of delivering customer value instead of just creating process.”

Learn more at cainc.to/how-agile-are-you.

The post Agile can’t succeed as an island appeared first on SD Times.

“Now you can use multiple levels of nested teams to reflect your group or company’s hierarchy within your GitHub organization, making your organization’s permissions structure clearer and easier to manage,” Katie Sipos, a GitHub staff member, wrote in a post.

Nested teams allow “parent” teams to have multiple “child” teams, but child teams can only have one parent team. Child teams inherit parent permissions, but membership inheritance is not automatic. “If you’re a member of Engineering and someone creates a child team called Security, team members of Engineering aren’t automatically direct team members of Security. Security and all other teams nested under the Engineering will inherit repository permissions and @mentions but nothing else,” Sipos wrote.

Teams within GitHub also allow organizations to provide certain access, permissions and mentions.

Before adding nest teams to your organization, GitHub suggests auditing each repository and its access permissions.

More information is available here.

The post GitHub gives organizations a new way to structure their development teams appeared first on SD Times.

Container adoption and the container ecosystem have been growing exponentially on the application development side, and have made their way into production and data centers, according to Roy Ritthaler, vice president of product marketing at HPE. As a result, HPE is using its technology to both build and deploy its products to help their customers manage their deployments and deliver products and software more quickly.

When talking to customers, Ritthaler said they all want several things: to become more efficient, to save money, to go faster, and to continue to innovate and transform the way the company works. The use of container technology can help customers achieve these goals, and it can give organizations the information they need to scale services and resources across the cloud, container-as-a-service, virtual and physical environments.

“[This release] allows you to ultimately deploy anywhere you want,” said Ritthaler. “If you need to deploy it on premises, you can, or deploy it to the cloud” or even hybrid environments. “That flexibility is important,” he said.

The suites included in this launch are HPE’s Hybrid Cloud Management, Data Center Automation, Operations Bridge and IT Service Management Automation. These suites are delivered via Docker containers and they are based on a container deployment foundation. Since the suites are driven by analytics, IT teams will be able to use these insights to make better business outcomes, according to the company.

Both operations and development teams will benefit from this release, according to Ritthaler. In addition to the launch of containerized suites, HPE is also boosting its Business Value Dashboard, which is a visual way of showing what is going on in the data center and in production, said Ritthaler. This is built as a container-as-a-service, so it has all the benefits of containerization, it’s easy to scale out and it is visual, said Ritthaler.

The post HPE launches containerized versions of its IT operations suites appeared first on SD Times.

DevSuite 10.0 simplifies requirements traceability through the entire life cycle, including development, testing, bug fixes and release. This feature aims to create a better user experience by ensuring that a development team’s finished product is free of bugs and has the most current functionality. DevSuite also links requirements, development tasks and test cases, which is another way companies will be able to deliver a bug-free product.

(Related: Doing ALM right means getting everyone involved)

With DevSuite 10.0, teams from QA, development and product management can work together to speed up the delivery of a company’s products. The integrated platform also includes monitoring solutions and solutions for controlling ALM in phases of definition, design, development, testing and deployment.

“Developing quality software is challenging, given the complexity of modern applications, the demand for shorter cycles and quicker deliveries, and requirements that change continuously throughout the development lifecycle,” said Jason Hammon, director of product management at TechExcel.

Some of the capabilities in DevSuite include:

• Black Theme support
• Inline editing and resizable editing controls
• Improved support for Scrum and Kanban
• Storyboard and backlog improvements
• Prioritization of stories and tasks
• Seamless JIRA integration

DevSuite also includes bidirectional traceability, which allows full traceability of code from each requirement to its final delivery. It can also integrate with third-party tools to increase quality and agility through the development life-cycle activities.

DevSuite is available now, and more information, at TechExcel’s website.

The post TechExcel’s new version of DevSuite 10.0 speeds up delivery, development appeared first on SD Times.