|Jira Agile 6.3
In many software development shops, a Waterfall methodology drives the management of the development process: the boffins sit in a room for some time, figure out what should be included in the software, and simply present a fully formed software spec to the dev team as though it were Minerva emerging from Jupiter. After some number of months, the software team will finish incubating the product and give birth to version 1.0. Typically, there's a few obstacles; stakeholder requirements may have changed, bugs may have been introduced during the coding work, or implementation may differ subtly from the spec. This begins a painful process where incomplete or faulty software is delivered to the customer who reviews the software for bugs or concerns, and only after that does the development team start anew on version 2.0. This process can work fine, but it does suffer from very log cycle times and inefficient feedback mechanisms for the software team.
Once upon a time, a man named W. Edwards Deming found himself giving a series of lectures to industrial engineers and industrialists in Japan as a result of an invitation into the JUSE, or Japanese Union of Scientists and Engineers. Among the many things that he shared with his hosts was the Deming circle (pictured, left) that may qualify as the very first concept of a Scrum iteration. Nicknamed PDCA, this describes the basis of the Scrum iteration cycle - first Plan, or groom your backlog; then Do, or write your code. Then Check, by doing demos at the Retrospective or through CI testing. Finally, Act by releasing the software into the wild.
Some of the attendees of the lectures included the top people at Toyota Motor Company, including Eiji Toyoda, CEO of Toyota Motors. Using what he learned (and expanding on it significantly), Eiji and his team created the Toyota Production System and went on to build the most reliable and most popular cars in the entire world. Among the outcomes of this effort is the discipline known as Kanban (signalling), a method through which every production team was given the responsibility of determining the work output and timing for the team immediately prior to them in the production line.
As time passed, Toyota's manufacturing system made reliability the expectation in the industry instead of a noble goal. With time, first the Japanese and then the global automotive industry followed suit, resulting in more reliable and less expensive cars for all people. Eventually, these advances seeped into other sorts of manufacturing other than automotive, and to other fields than manufacturing. Everywhere it goes, efficiency improves and waste declines. You'll notice that most of Atlassian's support teams use Kanban for support, allowing us to easily manage each individual's workload and accommodate any special concerns such as high-priority tickets.
In 1986, these researchers looked into the various product development methods used in the auto, photocopier, and printer industries to find the most efficient way to design products. They found that the best designs came from holistic teams that work together (generally interchangeably) on the same work in overlapping iterations. They named this holistic method 'rugby', after the common tactic of a rugby team to remain in close proximity and pass the ball back and forth repeatedly on their way to the goal. While this was great for creatives in the photocopier, auto, and printer industries, it wasn't until Jeff Sutherland, with John Scumniotales and Jeff McKenna, applied the methodology used by Ken Schwaber at Advanced Development Methods to Easel Corporation that it was known by the term Scrum. At the OOPSLA conference in Austin, TX in 1995, the concept of Scrum was given its first public airing. Around the time, similar methodologies were becoming popular, such as Rational Unified Process (1994), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995).
In February of 2001, a group of software developers met at the Snowbird resort in Utah to ink out a way to apply Agile methodology to software development. The pioneers involved were: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Stephen J. Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas; they agreed on the following principles, from which all Agile software development follow:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
This became, in short order, the most popular emerging development methodology for emerging teams, and is still taking over existing teams the world over. As it allows creatives to have more direct control of their work and the terms of their work, the productivity seen from a team that incorporates Agile is far greater than the same team prior to accepting the Agile methodology. Because the process is iterative, much less waste is produced by doing development work that will later be made unnecessary, redundant, or incorrect due to the evolution of customer requests; the evolution of requirements continues along with the product, instead of being a comparison reserved to the end of the development cycle. As this process is short term focused, technical debt is allayed by frequently reviewing the finished work, often with the participation of the stakeholders who can advise if implementation is correct, and with active QA that can quickly identify and define bugs.
As with so many things, Agile is being adopted at different rates by different groups of people. At this point, it seems to have crossed the 'chasm' between the neck-bearded enthusiasts and the pragmatic development teams. Because of this, only a fairly small proportion of Agile teams use a strict methodology as defined by the Snowbird Cabal. As a result, the teams who use JIRA Agile will have varying degrees of adherence to various principles and doctrines in Scrum. For instance, some teams insist upon estimating and calculating burndown for all issues, even issues that do not generate value. Other teams insist that the Product Owner gets to rank the backlog. Others still will add or remove issues after a Sprint has been committed. JIRA Agile does, by its nature, bias towards the traditional Scrum and Kanban methods, but it can generally be configured to accommodate all types of teams.