Breaking the Addiction to Process

Breaking the Addiction to Process: An Introduction to Agile Project Management

ELIZABETH SCANLON THOMAS
Copyright Date: 2011
Published by: IT Governance Publishing
Pages: 129
https://www.jstor.org/stable/j.ctt5hh607
  • Cite this Item
  • Book Info
    Breaking the Addiction to Process
    Book Description:

    Breaking the Addiction to Process will give you a clear understanding of the way Agile works and how it can improve your business practices. It explains how Agile will help you to improve your relationships with your customers, to work more efficiently with your colleagues and to develop more streamlined and successful working practices, saving you time and money.This practical twelve-step guide is clearly written and offers simple solutions to age-old problems. Agile is a flexible, adaptable system and this book will help you to implement it for maximum impact and success for your business.

    eISBN: 978-1-84928-177-5
    Subjects: Management & Organizational Behavior, Technology

Table of Contents

  1. Front Matter
    (pp. 1-4)
  2. PREFACE
    (pp. 5-5)
  3. ABOUT THE AUTHOR
    (pp. 6-6)
  4. ACKNOWLEDGEMENTS
    (pp. 7-7)
  5. Table of Contents
    (pp. 8-10)
  6. INTRODUCTION
    (pp. 11-24)

    You’ve been part of a failed project before. You can remember exactly how it felt – the dawning realisation that you weren’t going to make the deadline or that the software wasn’t very good. You tried to alert management, but they didn’t want to hear. On the contrary, they made public statements about how well the project was going. It seemed surreal that they could be in denial when it was obvious things were going wrong.

    Sometimes, management is only too aware that a project is heading for the edge of a cliff, but are unwilling or unable to do...

  7. CHAPTER 1: SATISFY THE CUSTOMER THROUGH EARLY AND CONTINUOUS DELIVERY
    (pp. 25-37)

    This chapter explains how to work quickly from defining a requirement to delivering a working piece of software to your customer. Instead of time-consuming overall planning ahead of time and working towards a big release, you work on a small piece of the project and deliver that continuously. As Peter Drucker points out, ‘Plans are only good intentions unless they immediately degenerate into hard work’.

    You know how people hate to wait to get something big – Christmas is a good example. You’re getting a nice present – you’d rather have it now than wait until the 25th December. Customers...

  8. CHAPTER 2: WELCOME CHANGING REQUIREMENTS
    (pp. 38-55)

    Some managers are afraid of changing project plans because:

    You’ll be seen as a wimp because you don’t have a ‘consistent vision’.

    You think you need to keep a tight grip on everything around you.

    Often, though, the ‘vision’ will be incorrect in the first place, and the ‘control’ is illusory. These are two important reasons why authoritarian management styles usually fail.

    If you really knew somehow what your customer would need by the end of the project cycle, or what products your competitors would release in the middle of your work, maybe this old-fashioned view of good leadership would...

  9. CHAPTER 3: DELIVER WORKING SOFTWARE FREQUENTLY
    (pp. 56-64)

    Do you leave things to the last minute, then feel like you’ll sink from the boatload of stuff you have to do? Agile methodology has a way to handle this that will help you in real life too.

    Have you ever seen one of those Lazy Person’s Guide to Getting Things Done-type of article? The generic items on those lists are applicable to an Agile project too, for example:

    Make a To Do list. Keep a notebook with you and cross out any item you’ve completed. Bask in the feeling of accomplishment of getting something done.

    Stop putting things off....

  10. CHAPTER 4: BUSINESS PEOPLE AND DEVELOPERS WORK TOGETHER DAILY
    (pp. 65-72)

    This chapter describes how managers, developers and their customers can work together more cohesively. By abandoning the old ‘master–slave’ paradigm and really listening and learning from each other, the chances of your project succeeding substantially increase.

    There is more conversation in Agile projects than in traditional ones. You don’t just have one big meeting upfront to decide everything – then the engineers take it away and do it. Instead, there is a continuous conversation between customers and engineers over the course of the project in which requirements can change.

    Through this conversation, engineers who are developing the products have...

  11. CHAPTER 5: BUILD PROJECTS AROUND MOTIVATED INDIVIDUALS
    (pp. 73-77)

    Agile cuts down on top-heavy management through the principle of building teams of motivated people who choose their own work, so don’t need to be actively managed all the time. They can drive progress themselves as they feel listened to and valued in the team, and so have the inner motivation to succeed. ‘I recruit people who communicate well and are full of ideas,’ explains one manager.

    Steve Borthwick comments on this principle of Agile:

    It is not something that is specific to software or Agile, but people need to be allowed to take risks and make mistakes.

    It’s far...

  12. CHAPTER 6: CONVEY INFORMATION VIA FACE-TO-FACE CONVERSATION
    (pp. 78-87)

    How many times have you nodded off in a meeting? You are desperately trying to keep up with the slides being presented at the front of the room, but they are confusing with lurid colours and flying animation to jazz them up. All the jazzing-up does is kill any simplicity in the message, so you can’t understand it at all.

    As if the slides weren’t bad enough, what about the jargon-packed speech you have to listen to? You can barely understand any of it, yet it sounds so impressive – surely the speaker must know something that you don’t? It...

  13. CHAPTER 7: WORKING SOFTWARE IS THE PRIMARY MEASURE OF PROGRESS
    (pp. 88-93)

    This chapter discusses a new way of thinking about productivity – it’s not how many hours you work, what your professional qualifications are or who you know – it’s how often your team produces a working piece of software, no matter how small, for the customer.

    Steve Borthwick explains:

    This is important for the rest of the business to buy into. In most business fields, it’s harder work or more hours that are the measures to watch; these are much easier to track. Ideally, you need to come up with some measures that correlate to the ‘usefulness’ of your product....

  14. CHAPTER 8: MAINTAIN A CONSTANT PACE INDEFINITELY
    (pp. 94-99)

    In traditional projects, a team has a finish line – the last date the software can be delivered to a customer. Time is not managed as well as it could be – perhaps the team is slow to get going, but the deadline is unmovable. As the finish line comes in sight, teams go into overdrive mode, driven to deliver a complete software application.

    A related point is that only in Agile do you get the bad news quickly. In a conventional project, bad news comes slowly, fooling everyone into thinking there’s much more time left than there really is....

  15. CHAPTER 9: GIVE CONTINUOUS ATTENTION TO TECHNICAL EXCELLENCE
    (pp. 100-105)

    Agile methodology speeds up the traditional project cycle. Scrum teams work in short iterative cycles with continual testing and code integration. Because code integration occurs at frequent intervals, there is less chance that a big code integration at the end of a long cycle will result in broken functionality and the ultimate failure of a project.

    Use the ‘Fail Fast’ principle in your projects, then you can see what’s wrong and needs re-planning, rather than waiting for a whole project to be completed. (A Fail Fast system is designed to report failures quickly and halt. In an IT company, for...

  16. CHAPTER 10: SIMPLIFY – MAXIMISE THE AMOUNT OF WORK NOT DONE
    (pp. 106-111)

    This chapter explains how Agile reduces the workload of an old-fashioned project that is burdened by too many meetings, slide presentations and dictates from authoritarian management by minimising the work needed to be done. Also, you need to avoid Parkinson’s Law:

    Work expands so as to fill the time available for its completion.

    Observations of the British Civil Service in the 1950s showed that their numbers increased, even as their duties decreased with the decline of the British Empire. This was explained by John Murray in an essay in 1958. He wrote that the growth occurred because of two reasons:...

  17. CHAPTER 11: TEAMS SELF-ORGANISE
    (pp. 112-121)

    In the old days, to improve productivity and quality, managers thought it was important to formalise the activities and tasks of the development process. In this kind of methodology people have to adapt to the process.

    Agile methodology, however, has put people back at the centre of the development activities. In this kind of methodology ‘people trump process’, and processes have to be adapted to the needs of the workers.

    But even Henry Gantt saw that was wrong in the early 20th century. He said:

    Whatever we do must be in accord with human nature. We cannot drive people; we...

  18. CHAPTER 12: TEAMS HOLD RETROSPECTIVES AND TUNE THEIR BEHAVIOURS
    (pp. 122-126)

    Do you generally finish a project with great relief and move on quickly to the next thing without trying to learn from your mistakes? No one likes dwelling over errors they’ve made or bad judgement calls; but don’t you want to learn something from it, so you won’t repeat the same mistakes again?

    Remember the axiom: ‘If you’re not making mistakes, you’re not trying hard enough.’

    It can be hard on the ego to review a situation where you have clearly screwed up, but Agile makes it easier to handle because you review your actions and accomplishments after every sprint...

  19. ITG RESOURCES
    (pp. 127-129)