The Truth About Agile Software Development with Scrum, The Facts You Should Know

(1)

(2)

All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher.

Notice of Liability

The information in this book is distributed on an “As Is” basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it.

Trademarks

Many of the designations used by manufacturers and sellers to

distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of

(3)

(4)

(5)

The Truth About Agile Software Development with

Scrum, The Facts You Should Know

Agile software development refers to a group of

software development methodologies based on iterative

development, where requirements and solutions evolve

through collaboration between self-organizing

cross-functional teams.

Agile methods generally promote a disciplined

project management process that encourages frequent

inspection and adaptation, a leadership philosophy that

encourages teamwork, self-organization and

accounta-bility, a set of engineering best practices that allow for

rapid delivery of high-quality software, and a business

approach that aligns development with customer needs

and company goals. Conceptual foundations of this

framework are found in modern approaches to

opera-tions management and analysis, such as lean

manufac-turing, soft systems methodology, speech act theory

(network of conversations approach), and Six Sigma.

(6)

Filled with examples of how Scrum is applied

Scrum in many varying situations.

Although this book is ostensibly about software

de-velopment, Scrum has its roots in general new product

development and can (and has been) applied to a wide

variety of development projects. Learning Scrum by

reading a book filled with examples like this is the best

way to get the feel for how to use it on your own projects.

(7)

Agile - More Than Just a Methodology

Agile is not just a software development methodology but a way of working that helps deliver business value faster, cheaper and with less risk. If you are an IT professional within an IT department or organization, or if you are a business professional in any sector, Agile values, principles and practices can help you optimize your team, your deliverables and the related processes.

Agile started off as a software development and delivery methodology but over the last few years it has grown broader and scaled to the organization level. Organizations in all kinds of industry are finding that the Agile way of working is not just suitable for IT departments but for the organization as a whole and it is delivering tangible benefits in record time. Agile is not a radical new way but rather an evolution of best practices and work philosophy that now has a definite shape and can be implemented to deliver substantial improvements. Agile Values Values are ideals that teams should pursue as a goal. Agile Principles Prin-ciples are applications of the Agile Values or Ideals to a particular industry.

Value:Focus on business benefits and risk mitigation. Collaboration:Focus on actively working together and leveraging collective knowledge. Speed:Focus on time-boxed delivery and sustainable development. Flexibility:Focus on adapting to busi-ness requirements and welcoming change. Simplicity:Focus on keeping things simple. Teamwork:Focus on creating empowered, self-adjusting teams.

Agile in Practice

(12)

12

Agile Leadership

Focusing on leaders and stakeholders outside and around the Agile project team (not project or iteration managers), this course outlines and examines the leadership role in dealing with Agile project teams and teams working in an Agile manner in general. Learn about the roles, responsibilities and accountability of line management and team leaders, both de-facto and nomi-nated. This course covers leadership behaviors and traits required to be effective and efficient in an Agile environment, as well as imparting tips and techniques to enable leaders to build high performing teams.

(13)

13

Agile Development Brings IT, Business

To-gether

I write a lot about the general importance of improving communications between IT and the business and the havoc that poor communication between the two camps can wreak.

Considering the strategic importance of software applica-tions to many companies and the high costs of development and, in particular, of going back and doing major code fixes, develop-ment is one process where communication would appear to be especially important. There's also users' general dissatisfaction with enterprise applications to consider.

Close communication between users and developers is a key characteristic of a process Computerworld calls application devel-opment 2.0. I'm no expert, but I think the article is referring to Agile software development, which departs from the traditional waterfall development process in a number of ways.

As is the case with a number of other tech trends, Agile first gained popularity with consumer-oriented applications and is making its move to a somewhat skeptical enterprise. Looking at it from a high (and admittedly non-technical) level, I am not sure why companies seem so suspicious. Agile values flexibility, sim-plicity and getting tasks accomplished quickly - three characteris-tics that are hard to see as negative.

(14)

14

In outsourced application development, a competitive force, regulation or other factor that leads companies to ask for a change not included in original design specifications leads to a change in scope and a change order with added cost. While added costs may not be as obvious for an in-house project, delays do drive up costs and also often create ill feelings between the busi-ness and IT. As Mow puts it:

"There's often this gap of IT saying, "The business can't make up their minds" and business saying, "IT can't keep up."

Agile's emphasis on speed and its iterative nature result in greater user participation, fewer hard feelings and hopefully, happier business people. Says Mow:

"One of the benefits of this is that you deliver working code much sooner. The business community can request changes in between each one of these iterations. The business community is watching this system become more malleable instead of more rigid. The changes they request are actually being incorporated. The issues they raise are addressed sooner in the process. Their participation actually has an effect on what happens - this isn't always the case with more traditional development methodologies. You really get a greater degree of alignment between IT and the business."

A caveat: Whether a project is in-house or outsourced, Agile requires a high degree of collaboration between IT and the business, something that not every organization is prepared to offer.

According to the Computerworld article, which echoes many of Mow's points, 70 percent of developers participating in a recent TopCoder online coding competition said that traditional corporate development teams could benefit from newer tech-niques, especially incremental feature releases, speedy user feed-back and quality assurance programs involving users.

(15)

15

Encourage close contact between developers and end users, and involve users in quality assurance processes; Stress simplici-ty; Use dynamic scripting languages like Ruby, Python and Perl rather than Java or .NET; Emphasize frequent releases; Users, not developers, should determine new features.

Another endorsement for Agile: General Electric engineers apparently use Agile methods for frequent tweaks to the compa-ny's much-vaunted SupportCentral network , which serves 400,000 users in 6,000 locations around the world.

Read Ann's complete interview with Doug Mow, senior VP of marketing at Exigen Services, "Outsourcing, with an Agile Twist" - http://www.itbusinessedge.com/item/?ci=42547

(16)

16

Agile Planning from Enterprise Vision to

Team Stand-Up Part 1

Experience gathered during large-scale implementation of Agile concepts in software development projects teaches us that the currently popular Agile software development methods (like Scrum ) do not scale to program, product and organization level without change. The fundamentals for changes to these methods are found in Lean principles, or: the future of Agile methods is found in its origins. This paper describes a planning framework that has been used successfully in large-scale Agile projects and investigates the impact of introducing this framework on three core Lean principles : Muri, Mura and Muda.

Planning in Large Scale Agile Projects

In Agile methods, loading a team with work is done through iteration planning. Due to the shortness of the iteration (typically one to six weeks) a plan reduces in importance and planning gains in importance. For small projects, it may be sufficient to plan only a single iteration at a time. The experienced disadvantage of iteration planning when applied to projects that run for more then a few iterations or with multiple teams is that the view of the longer term implications of iteration activities can be lost. In other words: the view of “the whole” is lost. A solution is to add planning levels to incorporate the current view of “the whole”.