[!JIRADL:_Images^jira_ninja.png!]
[!JIRADL:_Images^agile_ninja.png!]
Hey there! This page is no longer being maintained, but we've created some new and improved resources to replace it. Head on over to our Quickstart site to check them out.
While we do consider ourselves experts on GreenHopper, we've seen a few resources on agile practices that would be hard to improve upon.
Here are some links to agile information that can get you and your team off on the right foot.
Click the terms to expand the definitions.
The Scrum Alliance is a nonprofit organization committed to delivering articles, resources, courses, and events that will help Scrum users be successful.
Scrum.org's purpose is to improve the profession of software development so that we love our work and our customers love working with us and trust our integrity.
Scrum is a repetitive framework for software and product development. It can be compared to a game - company is a team owner, employees are team players and the game itself is desired product waiting to be enhanced. When the game is on we can clearly see what is wrong and what is acceptable.
Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends).
There has been some noticeable increase in interest in Kanban recently, with a number of people asking for more basic info, and more people writing new blogs and articles. This is my attempt to describe in more detail my take on it all, which I refer to as Kanban, Flow and Cadence.
The Lean-Kanban University is the place to learn about Lean and Kanban as it is used in knowledge work. It lists quality classes, services and resources for continuous learning and continuous improvement. This website is produced by Net Objectives and David J. Anderson and Associates, Inc.
How to use Kanban practices for Scrum teams that support existing products and receive a lot of urgent requests during a sprint (video).
While Scrum and Kanban differ quite a bit, they both provide a framework for teams to foster change and continuous improvement. It is not always a question of which is better than the other, but more a matter of which is right for your team at any given time. Each framework can be used exclusively or in combination with the other.
I feel that I can add some insights that Henrik and Mattias didn’t cover - insights that have emerged while I’ve been touring the world this past nine months working with teams and agile coaches on 5 continents from small innovative startup firms to some of the world’s largest industrial and technology businesses.
There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is 'so what is Kanban, and how does it compare to Scrum?' Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some of the fog.
One way or another, Scrum users are an important constituent of the Kanban audience. Since Scrum can be described as a statement in the language we use to describe kanban systems, it is also fairly easy to elaborate on that case in order to describe Scrum/Kanban hybrids. This can be useful for existing Scrum teams who are looking to improve their scale or capability. It can also be useful for more cautious new users who find comfort in an “established” method.
The one thing that all agile development teams have in common is that they are all different. And not just different from one company to the next, but also from team to team within any given organisation. Obviously, this is largely due to the unique mixtures of skill sets and development experience within each team, and the varying objectives and requirements of the project they are working on.
Admittedly it is a bit confusing, as these phrases are often used quite interchangeably (at least by me). Here's my take on what the difference is...
Our developers have also written a number of blogs about how we do agile here at Atlassian.