Getting Things Done and Agile Development
•Télécharger en tant que KEY, PDF•
9 j'aime•29,248 vues
Recommandé
Contenu connexe
Similaire à Getting Things Done and Agile Development
Similaire à Getting Things Done and Agile Development (20)
Dernier
Dernier (20)
Getting Things Done and Agile Development
- 1. Getting Things Done and Agile Development Dan Nordquist Popular Front Dan Nordquist / @dnord / #gtdagile
- 2. Resources • @dnord on Twitter • gtdagile.tumblr.com • use hashtag #gtdagile • I’ll assume you’re asking a question for the group • my cards, on the desk • prize Dan Nordquist / @dnord / #gtdagile
- 3. Thanks! Dan Nordquist / @dnord / #gtdagile
- 4. Why We’re Here • Code Camps are great • Learn about softer skills • You’re a professional Dan Nordquist / @dnord / #gtdagile
- 5. What We’re Talking About Today • GTD • Agile • Scrum • Lean? Dan Nordquist / @dnord / #gtdagile
- 6. Our focus • What do these plans have in common? • Promotions • Raises • Management Dan Nordquist / @dnord / #gtdagile
- 7. Dan Nordquist / @dnord / #gtdagile
- 8. Dan Nordquist / @dnord / #gtdagile
- 9. Dan Nordquist / @dnord / #gtdagile
- 10. About You Dan Nordquist / @dnord / #gtdagile
- 11. About You • “Knowledge work” Dan Nordquist / @dnord / #gtdagile
- 12. About You • “Knowledge work” • You make choices about your input and output Dan Nordquist / @dnord / #gtdagile
- 13. About You • “Knowledge work” • You make choices about your input and output • You define your work Dan Nordquist / @dnord / #gtdagile
- 14. About You • “Knowledge work” • You make choices about your input and output • You define your work • You have your own standards Dan Nordquist / @dnord / #gtdagile
- 15. “Organizations must create a culture in which it is acceptable that everyone has more to do than he or she can do, and in which it is sage to renegotiate agreements about what everyone is not doing.” Dan Nordquist / @dnord / #gtdagile
- 16. Brains: Good and Bad • Long term / short term memory failure • Bugs you at wrong time about wrong things • Has its own special way of motivating you Dan Nordquist / @dnord / #gtdagile
- 17. Three Options Dan Nordquist / @dnord / #gtdagile
- 18. Three Options A)Lower your standards Dan Nordquist / @dnord / #gtdagile
- 19. Three Options A)Lower your standards B) Interrupt-driven workflow Dan Nordquist / @dnord / #gtdagile
- 20. Three Options A)Lower your standards B) Interrupt-driven workflow C)Use reminders, and deal with it when you’re ready Dan Nordquist / @dnord / #gtdagile
- 21. Brains: Generally Good • Creative problem solving • Resolving conflicts • Connecting seemingly unrelated things Dan Nordquist / @dnord / #gtdagile
- 22. "These five phases of project planning occur naturally for everything you accomplish during the day. It's how you create things—dinner, a relaxing evening, a new product, or a new company. [...] And you do all of that naturally, without giving it much thought." Dan Nordquist / @dnord / #gtdagile
- 23. Purpose and Principles Dan Nordquist / @dnord / #gtdagile
- 24. Outcome Visioning Dan Nordquist / @dnord / #gtdagile
- 25. Brainstorming Dan Nordquist / @dnord / #gtdagile
- 26. Organizing Dan Nordquist / @dnord / #gtdagile
- 27. Define the Next Action Dan Nordquist / @dnord / #gtdagile
- 28. That’s the Process! • Purpose and Principles • Outcome Visioning • Brainstorming • Organizing • Next Actions Dan Nordquist / @dnord / #gtdagile
- 29. That’s Important! • Not over-planning (looks Agile) • Visioning sort of test-driven • On teams, we need to agree about vision Dan Nordquist / @dnord / #gtdagile
- 30. What Else is GTD? Dan Nordquist / @dnord / #gtdagile
- 31. What Else is GTD? • Projects Dan Nordquist / @dnord / #gtdagile
- 32. What Else is GTD? • Projects • Actions Dan Nordquist / @dnord / #gtdagile
- 33. What Else is GTD? • Projects • Actions • Contexts Dan Nordquist / @dnord / #gtdagile
- 34. Contexts • When / where can you do this thing? • Dependencies • Means different things to different people • Fairly flexible in the scheme of GTD Dan Nordquist / @dnord / #gtdagile
- 35. Review • Write stuff down • Don’t lose it • Analyze what you’re not doing Dan Nordquist / @dnord / #gtdagile
- 36. Capture • Start having ideas! • Stop losing them! • Surround yourself with ways to record your ideas. Dan Nordquist / @dnord / #gtdagile
- 37. Agile Dan Nordquist / @dnord / #gtdagile
- 38. Dan Nordquist / @dnord / #gtdagile
- 39. Dan Nordquist / @dnord / #gtdagile
- 40. Dan Nordquist / @dnord / #gtdagile
- 41. Dan Nordquist / @dnord / #gtdagile
- 42. What’s Agile? • Everyone on the team exposed to every job • Daily review • Test-first development • Automation Dan Nordquist / @dnord / #gtdagile
- 43. Waterfall • Deciding early • Attachment to a plan • Lack of flexibility • Not Agile Dan Nordquist / @dnord / #gtdagile
- 44. Planning • Oh, there’s planning in Agile • Stop saying that there isn’t • I mean it Dan Nordquist / @dnord / #gtdagile
- 45. “Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency[,] the very definition of ‘emergency’ is that it is unexpected, therefore it is not going to Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of happen the way you are planning.” 'emergency' is that it is unexpected, therefore it is not going to happen the way you are planning. Dwight D. Eisenhower Dan Nordquist / @dnord / #gtdagile
- 46. Agile Planning • Group effort • What’s possible? • What’s valuable? • Educational process for everybody Dan Nordquist / @dnord / #gtdagile
- 47. Planning a Vacation Dan Nordquist / @dnord / #gtdagile
- 48. Expect Change • Attachment to a plan is inflexibile • Changes are new opportunities • It’s pretty much happening anyway Dan Nordquist / @dnord / #gtdagile
- 49. Scrum • Backlog • Sprint • Daily Standups Dan Nordquist / @dnord / #gtdagile
- 50. Backlogs • Product backlog • Sprint backlog • Any crazy idea goes in the product backlog • Sprint backlog is more filtered down • Helps with focus! Dan Nordquist / @dnord / #gtdagile
- 51. Sprint Planning • Sprint Backlog / Product Backlog • Carefully of development for the next iteration filtering work items • Setting goals for progress Dan Nordquist / @dnord / #gtdagile
- 52. Focus • Narrowing down your options can be freeing • Choice can be overwhelming • Decide once • Spend the rest of your time making stuff Dan Nordquist / @dnord / #gtdagile
- 53. Daily Meetings • Better than statusing whoever pops by • Increases visibility • Makes a ton of useful information available for measurement Dan Nordquist / @dnord / #gtdagile
- 54. Solo Projects • Anyone can benefit from increased visibility Dan Nordquist / @dnord / #gtdagile
- 55. Lean Thinking • Flow • Systematic simplicity • Different kinds of inventory Dan Nordquist / @dnord / #gtdagile
- 56. Getting Things Done vs. “Flow” Dan Nordquist / @dnord / #gtdagile
- 57. Lean Steps • Define Customer Value • Find Value Streams • Flow • Pull • Perfection Dan Nordquist / @dnord / #gtdagile
- 58. • Poor or missing specifications - lack of information brings work to a standstill • Inflexible architectures - these can make it awkward to progress incrementally • Defects - they make us waste time on non-value-added rework and retesting • Unbalanced resources - these cause inventory pile-ups and waiting • Poor configuration management - not being able to access artifacts causes delays • Unreliable builds - not being able to reliably build releases can halt progress • Task switching - individuals waste time trying to juggle multiple activities Dan Nordquist / @dnord / #gtdagile
- 59. Lean Steps • Define Customer Value • Find Value Streams • Flow • Pull • Perfection Dan Nordquist / @dnord / #gtdagile
- 60. Lean Steps • Define Customer Value • Find Value Streams • Flow • Pull • Perfection Dan Nordquist / @dnord / #gtdagile
- 61. Common Threads Dan Nordquist / @dnord / #gtdagile
- 62. Common Threads • External memory Dan Nordquist / @dnord / #gtdagile
- 63. Common Threads • External memory • Drive productivity (predictably) Dan Nordquist / @dnord / #gtdagile
- 64. Common Threads • External memory • Drive productivity (predictably) • Break down a large project into smaller ones Dan Nordquist / @dnord / #gtdagile
- 65. Common Threads • External memory • Drive productivity (predictably) • Break down a large project into smaller ones • Planning time vs. doing time Dan Nordquist / @dnord / #gtdagile
- 66. Common Threads Dan Nordquist / @dnord / #gtdagile
- 67. Common Threads • Adaptive practices Dan Nordquist / @dnord / #gtdagile
- 68. Common Threads • Adaptive practices • Decide late - stay flexible Dan Nordquist / @dnord / #gtdagile
- 69. Common Threads • Adaptive practices • Decide late - stay flexible • Not priority-based Dan Nordquist / @dnord / #gtdagile
- 70. Productivity Antipatterns Dan Nordquist / @dnord / #gtdagile
- 71. Messing with the system Dan Nordquist / @dnord / #gtdagile
- 72. Allowing Interruptions into the Flow Dan Nordquist / @dnord / #gtdagile
- 73. Dan Nordquist / @dnord / #gtdagile
- 74. Dan Nordquist / @dnord / #gtdagile
- 75. Deciding Late Isn’t Deciding Alone Dan Nordquist / @dnord / #gtdagile
- 76. Be Nice About Other People’s Purpose Dan Nordquist / @dnord / #gtdagile
- 77. Don’t Be Afraid to Make Mistakes Dan Nordquist / @dnord / #gtdagile
- 78. Questions? Dan Nordquist / @dnord / #gtdagile
- 79. Thanks Again! gtdagile.tumblr.com Dan Nordquist / @dnord / #gtdagile
- 80. The Stack • OmniFocus (OS X and iPhone) • Gmail with rules and tags • Simplenote (website, iPhone app) • Evernote (desktop and mobile) • Any password manager • Instapaper Dan Nordquist / @dnord / #gtdagile
Notes de l'éditeur
- Hey there. My name is Dan Nordquist, and I'm a .NET developer at Popular Front in Northeast Minneapolis. That’s a digital agency and we make websites, tools for businesses, and mobile applications, I think we do really remarkable work. We're having a foosball tournament in five weeks, so if you haven't been invited and you play, or drink, just let me know.
- How are you going to let me know? Well, I'm on twitter at dnord. I've got cards up here with my email address on them. And I want to draw your attention to a Tumblr site I set up at gtdagile.tumblr.com - that's got a lot of resources I used to research this talk, and some book links in case you don't own these books and you hear about something you're interested in. And hey, if you tweet something during the talk, using the hashtag #gtdagile, I will take that either as a question to answer at the end of the talk, or maybe I'll get back to you later on. And someone's going to win this book - I'm going to add it to the prize pile at the end of the day and Jason's going to give it away to someone. Did you know you can just do that? If you bring stuff, Jason will give it away. So all those old citrix clients you have in the back office, bring 'em to code camp 9.
- I want to thank you all for coming today. You could have been a lot of other places, four other interesting talks, and you're here with me. So I want to thank the organizers for having me. This talk is code-free, but has a lot to offer to coders, so it's a real honor to be at a code camp with an opportunity to talk.
- I attended Code Camp 6, and it was a great experience. I saw a few talks that changed the way I felt about some really important topics and I immediately felt a need to give something back to the community. What came to mind for me was this: there are a lot of talks about next-generation technology, stuff that is one to five years out, and the new tools of Silverlight and MVC and Visual Studio tips and tricks, and I don't know. I might not be a developer in one to five years. I am honestly much more interested in the "professionals" part of the professional developer community. The syntax of these new toolsets will always come and go, but I would be honored if I could help you with some fundamentals that might stick with you for ten or twenty years.
- So I want to preview what I'm going to talk about if anyone wants to get the heck out of here because, like I say, it's a talk that's pretty light on code. But it's early in the morning, so maybe that's cool. I want to introduce you to Getting Things Done. So first, who here has read Getting Things Done? And who is somewhat familiar with the concept, or has read online about it? Okay, awesome. I want to show you the natural planning model, which is a key concept of GTD, and I want to talk about what else exists in that framework of productivity. Even though there isn't code here, there's a really sweet spot for developers in the heart of GTD, because their jobs and responsibilities are a naturally close match for the kinds of problems that GTD solves. I think almost everybody could get something out of this talk, but I'll try to relate the material to your jobs and what you do on a daily basis. And the last thing I want to do on the GTD front is some exercises that illustrate some of the value there. No discussion pairs or group work but I do want this to be kind of interactive. I want to introduce agile and Scrum to you guys - who here is working in an agile shop now or has agile experience? And who has seen Scrum in action? Okay, great. I want to focus on the execution parts of those frameworks, and see how the structure and support there exist to help developers get work done. I also want to look at the sprint planning and daily standup components and see what's relevant to the ideas in GTD. I feel like the agile ideas of frequent deliveries and special names for the people on the team and burndown charts are fairly well-covered elsewhere. And they don't have a lot to do with GTD, so I'm going to leave them be. I want to talk about Lean a little bit, which I haven't used professionally, but some of the ideas there are interesting.
- The focus with all these things should be what they have in common. Thousands of people are getting tremendous value out of GTD, and a lot of them have jobs like yours. And thousands are figuring out agile and Scrum, getting more done and doing it more predictably. But here’s the deal: I feel like when two systems or frameworks agree on something you should be doing, you need a pretty good reason to disagree. And maybe you do, but we're going to focus on where they overlap. That's what I'm most interested in. So why does all this matter? I think that understanding the principles of productivity is good for you and good for your teams. I can't promise that studying this kind of thing will result in promotions and raises, but I know that your management layer, whatever you have, wants to see which of us are interested in how things get done and how they get done predictably. We all have projects and tasks and jobs where we feel stuck. That’s kind of what we do. I feel like you'll probably learn something about getting unstuck from those things. So I think you've made an excellent decision to be here with us this morning.
- So first on the agenda is Getting Things Done. Getting Things Done was originally a book by David Allen, but now it's a lot of books and seminars and podcasts and a website that you have to pay to be a part of. There's also a cottage industry of third-party tools, including training and printed materials and websites and software. If you've written or used a to-do manager in the past five years, I'd be very surprised if it wasn't influenced or notified in some way by Getting Things Done. It's not the only productivity system on the planet.
- If you're older than I am, you remember Covey's Seven Habits of Highly Effective People, which is different than the Seven Habits of Highly Successful People, which I found on McSweeney's when I was researching this talk.
- Pomodoro Technique is another way people are pushing through blocks and getting it done. And so the first thing I want to say about this is that the arguments there are largely of the protestant / orthodox variety, which means that you might be arguing exactly how or when you review your stuff, and differences between the workflows, but to people outside, you're doing thinking that looks really amazingly similar. So don't get bogged down in the internet squabbling about all that - it's rarely worth it. GTD is popular with people like you. Why is that? In a way, it's about the promise of control. Anything that helps you make sense of the information coming into your life helps you control your response to that. If you can control that, you can control your time and your attention and, in a way, how you conduct and coordinate your life.
- But I don't want to get ahead of things. We might, in this room, have different jobs, but let me just make some assumptions about you as a professional. * You're a knowledge worker, right? That means that you process input and turn it into something more valuable. Whether that's database administration or project management, people give you information and you build something worthwhile based on that. * You make choices specifically about how you go about doing what you do and how you define it. For example, you don't break big rocks into little rocks, right? There isn't a conveyer belt of unpainted toys and your job isn't to paint the toys for eight hours. * You define your work every time you sit down in your chair, and even someone with your same talents could do radically different things in a given day just based on their read of the landscape and what to do in what order. So your expertise is an asset. * You kind of decide where to start, and you kind of decide when you're done, right? You have to balance the demands of maybe more than one boss, and you personally have some standards that you just refuse to fall short of. But it's your choice.
- But I don't want to get ahead of things. We might, in this room, have different jobs, but let me just make some assumptions about you as a professional. * You're a knowledge worker, right? That means that you process input and turn it into something more valuable. Whether that's database administration or project management, people give you information and you build something worthwhile based on that. * You make choices specifically about how you go about doing what you do and how you define it. For example, you don't break big rocks into little rocks, right? There isn't a conveyer belt of unpainted toys and your job isn't to paint the toys for eight hours. * You define your work every time you sit down in your chair, and even someone with your same talents could do radically different things in a given day just based on their read of the landscape and what to do in what order. So your expertise is an asset. * You kind of decide where to start, and you kind of decide when you're done, right? You have to balance the demands of maybe more than one boss, and you personally have some standards that you just refuse to fall short of. But it's your choice.
- But I don't want to get ahead of things. We might, in this room, have different jobs, but let me just make some assumptions about you as a professional. * You're a knowledge worker, right? That means that you process input and turn it into something more valuable. Whether that's database administration or project management, people give you information and you build something worthwhile based on that. * You make choices specifically about how you go about doing what you do and how you define it. For example, you don't break big rocks into little rocks, right? There isn't a conveyer belt of unpainted toys and your job isn't to paint the toys for eight hours. * You define your work every time you sit down in your chair, and even someone with your same talents could do radically different things in a given day just based on their read of the landscape and what to do in what order. So your expertise is an asset. * You kind of decide where to start, and you kind of decide when you're done, right? You have to balance the demands of maybe more than one boss, and you personally have some standards that you just refuse to fall short of. But it's your choice.
- But I don't want to get ahead of things. We might, in this room, have different jobs, but let me just make some assumptions about you as a professional. * You're a knowledge worker, right? That means that you process input and turn it into something more valuable. Whether that's database administration or project management, people give you information and you build something worthwhile based on that. * You make choices specifically about how you go about doing what you do and how you define it. For example, you don't break big rocks into little rocks, right? There isn't a conveyer belt of unpainted toys and your job isn't to paint the toys for eight hours. * You define your work every time you sit down in your chair, and even someone with your same talents could do radically different things in a given day just based on their read of the landscape and what to do in what order. So your expertise is an asset. * You kind of decide where to start, and you kind of decide when you're done, right? You have to balance the demands of maybe more than one boss, and you personally have some standards that you just refuse to fall short of. But it's your choice.
- So here's something that some people aren't comfortable with. You have too much to do. I want to show you this, because the company you work for would fail if we all didn't have too much to do. Because it's hard to dole out exactly the right amount of work, healthy working environments are going to put too much on your plate. Now, some people don't understand this and they try to get down to zero by working through 60 or 70 hours of stuff in a week. Some of those people are running their own companies, and they don't have a choice, but a lot of them simply don't understand that they could or should be renegotiating their commitments, getting help or simply communicating better where they are with their week. If you aren't setting expectations for yourself, regarding what you're going to get done in a week, you're almost certainly going to overextend yourself, and that's something that nobody wants to do to you. So this, again, it’s about putting yourself in charge of your commitments. Controlling what has your attention, and feeling good about those choices.
- You're setting yourself up for failure if your brain is your only ally in this. Your brain is terrible at storing discrete information, and you've heard about this or read it. There's short-term memory, and that's fairly wide-scoped, but there's long term memory, which is not quite as powerful. Suffice it to say that if you're depending on your long-term memory to manage everything you've got cooking right now, AND everything you want to save forever, or every goal you have, you're going to let something slip. You look like a young and handsome audience, so if it hasn't happened to you yet, trust me when I say that it will. I assure you. Your brain is also terrible at leaving you alone if it thinks you have to do something. There's a story in David Allen's book about cleaning the garage. You notice that the garage is a mess, and you say to yourself "man, I really have to take care of that", and literally every hour you aren't taking care of that, your brain is confused and acting out. It's producing reminders and guilt and tension and misery and you can't avoid it because you're supposed to be cleaning the garage. Now, that kind of tension can be really good. If you have to leave at 2:45 to get somewhere, your brain automatically generates the same kind of motivation as soon as it notices that you're going to be late. It says "we should be leaving", notices "hey, we aren't leaving" and starts to motivate you to leave. But when you consider that the garage is just one thing, and that we're professionally and personally trying to do a hundred other things, it makes sense that our brains need to delegate some of that responsibility.
- David Allen writes that you have three options to deal with this kind of tension, and I want you to tell me what works best for you. * First is lowering your standards. You can't find your phone, you can just say "maybe I'll never find it" or you decide that the garage is a disaster and that's just what happens to garages. * The second option is that you can immediately start working on the thing - so you just clean the garage right now, because you know you have to do it before you die, and you put everything else out of your mind. Until you notice something else, and then you do that. At least it shuts your brain up for a little while. * David Allen's third option is to put a reminder in a reviewed and trusted system. There's a lot in that sentence that isn't obvious so let me parse it a little bit. Written reminders are one key - a lot of what we're talking about is the system of externalizing memory, but it doesn't necessarily matter if you're using a pencil or putting it in a computer system. But what's a trusted system? In a trusted system, the stuff doesn't go anywhere, so you don't have to worry about it any more. It’s not going to get away. It isn't enough to just write everything down permanently - you don't unlock the benefit unless you routinely review that external system. So what do you want? That's by far the healthiest way to deal with the pile of stuff you've got stacked up for yourself. Trying to remember without a system is a waste of your brainpower until you do forget it, and I imagine you understand the odds of coincidentally getting it done before you forget it. Doing everything as you notice it kind of works, but it gives way too much power to the most recent, loudest, or most frequent drags on your attention. And lowering your standards and not doing anything is just sad. So it's out of your brain and it's in a trusted system and you've just cleared that RAM for something else. That's the basis for putting things out of your head and keeping better track of them.
- David Allen writes that you have three options to deal with this kind of tension, and I want you to tell me what works best for you. * First is lowering your standards. You can't find your phone, you can just say "maybe I'll never find it" or you decide that the garage is a disaster and that's just what happens to garages. * The second option is that you can immediately start working on the thing - so you just clean the garage right now, because you know you have to do it before you die, and you put everything else out of your mind. Until you notice something else, and then you do that. At least it shuts your brain up for a little while. * David Allen's third option is to put a reminder in a reviewed and trusted system. There's a lot in that sentence that isn't obvious so let me parse it a little bit. Written reminders are one key - a lot of what we're talking about is the system of externalizing memory, but it doesn't necessarily matter if you're using a pencil or putting it in a computer system. But what's a trusted system? In a trusted system, the stuff doesn't go anywhere, so you don't have to worry about it any more. It’s not going to get away. It isn't enough to just write everything down permanently - you don't unlock the benefit unless you routinely review that external system. So what do you want? That's by far the healthiest way to deal with the pile of stuff you've got stacked up for yourself. Trying to remember without a system is a waste of your brainpower until you do forget it, and I imagine you understand the odds of coincidentally getting it done before you forget it. Doing everything as you notice it kind of works, but it gives way too much power to the most recent, loudest, or most frequent drags on your attention. And lowering your standards and not doing anything is just sad. So it's out of your brain and it's in a trusted system and you've just cleared that RAM for something else. That's the basis for putting things out of your head and keeping better track of them.
- David Allen writes that you have three options to deal with this kind of tension, and I want you to tell me what works best for you. * First is lowering your standards. You can't find your phone, you can just say "maybe I'll never find it" or you decide that the garage is a disaster and that's just what happens to garages. * The second option is that you can immediately start working on the thing - so you just clean the garage right now, because you know you have to do it before you die, and you put everything else out of your mind. Until you notice something else, and then you do that. At least it shuts your brain up for a little while. * David Allen's third option is to put a reminder in a reviewed and trusted system. There's a lot in that sentence that isn't obvious so let me parse it a little bit. Written reminders are one key - a lot of what we're talking about is the system of externalizing memory, but it doesn't necessarily matter if you're using a pencil or putting it in a computer system. But what's a trusted system? In a trusted system, the stuff doesn't go anywhere, so you don't have to worry about it any more. It’s not going to get away. It isn't enough to just write everything down permanently - you don't unlock the benefit unless you routinely review that external system. So what do you want? That's by far the healthiest way to deal with the pile of stuff you've got stacked up for yourself. Trying to remember without a system is a waste of your brainpower until you do forget it, and I imagine you understand the odds of coincidentally getting it done before you forget it. Doing everything as you notice it kind of works, but it gives way too much power to the most recent, loudest, or most frequent drags on your attention. And lowering your standards and not doing anything is just sad. So it's out of your brain and it's in a trusted system and you've just cleared that RAM for something else. That's the basis for putting things out of your head and keeping better track of them.
- So what is your brain good at, if we have to hack around the parts that aren't good? Dynamically and creatively solving problems, right? Imagine with me that you've just sat down in a restaurant and your table’s kind of wobbly. What are you going to do to solve that problem? You don't even have to think about it seriously, right? Your brain is just generating ideas to get out of that situation. (Like what did you think of?) Or what if I say that the bathrooms are located on either side of the room, outside the doors there? Your brain identifies the exit you might use and who you’ll have to go past to get there. This seems kind of dumb, maybe, because we're used to working on really complicated solutions, but if you saw a monkey stuff a napkin under a table leg because it was wobbly, you'd be really impressed. Your brain also connects seemingly unrelated things. Have you ever been watching a movie and something about it mysteriously relates to a situation from your work day? There's nothing about the movie that's actually about your work, but your brain can't help but identify common patterns and relate one to the other. Or when you're going to bed, falling asleep, and an approach you hadn't thought of just suddenly occurs to you? That's what your brain can do when it isn't bogged down by being "busy". Sometimes we drive ourselves so hard to produce an answer, we don't give our brains a chance to come up with the answer. Sometimes direct pressure is amazing, but usually, your brain wants to lead the way, not be forced into a corner. So in conclusion on the brain stuff, it's better to let it do the jobs it's good at, and try to delegate the rest as much as possible. Using an outside system for the tracking job of todos and goals, the specifics and the details, as much as you can, get it somewhere you can trust.
- So let's talk about getting unstuck. I want to introduce you to the natural planning model, which serves as the basis for most of GTD, although it's not all of it, because then there wouldn't be five books and a website you have to pay for. But the natural planning model is good. This is how David Allen introduces it. Just think of something that you want done, or something you recently got done. Anything that's an open loop for you, maybe something that your brain reminded you about when I was talking about the monkeys dealing with a restaurant table. Right, because your brain has these open loops, and they don’t close themselves. David Allen says that people estimate that they have hundreds of thoughts an hour, okay? But he says they're having basically the same 10 over and over. So get those out and you can get some real work done. Anyway. They use "going out to dinner" in the book, but I'm going to use this talk. I wanted to give this talk and now I'm giving it, so that's a success story in my book.
- There are five steps, and the first one is defining your purpose and principles. You have a reason for wanting to do what you want to do. It's not everything you think about, but you operate within that framework and it certainly dictates a number of things you won't or wouldn't do. Think about why you want to do that thing for twenty seconds. For this talk, the purpose was to give back to the community and spread some of these ideas, but also to get better at speaking and to meet really smart people that I might work with in the future and get better as a developer. So everything I do here has to be compatible with those ideals. Every idea I had about what talk to give or what parts to include were matched up against the purpose of you guys and what you'd want or what you'd think. It's easier using the example they give: dinner. If you're really hungry, or you're picking a restaurant for a first date, or you only have five minutes until you have to be somewhere, those dictate totally different dining out choices, right? You likely don't write them down but if you're trying to make a decision as a group, it's really important that everyone be on the same page about this, or you'll never come to a consensus. A lot of groups don't do this and that's the basis for arguments.
- The next step is outcome visioning. This is where you figure out what “done” looks like. Just take 20 seconds and imagine what your end-state is. For me, "what I want to say" was a million times easier if I imagined myself up here saying things. In the case of dinner, you might envision a certain aspect of the meal or the company or the price or the speed with which it will be served. Whatever it is, knowing what it looks like when it's done is another thing that we frequently skip and, once you realize that, it's hard to imagine working with a group in the same way. If you aren't imagining the best possible outcome for your projects or your tasks or your sprints, you're missing out on a tool that provides motivation and guidance. Just like your brain gets its way out of jams that you just imagined, if you're somewhere and you can just imagine the destination, your brain does amazing work figuring out how to get from here to there.
- The third thing is brainstorming. This one isn't too strange, and we do this a lot. Your brain does it automatically, if you remember what we talked about a minute ago. The key thing to understand about brainstorming is that almost every planning process accounts for it, but frequently it's done without any kind of direction. Everyone gets into a room and has a bunch of GOOD IDEAS! and now everyone has more than enough GOOD IDEAS! and no real plan for what actually needs to get done. Do those ideas fit the project vision? Do they serve the purpose of the project? "We want to make a Twitter client", "yeah, and we want it to take a picture of you when you hit send, NO MATTER WHAT." Okay, why do you want to do that? Maybe that's a really good idea, maybe there's a vision there, but until you understand why that feature is important, could you make all the decisions necessary to make that a successful feature? You couldn't, because you don't know what success really means, for that particular feature. Now I said as soon as I had a vision for how terrified I was going to be up here with nothing to say, I thought of things to say. Lots of them. Our restaurant friends are right now arguing over what restaurant to go to, but they're automatically arguing based on the values and principles in the first two steps. Easy.
- The fourth step is organizing. As soon as you start having ideas, you probably stash them under "good ideas" or "bad ideas", or maybe if you're writing a paper you write them down on index cards and make stacks of them, or maybe your ideas go into a mind map or outline where you aren't organizing things in your head anymore, you're using an outside tool. In the case of this very talk, I used OmniFocus and starting hanging the things I wanted to say on an outline that helped me put similar things together and provide some flow. But even this talk wasn't the only community-contribution idea I had. Right next to "give GTD talk" in my system, I've got "get gifts for code camp" and "go to nerd dinners" and "follow presenters on blogs". With all those things in the same place, I can, once this talk is done, start thinking about the next thing I want to do to advance the larger goal of participating in the community and improving myself as a developer, consultant, thought leader, blue sky imagineer, kimono opener, etc.
- Finally, we generate next actions. This is really very important, and if you do nothing else I think you should take away this particular feature of GTD. David Allen recommends you find the next thing that you would do about your project (again, just the one thing we agreed to work on during this exercise), and then generate or capture nothing else. That's your one focus for the project. The thing after that, you'll know it when you get to it. Trust yourself to find it and don't clutter your view with anything you can't do now to move the project forward. As you work through any project, that next action is constantly changing. Depending on where you are in the process, you can come up with lots of different approaches. But it's always driven by the question, "what is the next thing I'd do if this was the only thing I had to do?" Because you came up with the successful outcome, you've given your brain everything it needs to do the job of determining whether you're headed in the right direction. This step usually only takes twenty seconds, but it's amazing how much people can muddle through or procrastinate with their work because they haven't done this step and they don't know that they need to do it. They think that the next step should be obvious or that it's laying on the ground in front of them and all it takes is a little bit of thought in the right direction.
- The end of the whole process is to write down this next action, put it in a system where we'll look at it again - we won't lose it - so now it's out of our brains. We don't need to remember it. We'll see it again when we need it, and we can use the extra RAM to work on bigger problems. And then you do that for every other project in 360 degrees of your responsibility. Now, there's also layers and layers to this - "do something good for Valentine's Day this year" is a project, and so is "plan for retirement", but they're on completely different scales. There's interesting stuff to say here, but it's not completely relevant at the moment.
- So what's important about that? It's not over planning. Does it seem like the kind of process that allows you to learn as you go and maybe change your mind about what's important after doing the first few steps? And in that way, is it more agile or more waterfall? Agile planning starts with the same "purpose and principles" process and proceeds through a lot of the same phases. In a way, the vision step is a form of test-driven decision making. If you know what you want the end result to be before you start working on making it a reality, you're much more likely to be controlling your progress towards the actual end goal. Take that and turn it: if you don't have a successful outcome in mind, making any kind of progress is sort of suspect, isn't it? Because if you haven't done those foundational steps, you can't really be sure. This is important in team environments. Whether you're writing code that satisfies a test or taking steps to accomplish an agreed-upon, predefined goal, you’re in control of what you're doing. And the more you think about it, the people that don't do this, they can’t be sure that they’re in control of what they're doing.
- So what's left in GTD? A lot of it is in that simple common-sense exercise, but I want to check off a few points before we move along to agile. Projects are anything that takes more than a step to complete. Actions are the steps we take to get those things done. And the next action is just the one action per project that's been defined and that you could work on if it happens you get around to it. The focus on the next action is a little uncomfortable for some people, but it's actually really freeing to be able to let go of what might come after we take the next step. So you don't generate a ton of tasks for each project in your life. Instead, you filter it down to the next thing you need to do, that you're likely to do, that you can possibly do, and then you have one or maybe two of those for each project. Here's an opportunity for even more focus, though: we break up that list of actions into contexts.
- So what's left in GTD? A lot of it is in that simple common-sense exercise, but I want to check off a few points before we move along to agile. Projects are anything that takes more than a step to complete. Actions are the steps we take to get those things done. And the next action is just the one action per project that's been defined and that you could work on if it happens you get around to it. The focus on the next action is a little uncomfortable for some people, but it's actually really freeing to be able to let go of what might come after we take the next step. So you don't generate a ton of tasks for each project in your life. Instead, you filter it down to the next thing you need to do, that you're likely to do, that you can possibly do, and then you have one or maybe two of those for each project. Here's an opportunity for even more focus, though: we break up that list of actions into contexts.
- So what's left in GTD? A lot of it is in that simple common-sense exercise, but I want to check off a few points before we move along to agile. Projects are anything that takes more than a step to complete. Actions are the steps we take to get those things done. And the next action is just the one action per project that's been defined and that you could work on if it happens you get around to it. The focus on the next action is a little uncomfortable for some people, but it's actually really freeing to be able to let go of what might come after we take the next step. So you don't generate a ton of tasks for each project in your life. Instead, you filter it down to the next thing you need to do, that you're likely to do, that you can possibly do, and then you have one or maybe two of those for each project. Here's an opportunity for even more focus, though: we break up that list of actions into contexts.
- We determine where we have to be to do a certain action. Or what we have to have. And we can organize our actions by those conditions, and we call those groups contexts. A context is something like a dependency. What are some good contexts? The classic one is “phone”. We use contexts to filter the next-action list, so when you're not in your office, you're not looking at the office list, and when you've got your computer out, you can focus on the actions that require it. A really common complaint about contexts is that computer people have all of their actions in this "computer" context, and that doesn't do much good. Whatever kind of work you do, if you do it at a computer, it's totally reasonable to say that those are all "office" tasks and all "computer" tasks and then your contexts are kind of all muddled up together or out of whack. The thing about contexts is that you can certainly make your own, so if you want a "computer/email" context, and a "computer/visual studio" context, and a "computer/chat" context, that's all fine. I also want to mention that the benefit of contexts is to focus your attention on the things that you can be doing right now, and developers have a lot of things that they could be doing at their desks with their computers. If it doesn't bother you to switch contexts between visual studio and the database server and the build server, then that's okay, too. Maybe it's a "computer/dev" context vs. a "computer/email" or "computer/admin" context. Object-oriented programmers also understand the concept of multiple dependencies, where you might have to be in the Out-and-About context and the Having Money context and the with-some-friends context to really make the most of certain tasks or goals. Some GTD tools support that, but in truth, it can pretty deeply complicate a system that should really be about simplicity as much as possible.
- Another concept important to GTD is the review step. So we’ve written things down. It's super important that we don't take the product of that useful process, the thinking we did to get to an action, and then lose it in a drawer or forget about it. So you process what you've captured during the week, but you don't let those notes and meetings and emails and important things slip by. We make time to look at them and figure out what they mean. Another really nice benefit of continual review is that you discover what you're not doing. We talked about cleaning the garage a minute ago, and I want you to imagine that you do a weekly review of all of the things you want to get done in your life and there's this action item about learning the clarinet. And you've gone through the process where you know what your action item is about the clarinet and it comes up week after week and you're not taking that first step. You have to confront the truth about your desire to learn the clarinet, because you've done everything you needed to do to make it happen and it's not happening and the review process can facilitate that kind of discovery. That information can become available to you with some hard facts where it might not be something you even knew you were thinking about before.
- Okay so ubiquitous capture. We've started the process of clearing our minds of little admin taskmaster stuff, because our brains are wonderful machines and they generate awesome ideas if they're put in charge of that, even in an idle mode, right? So you stand up from this session and you start walking to the next one and you have an idea and, then what? You're stuck trying to remember it until you can get it into your system or write it down or whatever. So David Allen recommends that you just surround yourself with devices for capturing ideas. Keep paper in your pocket, configure your phone to give you quick access to a recorder, use a note taking application, leave yourself voice mail - there are dozens of ways that you can get that idea out of your head, and then that feeds back into that next daily or weekly review. You check your note taking applications or the emails you sent yourself and you get them into the system when you have time for that. But the last thing you do is waste your newfound psychic RAM on ideas you just had, when you just cleared the space by delegating the ideas you used to have, right? Ubiquitous capture is really important.
- I want to start relating these concepts to agile development practices but I want to do a quick recap of agile for people in the audience who may not have worked with or observed or read about agile. James Shore wrote the book, pretty much literally, but agile means a lot of things to a lot of different people.
- Here's James Shore on agile, and I think he's right.
- [Read, then:] Lots of shops have read about agile or know what agile represents and they like promise more than the discipline. I feel like agile development is a discipline of development the way that object-oriented programming was once a programming discipline. The professionals are showing that it's the correct approach to software projects. I bet we'll soon just assume that you're doing it if you're serious about building software as a team.
- The agile dev process puts team members in charge of everything. That means that you will be exposed to testing and requirements and deployments and design, because agile encourages you to do all of these activities side-by-side and simultaneously. There's a daily review of what's moving and what needs to get done, so everyone knows where things stand, and management can use some of the estimates and logged hours from these daily meetings to measure velocity and get a better picture of what's actually happening. There's a strong emphasis on test-first development, which is another excellent practice, but that grows out of a commitment to automate as much of the process as possible. Agile developers are always looking for a way to do more with fewer actions, maximizing their productivity by automating tests and automating builds and automating deployments and reporting.
- But what have you heard about when you hear about agile? It isn't waterfall, right? We're so used to waterfall but we're giving agile a try and it doesn't seem to be working because we can't change the expectations of the stakeholders because they do it waterfall style. So what's wrong with waterfall that drives us to agile? It has you plan the whole process up front. Think about this: on day ONE, the day that everyone understands the least about the value of the software, you decide what's going in and what's getting cut and how long it'll take. Of course we learn about the value as we go, but waterfall doesn't let that learning inform the process. You wait to test until the software's done, and you're surprised to find that the tests result in rework - challenges and changes to the way it should work. The customers took over testing when the software was "done", so the developers had nothing left to do and they went on to different projects. Or during deployment you find a constraint that should have been identified during planning, but the planning and budgeting were done. Then that informed some changes to the design and they couldn't be made, because the designers were "done". That's the frustration of the waterfall approach.
- So I highly recommend that you read about agile if you haven't. Because a lot of people hear that, and they go "awesome, chaos" and they start down a path that's like waterfall, except less disciplined, and you make my job hard when you do that. As a developer and as an advocate for agile, you're killing me twice. The lack of a segmented planning process with defined handoffs doesn't mean that planning is anti-agile. Plans (and the attachment that they create) are waterfall. Planning is, in fact, agile.
- So is this the first Eisenhower quote in a code camp talk? I sure hope so.
- So how do we plan agile projects? The first answer to that question is that we do it together. James Shore talks about planning being a collaboration between the customers (who are experts on the value of the software) and the developers (who are the experts on the costs). Developers can only guess at what kind of features or experience or design will be most valuable to the people that will eventually use the software, but it's just as true that the non-developers are only guessing at how complex the software actually is. They need each other. So Shore describes a strategy where the important features are listed, the developers semi-estimate them, and then that process repeats. The semi-estimation hack, if that's not familiar to you, is basically assigning a score of complexity to a certain user story or feature. We try to avoid talking about "five days" or "four hours" or "three weeks" when we're doing the planning piece for a lot of different reasons. So you might have seen cards with numbers between 0 and 100 and each feature gets "points" based on how complex it's going to be. 40 isn't twice as long to do as a 20, it's just maybe twice as complex from an integration standpoint, or represents more unknowns, or involves a dependency that has proven difficult in the past. It's just that "more" means "more" and less means less.
- And iterations of this happen at the last responsible moment. Avoid decision-making before it's necessary, but once it's necessary, don't put it off. Shore describes vacation planning, and two different ways it's worked out for him. Have you ever been on a trip where you had something specific to do every day, sometimes scheduled down to the hour? All it takes is one blown connection or a lost reservation and the day is ruined. It all kind of flows downhill from there. Plus, it's miserable. Maybe you were out late on Friday, and Saturday morning is the dolphin-watching excursion, and you just wish you had any kind of choice about it, but that was the plan, and if you don't do that, you can't do anything, because it's the plan. Another way to handle a vacation is to prepare yourself for every possible thing you might want to do, pack well, and get in the car. As it comes, figure out what feels right and do it. Make reservations in three cities and cancel two of them as soon as you know which one you want to do. When things start to go bad, you change your plan so that things go better. There's no excuse not to have a good time because you made the decision every day about what you wanted to do. And if excellent opportunities come up, you're free to embrace them. It's important to stay flexible about what's coming up next, and the direction that our days or weeks or projects or lives might take. Deciding too soon can rob us of that flexibility.
- Agile planning can be like that, where you're so prepared that preparation becomes your plan. As your project moves along, you're swapping out priorities and approaches to stay on target. We've all been there on the requirements change that comes after most of the work is done, and our attitude is frequently "it's too late" or "we can't do that." But a change in the plan is often an opportunity to add value that the customer just figured out. If they knew about it earlier, they would have told you, but now that they know they want it, we can argue about the requirements or we can embrace the opportunity. If you do enough of this work, you can come to expect it.
- So Scrum is an agile methodology that has a few identifying features. The first is the backlog, another is the sprint, and there's also a daily standup.
- The product backlog is one of my favorite Scrum concepts because it leverages the same externalized memory theory that GTD uses. The product backlog starts as the work that's defined for the project at the outset, but evolves to become a list of tasks or reminders or placeholders for work that could be done, but isn't on anyone's plate yet. You'll move these cards to a "developing" column one day, but for now it's a free parking spot for any idea you, the team, or the client may have. So this is a concept we reviewed at the start. You can focus your attention on solving the problems of software development, or you can use the same brain power to track the 44 ideas that you, the team, the client, your boss, and your five favorite bloggers had about your chosen technology, the features we can't miss, the architecture pieces you want to try, the things you screwed up on the last project... it's a lot better to write them down, stick them to the wall, and move on. Not leave them forever, right, because that's not a healthy pattern but set aside time to regularly review them. So this starts to look like the ubiquitous capture or the INBOX of Getting Things Done. No idea is a bad idea, and as long as this list is prioritized by the team and the customer and it's not taking up anyone's time to be continually saying "these aren't relevant ideas", go ahead and let that backlog grow. I've read people who say "keep the backlog clean" and I really think that creative groups, collaborative teams and projects that have a lot of potential really need to review wild and crazy ideas on a regular basis.
- Now that's the product backlog, but you've also got a backlog that you break off for the sprint. (And the sprint is the 30-day window you give yourself to finish some stuff and then come back up for air and a demo.) So for sprint planning, we take the time decide what of the product backlog we’re actually going to work on. We decide on these things, and set goals, together, with the customer and the developers. We decide it once - we’re determining what the focus of the next block of development should be. That is sterile and pristine by definition - if anything sneaks onto that backlog, you're straying from the scrum planning process. The product backlog is the crazy ideas that who knows when we'll get around to them, but the sprint backlog is the defined work that we're focused on right now. That’s what we’re measuring our progress against. For now, that’s all that matters. Moving things back and forth can be really disorienting and demotivating.
- The point I want to make here is about focus, and how having a narrowed down scope of things that we're working on is similar to the focus enforced by Getting Things Done. Your project likely has thousands of tasks and actions that'll need to be taken, hour by hour. The choices regarding those actions can be overwhelming, and narrowing your focus can be a huge relief. There are a million fun things in everybody's backlog, so much so that we * distract ourselves from the important things in today's plan * to worry about the undefined stuff * that we probably won't even get to tomorrow. It increases anxiety to have choices, and both Scrum and GTD help you make choices once, in a smart way, and then spend the rest of your time executing. But it's only possible if you focus on the decision-making during planning, and then focus on the actions during the rest of the time.
- You probably already know what I'm going to say about the daily meeting - it's a lot like GTD's daily review. We ask ourselves three questions in the daily standup - what did you do yesterday, what are you going to do today, and what can anyone else do to free up any blocks you have. This should be possible in a couple of minutes per person, and it encourages constant communication between team members. I like these because I like checking off checkboxes. It keeps the progress visible. Whatever you're doing, there's an inherent benefit to having the people who care about what you're doing aware of how it's going. I want to switch perspectives back to GTD, but first I want to talk about the alternative - have you ever worked in an environment where anyone can tap you on the shoulder and say "how's it going?" And you stammer, and describe something that you just got done doing, even if it's kind of only tangential to the thing that your boss is expecting you're doing, and you have to think back to the last time he asked the question, and what's changed since then, and he thinks he's doing the management job, and he's only making you feel like you always have to have a thirty-second presentation ready about your value to the project. So the once-a-day meeting should cut down on that. And we have a object-oriented concept for this, right? Don't Repeat Yourself. The status you give to your boss at 11 is basically the same one you'd give to his boss at noon, so have them both come to the daily standup if they're interested.
- Why would you need increased visibility on something only you're working on? Well, I honestly think that the guy who says "I should get certified" wears a different hat than the guy who has to take the test. I mean, they're both you, but you've got different scope and priorities in all of those modes. Daily review in GTD means finding that day-to-day progress and those struggles and making them available to the bigger-picture thinker that maybe doesn't do the driving most days.
- I want to touch on the ideas in Lean Thinking as well, because I haven't done Lean professionally but I thought the principles had a lot in common with what I wanted to talk about today. Lean puts a lot of emphasis on flow, which comes up a lot when you talk to developers about how they do what they do, and in particular when they feel that they're especially effective. Lean translates the developer flow to a kind of systematic simplicity - eliminating unnecessary business process steps and synchronizing things so that a bigger share of what developers work on, and what we can control, gets into the hands of customers. They literally talk about inventory, like a company that makes widgets and puts them in a warehouse. The more unsold widgets they have on hand, the more serious their inventory management problem is. What the widget company would really like is to make the widgets instantly, as soon as there was demand, and exactly where the customer is, right? And so Lean thinks of the work we do as something like that, where if too much of it is defined, the list is overwhelming. So one of the ways they enhance flow is by reducing that management overhead.
- Two things should be obvious here: Getting Things Done is about reducing the management problem of projects, because we're leaving some things that are unknowable anyway as undefined. The focus on the next action helps us manage the actual projects. And we use contexts to pare down even further the number of options that are open to us, increasing the chances of finding that flow. Getting Things Done's "flow" is closer to that personal mental state than it is to the elimination of complications in a software system or development project. And yet, in both cases, we're trying to figure out what it is we don't need to worry about, not worrying about it, and doing an A+ job of the things that we decided were worth our time and effort. As a result, we stay in control of our focus. More of our best energy goes into the things that are most important to us, and we don't leave anything dangling even if it's not a top priority.
- So how do Lean practitioners encourage flow? They have five lean steps, and each maps really closely to what we've been talking about. The first is "define customer value", and the second is about the value stream. Until you've defined what it is you expect to do, and the value you expect to get out of your time, you're basically just guessing at what actions are going to provide those results. Don't put emphasis on "customer" here - you're the customer of your system, and the time you spend on your priorities is how you're going to make that customer happy. It's defining value - that couple of seconds where you really figure out which direction you're going, and it's amazing the value you can get from that if you're not doing it. What do you want? How are you going to get there?
- The third step is finding that flow. In their literature, they talk about the kinds of things that can hold up a development project, make developers wait, and distract them from their work. I've got a list of them here and I don't know that we need to go in-depth. Task switching is interesting to me, in that it's kind of congruent with contexts, but all of these things are good. Avoid these and maintain flow.
- Fourth on the list is pull, and pull is big in all of these. Pull means finding for yourself the thing that needs to be done first. Push is letting stuff just come into your system and take up your attention. Push is reactive. When we practice pull, we’re being proactive, proactively finding the place where we’ll make progress. There are analogs all over the place for this. Getting Things Done isn’t about consistently nagging you to do X or do Y. It’s about setting things up so that, when it’s time, you have clear actions that tie to higher goals. Pull, not push. Scrum’s the same way - that sprint backlog is a firewall between the ever-changing
- Fifth is continuous improvement, and that’s big for any system. If it provides visibility into your habits and hang-ups, let it lead to continuous improvement.
- So, of what we've seen today, what are some common threads? * We already talked about externalized memory and using something more reliable and less valuable than your brain to track the ideas you've had or the tasks you're tracking. Your brain works better and flows more smoothly when you're not trying to keep track of reminders. The inbox and the backlog and ubiquitous capture let us jot down any crazy idea - we don't have to lose them and we don't have to do anything with them immediately. * They drive productivity in a predictable way. No matter what system you're using, at the end of a cycle, you have some written record of what you were trying to accomplish, what you did to make that happen, and how close you got. Companies need that kind of visibility to make software development profitable and predictable. But you don't have to be a project manager to gain some of the same benefits in your personal life - finding out what's working for you and what isn't can be really eye-opening, and help you develop as a person and professional. * All of these systems involve eating an elephant one bite at a time. They don't all have all the answers for doing great things, but they all recognize the value in finding the first meaningful step and giving yourself every opportunity to do it. * This one's really huge, but all of these systems respect the importance of planning time and execution time and review time, without distraction. We just talked about Lean and "flow", and they don't own the concept, but what habits do these systems ask you to adopt? Taking the time in the daily review to really go through the actions that might be useful that day. The weekly review is going to expose you to lots of actions that, if you just did ‘em, might only take a minute. But if you start "doing" instead of "reviewing", you'll leave the review undone. Once that happens, how can you be sure that you're going to finish the thing you abandoned your review for? What if you get distracted during that? You can only do one thing at a time.
- So, of what we've seen today, what are some common threads? * We already talked about externalized memory and using something more reliable and less valuable than your brain to track the ideas you've had or the tasks you're tracking. Your brain works better and flows more smoothly when you're not trying to keep track of reminders. The inbox and the backlog and ubiquitous capture let us jot down any crazy idea - we don't have to lose them and we don't have to do anything with them immediately. * They drive productivity in a predictable way. No matter what system you're using, at the end of a cycle, you have some written record of what you were trying to accomplish, what you did to make that happen, and how close you got. Companies need that kind of visibility to make software development profitable and predictable. But you don't have to be a project manager to gain some of the same benefits in your personal life - finding out what's working for you and what isn't can be really eye-opening, and help you develop as a person and professional. * All of these systems involve eating an elephant one bite at a time. They don't all have all the answers for doing great things, but they all recognize the value in finding the first meaningful step and giving yourself every opportunity to do it. * This one's really huge, but all of these systems respect the importance of planning time and execution time and review time, without distraction. We just talked about Lean and "flow", and they don't own the concept, but what habits do these systems ask you to adopt? Taking the time in the daily review to really go through the actions that might be useful that day. The weekly review is going to expose you to lots of actions that, if you just did ‘em, might only take a minute. But if you start "doing" instead of "reviewing", you'll leave the review undone. Once that happens, how can you be sure that you're going to finish the thing you abandoned your review for? What if you get distracted during that? You can only do one thing at a time.
- So, of what we've seen today, what are some common threads? * We already talked about externalized memory and using something more reliable and less valuable than your brain to track the ideas you've had or the tasks you're tracking. Your brain works better and flows more smoothly when you're not trying to keep track of reminders. The inbox and the backlog and ubiquitous capture let us jot down any crazy idea - we don't have to lose them and we don't have to do anything with them immediately. * They drive productivity in a predictable way. No matter what system you're using, at the end of a cycle, you have some written record of what you were trying to accomplish, what you did to make that happen, and how close you got. Companies need that kind of visibility to make software development profitable and predictable. But you don't have to be a project manager to gain some of the same benefits in your personal life - finding out what's working for you and what isn't can be really eye-opening, and help you develop as a person and professional. * All of these systems involve eating an elephant one bite at a time. They don't all have all the answers for doing great things, but they all recognize the value in finding the first meaningful step and giving yourself every opportunity to do it. * This one's really huge, but all of these systems respect the importance of planning time and execution time and review time, without distraction. We just talked about Lean and "flow", and they don't own the concept, but what habits do these systems ask you to adopt? Taking the time in the daily review to really go through the actions that might be useful that day. The weekly review is going to expose you to lots of actions that, if you just did ‘em, might only take a minute. But if you start "doing" instead of "reviewing", you'll leave the review undone. Once that happens, how can you be sure that you're going to finish the thing you abandoned your review for? What if you get distracted during that? You can only do one thing at a time.
- So, of what we've seen today, what are some common threads? * We already talked about externalized memory and using something more reliable and less valuable than your brain to track the ideas you've had or the tasks you're tracking. Your brain works better and flows more smoothly when you're not trying to keep track of reminders. The inbox and the backlog and ubiquitous capture let us jot down any crazy idea - we don't have to lose them and we don't have to do anything with them immediately. * They drive productivity in a predictable way. No matter what system you're using, at the end of a cycle, you have some written record of what you were trying to accomplish, what you did to make that happen, and how close you got. Companies need that kind of visibility to make software development profitable and predictable. But you don't have to be a project manager to gain some of the same benefits in your personal life - finding out what's working for you and what isn't can be really eye-opening, and help you develop as a person and professional. * All of these systems involve eating an elephant one bite at a time. They don't all have all the answers for doing great things, but they all recognize the value in finding the first meaningful step and giving yourself every opportunity to do it. * This one's really huge, but all of these systems respect the importance of planning time and execution time and review time, without distraction. We just talked about Lean and "flow", and they don't own the concept, but what habits do these systems ask you to adopt? Taking the time in the daily review to really go through the actions that might be useful that day. The weekly review is going to expose you to lots of actions that, if you just did ‘em, might only take a minute. But if you start "doing" instead of "reviewing", you'll leave the review undone. Once that happens, how can you be sure that you're going to finish the thing you abandoned your review for? What if you get distracted during that? You can only do one thing at a time.
- * They're all adaptive practices, or they have that idea somewhere nearby. So what does that mean? That means that there are a lot of people that "do" GTD, and maybe they don't do the daily review. Or you go to a company that does more agile things than not. All of these processes involve a review, but the review needs to occasionally be about the process, and not necessarily always the work. If you've got a practice that isn't working for your team, use the review to measure how GTD or Scrum or Agile is working for you. Brainstorm improvements just the same way you’d brainstorm features and have a vision for the process really paying dividends. Don’t accept anything less. Adapt your process before you ditch the practices completely. * I think, also universal to personal productivity stuff and agile methods, is the idea that you decide late. You learn as you go and you expect change. You make a plan for the best, and you do as much as you can to prepare for the worst, but you don't get an unrealistic attachment to either outcome. * You might come from a traditional project management background and be asking where "priority" went. I've read some great writing over the past year on priority and I think I agree that people cling to the idea of priority, and managing priorities, in a vacuum of control about the actual things they're labeling. You can only do one thing at a time, and I hope that's a theme you're finding through this talk, as well - you will waste your time doing two things. So how can you have seven priorities? I can imagine you have seven things you want to do, and a guess about what order in which you want them to get done, but does calling something a priority make it any different than the rest of your actions? Priority, I feel, can get handed down to us from the same people that used to be handing down project plans. And under agile, the whole team determines what's going to happen and in what order - they're the experts on the execution. Priorities, in my experience, were decided on a hundred years ago. And we aren't being flexible if decorate what it is we're trying to do with bold or italics or anything else. If you have the vision for the end, that's your priority - getting there.
- * They're all adaptive practices, or they have that idea somewhere nearby. So what does that mean? That means that there are a lot of people that "do" GTD, and maybe they don't do the daily review. Or you go to a company that does more agile things than not. All of these processes involve a review, but the review needs to occasionally be about the process, and not necessarily always the work. If you've got a practice that isn't working for your team, use the review to measure how GTD or Scrum or Agile is working for you. Brainstorm improvements just the same way you’d brainstorm features and have a vision for the process really paying dividends. Don’t accept anything less. Adapt your process before you ditch the practices completely. * I think, also universal to personal productivity stuff and agile methods, is the idea that you decide late. You learn as you go and you expect change. You make a plan for the best, and you do as much as you can to prepare for the worst, but you don't get an unrealistic attachment to either outcome. * You might come from a traditional project management background and be asking where "priority" went. I've read some great writing over the past year on priority and I think I agree that people cling to the idea of priority, and managing priorities, in a vacuum of control about the actual things they're labeling. You can only do one thing at a time, and I hope that's a theme you're finding through this talk, as well - you will waste your time doing two things. So how can you have seven priorities? I can imagine you have seven things you want to do, and a guess about what order in which you want them to get done, but does calling something a priority make it any different than the rest of your actions? Priority, I feel, can get handed down to us from the same people that used to be handing down project plans. And under agile, the whole team determines what's going to happen and in what order - they're the experts on the execution. Priorities, in my experience, were decided on a hundred years ago. And we aren't being flexible if decorate what it is we're trying to do with bold or italics or anything else. If you have the vision for the end, that's your priority - getting there.
- * They're all adaptive practices, or they have that idea somewhere nearby. So what does that mean? That means that there are a lot of people that "do" GTD, and maybe they don't do the daily review. Or you go to a company that does more agile things than not. All of these processes involve a review, but the review needs to occasionally be about the process, and not necessarily always the work. If you've got a practice that isn't working for your team, use the review to measure how GTD or Scrum or Agile is working for you. Brainstorm improvements just the same way you’d brainstorm features and have a vision for the process really paying dividends. Don’t accept anything less. Adapt your process before you ditch the practices completely. * I think, also universal to personal productivity stuff and agile methods, is the idea that you decide late. You learn as you go and you expect change. You make a plan for the best, and you do as much as you can to prepare for the worst, but you don't get an unrealistic attachment to either outcome. * You might come from a traditional project management background and be asking where "priority" went. I've read some great writing over the past year on priority and I think I agree that people cling to the idea of priority, and managing priorities, in a vacuum of control about the actual things they're labeling. You can only do one thing at a time, and I hope that's a theme you're finding through this talk, as well - you will waste your time doing two things. So how can you have seven priorities? I can imagine you have seven things you want to do, and a guess about what order in which you want them to get done, but does calling something a priority make it any different than the rest of your actions? Priority, I feel, can get handed down to us from the same people that used to be handing down project plans. And under agile, the whole team determines what's going to happen and in what order - they're the experts on the execution. Priorities, in my experience, were decided on a hundred years ago. And we aren't being flexible if decorate what it is we're trying to do with bold or italics or anything else. If you have the vision for the end, that's your priority - getting there.
- So we’ve visited most of the things I wanted to talk to you about. My hope for you is that you look into GTD, and that you check out Agile or Scrum or Lean if you haven’t. If you have, I hope I’ve given you a chance to reflect on how this all comes together. The point here is to give people and project teams the ability to control what they’re doing and being really smart about those choices. Before we get done I just wanted to talk a little bit about productivity anti-patterns, and maybe find some things that you can bust through right away without having to read these books and visiting the tumblr and all that.
- The first pitfall. So you start doing some of this stuff, and you think, wow. Spending 15 minutes every day helps us get so much more done, and for an investment of a few hours every couple of weeks, we're so much more in touch, right? So if I spend the weekend setting up a meta-system of outlines and text files and perl scripts that manage this stuff for me, that's healthy, right? Or if I spend my 40-hour week trying out productivity software, instead of doing my stuff, that's gonna pay off really soon, right? There are people that take the challenge of busting through procrastination as the best excuse to procrastinate ever. There are Facebook groups about productivity. (Now that's not fair, there are Facebook groups about everything.) But my GOD. How do you get more done by joining a Facebook group?
- So I've made fun of those people for long enough. The next thing I want to talk about is allowing interruptions in the flow. We've talked about the hard work we're going to do to prepare ourselves to be in the zone for as long as we want. So, what's more valuable to us developers, two four-hour blocks or one eight-hour block? I know, trick question, right? How about two one-hour blocks versus one two-hour block. The two-hour block, uninterrupted, is way more than twice as valuable than the one-hour blocks, right? Uninterrupted time is how we do what we do, and we believe in these practices because they schedule and contain the interruptions in our day for statuses, reports, taking a break to make the build, even tracking down bugs are an interruption.
- And 90% of you have a thing on your desktop that makes a noise, pops something up on the screen, and gives you a juicy little preview of every email you get. And I don't know what your work habits are around this, but my guess is that most of you address it immediately. Email isn't your job, and it never has been. You didn’t interview on your emailing skills. But people get really amped up about knowing the instant they get an email.
- So we can spend the rest of the talk just staring at this slide, and I don't mind at all. I think it's that important. I hope you think about this and I hope you resolve that your email can wait for you. You can schedule two or three dashes of email a day. You can turn instant notification off and you can use your computer for your job. You can certainly turn off that thing that makes your phone DING when you get an email. I highly doubt you'll have to beg anyone for forgiveness for being three hours behind on email, and I think you'll appreciate the focus and quiet that that affords. Your attention is the most important thing you bring with you to work every day, and leaving distractions like that on your radar is giving that attention away. And while I think the same goes for texting and IM and twitter and facebook, some people misunderstand that and say "don't tell me how to do my job at my job". I think time certainly has to be carved out for that, but even that kind of interaction, for all the reasons we talked about before, is most rich and rewarding and satisfying when it's done without distraction. So do that, but don't make it this interrupt-driven thing.
- So again, I've beaten that horse to death. More productivity anti-patterns. I like planning meetings, and I like deciding late, but I don't like it when deciding late means deciding alone. If you do the majority of the breaking-up of large tasks into smaller ones with other people, and then you go back to your desks, it can pretty easily happen that you make important decisions without your team. So be on the lookout for that.
- Another thing I want to mention is about the purpose and visioning steps of the planning model. Maybe you've been in an environment, especially if you've been contracting, where you come in on a project that's already begun without you. And the first meeting they say they want that twitter client that automatically takes and posts pictures of you without your knowledge and you're like "WHY?" And they say they want to build a twitter client in the first place and you're like "WHY?" These are excellent questions, but you might find that senior management isn't super interested in defending their uncommunicated vision or, you know, self-obvious life purpose to you specifically. They might honestly be a little hostile about it. So it can be really helpful to ask these questions in a helpful and supportive way, like "help me understand how this will be used?" or "what does our happiest future customer think about this feature?" or something like that. Be calm, be polite, but don't stop short of getting that answer. You can't get the details right if you don't understand the big picture.
- And I also want to point out that the process is about a better end product, and not perfection at every step of the way. It isn't like you're going to adopt Agile and never make another mistake. Mistakes don't mean that you're doing Agile wrong, and your ability to react correctly is one of the indications that you're doing it right. So you shouldn't be hiding imperfections to make the process look better. Getting better all the time means that there are some things today that you'd change.
- So those are the things I wanted to talk to you about today. I want to remind you of the Tumblr site, gtdagile.tumblr.com, and invite you to contact me there, on twitter at dnord, reply to me or just use the hashtag #gtdagile and I will track you down.