The Agile Developer's Handbook

By : Paul Flewelling

5 (1)

Buy this Book

The Agile Developer's Handbook

5 (1)

By: Paul Flewelling

Buy this Book

Overview of this book

This book will help you overcome the common challenges you’ll face when transforming your working practices from waterfall to Agile. Each chapter builds on the last, starting with easy-to-grasp ways to get going with Agile. Next you’ll see how to choose the right Agile framework for your organization. Moving on, you’ll implement systematic product delivery and measure and report progress with visualization. Then you’ll learn how to create high performing teams, develop people in Agile, manage in Agile, and perform distributed Agile and collaborative governance. At the end of the book, you’ll discover how Agile will help your company progressively deliver software to customers, increase customer satisfaction, and improve the level of efficiency in software development teams.

Preface

Who this book is for

What this book covers

To get the most out of this book

Get in touch

Free Chapter

The Software Industry and the Agile Manifesto

Why the software industry needed to change

Incremental – adaptive versus waterfall – predictive

Agile is a mindset

Summary

Agile Software Delivery Methods and How They Fit the Manifesto

Understanding Scrum

XP - Extreme Programming

Kanban and Lean Software Development

Choosing the right framework

Summary

Introducing Scrum to your Software Team

Why Scrum is an excellent place to start

Starting a new Scrum team

Summary

Gathering Agile User Requirements

The pitfalls of traditional big upfront requirements

Why User Stories produce results

What a User Story is and how to use it

Brainstorming a bunch of User Stories

Estimating Agile user requirements

References

Summary

Bootstrap Teams with Liftoffs

What's a team liftoff?

References

Summary

Metrics that will Help your Software Team Deliver

A brief introduction to measurements for Agile software delivery

Quantitative metrics

Qualitative metrics

Summary

Software Technical Practices are the Foundation of Incremental Software Delivery

Building the thing right versus building the right thing

Refactoring

Test-Driven Development

Pair programming

Emergent design

The DevOps culture

Summary

Tightening Feedback Loops in the Software Development Life Cycle

Implementing incremental delivery in Agile

Introducing some Lean thinking to improve flow

Adopting Lean Startup methods to validate ideas

Summary

Seeking Value – How to Deliver Better Software Sooner

Moving from project to product thinking

Setting objectives to create alignment of purpose

Seeking value

Summary

Using Product Roadmaps to Guide Software Delivery

The importance of Product Roadmaps

Product Discovery to create roadmaps

Using Rolling Wave Planning for adaptive delivery

Summary

Improving Our Team Dynamics to Increase Our Agility

How to create high-performing teams

The stages of team formation

Stage 1 – forming

Stage 2 – storming

Stage 3 – norming

Stage 4 – performing

Stage 5 – adjourning/mourning

Learning by practicing

Summary

Baking Quality into Our Software Delivery

Cross-pollination of skills

Mob programming

No more bugs

No more estimates

Summary

The Ultimate Software Team Member

The power of motivation

The entrepreneurial developer

The team player

The growth mindset

Summary

Moving Beyond Isolated Agile Teams

How an Agile approach will organically flatten an organizational structure

Self-selection to create a true-self organization

Modern leadership

The art of Agile leadership

Organizational styles for flatter structures

Summary

Other Books You May Enjoy

Leave a review - let other readers know what you think

Customer Reviews

5 (1)

5 star

100%

4 star

3 star

2 star

1 star

No more bugs

Back in Chapter 8, Tightening Feedback Loops in the Software Development Life Cycle, we discussed how we tighten feedback loops from a variety of sources for us to ascertain two things:

Are we building the right thing?
Are we building the thing right?

Bug reports are a form of feedback that we should welcome, as they are the most straightforward problem detection system we could ask for. They cover many facets of our software, from a user requirement not being quite right to a broken API connection, from the user experience not being satisfactory to performance being suboptimal.

Some teams try to argue that a bug isn't, in fact, a bug. For example, they may say it's a case of the business requirement being wrong. Perhaps the user didn't know what they wanted. This is old-school contract thinking, which gets litigious because of the upfront promises...