"Stakeholders must be included" throughout an agile project "to ensure the evolving deliverables meet their expectations," according to an article this week in Communications of the ACM.

But long-time Slashdot reader theodp complains it's a "gushing how-to-make-Agile-even-better opinion piece." Like other pieces by Agile advocates, it's long on accolades for Agile, but short on hard evidence justifying why exactly Agile project management "has emerged as a critical component for firms looking to improve project delivery speed and flexibility" and the use of Agile approaches is being expanded across other departments beyond software development. Indeed, among the three examples of success offered in the piece to "highlight the effectiveness of agile methods in navigating complex stakeholder dynamics and achieving project success" is Atlassian's use of agile practices to market and develop its products, many of which are coincidentally designed to support Agile practices and teams (including Jira). How meta.

Citing "recent studies," the piece concludes its call for stakeholder engagement by noting that "59% of organizations measure Agile success by customer or user satisfaction." But that is one of those metrics that can create perverse incentives. Empirical studies of user satisfaction and engagement have been published since the 1970's, and sadly one of the cruel lessons learned from them is that the easiest path to having satisfied users is to avoid working on difficult problems. Keep that in mind when you ponder why difficult user stories seem to languish forever in the Kanban and Scrum Board "Ice Box" column, while the "Complete" column is filled with low-hanging fruit. Sometimes success does come easy!

So, are you in the Agile-is-Heaven or Agile-is-Hell camp?

Chinese e-commerce group Alibaba Group Holding will reorganize into six business groups and pursue public listings for five of them, in the most significant governance overhaul since the company was established 24 years ago. From a report: The company announced the move on Tuesday, a day after founder Jack Ma's surprise return to China following a lengthy stint abroad. The six business groups will focus on sectors such as cloud computing, e-commerce and logistics. "This transformation will empower all our businesses to become more agile, enhance decision-making, and enable faster responses to market changes," chief executive Daniel Zhang said in a letter to employees. The six new groups will be: Cloud Intelligence Group, Taobao Tmall Commerce Group, Local Service Group, Cainiao Smart Logistics, Global Digital Commerce Group and Digital Media and Entertainment Group.

Each of the groups will be run by its own CEO and board of directors, with the CEOs assuming full responsibility for company performance. Zhang will remain chairman and CEO of Alibaba Group, which will follow a holding company management model. He will also serve as the CEO of the Cloud Intelligence Group, which will be responsible for the company's cloud and artificial intelligence businesses. Zhang became acting president of Alibaba Cloud Intelligence after its cloud service suffered what the company described as "the longest large-scale outage in more than a decade" in Hong Kong in late December.

"The Perl Advent Calendar has come a long way since it's first year in 2000," says an announcement on Reddit. But in fact the online world now has many daily advent calendars aimed at programmers — offering tips about their favorite language or coding challenges.

• The HTMHell site — which bills itself as "a collection of bad practices in HTML, copied from real websites" — decided to try publishing 24 original articles for their 2022 HTMHell Advent Calendar. Elsewhere on the way there's the Web Performance Calendar, promising daily articles for speed geeks. And the 24 Days in December blog comes to life every year with new blog posts for PHP users.

• The JVM Advent Calendar brings a new article daily about a JVM-related topic. And there's also a C# Advent calendar promising two new blog posts about C# every day up to (and including) December 25th.

• The Perl Advent Calendar offers fun stories about Perl tools averting December catastrophes up at the North Pole. (Day One's story — "Silent Mite" — described Santa's troubles building software for a ninja robot alien toy, since its embedded hardware support contract prohibited unwarrantied third-party code, requiring a full code rewrite using Perl's standard library.) Other stories so far this December include "Santa is on GitHub" and "northpole.cgi"

• The code quality/security software company SonarSource has a new 2022 edition of their Code Security Advent Calendar — their seventh consecutive year — promising "daily challenges until December 24th. Get ready to fill your bag of security tricks!" (According to a blog post the challenges are being announced on Twitter and on Mastadon.

• Just as the Perl community spawned another language named Perl 6 — now called Raku — there's also a Raku-themed advent calendar. (It's now at a new URL, though it's been running since 2009.) Day Three's post tells the story of Santa and the Rakupod Wranglers.

• "24 Pull Requests" dares participants to make 24 pull requests before December 24th. (The site's tagline is "giving back to open source for the holidays.") Over the years tens of thousands of developers (and organizations) have participated — and this year they're also encouraging organizers to hold hack events.

• The Advent of JavaScript and Advent of CSS sites promise 24 puzzles delivered by email (though you'll have to pay if you also want them to email you the solutions!)

• TryHackMe.com has its own set of darily cybersecurity puzzles (and even a few prizes).

• For 2022 Oslo-based Bekk Consulting (a "strategic internet consulting company") is offering an advent calendar of their own. A blog post says its their sixth annual edition, and promises "new original articles, podcasts, tutorials, listicles and videos every day up until Christmas Eve... all written and produced by us - developers, designers, project managers, agile coaches, management consultants, specialists and generalists."

Whether you participate or not, the creation of programming-themed advent calendar sites is a long-standing tradition among geeks, dating back more than two decades. (Last year Smashing magazine tried to compile an exhaustive list of the various sites serving all the different developer communities.)

But no list would be complete without mentioning Advent of Code. This year's programming puzzles involve everything from feeding Santa's reindeer and loading Santa's sleigh. The site's About page describes it as "an Advent calendar of small programming puzzles for a variety of skill sets and skill levels that can be solved in any programming language you like."

Now in its eighth year, the site's daily two-part programmig puzzles have a massive online following. This year's Day One puzzle was solved by 178,628 participants...

A UCLA assistant professor of Information Studies just published a short history of software engineering in Logic magazine — titled "Agile and the Long Crisis of Software."

It begins by describing Agile's history as "a long-running wrestling match between what managers want software development to be and what it really is, as practiced by the workers who write the code." When software engineering failed to discipline the unwieldiness of development, businesses turned to Agile, which married the autonomy that developers demanded with a single-minded focus on an organization's goals. That autonomy is limited, however, as developers are increasingly pointing out. When applied in a corporate context, the methods and values that Agile esteems are invariably oriented to the imperatives of the corporation. No matter how flexible the workplace or how casual the meetings, the bottom line has to be the organization's profits.
But this has major implications, the essay's conclusion argues: Could Agile even have played a role in some of the more infamous failures of the tech industry...? If a company sets a goal of boosting user engagement, Agile is designed to get developers working single-mindedly toward that goal — not arguing with managers about whether, for example, it's a good idea to show people content that inflames their prejudices. Such ethical arguments are incompatible with Agile's avowed dedication to keeping developers working feverishly on the project, whatever it might be.

This issue becomes especially pressing when one considers that contemporary software is likely to involve things like machine learning, large datasets, or artificial intelligence — technologies that have shown themselves to be potentially destructive, particularly for minoritized people. The digital theorist Ian Bogost argues that this move-fast-and-break-things approach is precisely why software developers should stop calling themselves "engineers": engineering, he points out, is a set of disciplines with codes of ethics and recognized commitments to civil society. Agile promises no such loyalty, except to the product under construction.

Agile is good at compartmentalizing features, neatly packaging them into sprints and deliverables. Really, that's a tendency of software engineering at large — modularity, or "information hiding," is a critical way for humans to manage systems that are too complex for any one person to grasp. But by turning features into "user stories" on a whiteboard, Agile has the potential to create what [software engineer] Yvonne Lam calls a "chain of deniability": an assembly line in which no one, at any point, takes full responsibility for what the team has created.
Other observations from the article:

• "Daily standups, billed as lightweight, low key check-ins, have become, for some workers, exercises in surveillance. "

• "The warts-and-all breakdown of Agile 'retrospectives' seems healthy, but I've watched them descend into a structureless series of accusations; everything depends on who's leading the team."

• One freelance developer in the article even argues that "As developers, IT professionals, we like to think of ourselves as knowledge workers, whose work can't be rationalized or commodified. But I think Agile tries to accomplish the exact opposite approach."

• "Some people I talked to pointed out that Agile has the potential to foster solidarity among workers. If teams truly self-organize, share concerns, and speak openly, perhaps Agile could actually lend itself to worker organization.
  
  "Maybe management, through Agile, is producing its own gravediggers. Maybe the next crisis of software development will come from the workers themselves."

"It's Open Source. It's free," says a web page at Penpot.app.

Slashdot reader kxra writes: Penpot is a free-software, web-based vector design platform using .svg as a first-class filetype used as the underlying storage for all designs.

As more design teams around the world move to the convenience of multi-device synchronized and collaborative web apps, this is a welcome respite from proprietary vendor lock-in by the likes of Figma and Canva. Penpot has finally launched as Beta, with competitive features such as a template library that all creators can pull from.

It's created by Kaleidos Open Source, the same team behind the project management tool Taiga for Agile teams which is taking on the likes of JIRA and Confluence with FLOSS.
"Not having a free & open source UX/UI tool that would make devs participate in the design process and bridge the gap between UX/UI and code was a terrible itch for us..." explains the FAQ at Penpot.app. But it also answers the question: why Open Source? Software Technology has the unique advantage, compared to other industries and intellectual property, of having almost zero cost to replicate itself, thus providing a wonderful chance to massively distribute the tools for a more digitally sovereign society. Besides the pure license aspect of it and its legal framework, Open Source fosters more engaging communities where the lines between user and contributor are often blurred...

Penpot requires a browser, that's it. If you want to host your own Penpot instance, that's fine too. We plan to release a native app bundle later this year.

There is a theme here. Universal access. That's why we love to call our product Penpot, there's nothing more personal and yet more universal than a pot full of pens. It's all about choice.
Its GitHub repository already has 5,200 stars and 41 contributors.

"We are uncovering better ways of developing software by doing it and helping others do it," declared the Agile Manifesto, nearly 20 years ago. "Through this work we have come to value..."

* Individuals and interactions over processes and tools
* Working software over comprehensive documentation
* Customer collaboration over contract negotiation
* Responding to change over following a plan

Today a new ZDNet article asks how far the tech industry has come in achieving the vision of its 12 principles — and why Agile is often "still just a buzzword." The challenge arises "because many come to agile as a solution or prescription, rather than starting with the philosophy that the Agile Manifesto focused on," says Bob Ritchie, VP of Software at SAIC. "Many best practices such as automated test-driven development, automated builds, deployments, and rapid feedback loops are prevalent in the industry. However, they are frequently still unmoored from the business and mission objectives due to that failure to start with why."

Still, others feel we're still nowhere near achieving the vision of the original Agile Manifesto. "Absolutely not at a large scale across enterprises," , says Brian Dawson, DevOps evangelist with CloudBees. "We are closer and more aware, but we are turning a tanker and it is slow and incremental. In start-ups, we are seeing much more of this; that is promising because they are the enterprises of the future." Agile initiatives "all too often are rolled out from, and limited to, project planning or the project management office. To support agile and DevOps transformation, agile needs to be implemented with all stakeholders."

Some organizations turn to agile "as a panacea to increase margins by cutting cost with a better, shinier development process," Ritchie cautions. "Others go even further by weaponizing popular metrics associated with agile capacity planning such as velocity and misclassifying it as a performance metric for an individual or team. In these circumstances, the promises of the manifesto are almost certainly missed as opportunities to engage and collaborate give way to finger pointing, blame, and burnout." What's missing from many agile initiatives is "ways to manage what you do based on value and outcomes, rather than on measuring effort and tasks," says Morris. "We've seen the rise of formulaic 'enterprise agile' frameworks that try to help you to manage teams in a top-down way, in ways that are based on everything on the right of the values of the Agile Manifesto. The manifesto says we value 'responding to change over following a plan,' but these frameworks give you a formula for managing plans that don't really encourage you to respond to change once you get going."

Wojtek Borowicz interviews David Heinemeier Hansson, the creator of the popular Ruby on Rails web development framework: Wojtek Borowicz: Software methodology is an industry of its own. There is Scrum, and Agile, and coaches, and books, and all of that. But you and your team at Basecamp don't follow these practices. Why?

DHH: First of all, our approach to software development is heavily inspired by the Agile Manifesto and the Agile values. It is not so much inspired by the Agile practices as they exist today. A lot of Agile software methodologies focus on areas of product development that are not where the hard bits lie. They are so much about the procedural structures. Software, in most cases, is inherently unpredictable, unknowable, and unshaped. It's almost like a gas. It can fit into all sorts of different openings from the same basic idea. The notion of trying to estimate how long a feature is going to take doesn't work because you don't know what you're building and because humans are terrible at estimating anything. The history of software development is one of late or cancelled projects. If you were to summarize the entire endeavor of software development, you'd say: 'The project ran late and it got canceled.' Planning work doesn't work, so to speak.

What we do at Basecamp we chose to label Shape Up, simply because that is where we find the hard work to be. We're trying to just accept the core constraint that it is impossible to accurately specify what software should do up front. You can only discover what software should do within constraints. But it's not like we follow the idea that it's done when it's done, either. That's an absolute abdication of product management thinking. What we say instead is: don't do estimates, do budgets. The core of Shape Up is about budgets. Not how long is something going to take but what is something worth. Because something could take a week or four months. What is it worth? [...]

Wojtek Borowicz: So the problem with those methodologies is they put too much focus on estimating, which is inherently impossible with software?

DHH: I'd go even further and say that estimation is bullshit. It's so imprecise as to be useless, even when you're dealing with fixed inputs. And you're not. No one is ever able to accurately describe what a piece of software should do before they see the piece of software. This idea that we can preemptively describe what something should do before we start working on it is bunk. Agile was sort of onto this idea that you need running software to get feedback but the modern implementations of Agile are not embracing the lesson they themselves taught.

Steve Denning was director of knowledge management at the World Bank from 1996 to 2000, and now consults with organizations around the world on management and innovation. And in 2018 he wrote the book The Age of Agile. Now he's arguing in Forbes that "As the global coronavirus crisis is forcing many organizations to act with unaccustomed speed, organizational agility has suddenly become a necessity.

"The crisis is also making obvious that institutional agility means much more than having lots of agile teams scattered around the organization." "To create a truly agile enterprise," as the article, "The Agile C-Suite", by Bain consultants Darrell K. Rigby, Sarah Elk, and Steve Berez in the May-June 2020 issue of Harvard Business Review (HBR) points out, "the top officers — most, if not all, of the C-suite — must embrace agile principles too." Agility of course isn't new. What's new is to see the C-suite embracing it.

The contrast in stock market performance between firms that have been embracing Agile principles at the senior level for a number of years — such as Microsoft and Amazon — and two firms that have spurned Agile principles at the senior level — such as GE and IBM — is dramatic...

It is important that Harvard Business Review is highlighting the role of the C-suite in business agility. Wall Street has already got the message. Although the U.S. economy shrank at a 4.8% annual rate in the first quarter and suffered from 30 million unemployment claims, the stock market finished its best month in years. Why? The answer to the paradox is simple. After a devastating collapse the previous month, investors poured into the "chosen few." Firms that have demonstrated business agility by taking advantage of technological possibility — Amazon, Apple, Facebook, Google and Microsoft — have become the largest and fastest growing organizations in the world, while many others struggle.

OneHundredAndTen writes: According to this Forbes article, the Pentagon is worried that many in the USA's military nerve center claim to use Agile methods, when in fact, they aren't. Those responsible for these things at the Pentagon have therefore come up with a Detecting Agile BS document, so people can tell when they are doing Agile vs. when they are doing BS Agile. The implicit conclusion seems to be the usual "if it doesn't work for you, you are not doing it right."
The article was written by the author of The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done, a 2018 book arguing "An unstoppable business revolution is under way -- and it is Agile. Companies that embrace Agile Management learn to connect everyone and everything...all the time. They can deliver instant, intimate, frictionless value on a large scale." The book's author is Stephen Denning, who spent four years as Program Director of Knowledge Management during his decades of management at the World Bank.

His Forbes article this week warns "effective software development at DoD is not just a narrow issue affecting a few software developers. Questions of national cyber security and the integrity of the upcoming U.S. presidential election may depend on it... Fresh thinking and Agile mindsets are urgently needed."

Last week Forbes ran an article by writer/data scientist Kurt Cagle arguing that Agile software development "was becoming less and less relevant." Within five days it had racked up 300,000 hits, and "I'm still digging out from the deluge of email, Tweets and Linked In messages," he wrote this week.

But in a new follow-up, Cagle looks back over his 40 years of programming, remembering successful six-month development cycles in the 1990s that used "a home-grown methodology which I've since dubbed the Studio Model, because it reflected the way that you create movies, television programs, orchestrated concerts, video games, and to be honest, most intellectual property." He then attempts a 12-point manifesto for this Agile alternative, which emphasizes things like a clear vision, good design, redundancy, flexibility, and remembering that as a project moves forward changes become "exponentially expensive". All too often, proponents of certain methodologies want to claim that their methodologies are the reason for success, when in reality, the deciding factor was the skill and tenaciousness of the people involved, the presence of a clearly articulated vision that could be changed as needed but that was not written in jello, and on recognizing the distinction between providing flexibility and fueling failures.

Agile is not, by itself, a methodology. The Agile Manifesto is a wish-list, written primarily by programmers, in response to the incessant micro-management by non-technical managers who were in general too incompetent to learn about the technology that they managed. I cheered when I first read it... Agile legitimized the idea that all stakeholders must be involved in the process of shaping the product's constraints and parameters (something that even now is still more preached than practiced). It gave a voice to developers and (some) others in the production process who up until then often had little say, and its message to managers in particular about the need to trust in the competence of the people they manage is one that cannot be stressed loudly enough. Its emphasis on change management has spurred a lot of thought about the nature of change, experimentation and development costs in the field. And for all that I think that certain Agile tools are a bit on the cheesy size, the idea of formalizing the process of development in such a way as to give creatives both the opportunities and the tools to shape and push back on design decisions is invaluable.

Yet, there are two key sets of problems that the Agile community faces. The first, and foremost, is that it decentralizes responsibility too much -- it essentially punts on the whole issue of governance or editorial guidance. This is that whole vision thing all over again... Agile empowers autonomous teams, but those teams still need to be able to pull together towards a common set of goals, and this means sacrificing some autonomy for cohesiveness. Agile also does not (ironically) distribute very well for precisely that same reason...

Agile may be everywhere, as several readers suggested, but scratch the surface a bit and you'll find that most of those successful agile projects were ones where you had a strong architect or steward, a culture that was already primed to work in a more Studio-Model like manner, a strong design in the first place as a foundation, and exceptional team-members that used agile in the way it should be used -- as a scaffold, rather than a crutch. There are good things to take out of the last twenty years of Agile, but this is not 2000, and it's well past time to acknowledge what's worked with Agile ... and what hasn't.

"Agile is not dead, quite the opposite," argues Alistair Cockburn, one of the co-authors of the original Manifesto for Agile Software Development in 2001: Why then, do we read of agile's death? Three reasons: phony ads, misunderstanding ordinary movement of ideas through society, and looking at the wrong curves... The sales pitch is pretty obvious when you look for it. Ignore those articles, they are just cheap sales tricks...

The pundits you are reading typically are innovators and early adopters. They adopted agile 10-15 years ago. Quite naturally, they have moved on and are working on the 2nd or 3rd round of interesting things that have arrived since then... They have been looking at lean startup, hypothesis testing, and agile product management, for example. All agile consequences, just a little more advanced. They have quite naturally (for them) forgotten the joy of discovering the agile approach for the first time. Everyone they know is already using it or has moved forward. To them it looks "passé", "dead"...

Choice A: agile. Choice B: something else. What is the something else that you think is more effective? For most projects, I can't think of another way that is more effective. Collaborate, deliver, reflect, improve, in cycles, from first idea until final delivery. This works whatever the nature of the project (no, agile is not just for software). Even badly done agile (please complain away at this moment, it's fine, there is a lot of bad agile out there), tends to be better than whatever came before it. That only tells you how bad all the things were that came before...

Agile is not dead, on the contrary. It's scarcely gotten started. Collaborate, deliver, reflect, and improve, in tight cycles. If you can find something better, use it.

Microsoft has declined to comment on an expert's many complaints about the quality of its recent patches and cadence of Windows 10 feature updates. Earlier, Susan Bradley, a Microsoft MVP who for the past 18 years has volunteered her time helping Windows users, took a survey of over 1,800 respondents regarding the Windows 10 Update experience. She then sent an open letter to Microsoft executives summarizing the results of this survey and providing thoroughly researched material regarding the poor update experience Windows 10 users have been experiencing. In return, Microsoft argued in a blog that it gives admins all the tools they need to test and provide feedback before it releases Patch Tuesday updates. From a report: Microsoft's John Wilcox, who helps promote why organizations should move to Windows 10's Windows-as-a-service model has, at the behest of Windows pros, offered an explanation of its monthly Windows 10 quality update servicing cadence and terminology.

As noted by ZDNet's Ed Bott recently, IT admins who'd spent years learning about Windows Update needed to "prepare to do some unlearning" due to the many changes introduced by Microsoft's shift to a Windows 10-as-a-service model. "With Windows 10, Microsoft has completely rewritten the Windows Update rulebook. For expert users and IT pros accustomed to having fine-grained control over the update process, these changes might seem wrenching and even draconian," he noted. [...]

Wilcox outlines that Microsoft's guiding principles to its monthly Windows service updates are built around being "simple and predictable", "agile", and "transparent." Wilcox doesn't directly address patching expert Bradley's major complaints about Microsoft's patches of late, but said Microsoft's predictability meant IT managers should be able to handle its "simple, regular and consistent patching cadence."

An anonymous reader writes: The 12th annual "State of Agile" report has just been released by CollabNet VersionOne, which calls it "the largest and longest-running Agile survey in the world." After surveying more than 1,400 software professionals in various roles and industries over the last four months of 2017, "Only 12% percent responded that their organizations have a high level of competency with agile practices across the organization, and only 4% report that agile practices are enabling greater adaptability to market conditions... The three most significant challenges to agile adoption and scaling are reported as organizational culture at odds with agile values (53%), general organizational resistance to change (46%), and Inadequate management support and sponsorship (42%)...

"The encouraging news is that 59% recognize that they are still maturing, indicating that they do not intend to plateau where they are." And agile adoption does appear to be growing. "25% of the respondents say that all or almost all of their teams are agile, whereas only 8% reported that in 2016."
The researchers also note "the recognized necessity of accelerating the speed of delivery of high-quality software, and the emphasis on customer satisfaction," with 71% of the survey respondents reporting that a DevOps initiative is underway or planned for the next 12 months.

In early January, IBM announced a roughly $1.6 billion outsourcing deal with Lloyds Banking Group. IBM would pay Lloyds for its data center assets and in return will charge the bank for ongoing management. Today, Lloyds plans to move almost 2,000 members of staff to U.S. tech giant IBM as part of the IT outsourcing deal. An anonymous Slashdot reader shares a report from The Stack: The seven-year deal hopes to save the bank close to $930 million in costs, streamline the business and make its IT services more agile. Lloyds Trade Union (LTU), which represents around 35,000 members of staff, now "derecognized" by the bank, claimed in a newsletter that once the deal is signed the jobs would be "offshored" over a four-year period. It added that most of the 1,961 positions would be cut. "1,961 staff will be transferred to IBM including permanent staff, contractors, 3rd parties and offshore suppliers. However after 4 years, only 193 of the staff transferred to IBM will still be working on the LBG contract," wrote LTU.

You asked, he answered!

Perl creator Larry Wall has responded to questions submitted by Slashdot readers. Read on for his answers...

A harsh perspective on agile software development, shared by Slashdot reader itwbennett: Politicians would be utter failures as agile project managers, writes David Taber, and for all the reasons you might imagine, but mainly because they wantonly make promises they have no hope or thought of keeping. But then he gets into the political attributes successful project managers need. And that's where things get interesting because, while he points out that agile was 'conceived of as a way of bypassing bureaucracy and internal politics,' the attributes he says are required for success are pretty much the worst of the political behavior we've all witnessed in our organizations.

For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"

StewBeans writes: Finding and keeping IT talent is getting increasingly competitive and expensive. A recruiter for Bay Area and Seattle tech companies said in a recent New York Times article about the cloud computing skill gap. "Someone working deep inside Amazon is getting five to 20 recruiting offers a day. Compensation has doubled in five years." Beyond steep salary and benefits packages, the resources to train new IT talent is wasted if they jump ship for the next best offer. That's why some IT executives are focusing talent management inward and investing in their current employees who are loyal and eager to learn, adapt, and grow with their company. Curt Carver, CIO for the University of Alabama at Birmingham, said that this approach led him to do away with the 10-year IT org chart and remain more agile as technology needs change. He argues that 18-month org charts and constant training are the new reality for IT, providing this example: "If you go back a couple of years ago, we were heavily involved in the storage business. Now I can buy unlimited storage from the cloud. I don't need a lot of people doing storage. In fact, I may only need one. Everybody else, I'm willing to retrain you, but you're going to be doing mobile, or you're going to be doing business intelligence, or you're going to be helping our organizations do gap analysis."

purplie writes My non-technical spouse is an analyst in a small county government department, a handful of people plus some contractors for projects. Their project/task management is mouth-to-mouth, sticky notes, and emails, and it's driving them crazy. I want to suggest something like an issue tracker. It would have to work for tasks both large (year-long investigations) and small (arranging catering for a meeting). The issue trackers I'm familiar with are too software-development-oriented, or make too many assumptions about your 'agile' religion. Are there any good options for non-engineers? They use mainly Windows and have iPads. I don't like web-based tools, but that might work better for them because they don't have administrative privs on their machines. Something that also incorporates a wiki might be nice. There will be resistance if it's not really easy to use.

Lemeowski writes: Cloud, big data, and agile were three of the technology terms that were brandished the most by IT leaders in 2014. Yet, there could be a real danger in buying into the hype without understanding the implications of the technologies, writes Pearson CTO Sven Gerjets. In this essay, Gerjets warns that many IT executives drop the ball when it comes to "defining how a new technology approach will add value" to their organization. He says: "Yes, you can dive into an IT fad without thinking about it, but I can promise you'll look back and be horrified someday. The only time you can fully adopt some of these new methods is when you are starting from scratch. Most of us don't have that luxury because we are working with legacy architectures and technical debt so you have to play hand you've been dealt, communicate well, set clear and measurable outcomes, and use these fads to thoughtfully supplement the environment you are working in to benefit the ecosystem."

Esther Schindler writes "It's certainly fun to pretend to find work inspiration from our favorite SF films. That's what Carol Pinchefsky does in two posts, one about positive business lessons you can take away from SF films (such as 'agile thinking can save many a project (and project manager) in a crisis' from Robocop and team motivation lessons from Buffy), and the other, 5 Project Management Horror Stories Found in Sci-Fi Movies, with examples of the impact of poor documentation on Captain America."