Today: why both Microsoft and Google are enjoying renewed cloud growth, HashiCorp's short ride as a public company comes to an end, and the latest enterprise moves.
Today: C3 AI chairman and CEO Tom Siebel on the good sides and bad sides of AI, Microsoft introduces a small large-language model, and the latest funding rounds in enterprise tech.
Certainly, the generative AI craze has been good for C3 AI, but according to chairman and CEO Tom Siebel, it also has the potential to go to a really dark place.
The premise behind the Agile Manifesto is that developers, the users they serve, and business stakeholders all benefit by working together. But too often, organizations are faking true change by plastering a new label on older software development practices.
Many programming teams follow the Agile Manifesto, a set of software-team management principles meant to improve quality and user happiness. Among those principles: Deliver value frequently, maintain a sustainable working pace, keep it simple, and regularly reflect and adjust your development practices to boost effectiveness.
The premise is that developers, the users they serve, and business stakeholders all benefit by working together. Agile developers work iteratively, creating functional software bit-by-bit and confirming that the result meets expectations before moving on to the next step in the roadmap.
The practice has become exceedingly popular in development communities. According to a State of Agile survey released in January by software development company Digital.ai, which collected information from 788 tech workers, 69% of respondents said their IT, software development, and delivery teams use agile methodologies today.
But too often, organizations are faking true change by plastering a new label on older software development practices such as waterfall, the faults of which inspired the Agile Manifesto in the first place. And if their “adjustment to agile” doesn’t work, those organizations conclude that implementing agile practices was a waste of time.
“Agile offered a powerful lens on the importance of communication, collaboration, iteration, and adaptation,” explained Elizabeth Bacon of Devise Consulting, who embraced the Agile Manifesto on its release in 2001. However, as she pointed out, people are uncomfortable operating in ambiguity. Their uncertainty leads them to want to nail “truths” to the wall. “Thus some ‘best practices’ become ‘ceremonies,’ and then those ‘ceremonies’ become ‘This is the way it must be.’”
In pursuit of those truths, many companies wind up codifying policies and practices that deviate from the original goals of agile development. The longer that goes on, the harder it is to correct.
Agile is about clear communication, empowering individuals to act, and minimizing sunk costs such as time, said software architect Michael Richmond. And it requires the acceptance that any project of significant length will have to deal with change during its execution.
Agile methodologies may have their weaknesses — which includes conveying “what agile is” to the people who are meant to implement and use it — but too many companies, comfortable with the way things have always been, fail to follow its guidelines. Manifesto signatory Ron Jeffries captured the issues splendidly in his 2006 essay, “We Tried Baseball and It Didn’t Work.”
According to the State of Agile survey, 47% of survey respondents blame agile “failures” on a generalized resistance to organizational change or culture clash. Other factors include failures in leadership participation, management support, and business teams’ understanding of what agile does or could do.
Management rarely knows what developers are doing, so they reward the appearance of work.
The result? Meetings that don’t follow the agile practices, sprints that are poorly organized, and end users — for whom the application is being built — left on the sidelines.
Management rarely knows what developers are doing, said Gerald M. Weinberg, author of The Psychology of Computer Programming, at a 2005 Agile conference, “so they reward the appearance of work.”
Inside companies following the agile development process, team members meet daily to discuss progress, synchronize tasks that are underway, and identify blockers. The gathering, sometimes referred to as a “scrum,” is supposed to be so short that participants are comfortable doing so standing up.
Yet large bureaucracies sometimes interpret this as, “Oh goodie, another meeting!” According to Alex Adekola, CEO of Remove My Mugshot, “Standups turn into status meetings, where the focus is on reporting progress to managers rather than collaboration between team members.”
Standups can become political or emotional performances. “Daily scrums were uncontrolled gripe-fests that included more than 20 people. They ground on for hours without point or purpose,” said Shahpour Akhavi, currently a Ph.D. student at York University, describing an experience at one company.
The agile principles suggest that teams should work together on one project at a time. But with fake agile, “scrum teams” have people working on separate but somewhat related projects.
Another agile sin is when standup participants are expected to share daily updates by reading from the tracking system, such as Atlassian's Jira. Then, “the manager Slacks you privately to ask about delivery dates and what you are doing, as they have a meeting soon with the boss. Which means they didn’t get any information during the standup,” said longtime contractor Pere Villega.
Productive agile teams work in “sprints” over a short period of time (often two weeks) during which participants set a goal, break it into functional tasks tracked with tickets, and self-organize to reach the objective. At the end of each sprint, the team reflects on the work in what's called a “retrospective,” and identifies ways to improve.
However, the process breaks down at companies that emphasize “closing tickets” over software quality. At those companies “there is no team, let alone an autonomous, self-organizing team. There are no motivated individuals, only ticket processors,” explained Tim Ottinger, senior consultant at Industrial Logic.
Another behavior seen in “fake agile” companies is adopting rigid processes that are put in place around story point estimation and velocity tracking but failing to use the data to infer anything meaningful. In other places where agile isn’t working, development teams regularly shift uncompleted work from one sprint to the next without evaluating why the work drags on, or they abandon work underway because an executive reprioritizes a feature overnight.
“Is the task well defined? Are the success criteria defined and reasonably achievable? Are the developers empowered to flag issues, decompose the work into meaningful chunks, (and) find solutions?” asked Richmond. In companies where agile isn’t working, nobody knows.
Another common trap is when tickets become more important than software quality. The worst case may be at companies where employees are evaluated using stack ranking as measured by the number of tickets completed.
Developer Sharon Cochran worked on such a team. At the end of every two-week sprint, the tickets for unfinished tasks were marked as complete instead of carrying over to the next sprint, where they created brand-new tickets. “So, every sprint, our team magically had a perfect burndown and we always completed all of our work. The whole system became completely pointless,” she said.
Agile development is supposed to be iterative based on customer feedback. Each sprint should add new features that respond to “user stories,” or the high-level application requirements written from an end user’s perspective. For example, a typical user story might be “as an e-commerce customer, I want to find my order status so I know when my chocolate delivery will arrive.”
But when the input into the product roadmap comes from outside the user community, the process falls down. A marketing person might appoint themselves to represent the end user’s concerns, but they cannot speak for those users. An IT exec rarely knows the details about how the business operates well enough to create realistic user stories, or even to interview users to learn what they really want.
After a team finishes a sprint, retrospectives should prompt questions about how the participants can improve the business processes or whether the previous sprint’s deliverables met requirements. Retrospectives usually call for an icebreaker to create camaraderie, according to Villega.
However, on one malfunctioning team, that icebreaker consumed 15 minutes of a 40-minute meeting. That was followed by a templated outline representing generic agile scenarios, where the meat of the discussion was shoehorned into 5 minutes. It wrapped up with a recitation of the team’s commentary on the shared outline. “And then nothing is done [about any of it]. Repeat next sprint,” Villega recalled.
It’s important to focus on the behavior of the system rather than the output of the programmers.
That’s the sign of a team that has failed to iterate. “Instead of a true agile approach, the projects are generally laid out waterfall-style, where sprints are simply small chunks of the project executed thoughtlessly, one after the other,” said Josh Wickham, a principal engineer.
The people who do the work should choose who does the work, said George Dinwiddie, software development coach at iDIA Computing. One way to identify a fake agile organization is the insistence that all teams should work in the exact same way.
“It’s important to focus on the behavior of the system rather than the output of the programmers,” said Dinwiddie. When teams measure progress by “conformance to plan,” they often give the work to parallel, independent teams or individuals. “This is a major reason for such modules not working well together.”
Software engineering consultant Steve Mosley provided an example: a user story is assigned for the database task and another story to write the code, but the customer gets no value until both are delivered.
“People naturally want to focus on resource utilization [rather than] flow efficiency,” Mosley pointed out. It’s easy to split up work for the back end, front end, and infrastructure, where each individual focuses on their slice in isolation. But that means only a subset of the team is invested in a meeting discussion about each story. Thus, Mosley suggested, engineers conclude, “Scrum has too many meetings.”
Jeff Langr, author of Modern C++ Programming with Test-Driven Development, has an old picture showing two or three people actively engaging during a meeting, likely the project manager and a developer or two. “The remainder of people are disengaged, with arms crossed or holding up the wall,” he said. “And they are likely focusing on, ‘What am I gonna say when it’s my turn?’”
The end result of these fake agile practices is lip service and ceremonies at the expense of the original manifesto’s principles, Bacon said. When you use something the wrong way, it fails. Her favorite example: Large Agile Framework Appropriate for Big, Lumbering Enterprises.
To get agile right, Wickham recommended building on situations in your organization where agile is practiced relatively effectively. Most often, that involves teams building internal tools, such as administrative panels for customer support or CI/CD pipelines. Those use cases have more tolerance for “let’s put something up, ask for feedback, iterate, repeat,” he said.
After all, internal customers expect to accept seeing something that’s initially imperfect. “This indicates to me that people comprehend agile and have at least a baseline understanding of how to use it, but a lack of willingness to use it as defined when it comes to external customers,” said Wickham. Overcome the attitude by spending more time planning how to deliver small chunks in order to get feedback early and often, he advised.
The team manager can adjust how day-to-day work is performed by stressing such things as “deliver value frequently” and “regularly reflect and adjust your way of work to boost effectiveness,” Wickham said.
“If upper leadership doesn’t support or openly contradicts the agile principles and won’t change their minds, there has to be a kind of ‘malicious compliance,’ secretly implementing agile without them knowing,” Wickham said.
Remember, most companies really care about business outcomes, not process, said Richmond. They just want a recipe for what to do to improve execution toward those outcomes.
“Agile is an easy term to toss around as a ‘solution,’” Richmond said. “But effective agile does not have a cookie-cutter solution to improving execution.” Getting it right requires a focus on what has to happen to understand the company’s challenges, how those challenges manifest out of the business environment, in what way those challenges impact business outcomes, and then, finally, identifying how to apply agile concepts to the business.
But even with agile training and experience, “if the organization doesn’t communicate well, the communication issues will remain a barrier to success,” Richmond said. “Similarly, if the organization doesn’t trust their people, the trust issues will remain. Agile methods have a good chance of making execution worse than other methods if communication and trust are lacking.”
Ultimately, agile isn’t about ceremonies, or sprints, or tooling, Richmond said. Agile practices are important and can help structure its use, but they are not the methodology.
RPA is reaching an inflection point as enterprises increasingly look to get more than just productivity gains from their previous investments, and AI enters the chat.
Global teams across an enterprise are likely to speak different languages, of course, but also might be using different keyboard layouts with different characters. Those differences can lead to confusion about password requirements that could hinder collaboration and even compromise security.
Today: how international law enforcement agencies took down one of the most notorious ransomware operators, how two communities are dealing with a surge in data-center building, and the latest funding rounds in enterprise tech.
Like many companies that have grown through acquisitions over the years, Rajesh Naidu's job involves integrating those acquisitions onto a common tech stack, which requires taking a hard look at the SaaS applications used by those companies.
