1. ⁘  ⁘  ⁘
  2. ⁘  ⁘  ⁘
  3. Abo, Akinori 9
  4. aesthetics 19
  5. agile 30
  6. Albers, Josef 17
  7. Alexander, Christopher 135
  8. Alexander, Scott 5
  9. Allsopp, John 4
  10. Ammer, Ralph 6
  11. Anderson, Gretchen 7
  12. anxiety 9
  13. Appleton, Maggie 5
  14. Aptekar-Cassels, Wesley 5
  15. Arango, Jorge 4
  16. architecture 110
  17. art 86
  18. Asimov, Isaac 5
  19. attention 17
  20. Auping, Michael 6
  21. Aurelius, Marcus 14
  22. Bachelard, Gaston 12
  23. Baker, Nicholson 10
  24. beauty 58
  25. Behrensmeyer, Anna K. 7
  26. Bjarnason, Baldur 8
  27. Blake, William 5
  28. blogging 22
  29. body 11
  30. Boeing, Geoff 7
  31. boredom 9
  32. Botton, Alain de 38
  33. Brand, Stewart 4
  34. Bringhurst, Robert 16
  35. Brooks, Frederick P. 22
  36. Broskoski, Charles 6
  37. brutalism 7
  38. building 16
  39. bureaucracy 12
  40. Burnham, Bo 9
  41. business 15
  42. Byron, Lord 14
  43. Cagan, Marty 8
  44. Calvino, Italo 21
  45. Camus, Albert 13
  46. care 6
  47. Carruth, Shane 15
  48. Cegłowski, Maciej 6
  49. Cervantes, Miguel de 7
  50. chance 11
  51. change 16
  52. Chiang, Ted 4
  53. childhood 6
  54. Chimero, Frank 17
  55. choice 8
  56. cities 51
  57. Clark, Robin 3
  58. Cleary, Thomas 8
  59. Cleary, J.C. 8
  60. code 20
  61. collaboration 18
  62. collections 31
  63. color 23
  64. commonplace 11
  65. communication 31
  66. community 7
  67. complexity 11
  68. connection 24
  69. constraints 25
  70. construction 9
  71. content 9
  72. Corbusier, Le 13
  73. Coyier, Chris 4
  74. craft 66
  75. creativity 59
  76. crime 9
  77. Critchlow, Tom 5
  78. critique 10
  79. Cross, Nigel 12
  80. Cross, Anita Clayburn 10
  81. css 11
  82. culture 13
  83. curiosity 11
  84. cycles 7
  85. Danielewski, Mark Z. 4
  86. darkness 28
  87. Darwin, Will 10
  88. data 8
  89. death 38
  90. Debord, Guy 6
  91. decisions 10
  92. design 131
  93. details 31
  94. Dickinson, Emily 9
  95. Dieste, Eladio 4
  96. discovery 9
  97. doors 7
  98. Dorn, Brandon 11
  99. drawing 23
  100. Drucker, Peter F. 15
  101. Duany, Andres 18
  102. Eatock, Daniel 4
  103. economics 13
  104. efficiency 7
  105. Eisenman, Peter 8
  106. Eliot, T.S. 14
  107. emotion 8
  108. ending 14
  109. engineering 11
  110. Eno, Brian 4
  111. ethics 14
  112. euphony 38
  113. Evans, Benedict 4
  114. evolution 9
  115. experience 14
  116. farming 8
  117. fashion 11
  118. features 25
  119. feedback 6
  120. flaws 10
  121. Flexner, Abraham 8
  122. food 16
  123. form 19
  124. Fowler, Martin 4
  125. Franklin, Ursula M. 30
  126. friendship 6
  127. fun 7
  128. function 31
  129. games 13
  130. gardens 26
  131. Garfield, Emily 4
  132. Garfunkel, Art 6
  133. geography 8
  134. geometry 18
  135. goals 9
  136. Gombrich, E. H. 4
  137. goodness 12
  138. Graham, Paul 37
  139. graphics 13
  140. Greene, Erick 6
  141. Hamming, Richard 45
  142. happiness 17
  143. Harford, Tim 4
  144. Harper, Thomas J. 15
  145. Hayes, Brian 28
  146. heat 7
  147. Heinrich, Bernd 7
  148. Herbert, Frank 4
  149. Heschong, Lisa 27
  150. Hesse, Herman 6
  151. history 13
  152. Hoffman, Yoel 10
  153. Hofstadter, Douglas 6
  154. home 15
  155. Hoy, Amy 4
  156. Hoyt, Ben 5
  157. html 11
  158. Hudlow, Gandalf 4
  159. humanity 16
  160. humor 6
  161. Huxley, Aldous 7
  162. hypermedia 22
  163. i 18
  164. ideas 21
  165. identity 33
  166. images 10
  167. industry 9
  168. information 42
  169. infrastructure 17
  170. innovation 15
  171. interaction 10
  172. interest 10
  173. interfaces 37
  174. intuition 8
  175. invention 10
  176. Irwin, Robert 65
  177. Isaacson, Walter 28
  178. Ishikawa, Sara 33
  179. iteration 13
  180. Ive, Jonathan 6
  181. Jackson, Steven J. 14
  182. Jacobs, Jane 54
  183. Jacobs, Alan 5
  184. Jobs, Steve 20
  185. Jones, Nick 5
  186. Kahn, Louis 4
  187. Kakuzō, Okakura 23
  188. Kaufman, Kenn 4
  189. Keith, Jeremy 6
  190. Keller, Jenny 10
  191. Keqin, Yuanwu 8
  192. Ketheswaran, Pirijan 6
  193. Kingdon, Jonathan 5
  194. Kitching, Roger 7
  195. Klein, Laura 4
  196. Kleon, Austin 13
  197. Klinkenborg, Verlyn 24
  198. Klyn, Dan 20
  199. knowledge 29
  200. Kohlstedt, Kurt 12
  201. Kramer, Karen L. 10
  202. Krishna, Golden 10
  203. Kuma, Kengo 18
  204. language 20
  205. learning 30
  206. life 59
  207. light 31
  208. loneliness 12
  209. love 26
  210. Lovell, Sophie 16
  211. Lupton, Ellen 11
  212. Luu, Dan 8
  213. Lynch, Kevin 12
  214. MacIver, David R. 8
  215. MacWright, Tom 5
  216. Magnus, Margaret 12
  217. making 77
  218. management 14
  219. Manaugh, Geoff 27
  220. Markson, David 16
  221. Mars, Roman 13
  222. material 39
  223. math 16
  224. McCarter, Robert 21
  225. meaning 33
  226. media 16
  227. melancholy 52
  228. memory 29
  229. metaphor 10
  230. metrics 19
  231. microsites 49
  232. Miller, J. Abbott 10
  233. Mills, C. Wright 9
  234. minimalism 10
  235. Miyazaki, Hayao 30
  236. Mod, Craig 15
  237. modularity 6
  238. Mollison, Bill 31
  239. morality 8
  240. Murakami, Haruki 21
  241. music 16
  242. Müller, Boris 7
  243. Naka, Toshiharu 8
  244. names 11
  245. Naskrecki, Piotr 5
  246. nature 51
  247. networks 15
  248. Neustadter, Scott 3
  249. Noessel, Christopher 7
  250. notetaking 35
  251. novelty 11
  252. objects 16
  253. order 10
  254. ornament 9
  255. Orwell, George 7
  256. Ott, Matthias 4
  257. ownership 6
  258. Pallasmaa, Juhani 41
  259. Palmer, John 8
  260. patterns 11
  261. Patton, James L. 9
  262. Pawson, John 21
  263. perception 22
  264. perfection 7
  265. performance 17
  266. Perrine, John D. 9
  267. Petroski, Henry 24
  268. philosophy 6
  269. photography 20
  270. physics 6
  271. Pinker, Steven 8
  272. place 14
  273. planning 15
  274. Plater-Zyberk, Elizabeth 18
  275. poetry 13
  276. politics 9
  277. Pollan, Michael 6
  278. practice 10
  279. problems 31
  280. process 22
  281. production 7
  282. productivity 12
  283. products 21
  284. programming 9
  285. progress 16
  286. Pye, David 42
  287. quality 26
  288. questions 8
  289. Radić, Smiljan 20
  290. Rams, Dieter 16
  291. Rao, Venkatesh 14
  292. reading 16
  293. reality 13
  294. Reichenstein, Oliver 5
  295. religion 11
  296. Rendle, Robin 12
  297. repair 28
  298. research 17
  299. Reveal, James L. 4
  300. Richards, Melanie 3
  301. Richie, Donald 10
  302. Rougeux, Nicholas 4
  303. Rowe, Peter G. 10
  304. Rupert, Dave 4
  305. Ruskin, John 5
  306. Satyal, Parimal 9
  307. Saval, Nikil 13
  308. Sayers, Dorothy 32
  309. Schaller, George B. 7
  310. Schwulst, Laurel 5
  311. science 17
  312. seeing 36
  313. Sennett, Richard 45
  314. senses 11
  315. Seuss, Dr. 14
  316. Shakespeare, William 4
  317. Shorin, Toby 8
  318. silence 9
  319. Silverstein, Murray 33
  320. Simms, Matthew 19
  321. Simon, Paul 6
  322. simplicity 14
  323. Singer, Ryan 12
  324. skill 17
  325. Sloan, Robin 5
  326. Smith, Cyril Stanley 29
  327. Smith, Justin E. H. 6
  328. Smith, Rach 4
  329. socializing 7
  330. society 23
  331. software 68
  332. solitude 12
  333. Somers, James 8
  334. Sorkin, Michael 56
  335. sound 14
  336. space 20
  337. Speck, Jeff 18
  338. spirit 10
  339. streets 10
  340. structure 13
  341. Strunk, William 15
  342. Ström, Matthew 13
  343. style 30
  344. Sun, Chuánqí 15
  345. symbols 12
  346. systems 18
  347. Sōetsu, Yanagi 34
  348. Sōseki, Natsume 8
  349. Tanaka, Tomoyuki 9
  350. Tanizaki, Jun'ichirō 15
  351. taste 10
  352. Taylor, Dorian 16
  353. teaching 21
  354. teamwork 17
  355. technology 41
  356. texture 7
  357. thinking 31
  358. Thoreau, Henry David 8
  359. time 54
  360. Tolkien, J.R.R. 6
  361. tools 32
  362. touch 8
  363. transportation 16
  364. Trombley, Nick 44
  365. truth 15
  366. Tufte, Edward 31
  367. Turrell, James 6
  368. typography 25
  369. understanding 32
  370. urbanism 68
  371. ux 100
  372. Victor, Bret 9
  373. Viollet-le-Duc, Eugène 4
  374. vision 7
  375. visualization 34
  376. Voltaire 4
  377. wabi-sabi 8
  378. walking 23
  379. Wallace, David Foster 33
  380. Wang, Shawn 6
  381. war 7
  382. waste 12
  383. Watterson, Bill 4
  384. Webb, Matt 14
  385. Webb, Marc 3
  386. Weber, Michael H. 3
  387. Wechler, Lawrence 37
  388. whimsy 11
  389. White, E.B. 15
  390. Wirth, Niklaus 6
  391. wisdom 20
  392. Wittgenstein, Ludwig 7
  393. Woolf, Virginia 11
  394. words 35
  395. work 81
  396. writing 55
  397. Wurman, Richard Saul 18
  398. www 88
  399. Yamada, Kōun 5
  400. Yamashita, Yuhki 4
  401. Yudkowsky, Eliezer 17
  402. zen 38
  403. ⁘  ⁘  ⁘
  404. About
  405. RSS Feed
  406. Source

Agile Design and Development

Close
  • A late change in requirements is a competitive advantage

    A Quote by Mary Poppendieck
    1. ​​The State of Agile Software in 2018​​
    2. ​​Yagni​​
    3. ​​Complete and consistent requirements​​
    4. ​​Welcome changing requirements​​
    • agile
    • software
    • design
  • So that you can get feedback on it and make it better

    Fascinatingly, one of the other big complaints people had about agile is no iteration. I don't understand how being in an agile environment makes people less iterative, but somehow that seems to be the case. And I think it's because people misunderstand and think that agile is just about putting features out faster, and not about the important part, which is getting something in front of users faster so that you can get feedback on it and make it better.

    Laura Klein & Kate Rutter, Problems With Agile UX
    1. ​​The most rewarding iterations​​
    2. ​​To anticipate all the uses and abuses​​
    • agile
    • iteration
  • The most rewarding iterations

    Initial designs for sophisticated software applications are invariably complicated, even when developed by competent engineers. Truly good solutions emerge after iterative improvements or after redesigns that exploit new insights, and the most rewarding iterations are those that result in program simplifications.

    Evolutions of this kind, however, are extremely rare in current software practice—they require time-consuming thought processes that are rarely rewarded. Instead, software inadequacies are typically corrected by quickly conceived additions that invariably result in the well-known bulk.

    Niklaus Wirth, A Plea for Lean Software
    1. ​​So that you can get feedback on it and make it better​​
    2. ​​To anticipate all the uses and abuses​​
    • agile
    • iteration
  • Building is never a straight line

    Image from pketh.org on 2020-09-10 at 1.27.43 PM.png

    You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes.

    Building like this is never a straight line. Ideas and code get left on the cutting room floor because part of innovation is questioning whether what you made should exist. The process is cyclical and iterative, looking something like this.

    Pirijan Ketheswaran, Why Software is Slow and Shitty
    pketh.org
    1. ​​Follow the fun​​
    2. ​​Engineers who love their work​​
    • agile
    • iteration
  • Product owner vs. product manager

    A Product Owner is focused on output i.e. how quickly can we build these features?

    Product Management, on the other hand, is focused on outcomes i.e. why are we building these features in the first place?

    Henry Latham, Why Scrum is killing your product
    • agile
    • products

    Typically I've heard these defined exactly opposite.

  • Good design is redesign

    Good design is redesign. It's rare to get things right the first time. Experts expect to throw away some early work. They plan for plans to change.

    It helps to have a medium that makes change easy. When oil paint replaced tempera in the fifteenth century, it helped painters to deal with difficult subjects like the human figure because, unlike tempera, oil can be blended and overpainted.

    Paul Graham, Taste for Makers
    • mistakes
    • planning
    • agile
  • Finish designing as close to the end of a sprint as possible

    Image from matthewstrom.com on 2020-09-10 at 1.48.03 PM.jpeg

    The traditional process of delivering design, vs. delivering design just in time.

    Designers are often working at least one sprint ahead of engineers. While one sprint might not seem like much of a lag, a typical product team learns a lot after the design hand-off. ...Instead of working ahead, we should finish designing as close to the end of a sprint as possible: just-in-time design.

    Matthew Ström, Just-in-time Design
    • agile
    • ux
  • We optimize what we measure

    Scrum does not say “only focus on output”, but, unfortunately, humans will optimize for what they measure.

    If you worry about story points & hitting your estimations, that’s what is going to consume your attention. That is what you and your team will optimize for.

    And that is the core critique of Scrum as it is practiced: That it focuses a product team’s attention so heavily on delivery — on building lots of features quickly & efficiently — that teams fail to focus on spending time to discover what the right thing to build is.

    Henry Latham, Why Scrum is killing your product
    • optimization
    • agile
    • features
  • How we can do better

    It actually doesn't matter whether you actually have a formal retrospective. It doesn't matter whether you have four or five labels of things on your retro board, or exactly how you do the retro. What does matter is the notion of thinking about what we're doing and how we can do better, and it is the team that's doing the work that does this, that is the central thing.

    Martin Fowler, The State of Agile Software in 2018
    martinfowler.com
    • agile
    • process
    1. Good people are at the core of a truly agile organization – individuals over processes and tools.
    2. Those people should continue to evolve and change the process as they go.
  • The 'date scrum' anti-pattern

    Date Scrum is an R&D pattern where developers are asked to estimate software project requirements upfront for the entirety of the project. After the project is green lighted and the budget is set based on the final estimates, the team then holds daily scrums to status and manage risk as they “iterate” the solution toward the release date. To some, this approach is described as doing Waterfall in sprints.

    The fundamental problem with Date Scrum is that the team is de-focused from discovering the best solution. Instead they are heavily focused on delivering Something™ by the Date™. Engineers are problem solvers, and if the primary problem becomes delivering Something™ that will pass QA by the Date™, they will, with enough pressure, solve that exact problem.

    Gandalf Hudlow, Software that nobody wants
    iism.org
    • agile
  • That which requires caring

    Today's real world of technology is characterized by the dominance of prescriptive technologies.

    The temptation to design more or less everything according to prescriptive and broken-up technologies is so strong that it is even applied to those tasks that should be conducted in a holistic way. Any tasks that require caring, whether for people or nature, any tasks that require immediate feedback and adjustment, are best done holistically. Such tasks cannot be planed, coordinated, and controlled the way prescriptive tasks must be.

    Prescriptive technologies eliminate the occasions for decision-making and judgment in general and especially for the making of principled decisions. Any goal of the technology is incorporated a priori in the design and is not negotiable.

    Ursula M. Franklin, The Real World of Technology
    1. ​​Holistic and prescriptive technologies​​
    2. ​​The Nature and Art of Workmanship​​
    3. ​​The Nature and Aesthetics of Design​​
    • agile
    • software
    • process
  • Manifesto for Agile Software Development

    A Definition
    agilemanifesto.org

    We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    That is, while there is value in the items on the right, we value the items on the left more.

    1. ​​Deliver early and continuously​​
    2. ​​Welcome changing requirements​​
    3. ​​Self-organizing teams​​
    4. ​​Technical excellence and good design​​
    5. ​​Agility and sustainability​​
    • agile
    • process
    • software
  • Agile Scrum is not working

    An Article by Gene Bond
    iism.org

    The Agile founders had it right, one size doesn't fit all. What the founders perhaps didn’t foresee, or couldn’t agree on, is that in order for the world to scale and consume their wisdom, it had to be packaged as concrete practices, not as abstract classes with virtual methods to be defined in context. And to the proponents of Agile Scrum, give them their due, for their part, they made it concrete – Agile Scrum has been packaged and delivered. Yet much work remains to realize the promise of Agile, which in summary is, the realization of wise use of lightweight development practices and workflows that flexibly adapt to the changing and evolving needs of customers.

    1. ​​Beware SAFe, an Unholy Incarnation of Darkness​​
    • agile
  • Driving engineers to an arbitrary date is a value destroying mistake

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2021-11-17 at 6.15.52 PM.jpeg

    What happens when you apply date pressure to software engineers working on high value software projects? The engineers will focus on delivering Something™ by the Date™! This fatal flaw results in delivery of a Something™ full of chaos and features that nobody really wants or needs.

    1. ​​The Thing-deadline calculus​​
    2. ​​The value-destroying effect of arbitrary date pressure on code​​
    3. ​​Deadlines are bullshit​​
    • planning
    • agile
    • software

    "Whether it takes 2 rounds or 10 rounds of estimate squashing, most teams eventually capitulate and figure out what date is politically acceptable. They do this so they can go back to work and stop trying to predict the future with insufficient information."

  • Beware SAFe, an Unholy Incarnation of Darkness

    An Article by Sean Dexter
    seandexter1.medium.com

    The Lean Portfolio Management function that controls funding, are given sole authority to approve which Portfolio Epics move into each stream. Epics are not explanations about a problem that needs to be solved. They are pre-formed ideas about how best to solve those problems.

    Right away we can see signs of the old-school mindset of viewing teams as a “delivery” function instead of a strategic one. The high level thinkers come up with ideas, and the low level doers execute on those ideas. Ignored is the possibility that those closest to the work might be best equipped to make decisions about it. Escaping from this misguided mindset is a core goal of Agile thinking that SAFe fails to remotely accomplish.

    1. ​​SAFe is oriented around volume, not value​​
    1. ​​Why Scrum is killing your product​​
    2. ​​Agile Scrum is not working​​
    3. ​​The management strategy that saved Apollo 11​​
    4. ​​Design Systems, Agile, and Industrialization​​
    • agile
  • Why Scrum is killing your product

    An Article by Henry Latham
    uxdesign.cc
    1. ​​Product owner vs. product manager​​
    2. ​​We optimize what we measure​​
    1. ​​Beware SAFe, an Unholy Incarnation of Darkness​​
    • agile
    • management
    • software
    • products
  • Design Systems, Agile, and Industrialization

    An Article by Brad Frost
    bradfrost.com
    Image from bradfrost.com on 2020-09-10 at 1.41.24 PM.png

    I’ve come to the conclusion that “enterprise web development” is just regular web development, only stripped of any joy or creativity or autonomy. It’s plugging a bunch of smart people into the matrix and forcing them to crank out widgets and move the little cards to the right.

    In these structures, people are stripped of their humanity as they’re fed into the machine. It becomes “a developer resource is needed” rather than “Oh, Samantha would be a great fit for this project.” And the effect of all this on individuals is depressing. When people’s primary motivation is to move tickets over a column, their ability to be creative or serve a higher purpose are almost completely quashed. Interaction with other humans seems to be relegated to yelling at others to tell them they’re blocked.

    Reading “AS PER THE REQUIREMENTS” in tickets makes me dry heave. How did such sterile, shitty language seep into my everyday work?

    1. ​​Beware SAFe, an Unholy Incarnation of Darkness​​
    • www
    • agile
    • systems
    • creativity
  • The value-destroying effect of arbitrary date pressure on code

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2021-08-10 at 9.31.59 PM.jpeg

    The mandate from above is clear, just get it done! Avoid everything that's in the way: all advice, all expertise, all discovery efforts that detract from hitting the Date™!

    What these organizations don't realize is that all software change can be modeled as three components: Value, Filler and Chaos. Chaos destroys Value and Filler is just functionality that nobody wants. When date pressure is applied to software projects, the work needed to remove Chaos is subtly placed on the chopping block. Work like error handling, clear logging, chaos & load testing and other quality work is quietly deferred in favor of hitting the Date™.

    1. ​​Driving engineers to an arbitrary date is a value destroying mistake ​​
    • agile
    • planning
    • quality
    • discovery
  • Agile is Dead (Long Live Agility)

    An Article by Dave Thomas
    pragdave.me

    The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.

    …Let’s abandon the word agile to the people who don’t do things. Instead, let’s use a word that describes what we do. Let’s develop with agility.

    • You aren’t an agile programmer—you’re a programmer who programs with agility.
    • You don’t work on an agile team—your team exhibits agility.
    • You don’t use agile tools—you use tools that enhance your agility.

    /

    Individuals and Interactions over Processes and Tools
    Working Software over Comprehensive Documentation
    Customer Collaboration over Contract Negotiation, and
    Responding to Change over Following a Plan

    • agile
  • Traditional companies are losing because they mismanage software engineers

    An Article by Emma Watterson
    ewattwhere.substack.com

    Innovation is messy, and frankly Anti-Steve [Jobs] can’t figure out why you wouldn’t just tell people the right thing to build and skip all the trial and error that comes with innovation. Anti-Steve and his board of directors that keep him in place fundamentally believe that they know what needs to be built. Or at least that they can hire the messiah that will come down off the mountain and tell everyone what to build. There is no such messiah.

    1. ​​Steve Jobs​​
    • innovation
    • software
    • agile
    • management
  • Why we stopped breaking down stories into tasks

    An Article by Adam Silver
    adamsilver.io

    The Scrum process says to break down stories into tasks to make estimation easier, encourage collaboration and to be able to show more granular progress during a sprint.

    But after a few sprints, we decided to do the next sprint without creating tasks. As a result we drastically increased our velocity and never went back. Here I'll jot down some of the reasons we decided to do this:

    1. Breaking down stories into tasks is time consuming
    2. The tasks we came up with invariably would change as we worked on the stories
    3. Tasks are repetitive
    4. Tasks were often carried out in parallel
    5. Our estimates didn't improve
    6. It decluttered our task board
    7. It encouraged collaboration throughout the sprint

    While we started our process by following Scrum to the letter, we soon realised that breaking down stories into tasks was something that wasn’t worthwhile for us. In the end we realised that it was overplanning and poor use of our time. In the end we used that time to get on with the work and deliver at a significantly faster pace.

    1. ​​Why We Don't Do Daily Stand-Ups at Supercede​​
    • agile
  • Why We Don't Do Daily Stand-Ups at Supercede

    An Article by Jezen Thomas
    jezenthomas.com

    Yesterday I worked on the widget.
    Today I will work on the widget.
    I have no blockers.

    Are you asleep yet? The developers are. You promise them an intellectually stimulating work environment and what they end up with is drudgery.

    What value can be had from these meetings anyway? Using “alignment” for justification is so nebulous that it is essentially meaningless. Engineers align themselves. They talk. Especially if you hire good ones (which, you know, you’ll struggle to if you have a culture of coercing them into this kind of busywork). Where does the real discussion happen? It’s written down.

    1. ​​Why we stopped breaking down stories into tasks​​
    • agile
  • Software that nobody wants

    An Article by Gandalf Hudlow
    iism.org
    Image from iism.org on 2020-08-17 at 9.31.09 AM.jpeg

    Finding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.

    What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:

    • Not wanted - Company specified a solution to a problem that customers don't actually have
    • No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
    • Incorrect Packaging - Customers need a website, but the company created an iOS app instead
    • Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
    1. ​​The 'date scrum' anti-pattern​​
    • software
    • agile
    • products
    • features
  • Making sense of MVP

    An Article
    blog.crisp.se
    Image from blog.crisp.se on 2021-04-08 at 3.05.26 PM.jpeg

    Henrik Kniberg:

    The top scenario (delivering a front tire) sucks because we keep delivering stuff that the customer can’t use at all. If you know what you’re doing – your product has very little complexity and risk, perhaps you’ve built that type of thing hundreds of times before – then go ahead and just do big bang. Build the thing and deliver it when done.

    • agile
    • ux
  • Doing It Right

    An Article by Brad Frost
    bradfrost.com

    Doing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.

    • agile
    • goodness
    • features
    • ux
  • Planning doesn't make for better software

    A Fragment by Robin Rendle
    www.robinrendle.com

    My own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily standup. Each day we come to work, figure out what’s the most important thing that we could be doing, and then we—gasp!—actually do it.

    Watching so many other teams slowly flail about whilst they plan for quarter 3.2 of subplan A, whilst our team produces more work in a week than they all do combined in a quarter has been shocking to me.

    After four years of working in a large startup, I know what I always assumed was true: you don’t need a plan to make a beautiful thing. You really don’t. In fact, there’s a point where overplanning can be a signal of inexperience and fear and bullshit. The scrum board and the sprints and the inane meetings each and every day are not how you build another Super Mario 64.

    Instead all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.

    1. ​​Why Software is Slow and Shitty​​
    • planning
    • software
    • agile

    This article is a direct response to pketh's.

  • Agile as Trauma

    An Essay by Dorian Taylor
    doriantaylor.com

    The Agile Manifesto is an immune response on the part of programmers to bad management.

    1. ​​Many a corner office​​
    2. ​​Intramural brownie points​​
    3. ​​Feature factories​​
    • agile
    • management
  • Yagni

    A Definition by Martin Fowler
    martinfowler.com

    Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

    1. ​​A late change in requirements is a competitive advantage​​
    2. ​​Requirements proliferation​​
    • software
    • agile
    • features
    • planning
  • The State of Agile Software in 2018

    A Talk by Martin Fowler
    martinfowler.com

    On the surface, the world of agile software development is bright, since it is now mainstream. But the reality is troubling, because much of what is done is faux-agile, disregarding agile's values and principles. The three main challenges we should focus on are: fighting the Agile Industrial Complex and its habit of imposing process upon teams, raising the importance of technical excellence, and organizing our teams around products (rather than projects).

    1. ​​How we can do better​​
    2. ​​Taylorism in software​​
    1. ​​A late change in requirements is a competitive advantage​​
    2. ​​Make the change easy​​
    • agile
    • software
  • Product vs. Feature Teams

    An Article by Marty Cagan
    svpg.com

    This article is certain to upset many people.

    1. ​​Empowered product teams​​
    2. ​​Viability, usablity, feasibility​​
    3. ​​What went wrong?​​
    • features
    • software
    • agile

See also:
  1. software
  2. features
  3. planning
  4. process
  5. management
  6. products
  7. iteration
  8. ux
  9. design
  10. optimization
  11. www
  12. systems
  13. creativity
  14. goodness
  15. mistakes
  16. quality
  17. discovery
  18. innovation
  1. Gandalf Hudlow
  2. Henry Latham
  3. Martin Fowler
  4. Brad Frost
  5. Ursula M. Franklin
  6. Mary Poppendieck
  7. Marty Cagan
  8. Dorian Taylor
  9. Pirijan Ketheswaran
  10. Robin Rendle
  11. Laura Klein
  12. Kate Rutter
  13. Adam Silver
  14. Matthew Ström
  15. Paul Graham
  16. Niklaus Wirth
  17. Jezen Thomas
  18. Emma Watterson
  19. Dave Thomas
  20. Gene Bond
  21. Sean Dexter