What's the best way to bring Agile to your team? The answer depends on just what you want to transform.

Curtis Franklin Jr., Senior Editor at Dark Reading

February 4, 2016

5 Min Read
<p align="left">Waterfall management has been used for decades.</p>

10 Productivity Tools To Help You Win At Work

10 Productivity Tools To Help You Win At Work


10 Productivity Tools To Help You Win At Work (Click image for larger view and slideshow.)

These days, the decision to go Agile doesn't put a company in select company. It seems like just about every organization that's doing more than simply maintaining an existing IT platform has adopted some variety of the Agile philosophy. Once you decide to go Agile, though, you've still got to figure out precisely how you're going to put the Agile discipline into practice.

There are two main methods used to put Agile into practice: scrum and kanban. One comes from software development, while the other was born of just-in-time manufacturing needs. Before we look at each of them, there are a couple of things that you should know. The first is that both scrum and kanban are sets of principles and prescriptions rather than strict recipes. They are, in that respect, much more barbecue than baking. The second thing to know is that each of these methodologies is a response to an older methodology.

From the Ashes of a Waterfall

The waterfall methodology ruled enterprise development from the 1950s until relatively recent times. It is, in most respects, the process for developing software that we learned at university. It's a linear, rigid, methodology that lends itself to strict rules and deadlines. It has been thoroughly documented and automated. On the other hand, the rigid nature means that changes to the specs are difficult after they've been established, and the opportunities to involve shareholders in the development process are few.

Agile is a response to the rigid nature of the waterfall model. Scrum and kanban provide options for putting Agile into place that differ depending on precisely what you hope adopting Agile will help your organization accomplish. Let's take a quick look at the strengths and challenges of each, and how each can help an organization solve development problems.

Scrum's Organized Uncertainty

The central principles of scrum development are rapid iteration and constant communication within a relatively small time box. The time box is called a sprint, and a sprint rarely extends beyond 30 days. During the sprint, the precise details of the features expected can change multiple times. It's rare for the delivered set of features and functions to be unchanged from those at the beginning of the sprint.

The specifics of features can change because scrum development allows lots of chances for "stakeholders" (read: users, customers, and management) to review what has been done, provide feedback, and offer suggestions on changes in the path. These people also offer input on priorities among the features and functions, because in scrums the end of the sprint is sacrosanct. If things get tight, the question is: Which features and updates must be moved into the next sprint?

Scrum_Framework.png

There is always a next sprint. Agile methodology is one of constant change and improvement. One of the most strident complaints made by waterfall stalwarts against agile methods is that air of constant change. Backend systems that must be rock-solid on the reliability front are seen by those stalwarts as poor candidates for constant improvement. Of course, there are options for those who want the agile philosophy without the rapid-fire baggage of scrums.

Just-In-Time Development

Toyota is famous for its "just-in-time" manufacturing, in which parts are delivered to the factory as they're needed, rather than stored at the factory in anticipation of need. Half a decade ago, Corey Ladas and David Anderson began applying the principles of just-in-time to software development in methods they called scrumban and kanban, respectively.

[See 10 Tools to Keep Your Agile Dev Projects on Track.]

Both of these methods have several key principles: Each is based on visual management tools that let everyone on the team know the status of each project component; each uses the visual tool to show where bottlenecks or obstacles have formed; and each places great emphasis on not overloading any single member of the team. Scrumban is seen as a method that can allow teams to transition from scrums to kanban, while kanban is a no-apologies just-in-time methodology.

640px-Simple-kanban-board-.jpg

One of the key differences between scrum and kanban is that kanban places the project and its needs at the heart of the process. In scrum, the sprint and its time box is at the core. Kanban radically changes the way that projects are managed within the non-project environment of the organization, while scrum is more appropriate for organizations in which development is constant rather than episodic.

So which is right for your team or company? It really depends on what problem you're trying to solve. Kanban is more linear; scrums are intensely multi-threaded. Kanban looks at agile from the project perspective. Scrum assumes that work on products and systems never ends. The question in scrum is what will be accomplished within the next sprint. Kanban fits easily within the traditional processes that already exist in most organizations. Scrum forces a different relationship between deadlines and tasks.

Agile is a philosophy that tends to take over and transform the organizations that embrace it. The method you choose to bring Agile to life will go a long way toward determining whether that embrace is warm or at arm's length.

Rising stars wanted. Are you an IT professional under age 30 who's making a major contribution to the field? Do you know someone who fits that description? Submit your entry now for InformationWeek's Pearl Award. Full details and a submission form can be found here.

About the Author(s)

Curtis Franklin Jr.

Senior Editor at Dark Reading

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and other conferences.

Previously he was editor of Light Reading's Security Now and executive editor, technology, at InformationWeek where he was also executive producer of InformationWeek's online radio and podcast episodes.

Curtis has been writing about technologies and products in computing and networking since the early 1980s. He has contributed to a number of technology-industry publications including Enterprise Efficiency, ChannelWeb, Network Computing, InfoWorld, PCWorld, Dark Reading, and ITWorld.com on subjects ranging from mobile enterprise computing to enterprise security and wireless networking.

Curtis is the author of thousands of articles, the co-author of five books, and has been a frequent speaker at computer and networking industry conferences across North America and Europe. His most popular book, The Absolute Beginner's Guide to Podcasting, with co-author George Colombo, was published by Que Books. His most recent book, Cloud Computing: Technologies and Strategies of the Ubiquitous Data Center, with co-author Brian Chee, was released in April 2010. His next book, Securing the Cloud: Security Strategies for the Ubiquitous Data Center, with co-author Brian Chee, is scheduled for release in the Fall of 2018.

When he's not writing, Curtis is a painter, photographer, cook, and multi-instrumentalist musician. He is active in amateur radio (KG4GWA), scuba diving, stand-up paddleboarding, and is a certified Florida Master Naturalist.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights