Welcome!

SDN Journal Authors: TJ Randall, Yeshim Deniz, Liz McMillan, Elizabeth White, Pat Romanski

Blog Feed Post

Agility is Not a Methodology.

Lori and I were discussing the entire topic of agility the other day, she looking at it from the SDN prospective, and I from the evolutionary perspective for development. While I know there has been a metric ton of writing about the topic, since I’ve used agile development, and find it to be useful, but didn’t become a fanatic on my first agile project, I thought some perspective might be in order.

There is a reason why absolutists always fail in technology. Not just because high-tech is always changing – which makes absolutism fleeting at best  - but because the part that determines whether computer scientists get to be absolutists on topics as varied as “object purism”, “No [fill in mobile device since first Palm] on my network”, or “We’re an X shop” is not at all scientific. Nor is making absolute statements, unless you’re discussing a proven fact.

Money and by extension people’s productivity determine what kind of shop you are, what you use or don’t use, what standards are set in stone and what are not. And sometimes the market. I used to work with a network manager that told me “We’re a Nortel shop, we’ll never use anything else.” Uhhmmm… Wonder how that’s working out for him.

And over the last several years, agile/lean development has that air of “My OS is better than yours!” to it. In these back-and-forth discussions, I have tried to maintain perspective, no matter what topic is polarizing my fellow geeks this year. What you like is irrelevant. Use the right tool for the job. Sometimes, that’s not your favorite, because frankly, there are no silver bullets.

Don’t get me wrong, I firmly believe the evolution of agile is what finally broke the “Mythical Man Month” mentality that had ruled over and held back IT as badly as Hume has decimated philosophy with regards to actual science. I hate that they let Hume hold them up while science continues to forge new ground and face issues that philosophers could help with, and I hated that IT shops believed there was no faster way to get code out the door once the team was bigger than one person.

Agile improved developer productivity through a variety of methods, but I feel the biggest was focusing on one thing at a time and reducing non-coding activities. All in all it is a great improvement.

But our field of endeavor tends toward zealotry, and the agile pundits out there sound alarmingly like the cloud pundits or any of the other absolutists we’ve burned through in the past 20 years or so “all other things are obsolete, we have our flavor of agile now!”. I’ll agree that agile methods are right for a huge percentage of IT projects, I just won’t agree they are for all IT projects.

The thing is, there are cases – more than one might think – where agile isn’t the best solution. The larger the code base, the larger the team, the more distributed the team, the less and less it a project is suited to agile methods. Oh, like so many methodologies, you can force-fit it, but I’m talking about best solution, not possible solution. And the more documentation required, well, agile teams don’t tend to excel in that department, viewing a document as a waste when you could be writing code. And that doesn’t even touch on the array of things like “don’t generalize for re-use, you can’t predict the future” slamming into “We are building a corporate repository…”

But the thing is, like all such methodologies, it does introduce some great tools to be put to use even on projects that don’t lend themselves to its overall methodology. And some that hold it back even when the methodology is the right one. Sponsors vary in actual support from “assigned to me, whatever” to “we really need this, what can I do to help get it right?” And that is just the nature of any methodology that requires sponsors for each project. Just as drafted militaries tend to be lower quality than volunteer ones, the sponsor process includes both good and bad.

From the good bits, breaking the problem down as small as possible is a great way to achieve focus, just  beware of blinders. The future is coming, and sometimes you can reasonably predict it. Others may need to re-use some of the source – assuming the team didn’t write it so specific as to be useless, and where documentation is concerned, the team needs to focus on new developers a couple years from now, when the SMEs won’t necessarily be available, not the minimum to communicate today.

But the most agile thing that comes out of agile? Business management is now aware that development can be faster than (maximum estimate X 2, measured in the next highest unit of measure). Agile projects are sometimes late, just as any other, but they are generally tracked better by the nature of labor division, so expectations are managed better. And upper management can now drive the mentality that will make IT more responsive.

And in the end, that’s the point. If senior management says “agility is our goal”, and is willing to put the money and effort behind it, the fact that some projects are better suited to other, more overarching methodologies doesn’t matter, but saying “We need tool X and it will make us more agile, here’s how” will get budget, improving overall IT responsiveness.

Most of us don’t get to choose the methodology (or lack thereof) in use for our team/group/department, but we do get to point out when the One True Methodology mentality is a weight and not helping. Do so. Strive, as most of us do, to do what is right for the organization, not what is the tool of today.

And embrace the bits that help no matter what. Focus on small problems, don’t over-document (but don’t under-document either, there will be others behind you that need to get up to speed), and unit/functional test at that one-business-problem level.

In the end, I titled this blog “Agile is not a development methodology”, simply because it is a mindset. A mindset that starts at the top, and prioritizes getting the business what they need in the fastest manner possible while still meeting requirements. You know, what we should have been (and many of us were) doing long before agile came along.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
DevOps is a world surrounded by information, starting from a single commit and ending in roll out to production. In this talk, I'll introduce you to the world of Taboola DevOps data collection, to better understand what goes on under the hood. The system we've developed in-house helps us collect and analyse the entire DevOps process from the very first commit all the way to production. It provides us a full clear view with a drill-down toolset that helps keep us away from the dark side. Our KPI's moved from being abstracted ideas to data driven goals, which we can measure and act upon. We're living in a data driven world when all business components are based on our clients action and reaction, why not doing the same thing within our DevOps eco-system?
After years of investments and acquisitions, CloudBlue was created with the goal of building the world's only hyperscale digital platform with an increasingly infinite ecosystem and proven go-to-market services. The result? An unmatched platform that helps customers streamline cloud operations, save time and money, and revolutionize their businesses overnight. Today, the platform operates in more than 45 countries and powers more than 200 of the world's largest cloud marketplaces, managing more than 27 million enterprise cloud subscriptions valued at more than $1 billion in revenue.
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, will discuss how to use Kubernetes to setup a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. His expertise is in automating deployment, management, and problem resolution in these environments, allowing his teams to run large transactional applications with high availability and the speed the consumer demands.
Containerized software is riding a wave of growth, according to latest RightScale survey. At Sematext we see this growth trend via our Docker monitoring adoption and via Sematext Docker Agent popularity on Docker Hub, where it crossed 1M+ pulls line. This rapid rise of containers now makes Docker the top DevOps tool among those included in RightScale survey. Overall Docker adoption surged to 35 percent, while Kubernetes adoption doubled, going from 7% in 2016 to 14% percent.
In an age of borderless networks, security for the cloud and security for the corporate network can no longer be separated. Security teams are now presented with the challenge of monitoring and controlling access to these cloud environments, as they represent yet another frontier for cyber-attacks. Complete visibility has never been more important-or more difficult. Powered by AI, Darktrace's Enterprise Immune System technology is the only solution to offer real-time visibility and insight into all parts of a network, regardless of its configuration. By learning a ‘pattern of life' for all networks, devices, and users, Darktrace can detect threats as they arise and autonomously respond in real time - all without impacting server performance.