ValueOps by Broadcom Software delivers on the promise of value stream management (VSM) as the first to combine business and investment-oriented product management with advanced, operationally-focused agile planning and management capabilities. The integration of Broadcom’s proven Clarity and Rally Software Agile management products enables every role within an enterprise to fund, manage, track and analyze unified value streams with a consistent value orientation and methodology. Combining these leading-edge products as one comprehensive VSM solution delivers crucial insights tailored to meet the needs and requirements of each discipline. It aligns teams across the enterprise, increasing alignment, reducing inefficiencies, and improving time to value.

Atlassian offers Jira Software, a software development tool used by agile teams. As an agile project management tool, it helps teams plan, track and move work forward. Atlassian’s Jira Align extends the power of teams working in Jira by connecting business strategy to technical execution while providing real-time visibility at enterprise scale. It allows enterprises to aggregate team-level data and makes all work visible across the organization in real-time.

Azure DevOps is Microsoft’s suite of DevOps tools designed to help teams collaborate to deliver high-quality solutions faster. Agile teams can utilize the solution to plan, track and discuss work as well as use Scrum-ready and Kanban-capable boards. Other features include Azure Pipelines for CI/CD initiatives; Azure Boards for planning and tracking; Azure Artifacts for creating, hosting and sharing packages; Azure Repos for collaboration; and Azure Test Plans for testing and shipping.

RELATED CONTENT: Agile is the perfect antidote to Great Resignation, Recession

ConnectALL: ConnectALL is a value stream management company dedicated to helping customers achieve higher levels of agility, traceability, predictability and velocity. ConnectALL’s services and solutions help organizations to connect people, processes and technology across the software development and delivery value stream, enabling companies to align digital initiatives to business outcomes and improve the speed at which they deliver software. ConnectALL’s value stream management platform allows companies to see, measure and automate their software delivery value streams. 

Digital.ai is a leading platform provider for Value Stream Management, Agile planning, DevOps and source code management. Its offerings provide global enterprise and government industry leaders a cohesive solution that enables them to ideate, create and orchestrate the flow of value through continuous delivery pipelines with measurable business outcomes. 

GitLab is a single application built from the ground up for all stages of the DevOps lifecycle for Product, Development, QA, Security, and Operations teams to work concurrently on the same project. Agile teams can use GitLab to plan and manage projects with features like issue tracking and boards, task lists, epics, roadmaps, labels, and burndown charts. GitLab supports SAFe, Spotify, Disciplined Agile Delivery and more. 

Micro Focus ALM Octane is an enterprise DevOps Agile management solution designed to ensure high-quality app delivery. It includes Agile tools for team collaboration, the ability to scale to enterprise Agile tools, and DevOps management.

The Perforce Helix ALM suite provides end-to-end traceability across the life cycle. It includes modules dedicated to requirements management, test case management and issue management. In addition, it works with popular Agile methodologies like Scrum, Kanban and XP and supports traditional methodologies such as waterfall. 

Planview’s Enterprise Agile Planning solution enables organizations to adopt and embrace Lean-Agile practices, scale Agile beyond teams, practice Agile Program Management, and better connect strategy to Agile team delivery while continuously improving the flow of work and helping them work smarter and deliver faster. With Planview, choose how you want to scale and when. We’ll help you transform and scale Agile on your terms and timeline.

Plutora: Plutora ensures alignment between software development and business strategy and provides visibility, analytics and insights into the entire value stream. Plutora ensures governance and management across the entire portfolio by orchestrating release pipelines, managing hybrid test environments, and orchestrating complex application deployments.

The Scaled Agile Framework (SAFe) is the leading framework for scaling Agile across the enterprise. It is designed to help businesses deliver value on a regular and predictable schedule. It includes a knowledge base of proven principles and practices for supporting enterprise agility. 

Targetprocess: To connect portfolio, products and teams, Targetprocess offers a visual platform to help you adopt and scale Agile across your enterprise. Use SAFe, LeSS or implement your own framework to achieve business agility and see the value flow through the entire organization.

The post A guide to Agile tools appeared first on SD Times.

On top of that, all signs seem to be pointing to a recession in the US economy, which could lead to slashed budgets, layoffs, and a lot of uncertainty. A number of tech firms have already begun laying off workers, including those from their development and IT teams. 

Companies will be relying on the processes they have in place to make it through these times, and an important one to practice will be Agile. Agile enables development teams to do more with less because they focus on the work that matters and are able to eliminate unnecessary work that doesn’t help their customer or add value to the business. 

RELATED CONTENT: A guide to Agile tools

“This is the only way to avoid building stuff that is not necessary,” said Diego Lo Giudice, VP principal analyst for research firm Forrester. “And therefore the concept of minimum viable product, minimizing the product features and focusing on the ones that you really want is the best optimal way to deal with lower budgets … That minimum viable product concept helps with focusing and spending the money in the right way, for those that understand it.”

Laureen Knudsen, chief transformation officer at Broadcom, explained that the idea of ‘doing more with less’ maxed out about 10 or 15 years ago. Companies cannot place more work on fewer developers and expect good results. 

“There is no more space in our people’s schedules in which to do more. The focus needs to be on eliminating the waste to free up space so we can focus on creating more value. We need to stop looking at how to be more efficient and look at how we can be more effective,” said Knudsen. 

Though Agile is rather widely practiced at this point in time, there are still those who have yet to successfully implement it. But as 2020 showed us, people make a lot of changes when they are under pressure to do so. Think of all the changes companies had to quickly figure out in 2020: remote work, online ordering of things that didn’t have that type system in place before, and more. 

“What I saw during the pandemic is that companies that were not adopting it, they started adopting Agile because it was the only way for their distributed teams to do something,” said Lo Giudice. 

Another recession is an example of a pressure that could inspire companies to either rethink their Agile practice or adopt new parts of it they weren’t really practicing before. 

Lo Guidice also added that at Forrester their number one inquiry for the last year for the application development and delivery team has been on scaling agile. Scaling agile is something that interests companies more than other hot topics like citizen development or cloud. 

Value stream management ties multiple Agile units together

Knudsen also explained that Agile is no longer just practiced by development teams. Over the past two decades it has been spreading into other areas of business.

She said that newer companies who were born in this fully digital era don’t have any areas of the business that aren’t lean. But more established companies tend to have trouble keeping up, and she said they won’t keep pace unless they get over the idea that agility and lean principles are only for development teams.

She added that value stream management comes into play here as it allows companies to incorporate different parts of the organization and focus them around customer value. 

Lo Giudice explained that value stream management is important even if Agile has not made its way out of development. For example, for companies that have broken their development teams up into much smaller units, it can be difficult to have an idea of the investments that are being made and what impact they are having once they’re in production. 

He explained that measuring value was much easier when 200 people were all working on the same siloed app together. 

“What we need to do now is bring that simplicity back,” said Lo Giudice. “That doesn’t mean going back to siloed apps, but it means having practices, tools and technologies to help have that vision again, of where the investments that are made are generating value, and where there are impediments, and that’s what I think value stream management is going to do.”

Challenges still exist

Despite the age and prevalence of Agile as a methodology, there are still challenges that organizations run into.

One big challenge that Knudsen sees is companies not seeing their business as a system. 

“You cannot change part of the system and expect that change to have a great impact,” said Knudsen. “We still see companies pitting departments against each other using management by objectives (MBOs) of leaders, with a mistaken belief that internal competition is a good thing. It can be, but not if part of your system loses in the process. Today, those that can pivot and change to take advantage of opportunities that arise are the ones that will have success in the future.  And to do that, work, data, and funding needs to flow through your entire organization, not just your development teams.”

Another challenge is related to the process of scaling agile. According to Knudsen, companies that have a lack of understanding of agility in the first place will struggle to scale it. 

Of the companies she has seen struggle the most to scale, one common factor is that they didn’t implement agility well in the first place.

She believes in addition to having disciplined agile practices, solid automation, and infrastructure, it’s important to have an aligned understanding of how work will be planned, performed, tracked, and measured. 

“Most leaders can’t even tell me their definition of done or their release criteria,” said Knudsen. “The most successful companies scale agility through the entire organization using value streams.”

The three biggest challenges Lo Giudice sees in his research include:

1. A lack of product ownership
2. A lack of strong change management
3. A lack of commitment of product owners from the business

“When I hear these inquiries around projects going from project to product, of course they’re trying to overcome some of these challenges,” said Lo Giudice. 

AgileThought releases new Agile guides

AgileThought recently announced the release of eight technology guilds that are aimed at enabling businesses to accelerate their digital transformations through Agile. 

The guilds are groups that have domain experience that work cross-functionally in teams called Agile Squads. The eight guilds include:

1. Data and AI
2. Enterprise Solutions
3. Front-end Engineering
4. Cloud Platforms and Back-end Engineering
5. Quality
6. Design and Product
7. Cloud Operations and Cybersecurity
8. Agility

According to AgileThought, for companies to successfully keep up in times of rapid change, they need to have both expertise and an agile culture that can quickly adopt new technologies. 

“The rapidly changing digital market has provided a need for companies to react more quickly to transform their business while continuing to provide increasing value for their customers. Through our Guilds, we are bringing our business and technology experts, proven agile methodology, and customer-first approach to deliver at a rapid pace to our clients every day. This framework will also provide high-growth career paths for our employees and help deliver on the latest digital trends and innovations for our clients,” said Alejandro Manzocchi, chief delivery officer and chief technology officer at AgileThought. 

How does Broadcom help companies practice Agile?

Laureen Knudsen, chief transformation officer at Broadcom

“Broadcom leverages its enterprise-class Agile Management SaaS platform to help organizations scale Agile across the enterprise. Our ValueOps platform includes the proven Rally Software® which enables organizations to plan, prioritize, manage, track, and continuously improve work so they can deliver the value that their customers need with speed, quality, and efficiency. It also provides visibility into progress, roadblocks, and dependencies across multiple teams, projects, and programs. This allows organizations to align strategic goals to the work and create better business results—and do it all in a single system of record. It also supports hybrid methodologies and is flexible enough to allow teams to work the way they want to work. We also have a variety of services and transformation assistance to help organizations on their Agile and/or Value Stream Management journey.”

The post Agile is the perfect antidote to Great Resignation, Recession appeared first on SD Times.

Read more in this article, written by Gartner analyst George Spafford, which initially appeared on ITOpsTimes.com.

The post Agile mindset can be applied to more than just development teams appeared first on SD Times.

Developers waste immense cycles trying to avoid software failure. Rather than defining “good enough” reliability and stopping there, teams go way beyond the point of diminishing returns, building what is jokingly referred to as “gold plated” reliability infrastructure around their software. Fear of failure has instilled an all-or-nothing mindset to software reliability that is the opposite of Agile simplicity.

The reason developers overbuild for reliability — and there are many ways you can over-engineer for performance, uptime, high availability, even security — is that they never really had a way to define “good enough” reliability in the first place. Without a clear picture of success or a clear finish line, developers can’t readily communicate with the organization. The big boss wants 100% reliability, and that leads to eye rolls from engineers.

Eureka! SLOs Forever Changed What I Thought I Knew About Reliability

After Google acquired a company I co-founded, we had to re-platform the entire solution to run on Google Cloud Platform. We got a crash course in the site reliability engineering (SRE) practices that run some of the world’s most popular web services at Google. Once you experience Service Level Objectives (SLOs) as I did, you will never be the same.

SLOs are the heart of Google’s reliability engineering practice. SLOs are a math-based discipline of setting goals that model the reliability of cloud services. SLOs are an evolution of SLAs (“service level agreements”) but more fine-grained and designed for consistent slight overachievement over time that yields happy customers (as opposed to SLAs, whose violation represents a total disaster). Google uses SLOs to make better decisions in managing software and cloud services.

SLOs give developers a way to take the expected behavior of applications out of their brains and codify these outcomes so that product teams can track them.

To be more precise, SLOs take software events and set a mathematical proportion of “valid events” as a percentage of total events. SLOs are mapped to crucial application and system intervals and are representations of user success that you can modify over time. For example, a developer might set an SLO that an HTTP GET request for an API takes less than two milliseconds, 99.99% of the time. Or a developer might set an SLO for a specific user outcome to define success in a multi-part transaction (what’s a “good” success rate for a shopping cart checkout in an e-commerce transaction?). 

Error Budgets are a conceptual model for understanding acceptable risk in your services. The idea is that your team plans for (or “budgets”) some small amount of error that customers won’t notice much and “spend” that budget to make the service better. Error rates rise and fall throughout the day or month, affecting your tolerance for the additional risk. The error budget vividly expresses how to balance many competing priorities across a large-scale software organization. And you can use error budgets to trigger automation and on-call staff proactively as the foundation of your observability stack.

SLOs Fill the White Spaces Between Dev and Ops for Agile Teams

Sometimes it seems like developers and operators speak two different languages. Devs are interested in pushing code, making apps work for users, and quickly getting new ideas to life. The limit of their interest in reliability is whether they are getting woken up when their app breaks. In contrast, operators need to look at the core infrastructure and think about resource utilization, noisy neighbors, broadly applicable services for various apps, and how the overall system orchestrates to deliver constant, consistent, reliable value to customers.

The work not done by the developer creates a need for gold-plated infrastructure from the operators. The conversation not had between dev and ops leads to a disconnect in designing the services (for customers to be happy) and the engineering system (for engineers to be productive). 

The main benefit of SLOs is that you know you can focus resources on your most critical services because you understand what degree of un-reliability is OK for the lower impact areas. Counterintuitively, by lowering reliability goals where it matters less (basically any time the user is likely to blame their internet connection), you can focus on what matters. The work not done by the service in less critical areas allows for increased resiliency — from engineering and cloud capacity — in the essential purpose of our customers, as defined by SLOs.

SLOs are the language for this conversation that’s been missing, and these are the decision points that allows developers and operations to navigate around software reliability:

New Features Versus Technical Debt

Agile teams face a constant decision-point on new features versus settling technical debt that may be causing customers pain. When is the right time to go spend months refactoring code that is not optimized? How do you know you aren’t spending cycles on a problem that currently isn’t even giving users pain? If you have modeled an SLO, you have a clear compass for making that decision.

Complex Workflows Without a Definition of ‘Success’

Many user journeys today traverse multiple APIs and multiple steps within your applications. Password reset is the canonical example that the SLO community calls out to describe why these are problematic to model success in any “five nines” type of way. A password reset is contingent on the user entering their email correctly, the reset email not getting caught in a spam filter, the transactional email systems working correctly, and the user completing the process. You may find that for your “forgot password” system, 70 percent is the general expected success rate. And there are countless examples of this type of complicated workflow where you can’t just look at the metrics of the individual systems; you have to look at the totality of the user experience and define success rates that describe user happiness. SLOs allow you to codify the expected outcome and to adjust that outcome success rate upwards or downwards based on the data you are getting.

Guardrails for What You Can’t Test 

Testing is great, and testing isn’t going away. Unit testing, end-to-end testing, and integration testing all have their place in the software development lifecycle. But the reality today is that you simply cannot test every scenario in dev or staging in a way that will cover all the unforeseen ways that things break in production. SLOs give you another guardrail around your systems in production that lets you see through all the beeps and pages from APM and logging tools to get to the essence of whether your software is behaving in expected ways.

Dependencies Between Teams

A really popular target for SLOs is APIs. SLOs allows you to define the latency or other performance vectors of the APIs you create. If the quota you set is 10ML of latency for your API, but something changes in a system that brings that up to 50ML of latency, SLOs give you a method of seeing which team violates the Error Budget for that SLO. This tradeoff makes SLOs an excellent fit for the “self-organizing teams” principle of Agile, where teams need ways to move independently while also understanding how their work is impacting other groups.

The Work Not Done is Getting Started

I’ve talked with countless organizations frustrated with over-building reliability, but they can’t get out of that mindset because they feel so inundated with critical issues. They’ve got so much technical debt that they can’t stop digging. 

If there’s one thing I recommend to everyone, it’s to start thinking about how to benchmark your users’ expectations based on how your service works today and figure out what truly matters to them. Having wrong SLOs and iterating is infinitely better than having no goals and waiting to decide what is most critical. Better to get ahead of making your service work for users before they vote with their feet. 

Don’t put your customers and engineers in the gilded cage of the reliability work not done or even started.

The post SLOs: The heart of reliability practices appeared first on SD Times.

While Agile Lineout is designed to operate for non-software teams, the framework was developed with the help of novice development teams. According to Ward, the idea behind Agile Lineout came from projects he ran with these development teams using tools from W. Edwards Deming’s book, “The System of Profound Knowledge,” in combination with systems theory. After seeing the progress these teams made when employing these strategies, Ward started to consider how this method could work for non-software teams as well. Ward explained, “As a coach I constantly get asked questions like: ‘I work in marketing, I don’t do software but could Agile help me?’… And so we’ve started to use it in a non-software way and it really works.” 

According to Ward, he combined knowledge from his experience with development teams and Scrum Masters to then build out the Agile Lineout framework around non-software teams. “What I’ve done is try to learn from the software teams and then mirrored that,” he explained.

Agile Lineout helps non-software teams take three elements into consideration: defining and producing the outcome required, deciding how best to produce that outcome, and organizing so that they can work effectively as a team. It does this by taking tools from Agile’s software development team framework and pairing them with relevant management theory to help non-software teams better understand what they need to do. 

Agile Lineout  is designed in a way that makes it adaptable for several different non-software teams. Since it is rare for these kinds of initiatives to be identical, Agile Lineout operates contextually. This method enables teams to make informed decisions regarding what they need to do or change for each iteration. As the team continues, they build off of feedback from shareholders and the project adapts and transforms through the learning process.

Agile Lineout encourages teams to explore and evaluate what they must do to improve effectiveness by explaining the theories being applied to the project. This allows a team to experiment and continuously learn new things.  

The post Agile Lineout framework helps diverse types of teams appeared first on SD Times.

In recent months, Mozilla has also announced three Common Voice fellows, a $3.4 million investment to fuel work in East Africa, and a partnership with NVIDIA.

“By giving individuals the ability to share their speech, we can help ensure all communities have access to voice technology and the opportunity it unlocks,” said Hillary Juma, the Common Voice Community manager. 

Dataiku raises $400 million in Series E funding

The recent investment brings Dataiku’s total valuation to $4.6 billion and the company said it will use the funding to systemize the use of data for exceptional business results.

Dataiku enables companies to leverage one end-to-end platform to design, deploy, and manage AI and analytics applications, and facilitates using prebuilt components and automation wherever possible.

“Organizations that use Dataiku elevate their people – whether technical and working in code, or on the business side and low- or no-code – to extraordinary, arming them with the ability to make better day-to-day decisions with data,” said Florian Douetteau, the co-founder and CEO of Dataiku. “This latest round of funding is a proof point that everyday AI is the future, and we’re excited to help many more companies realize its benefits.”

Parallel Agile releases new version of CodeBot

The team at Parallel Agile announced a new version of CodeBot, a low-code MERN stack application generator, which connects screens to databases and provides an extensive library of UI components.

“Fundamentally, the benefits of an agile approach to development derive from running a feedback-driven project, where there are no long delays before working software can be tried out by project stakeholders,” said Doug Rosenberg, the CEO of Parallel Agile. “CodeBot’s ability to generate and deploy a working application in a few minutes compresses sprint time from a couple of weeks to a couple of hours – and faster iterations enable the project to be more feedback-driven.”

CodeBot uses domain models and wireframes to automatically build an enterprise application that includes a scalable, secure REST API, MongoDB database schema, Java client library, and more. 

Microsoft expands support with Eclipse Foundation

Microsoft announced that it is expanding its support for the Eclipse Foundation AISBL as a Strategic Member.

“Microsoft is committed to Java developers and the health of the Java ecosystem, actively participating in Eclipse Adoptium (formerly AdoptOpenJDK) and other projects,” Stephen Walli, the principal program manager at the Azure Office of the CTO, wrote in a blog post. 

Microsoft is interested in participating in new Eclipse Foundation projec.ts such as Eclipse Dataspace Connector and Eclipse Tractus-X.

Checkmarx acquires Dustico

Checkmarx announced that it is acquiring Dustico, a SaaS-based solution that detects malicious attacks and backdoors in open source software supply chains. 

Through the acquisition, Checkmarx will combine its AST capabilities with Dustico’s behavioral analysis technology to offer customers a unified view into the risk, reputation, and behavior of open-source packages. 

Additional key features of Dustico include advanced machine learning and threat intelligence, ahead-of-time analysis and a developer-first approach. 

Additional details are available here.

The post SD Times news digest: Mozilla Common Voice adds 16 new languages and 4,600 new hours of speech, Dataiku raises $400 million in Series E funding, Parallel Agile releases new version of CodeBot appeared first on SD Times.

Enterprises can transform the way they develop and deliver products and services by reimaging customer journeys. 

“Forward thinking firms are now evolving to a product centric operating model to ingrain customer centricity, business agility and innovation in the fabric of their organizations. Building product management and experience design capabilities are becoming the need of the hour,” said Ravi Kumar S, president of Infosys. At Infosys, we leverage our wide range of Enterprise Agile DevOps platforms, expertise, and tools to help clients create new ways of collaboration, orchestrate, and deliver products and solutions against robust business outcomes.”

Algolia announces Series D funding

Algolia announced that it received $150 million in Series D funding that the company will use to scale, serve the increased demand for the company’s Search and Recommendations products, and fuel the company’s continued global expansion into adjacent markets and use cases.

“Algolia helps power developers’ search and content discovery capabilities with an API-first approach that can be applied to SaaS applications and e-commerce, as well as enterprise applications across industries,” said Mala Gaonkar, portfolio manager and managing director at Lone Pine Capital. 

Algolia provides an API platform for dynamic experiences that enable organizations to predict intent and deliver results.

Ampere to acquire OnSpecta 

Ampere announced its intent to acquire OnSpecta to accelerate AI inference on cloud-native applications. 

The OnSpecta Deep Learning Software (DLS) AI optimization engine can deliver significant performance enhancements over commonly used CPU-based ML frameworks. 

“The addition of deep learning expertise will enable Ampere  to deliver a more robust platform for inference task processing with lower power, higher performance and better predictability than ever. This acquisition underscores our commitment to delivering a truly differentiated cloud native computing platform for our customers in both cloud and edge deployments,” said Renee James, founder, chairman and CEO of Ampere Computing.

Blue Prism announces integration with Alteryx for better data analytics

The new integration will merge analytics automation and robotic process automation to drive better business outcomes. 

Blue Prism developers can include an Alteryx analytic process within their RPA driven processes via the Alteryx Visual Business Object (VBO) for Blue Prism Process Studio, adding robust analytic and machine learning intelligence to their digital workers’ actions.

“Pairing Alteryx with Blue Prism’s intelligent automation improves the quality of data extracted, enabling customers to use data automation across the entire enterprise, facilitating smarter and faster decisions. This is critical for future-focused businesses that want to remain agile, productive and competitive,” said Nitin Brahmankar,  global vice president of ISV and ecosystem partnerships at Alteryx. 

The post SD Times news digest: Infosys unveils new Enterprise Agile DevOps capabilities, Algolia announces Series D funding, Ampere to acquire OnSpecta appeared first on SD Times.

As many organizations look to transition to a hybrid remote work culture, development leaders are wondering if it will be possible for their teams to maintain effectiveness when working outside of the office long-term. Agile teams are inherently self-organizing and adaptive to change, but application technical professionals must maintain a strong team culture of close collaboration, feedback loops and dynamic interaction to stay effective in a remote environment. 

RELATED CONTENT: Developers reflect on challenges, feelings about remote work in pandemic year

To maintain a successful and efficient remote work team, software development leaders can champion six best practices:

1. Review the situation

First, review your remote team situation. Because we have lost the benefits of colocation, where constant interaction, easy pairing and water cooler conversations aid teamwork, we need to address collaboration in other ways. 

Set the tone in a remote environment by arranging a video conference with your team to outline how you communicate and collaborate when working remotely, evolve your team culture to solve remote challenges and adapt the way you work. Hold another video conference with your product owner to align the team on the product, vision and strategy. These video conferences help empower a team by agreeing to new ways of working and reinforcing purpose.

Every problem is a people problem — or at least, it has a people solution. Evaluate the degree to which your team possesses the essential skills for working together in a remote environment, which should include complex problem-solving abilities, critical thinking skills, creativity, flexibility and strong judgement. 

2. Engage as a team and focus on culture

Remote working is a skill that requires time and effort to develop. Video conferencing is a great way to engage with your team, but how many times have you been in a video conference with your camera off, your microphone muted, checking your email or even making a cup of tea? 

Reinforce simple rules for video conferencing etiquette, including:

• Be present. If you do not feel the meeting has value for you, decline the invite. If you do attend, be attentive and leave your camera on.
• Be human. Don’t be concerned that your children, significant other or pets will invade your picture. Welcome this, as it shows that you’re human and face the same challenges as everyone else. Stay on mute if you’re worried about interruptions. 
• Be part of the team. If it’s a team call, don’t mute it. Team members want to hear feedback. Keep team lunches or after-work drinks on the schedule to maintain team culture — and leave your camera and microphone on, eat on the call and invite your family around to say hello.

Culture is frequently viewed as a barrier to effective collaboration, and this becomes more challenging when working remotely. Here are a few ways to improve your remote work culture:

• Facilitate a short team workshop to evaluate your company’s values and align work to those values. 
• Act in a manner you would like to see. Culture is what you say and what you do. 
• Agree on values and a team charter to guide conduct and provide behavioral nudges. 
• Demonstrate personal cultural leadership by committing to following these guiding values every day. 

3. Maintain momentum 

As development teams, we must continue to deliver value while working remotely, and this may require some process tinkering. Make adjustments at every phase of the software development life cycle to be inclusive, build trust and ensure that everyone is heard.

We sometimes forget that the reason we do the work is to solve a problem for our end users. Working remotely adds another barrier between product teams and the people they support. 

To address this, we must refocus on helping the people who use our products to solve their problems. Get closer to your customers, understand the work they wish to accomplish and help them to achieve it.

4. Foster openness and transparency 

We must build trust in our remote teams based on mutual understanding and respect. Encourage openness with weekly remote lunch events and virtual coffee breaks. Discuss everyday life, build empathy, form connections, and be clear on your intentions and reasoning. 

Fostering transparency builds trust, which enables team members to take risks, admit mistakes, rely on each other and improve together. Be understanding and empathetic when working with your team, but don’t value politeness over progress. Challenge behaviors that conflict with your remote working agreement and highlight potential issues early. Communicate openly, using reply-all on team emails and raising questions in your collaboration tool so everyone can contribute.

While remote, we must also continue to validate our work with real customers. Fast feedback is essential to enable agile teams to make rapid decisions and focus on the right features. Without in-person user testing, we must rely on technology solutions. Video calls, surveys and usability testing are all ways to receive quick feedback. Everyone on the remote team should be involved with user testing to create a shared understanding and a better product experience.

5. Leverage technology 

Effective remote teamwork requires close collaboration over multiple open channels with individuals skillfully moving between technology tools. Developing good communication and collaboration habits is a great start, but remote development teams must create a shared virtual space to succeed. 

Match collaboration tools to desired behaviors to create a common toolset, form a sense of community and maintain trust through team connection. Identify tools that can support the way your team works while prioritizing face-to-face interactions. Technology is rarely the answer, but it does provide the right platform to enable conversations. 

Shifting to cloud-hosted development environments can also increase the team’s agility and resilience through flexible, shared and always-available environments. Fully cloud-hosted development environments offer code, build, test and debug capabilities. Teams that have already moved to a cloud-hosted development environment are realizing their value in a remote workplace.

6. Evolve your remote team practices

The agile process is built on the three pillars of the empirical process: transparency, inspection and adaption. We must use these to continually evolve our working practices to improve the outcomes we produce for our customers. 

Disruptive change is stressful. Keep communication lines open, schedule one-on-ones, check in on people — but most of all, be kind to yourself and others. Your process modernization must be matched by a change to the way you organize your work. Your customers are unlikely to care about your process or product — they are more concerned about resolving their challenges and getting their jobs done. Your product is more likely to succeed if it aligns with their values and provides the best way to achieve their goals. 

These six best practices of the remote team framework can help you reassess how to help remote employees remain effective. This framework has proven successful in supporting remote product development teams and improving how they operate.

Gartner analysts will further discuss application innovation and software engineering strategies at the Gartner Application Innovation & Business Solutions Summit 2021 taking place virtually May 26-27 in the Americas.

The post Analyst Watch: Succeeding as a remote Agile team appeared first on SD Times.

The approaches that have gotten us this far have stalled. Instead of adding people to a team, in order to grow we need to look differently how people, already in a team, work together.

Before we dig into that, let’s look at the story so far.

The Waterfall model was essentially the first project management method to be introduced to the software engineering industry. At the time, software was just a small part of larger infrastructure projects. 

RELATED CONTENT: Agile at 20: Where it’s been and where it’s going

Due to the rigidity of specifications for those projects, there was little room for variation in the process. Any changes made to the specifications during development would have resulted in high costs, so the very rigid and structured approach of Waterfall worked well.

As software became more prominent in business use, and ultimately personal use, there was a rise in the number of much smaller software applications. This, in turn, resulted in a rise in the number of software companies creating such applications, and a rise in the issues with the rigid and deterministic approach of Waterfall.

Agile was born out of the need to address these challenges. Software teams identified that it was far more useful to have a process that could respond to changes in customer requests, and to get something basic working quickly, and then adjusting and iterating from there. 

Sprints, the most applied aspect of Agile development, enabled software companies to create value for customers much quicker. It also enabled teams to be more responsive and reduce the amount of rework that resulted from changing specifications.

And here we are in the present times. Despite the evolution of software development approaches through the years, and the benefits that have come with it, issues that arise from team and organization growth remain unresolved. 

So, what is going on? 

Let’s take a small development team and follow them as they scale. 

Our dev team, part of a start-up, has five developers. Of the five, one is an extremely experienced senior developer, another couple are senior devs, and the last two are juniors with far less experience. Before the juniors came on board, the three senior developers would coordinate themselves and just get on with it. But as the team has grown, they have needed to add a bit more structure into their sprint planning and execution, so that the whole team had plenty of work to do for the fortnight. 

As well as this, the most senior dev started to spend his time assisting the two new juniors. Naturally, this limits the other work that he can do. 

Coincidentally (or perhaps not a coincidence at all) two new pressures have arisen: to produce more features; and, at the same time, to fix up the quality based on the bugs resulting from the new developments. Our most senior dev, who has become the de facto team leader, complains to the founder about needing more assistance. They are, of course, old mates who have been in the business from the start, so convinces the founder to authorize more hires. 

At this point the team has a real structure and is sure to plan out everyone’s work to ensure they’re getting the most out of the team. This growing team requires a fair amount of the senior dev’s time, but that’s to be expected to keep the machine running. On top of this, the founder gets calls with ‘urgent’ customer requests and ignores the sprint load to expedite them into the senior dev’s workload.

Back to the question: What’s going on? Why would teams all over the world do this?

These issues don’t arise from malice and they certainly don’t arise from stupidity (given the calibre of minds involved). Instead, they come from two assumptions we make about how teams should operate.

Firstly, we assume all team members’ contribution is equal. At the end of the day there is no “I” in “team” and we all do our bit around here. 

This assumption is evident in the way we plan work. We hold planning meetings where everyone has a say in what work they should be doing. The focus in these planning meetings is on the inputs and an even spread of load, rather than on the output of the team. 

Secondly, we assume time not working is wasted time. The more everybody does, the more we get done as a team. Right?

This becomes obvious in situations where we have a team member who has an hour to spare in a day. Instead of being comfortable with letting that team member twiddle their thumbs, we will find something ‘more useful’ for them to do. Maybe start investigating a quick bug fix? 

These assumptions are based on reasonable efficiency drivers we have as human beings, but these assumptions don’t apply effectively to software teams.

Let’s examine them more deeply!

1. All team members contribute equally to the output of the team 

Every team has one person who is the most skilled person in that team. This gap in the skill level is magnified by their experience with the code base and the product, which creates a very large discrepancy in value of the code that is written by them, as opposed to that written by the most junior person. This does not mean that junior devs are not valuable, but instead it simply clarifies the type of work, and the value-add that is able to be done at each tier of seniority.

This is crucial because, by default, the most skilled senior dev acts as the bottleneck for the work the team can deliver as a whole, and even more so for the high value work the team can deliver, which leads us to conclude that NOT all members’ contributions are equal.

2. Idle time is a waste of time

A team of people working together is not like swimmers in a pool, each swimming in their own lanes. There are many interdependencies in the work the team members do, which means we will never have an even load across a single sprint, and some people will be idle from time to time. Forcing an even load is planning to fail.

If the first assumption is wrong, and not all team members’ contributions are equal, we should then be maximizing the contribution of the most skilled resource. This may be done in many ways, one being that they are idle for 30 minutes in between tasks because picking up another task would make them late to do a handover to the bottleneck resource.  

Sometimes, not working is the best contribution a team member can make!

How do we fix this?

The answer is conceptually simple, but much harder to implement. 

What the team needs is more capacity for the bottleneck end of the bottle (the most senior dev), not for the body of the bottle (the team as a whole). By increasing the capacity of the body, we are just putting more strain on the bottleneck, as opposed to focusing on widening the bottleneck, which increases the output of the whole team. 

So the answer is to coordinate more effectively around the bottleneck, then to protect the team’s work from the impact of variation, and finally to accelerate the flow of work through the team. These three initiatives make up ‘Pace,’ an Agile-friendly framework that replaces Scrum in many teams. To take something tangible from this article, here are 4 immediately applicable Pace rules to minimize bottlenecks and maximize team performance:

1. Ensure there is a steady supply of work for the bottleneck

• As the bottleneck controls our output, and time lost from the bottleneck is lost for the team, we ensure there is always valuable work for the bottleneck.

2. Offload the bottleneck from unnecessary tasks

• All work that can be done by others is assigned to them, freeing the bottleneck to only do work they must do. Check for the efficiency trap of planning tasks for the bottleneck because they are faster.

3. Plan others’ work around the bottleneck

• The bottleneck’s work (including others’ work that requires the bottleneck) is planned first. Then, others’ work which does not interact with the bottleneck’s can be planned.

4. Ensure quality inputs into the bottleneck

• To minimise the risk of bottleneck rework, extra quality steps such as tests or checklists are introduced immediately before the bottleneck.

Pace applies these proven rules and ensures they produce significant benefits – almost instantly, and certainly over the longer term.

The post Scaling up Agile requires a change of Pace appeared first on SD Times.

“Far too many teams that claim to be ‘Agile’ are not. I’ve had people — with a straight face — tell me they are ‘Agile’ because they do a few Scrum practices and use a ticketing tool. There is an awful lot of misunderstanding about Agile,” said Andy Hunt, one of the authors of the manifesto and co-author of the book “The Pragmatic Programmer.”

According to Dave Thomas, co-author of “The Pragmatic Programmer” and the Agile Manifesto, just the way Agile is used in conversations today is wrong. He explained Agile is an adjective, not a noun, and while the difference may be picky, it’s also really profound. “The whole essence of the manifesto is that everything changes, and change is inevitable. And yet, once you start talking about ‘Agile’ as a thing, then you’ve frozen it,” said Thomas.

However, Alistair Cockburn, a computer scientist and another co-author of the manifesto, believes that Agile being misunderstood is actually a good thing. “If you have a good idea, it will either get ignored or misinterpreted, misused, misrepresented, and misappropriated…The fact that people have misused the word Agile for me is a sign of success. It’s normal human behavior.”

What is Agile?

One thing that is missing from the Agile Manifesto is an actual definition of Agile. In one of Hunt’s books, “Practices of an Agile Developer,” he defined Agile development as an approach that “uses feedback to make constant adjustment in a highly collaborative environment.” 

“I think that’s pretty much spot on. It’s all about feedback and continuous adjustments. It’s not about standup meetings, or tickets or Kanban boards, or story points,” said Hunt. 

But Thomas believes there is a good reason a definition wasn’t included in the manifesto, and that’s because Agile is contextual. “Agile has to be personal to a particular team, in a particular environment, probably on a particular project because different projects will have different ways of working,” he noted. “You cannot go and buy a pound of Agile somewhere. It doesn’t exist, and neither can a team go and buy a two-day training course on how to be Agile.”

Thomas does note he doesn’t mind Hunt’s definition of Agile because you have to work at it. “None of this can be received knowledge. None of it can be defined because it’s all contextual. The way of expressing the values that we had was so powerful because it allowed it to be contextual,” he said. 

Dave West, CEO and product owner at Scrum.org, believes the real reason people don’t understand Agile is because of social systems, not the practice, the actual work or even the problems they are looking to solve. “Over and over again, we see this sort of pattern that agility is undermined not by the work, not even by the skills of the practitioners, but by the social systems and the context that those practitioners are working in…Bosses want to know when something is going to be done, but when you ask them what it is they want you to deliver, they can’t tell you that…but they want to know when it is going to be done,” he explained. 

If we really want to take the opportunity that Agile presented, we need to change the system agility runs within, according to West. For instance, he said while Fidelity was one of the first companies to ever do Scrum, they are still wrestling with the ideas around it today because they didn’t necessarily change the way they incentivize people.

It’s about the core principles

To get back to the true meaning of Agile, we need to get away from the terms and get back to the four core principles, according to Danny Presten, founder of the Agile.ai community.. Delivering incremental value, having a good look at the work, being able to prioritize and improve cycles is “what really makes Agile hum. It’s not the terms. The more people get focused on the principles and the less they are focused on the terms, the better Agile will be,” said Presten. 

A great starting point for teams that have only experienced waterfall or haven’t had as much success with software delivery is to start with Scrum, according to Hunt, but it should only be used as a starting point. “Modern Agile thought goes much further than Scrum, into true continuous development and delivery, committing directly to main many times a day… the goal has always been to shorten the feedback loops, to be able to change direction quickly, to leverage the team’s learning,” Hunt continued. 

Presten compared learning to be Agile with learning to play an instrument. “As you start out, you read the sheet music. It helps make momentum happen for you and gives clarity, but if it stops there and all we do is mindlessly read the sheet music and go through the motions, then there’s a problem,” he said. 

A good way to look at it is to look at how much feedback you are getting and when you are getting it, said Thomas. “The only way to be Agile is to be constantly adapting to your environment. Sometimes that can be minute by minute, sometimes it’s day by day and sometimes it’s week by week, but if you’re not getting feedback as often as you can, then you are not doing Agile,” he said. 

Cockburn explained there have been three waves of Agile. The first was at the team scale, then Agile started to move to the organization scale, and now we are in the third wave which is at a global scale. The global scale includes finance departments, HR departments, legal departments, entire supply chains, governments, social projects, distributed teams and even different geographies. “It’s not just teams. In fact, it’s not merely organizations. It’s not merely software. It’s not really products. It’s global adoption,” said Cockburn.

Cockburn went on to explain that the reason Agile is being looked at on a global scale is because of VUCA: volatility, uncertainty, complexity, and ambiguity. He said the world is “VUCA” and that became even more evident with COVID, the lockdowns and the distributed ways of working for every person, team, industry, company and event country. Everyone needs to have the ability to move and change direction quickly with ease, he said. 

“This is the new and current world. It is happening. Agile long ago stopped being only about software; it is now completely general. One can look at those values and principles and extrapolate them to any endeavor,” said Cockburn. 

Looking back at the manifesto

The Agile Manifesto was created to uncover these better ways of working, developing and delivering software. It includes four core values and 12 principles.

From Feb.11-13, 2001, 17 thought leaders met at the Snowbird ski lodge in Utah to try to find some common ground on software development. That common ground became known as the Manifesto for Agile Software Development. At the time, those 17 software developers had no idea what was to come from the industry or how Agile would even play out over the next 20 years.

“The Agile Manifesto fundamentally changed or incrementally changed how people approached work and focused on the customer,” said Dave West, CEO and product owner at Scrum.org. “Twenty-five to thirty years ago, I worked for an insurance company in the city of London and we didn’t care about the insurance. We didn’t care about the customer. We just wrote code on the specs. The fact that today we have customer collaboration, the fact we now respond to change, all those behaviors have resulted in a lot of fabulous software.”

The world, however, is very different from when the Agile Manifesto was written that it has some wondering if it still is relevant in today’s modern, digital world. 

According to Robert Martin, one of the authors of the Agile Manifesto and author of “Clean Agile: Back to Basics,” the manifesto itself is just a marker in time. “It does not need any augmentation because it is not a living, evolving document. It is just something that was said 20 years ago. The truth of what was said in the document remains true today,” he said.

Fellow manifesto co-author Dave Thomas believes that the manifesto actually applies even more today as software is moving faster than ever, people are adapting to remote work, getting feedback and adjusting as they go. “It’s becoming clear you can’t plan a year out anymore. You are lucky if you can plan a month out, and so you are constantly going to be juggling and constantly going to be reprioritizing. The only way to do that is if you have the feedback in place already to tell you what the impact is going to be of this decision versus that decision,” said Thomas.

If they could go back…

If Thomas had a chance to go back in time and change anything about the manifesto, he said he would remove the 12 principles and just leave the four values in it because they dilute the manifesto and give an idea that there is a certain way to do Agile. “I would make the manifesto just that one page and then possibly just because it may not be obvious to people, explain why it doesn’t tell you what to do,” he said. 

Peter Morlion, a programmer dedicated to helping companies and individuals improve the quality of their code, believes the 12 Agile principles are still relevant today. “That’s because they’re based on economic reality and human nature, two things that don’t really change that much. If anything, some principles have become more radical than they were intended to be. For example, we should deploy weekly or even daily and we can now automate more than we imagined in 2001. On the other hand, some principles have been given a different meaning than we imagined in 2001: individuals no longer need to be in the same room for effective communication for example,” he recently wrote in a blog post. 

Because of Agile, we have been able to adapt to those principles, and while we can’t be face to face in the wake of the pandemic, we can do video calls because of the software that was influenced by the idea of Agile, Agile.ai’s Presten explained.  

If Presten were present at the Snowbird meeting back in 2001, he said he would probably give a hat tip to what outcomes can be expected from Agile, so that those principles can be mapped back to those outcomes to help people understand the what and why of Agile. “I am finding a lot more success and getting value from Agile by setting organizational goals like ‘hey, we want to get better at predictability,’ and then taking steps to get better,” he said

Scrum.org’s West, who was not one of the original authors of the manifesto, believes one thing the manifesto was very quiet on was how you measure success and feedback to inspect it, adapt it and improve it. There are a number of new initiatives coming out to provide organizations with better outcomes such as value stream management and BizOps. According to West, one thing these approaches and Agile all have in common is inspection and adaptation, and the idea of rapid feedback loops and observation. He thinks any of these approaches will help. If you are a software engineer, the Agile Manifesto may be better to look at. If you are on the business side of things, the BizOps Manifesto might be a better start, but ultimately he said to begin with the customer, the problem and the outcome you seek. 

Looking back at the manifesto, co-author Hunt said if he had a chance he would add a preface to it that explains Agile is not Scrum. “Scrum is a lightweight project management framework. Agile is a set of ideals that a method should support. They are not the same, and you could argue that Scrum is not even all that Agile; it’s more like a mini-waterfall. Twenty years ago maybe we could wait weeks for feedback. Today, typically, we cannot,” he said. 

Thomas would also add something about respecting individuals over respecting the rules in order to reflect that it is not the organization’s job to tell individuals how to behave; it’s their job. In retrospect, he also would have liked to have had a more diverse group of people involved in the manifesto. Cockburn, though, noted that if anything inside that room 20 years ago had been different, if anyone else would have been added, the outcome would have been completely different and it probably would have been more difficult to come to an agreement. 

What Cockburn would change about the manifesto is the wording of responding to change over following a plan. “The discussion we had was that the act of planning is useful. [When] the plan goes out of date, you have to respond to change. People, especially programmers, use it to mean I don’t have to make a plan. I don’t have to have a date. And that’s just flat incorrect. There’s no way to run a company if you don’t have dates, prices and budgets,” he said. 

Agile.ai’s Presten added: “I’m just so grateful for the founders, the folks in Snowbird and what they created. It really made the world a better place…It’s changing the world that we live in for the good, and then also the culture that it is creating at the companies we work at where decisions are getting decentralized. People are able to come in and grow and learn and fail fast to succeed, and having that safety net there has been a really cool thing, so I’m just super grateful for the founders and the work they did, kind of putting their neck on the line. I think we’ve all benefited from that.”

Technical Agile

While it is normal for ideas to get diluted over time, Robert Martin, one of the authors of the Agile Manifesto and author of “Clean Agile: Back to Basics,” believes that the meaning of Agile has become more than just diluted; it has lost its way. 

He explained that Agille was originally developed by programmers for programmers, but after a couple of years there was a shift to bring Agile to project management. 

“The influx of project managers into the Agile movement changed its emphasis rather dramatically. Instead of Agile being a small idea about getting small teams to do relatively small projects, it turned into a way to manage projects in some bold new way that people could not articulate,” Martin said. 

Martin explained that the original goal at the Snowbird meeting, where the Agile Manifesto originated, was to bridge a divide between business and technology, but the business side took over the Agile movement and disenfranchised the technical side. 

He said at one point the Agile Alliance tried to throw a technical Agile conference in addition to its annual Agile conference, which reinforced the idea that Agile fell off course. It was held twice — in 2016 and 2017 — and then discontinued.

“What we see today now is Agile is very popular on the project management side and not very popular on the technical programming side,” said Martin. “There are remnants of technical Agile such as Test-Driven Development and refactoring, but that’s prevalent in the technical community and not the Agile community.” 

“Does the Agile Manifesto help the project management side of things? Yes of course, because about half of Agile was about project management, but the other half — the technical side —  that part fled. And so the project management side of Agile is now lacking the technical side and in that sense, it has not been a good evolution from the early days of the manifesto till today. It has been a separation, not a unification. I’m still waiting for that unification,” he added.

He explained without that unification, there will be an increasing number of software catastrophes. “We’ve already seen quite a few and they have become fairly significant. We’ve had the software in cars lose control of the cars, kill dozens of people and injure hundreds of people. There have been a number of interesting lawsuits paid out because of that, just a software glitch has done that. We’ve heard trading companies lose half a billion dollars in 45 minutes because of software glitches. We’ve seen airplanes fall out of the sky, because of software that wasn’t working quite right and this kind of failure of the software industry is going to continue.” 

If the business side and technical side of software development cannot be united again, Martin predicts the government will eventually step in and do it for us. 

“We cannot have programmers out there without some kind of technological disciplines that govern the way they work, and that’s what Agile was supposed to be. It was supposed to be this kind of governance umbrella over both project management and technology, and that split. Now many [technologists] are free to do what they want without any kind of discipline,” said Martin.

“My hope is that we could beat the government there and that we can get these two back together before the government acts and starts legislating and regulating because I don’t trust them to do it well. ” Martin added.

The post Agile at 20: Where it’s been and where it’s going appeared first on SD Times.