-
Notifications
You must be signed in to change notification settings - Fork 7
/
Copy pathwildagile.html
798 lines (639 loc) · 38.2 KB
/
wildagile.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
<!DOCTYPE html>
<html lang="en">
<head>
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-BVDP76N9NB"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-BVDP76N9NB');
</script>
<!-- Facebook -->
<meta property="fb:app_id" content="329861788447703" />
<meta property="og:image" content="https://curtispoe.org/static/images/facebook/ovid-facebook.jpg" />
<meta property="og:image:alt" content="A black and white image of the author, Curtis “Ovid” Poe." />
<meta property="og:type" content="article" />
<meta property="og:url" content="https://curtispoe.org/wildagile.html" />
<meta property="og:title" content="WildAgile" />
<meta property="og:description" content="" />
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png">
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png">
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png">
<link rel="manifest" href="/site.webmanifest">
<link rel="canonical" href="https://curtispoe.org/wildagile.html" />
<!-- Basic Page Needs -->
<meta charset="utf-8">
<title>WildAgile</title>
<meta name="description" content="WildAgile">
<meta name="author" content="Curtis Poe">
<link rel="alternate" type="application/rss+xml" title="Subscribe to my technical blog" href="https://curtispoe.org/article.rss" />
<link rel="alternate" type="application/rss+xml" title="Subscribe to my personal blog" href="https://curtispoe.org/blog.rss" />
<!-- Mobile Specific Metas -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- FONT -->
<link href="//fonts.googleapis.com/css?family=Raleway:400,300,600" rel="stylesheet" type="text/css">
<!-- CSS -->
<link rel="stylesheet" href="/static/css/normalize.css">
<link rel="stylesheet" href="/static/css/skeleton.css">
<link rel="stylesheet" href="/static/css/main.css">
<link rel="stylesheet" href="/static/css/dialog.css">
<link rel="stylesheet" href="/css/layout.css">
<link rel="stylesheet" href="/static/css/image.css">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/4.7.0/css/font-awesome.min.css">
<!-- Favicon -->
<link rel="icon" type="image/png" href="images/favicon.png">
</head>
<body>
<!-- Primary Page Layout -->
<div class="container">
<div class="row books">
<div class="twelve columns header">
<ul>
<li><a href="https://www.amazon.com/Perl-Hacks-Programming-Debugging-Surviving/dp/0596526741/" target="_blank"><img src="/static/images/perl-hacks.jpg" alt="The cover of the 'Perl Hacks' book" class="book"></a></li>
<li><a href="https://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/" target="_blank"><img src="/static/images/beginning-perl.jpg" alt="The cover of the 'Beginning Perl' book" class="book"></a></li>
<li><img class="book" src="/static/images/profile.png" alt="An image of Curtis Poe, holding some electronic equipment in front of his face."></li>
</ul>
</div>
</div>
<div class="row title">
<!-- Back to top button -->
<span aria-hidden="true"><a href="#top" class="arrow"><button id="scrollToTopButton">↑</button></a></span>
<h1><a name="-title-no-title-found-"></a>WildAgile</h1>
<hr>
<div class="twelve columns header">
</div>
</div>
<div class="row">
<div class="two columns">
<span id="wasm_search"></span>
<!-- Note the usage of `type=module` here as this is an ES6 module -->
<script type="module">
// Use ES module import syntax to import functionality from the module
// that we have compiled.
//
// Note that the `default` import is an initialization function which
// will "boot" the module and make it ready to use. Currently browsers
// don't support natively imported WebAssembly as an ES module, but
// eventually the manual initialization won't be required!
// import { search, default as init } from './tinysearch_engine.js';
import { search, default as init } from '/static/js/search/tinysearch_engine.js';
window.search = search;
async function run() {
// First up we need to actually load the wasm file, so we use the
// default export to inform it where the wasm file is located on the
// server, and then we wait on the returned promise to wait for the
// wasm to be loaded.
//
// Note that instead of a string here you can also pass in an instance
// of `WebAssembly.Module` which allows you to compile your own module.
// Also note that the promise, when resolved, yields the wasm module's
// exports which is the same as importing the `*_bg` module in other
// modes
await init('/static/js/search/tinysearch_engine_bg.wasm');
}
run();
</script>
<script>
// And afterwards we can use all the functionality defined in wasm.
function doSearch() {
let value = document.getElementById("demo").value;
console.log(`Search query: ${value}`);
const results = search(value, 5);
console.log(`Results: ${results}`);
let ul = document.getElementById("results");
ul.innerHTML = "";
for (i = 0; i < results.length; i++) {
var li = document.createElement("li");
let [title, url] = results[i];
let elemlink = document.createElement('a');
elemlink.innerHTML = title;
elemlink.setAttribute('href', url);
li.appendChild(elemlink);
ul.appendChild(li);
}
}
// https://stackoverflow.com/questions/47879864/how-can-i-check-if-a-browser-supports-webassembly#:~:text=There%20are%20a%20few%20ways,js).
const wasm_supported = (() => {
try {
if (typeof WebAssembly === "object"
&& typeof WebAssembly.instantiate === "function") {
const module = new WebAssembly.Module(Uint8Array.of(0x0, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00));
if (module instanceof WebAssembly.Module)
return new WebAssembly.Instance(module) instanceof WebAssembly.Instance;
}
} catch (e) {
}
return false;
})();
if (!wasm_supported) {
// don't even show them the search box if they don't have web assembly
// document.getElementById("wasm_search").innerHTML = "Your browser does not support WebAssembly. Please use a modern browser.";
}
else {
document.getElementById("wasm_search").innerHTML = '<div id="search"><strong>Search</strong><input type="text" id="demo" onkeyup="doSearch()"><ul id="results"></ul><div><hr>';
}
</script>
<ul>
<li><a href="/index.html">Home</a></li>
<li><a href="/articles.html">Articles</a> <a href="/article.rss"><img border="0" alt="Subscribe to Articles by Ovid" src="/static/images/rss.png" width="12" height="12"/></a></li>
<li><a href="/blog.html">Blog</a> <a href="/blog.rss"><img border="0" alt="Subscribe to Blogs by Ovid" src="/static/images/rss.png" width="12" height="12"/></a></li>
<li><a href="/videos.html">Talks</a></li>
<li><a href="/hireme.html">Hire Me</a></li>
<li><a href="/wildagile.html">WildAgile</a></li>
<!-- <li><a href="/tau-station.html">Tau Station</a></li> -->
<li><a href="/starmap.html">Starmap</a></li>
<li><a href="/escape.html"><strong>Escape!</strong></a></li>
</ul>
<hr>
<strong>Find me on ...</strong>
<ul>
<li><a href="https://www.linkedin.com/in/curtispoe/">LinkedIn</a></li>
<li><a href="https://github.com/Ovid/">GitHub</a></li>
<li><a href="https://fosstodon.org/@ovid" rel="me">Mastodon</a></li>
<li><a href="https://bsky.app/profile/ovid.bsky.social">Bluesky</a></li>
</ul>
<strong>Tags</strong>
<ul class="cloud" role="navigation" aria-label="Tag cloud for Ovid's site">
<li><a href="/tags/programming.html" data-weight="9">Software</a></li>
<li><a href="/tags/business.html" data-weight="6">Business</a></li>
<li><a href="/tags/oop.html" data-weight="5">OOP</a></li>
<li><a href="/tags/perl.html" data-weight="5">Perl</a></li>
<li><a href="/tags/ai.html" data-weight="4">AI</a></li>
<li><a href="/tags/corinna.html" data-weight="4">Corinna</a></li>
<li><a href="/tags/databases.html" data-weight="3">Databases</a></li>
<li><a href="/tags/personal.html" data-weight="3">Personal</a></li>
<li><a href="/tags/politics.html" data-weight="3">Politics</a></li>
<li><a href="/tags/space.html" data-weight="3">Space</a></li>
<li><a href="/tags/writing.html" data-weight="3">Writing</a></li>
<li><a href="/tags/family.html" data-weight="2">Family</a></li>
<li><a href="/tags/math.html" data-weight="2">Math</a></li>
<li><a href="/tags/science.html" data-weight="2">Science</a></li>
<li><a href="/tags/expat.html" data-weight="1">Moving Abroad</a></li>
</ul>
</div>
<div class="ten columns verticalLine article">
<article id="article">
<p><nav role="navigation" class="table-of-contents">
<ul>
<li class="indent-1"><a href="#preface">Preface</a></li>
<li class="indent-1"><a href="#the-problem">The Problem</a></li>
<li class="indent-2"><a href="#background">Background</a></li>
<li class="indent-2"><a href="#what-is-wildagile">What is WildAgile?</a></li>
<li class="indent-2"><a href="#benefits-of-wildagile">Benefits of WildAgile</a></li>
<li class="indent-2"><a href="#the-workflow">The Workflow</a></li>
<li class="indent-2"><a href="#assumptions-made-in-creating-wildagile">Assumptions Made in Creating WildAgile</a></li>
<li class="indent-1"><a href="#the-details">The Details</a></li>
<li class="indent-2"><a href="#wildagile-roles">WildAgile Roles</a></li>
<li class="indent-2"><a href="#wildagile-process">WildAgile Process</a></li>
<li class="indent-2"><a href="#wildagile-remote-teams">WildAgile Remote Teams</a></li>
<li class="indent-1"><a href="#discussion">Discussion</a></li>
<li class="indent-2"><a href="#extending-wildagile">Extending WildAgile</a></li>
<li class="indent-2"><a href="#wildagile-compliant">WildAgile-Compliant</a></li>
<li class="indent-1"><a href="#glossary">Glossary</a></li>
<li class="indent-1"><a href="#summary">Summary</a></li>
</ul>
</nav>
<hr></p>
<h1><a name="preface"></a>Preface</h1>
<p>Some of you may be familiar with <a href="https://en.wikipedia.org/wiki/Alistair_Cockburn" target="_blank">Alistair
Cockburn</a> <span class="fa fa-external-link fa_custom"></span>, one of the founders of the modern agile movement. I recently had
a brief email discussion with him regarding WildAgile. After reading this
article, he replied (and I’m quoting with permission):</p>
<blockquote>I think you should continue with what you’re doing, and get more
companies to go along, that will be really great for the world.</blockquote>
<p>WildAgile is an attempt to return agile to its agile roots. So let’s get
started.</p>
<h1><a name="the-problem"></a>The Problem</h1>
<p>I’ve worked with a variety of successful companies, many of which are Agile
in nature, but when discussion of Agile arises, the conversation often goes
like this:</p>
<blockquote>Them: We’re agile.<br>
<br>
Me: Ah! Do you use Scrum, XP, something else?<br>
<br>
Them (embarrassed): Um, er, we just sort of get things
done.</blockquote>
<p>And they do! And yet they’re embarrassed by the lack of a name for what they
actually do. I often hear something like “we do a modified scrum”, meaning
they have sprints and stand ups and that’s about it.</p>
<p>Thus, I developed <strong>WildAgile</strong>, an Agile methodology that is
so agile that it describes what <em>actually happens in the wild</em> instead
of what you are supposed to do. It’s designed for very rapid delivery, with
<strong>Just Enough Process</strong> to provide order to the chaos. Though I
draw inspiration from Scrum, XP, Kanban and Crystal Clear, there’s a good
chance that claiming your team is WildAgile-compliant merely involves reading
this and saying “yup, we’re WildAgile-compliant.”</p>
<p>All <strong>bolded</strong> terms are explained in the description and also
in a short glossary near the end. There aren’t many bolded terms because I
focus on process, not terminology. The “WildAgile Roles” and “WildAgile
Process” sections are all you really need to read to understand WildAgile.
Everything else is just providing the rationale. This documentation of
WildAgile is released under the <a title="Creative Commons Attribution 2.5
Generic License" href="http://creativecommons.org/licenses/by/2.5/"
target="_blank">CC by 2.5 license</a>. This means that you’re free to do
anything you want with this documentation, including sell it, so long as you
credit the original authors (just linking to this page is fine). See the <a
title="Creative Commons Attribute 2.5 Generic License"
href="http://creativecommons.org/licenses/by/2.5/" target="_blank">license
description</a> for details.</p>
<h2><a name="background"></a>Background</h2>
<p>When teams transition into an Agile environment, the changes can be
intimidating. XP practitioners regularly complain about pair programming (and
hence don’t do it). Scrum practitioners often ignore retrospectives. System
administrators get upset about a “failed sprint” because they had to stop all
work to fix a critical security issue.</p>
<p>And yet work still gets done. Developers finish a task and take a new task.
Wash, rinse, repeat. By formalizing this I introduce Just Enough Process to
get things done in a structured manner. “Just Enough Process” is an appropriate
tagline for management. “Shut Up And Write Some Code” is an appropriate tagline
for developers.</p>
<h2><a name="what-is-wildagile"></a>What is WildAgile?</h2>
<p>WildAgile is appropriate for small teams where the entire code base can be
roughly understood by a single programmer. That doesn’t mean that someone
points to a given library and the developer knows how it’s coded, or exactly
what it does, but the developer should at least have a <em>sense</em> of what
it’s for. Because WildAgile is designed to avoid <a title="Code that will be
unmaintainable if the developer is hit by a bus"
href="http://c2.com/cgi/wiki?HitByBus" target="_blank">bus-sensitive code</a>,
this might be better for small to medium sized codebases, though I know of a
huge company, with a codebase exceeding one million lines, which is very
profitable and follows a process not quite unlike WildAgile, despite having
hundreds of developers. What this means is that as a developer transitions
from <strong>Apprentice</strong> to <strong>Veteran</strong> (described
later), they won’t always know how to solve a problem, but they’ll know where
to look to solve that problem.</p>
<p>You may think of WildAgile as a <em>transitional</em> methodology. This
means that you may adopt WildAgile before your team transitions to a more
formal method (it’s particularly well-suited as a transition to Scrum), but
many teams find that WildAgile is all they need.</p>
<h2><a name="benefits-of-wildagile"></a>Benefits of WildAgile</h2>
<ul>
<li>High morale: developers can focus on getting stuff done.</li>
<li>Rapid development: developers can focus on getting stuff done.</li>
<li>Ease of implementation: developers can focus on getting stuff done.</li>
</ul>
<p>You may notice a theme in this.</p>
<p>That being said, WildAgile is not without its risks. These will be discussed
on an ad hoc basis as I discuss its components. However, I do not recommend
WildAgile when a potential for real harm occurs. For example, I probably would
not use WildAgile to design guidance systems for planes or medical radiology
software. I also do not recommend WildAgile for highly complex projects in
which the majority of developers cannot understand how various components fit
together.</p>
<h2><a name="the-workflow"></a>The Workflow</h2>
<p>Just to make it clear what I’m focusing on, here’s the development
workflow for one company I’ve worked with:</p>
<p><figure class="image">
<img src="/static/images/workflow.png" width="600" alt="Complicated
flowchart showing the workflow one company has adopted for every task
that need to be completed.">
<figcaption>Everyone ignored this and still got work done.</figcaption>
</figure></p>
<p>Every task is expected to follow that process. If you have to break a task
into new tasks, you’re still expected to follow that process for every subtask.
Developers in this company regularly ignore this workflow and still get things
done, but management gets frustrated because they can’t see the exact step that
every task is at.<span aria-label="Open Footnote" class="open-dialog" id="open-dialog-1"> <i class="fa fa-clipboard fa_custom"></i> </span></p>
<p>WildAgile strives to implement the following workflow:</p>
<p><img class="alignCenter" alt="A simple workflow with just a start node and
a finish node."
src="static/images/start_finish-209x300.png" width="209" height="300"/></p>
<p>Things are not this simple in the real world, but I strongly advise clients
to understand the Platonic Ideal of Agile and constantly strive towards
it.</p>
<h2><a name="assumptions-made-in-creating-wildagile"></a>Assumptions Made in Creating WildAgile</h2>
<p><strong></strong>Drawing on work from Alistair Cockburn’s <a title="Crystal
Clear PDF"
href="http://users.dcc.uchile.cl/~nbaloian/cc1001-03/ejercicios/crystalclearV5d.pdf"
target="_blank">Crystal Clear</a> methodology, I assume that the following
three requirements are the most important in developing high-quality
products.</p>
<ol>
<li>Easy and regular team communication</li>
<li>Rapid delivery</li>
<li>Expert customer access</li>
</ol>
<p>Many experienced individuals feel that if these three requirements are met,
a positive-feedback loop is created which allows the team to rapidly build and
improve upon products. Any obstacles to these three requirements being met are
detrimental to the productivity of any WildAgile-compliant team.</p>
<p>I am also a firm believer in the Pareto Rule: 80% of your benefits will
stem from 20% of your actions. WildAgile attempts to implement that 20% of
actions that give you majority of benefits of Agile. In fact, I’ve found that
for many smaller teams, attempting to implement the other 80% of actions may
actually be detrimental as you spend more time fighting process instead of
developing software. This is due to a fundamental tension in many Agile
methodologies: it’s an attempt to <em>create</em> processes that are designed
to <em>minimize</em> process. It’s a delicate balance that is easy to get
wrong.</p>
<p>Cockburn’s (pronounced <em>coe-burn</em>, if you’re curious) team
requirement actually said “colocation” of the team, requiring team members to
be physically near each other. This ignores today’s reality. Savvy companies
realize they have access to an entire world of developers if they are willing
to have remote workers. Thus, tools such as Slack, Google Hangouts, Skype,
Zoom, and other communication channels should be employed to ensure that
someone is always available to help. I’ve seen WildAgile work in teams that
are also temporally diverse (separated by many time zones), but this does
introduce challenges that require extra attention to team communication.</p>
<p>Note: if you don’t have much experience with remote teams, please read my
<a href="/articles/managing-a-remote-team.html">Managing a Remote
Team</a> article.</p>
<h1><a name="the-details"></a>The Details</h1>
<p>Yeah, yeah. That’s enough blathering. What’s it all about?</p>
<h2><a name="wildagile-roles"></a>WildAgile Roles</h2>
<p>There are only three roles defined in WildAgile.</p>
<ol>
<li>Developer</li>
<li>Team Lead</li>
<li>Product Owner</li>
</ol>
<p><strong>Developers</strong>, of course, develop the product. They take
<strong>tasks</strong>, finish them, and then take new tasks.</p>
<p>The <strong>Team Lead</strong> (often shortened to “Lead”) is also a
developer. The Lead is also the expert who knows the entire system and can be
relied upon to answer questions and provide excellent feedback. Developers
decide how they’re going to implement something, but if there is a problem, the
Lead has final say. The Lead should defer to the Developer whenever possible
and offer constructive advice when appropriate. Team Leads support, not
direct.</p>
<p>The <strong>Product Owner</strong> (<strong>PO</strong>), similar to Scrum,
maintains the product <strong>backlog</strong>. However, there is no “sprint
backlog” because there are no sprints. The PO is responsible for knowing the
full backlog and being able to answer any business question related to them.
It’s preferred if the PO can also answer technical questions as well, but I
realize that it’s often hard to find someone who is both a business expert and
a technical expert. Thus, the PO focuses on business excellence and the Team
Lead focuses on technical excellence.</p>
<p><em><strong>Note:</strong> if you’re new at this and you’re overwhelmed by
prioritizing the product backlog, <a href="/articles/project-management-in-three-numbers.html">read my
article “Project Management in Three Numbers”</a>. It makes this much
easier.</em></p>
<p>Additionally, the PO serves as the proxy for the customer. They are the
“expert customer” that you should be able to rely on at all times to answer
questions about the product. The PO is encouraged to practice an embedded
anthropology approach to knowing their customers. This means that they should
use the product, but also work directly with real customers (both new and
existing) to understand customer needs and desires.</p>
<p>As an aside, the customer should always be referred to as “the customer” and
<em>never</em> as “the user.” In English, the word “user” can have a negative
connotation and in our experience it is often used in a condescending manner.
Customers are people too.</p>
<h2><a name="wildagile-process"></a>WildAgile Process</h2>
<p>Every day, a 15-minute time-boxed <strong>stand up</strong> is held. It’s
recommended to be at the end of the day to ensure that what you did is fresh in
your mind, but this is not a requirement. The stand up begins with the
<strong>Summary</strong>. Before the stand up, the product owner should briefly
discuss where you’ve been and where you are going. Any interesting future
issues for the team should be mentioned at this time. The benefit of the
Summary is that it helps remind developers of the context of their work and
better understand upcoming priorities. This makes it easier to choose
appropriate tasks.</p>
<p>After the Summary, each team member should explain:</p>
<ul>
<li>What they did today</li>
<li>What they’ll do tomorrow</li>
<li>Any blockers they have</li>
</ul>
<p>On a daily basis, every team member is allowed, even encouraged, to improve
the code base. Add a Makefile target to rebuild the project. Factor out common
code. Move test data into fixtures. The developer is expected to mention this
in the stand up and it is the responsibility of the Team Lead and the PO to
rein in developers who spend too much time “improving” instead of “developing”
(and vice versa!).</p>
<p><strong>Tasks</strong> are “things a developer can do.” Every task is done
in a separate branch (when appropriate) and when it is done and the tests pass,
it is merged back into the “master”, “trunk”, or “integration” branch, or
whatever you call it. Tasks are expected to include tests, when feasible, and
if merging the code breaks any test, the developer responsible for merging the
code should be the person responsible for fixing the tests (again, when
feasible). Details about how to manage source control are left to the team.</p>
<p>Tasks should be as short as possible. Any task expected to take over a
certain amount of time (a week is a good limit) should, if possible, be broken
down into smaller tasks, each of which can add value even if the overall task
is cancelled.</p>
<p>When a task is finished, the developer independently chooses their next
task, keeping in mind the context provided by the last Summary. They should
prioritize tasks assigned to them, high value tasks, and quick tasks. It is the
responsibility of the Team Lead and PO to guide developers to suitable tasks if
the team member is regularly making poor choices on their next task.</p>
<p>If enough open tasks are open, it is the <em>optional</em> responsibility of
the PO to designate <strong>Priority</strong> tasks. If a new task is to be
chosen, they should be chosen from Priority tasks. If a team member is
unconvinced of their ability to accomplish any Priority tasks, they should
speak to the Team Lead for guidance.</p>
<p>Obviously, if a <strong>critical issue</strong> arises, any task can be
stopped and the Team Lead can assign someone to tackle the issue. There is no
formal structure to this because WildAgile is designed to be as lightweight as
possible.</p>
<p>New team members (<strong>Apprentices</strong>) are initially encouraged to
focus on a single area to become very comfortable with the business rules.
After the Team Lead and PO agree that the developer has become comfortable in
their area, they become <strong>Veterans</strong>. Veterans are strongly
encouraged to regularly choose tasks in areas of the code base they have less
experience with. If Veterans do not regularly work on different areas of the
code, they may find themselves focusing on a small subset of the code base. Not
only does this limit the Veteran’s ability to contribute to the code base, it
encourages other developers to not work on areas of the code that it’s assumed
the Veteran will work on. It is the responsibility of the Team Lead and the PO
to ensure that Veterans are regularly choosing tasks outside of their area of
expertise in order to spread knowledge of the system.</p>
<p>Team Leads and POs do not promote Apprentices to Veterans until the Apprentice:</p>
<ul>
<li>Appears to understand the business (not the code base!)</li>
<li>Is writing solid code</li>
<li>Is writing appropriate tests</li>
</ul>
<p>Releases are not described in the WildAgile process, but it’s suitable for
both continuous deployment and regular releases (as one might expect from a
sprint or iteration).</p>
<p>Note that in our experience, Apprentices get promoted to Veterans fairly quickly
and in established teams, you generally only have Veterans, thus reducing the
distinction between the two.</p>
<h2><a name="wildagile-remote-teams"></a>WildAgile Remote Teams</h2>
<p>Many companies are discovering the competitive advantage of having remote
workers:</p>
<ul>
<li>You have access to a much wider pool of developers.</li>
<li>You don’t need to pay for office space.</li>
<li>Developer salaries are easier to control.</li>
</ul>
<p>That last point is what is driving much of this and is causing some
industry disruption. When you realize that your $150K a year developer can be
had for $30K, that opens up possibilities you may not have had before,
particularly when you find that expert you couldn’t find locally.</p>
<p>However, companies often feel uncomfortable with remote workers because
they’re less used to this. WildAgile works well with remote workers, but a key
change needs to be made: stand ups.</p>
<p>For colocated teams, time-boxing a stand up to 15 minutes works well
because if there are issues later, a developer can simply walk over to someone
and ask. That doesn’t work with remote workers. Instead, you simply extend the
stand up time. I recommend 30 to 45 minutes. Yes, this means you’ll be
spending more time in the stand up, but you can communicate more about what
you’re doing, and how you are doing it. This helps to catch problems early on
and minimizes the need for developers to distract other developers while they’re
working.</p>
<h1><a name="discussion"></a>Discussion</h1>
<p>The idea behind WildAgile is not to formalize a new methodology, but to put
a name on a practice that is already moderately well-known but followed in an
almost embarrassed manner. It’s a way of following a set of reasonable
development guidelines that can eventually move on to a more appropriate Agile
development process. Think of it as “Agile light”, if you will. By putting a
name to it, you can say “we are WildAgile-compliant” instead of “eh, we just
get things done.”</p>
<p>In short, WildAgile eliminates the silo problem of cowboy coding, but allows
the extremely rapid development of products. It encourages creativity while
having Just Enough Process to keep development on target.</p>
<p>By separating developers into Apprentices and Veterans, I create the
psychological incentive to explore more of the code base. Ambitious developers
quickly want to shed the Apprentice label and fully participate in the rest of the
team’s work. However, by starting out by becoming an expert in one part of the
system, the Apprentice can quickly gain confidence in their ability to participate
and make a meaningful impact on the system.</p>
<p>Hiring for a WildAgile process is important. You want developers who are
comfortable in a fluid environment, but can also appreciate business concerns.
There is a tremendous amount of freedom in WildAgile and it’s very easy for
someone to get carried away and try to “perfect” (*cough*) everything at the
expense of adding value to the company. Thus, both the Team Lead and the PO are
required to keep things in check.</p>
<p>Also, WildAgile benefits from skilled, conscientious developers. It’s very
easy to spend too much time “perfecting” your code, but it’s also easy to spend
too much time pushing out new features and ignoring technical debt. This is a
hard balance to maintain. WildAgile does not address this directly because
every project is different and every company is different. However, as a
guideline WildAgile suggests that the PO advocate for features and the Team
Lead advocate for technical debt management, but each should be able to
understand and even agree with the other’s point of view. If you can’t balance
these two needs, you’re likely to have long-term problems.</p>
<p>In practice, I find this development model to be very successful for small
projects. The pace of development is very rapid and I don’t find that code
quality is significantly worse than for other methodologies. The most
significant obstacle that I find is appropriately managing the backlog.
Typically backlog items are merely added to a ticketing system, such as Jira,
RT, Redmine or Trac. This does not scale well unless the PO is competent at
managing the tickets and creating appropriate Priority tasks.</p>
<h2><a name="extending-wildagile"></a>Extending WildAgile</h2>
<p>Do you like retrospectives? Do them. Do you need milestones? Great! Do you
like pair programming? That’s fine. WildAgile is designed to describe the
core of what successful development teams are already doing. Items outside of
this core are deliberately unspecified to allow you to customize WildAgile to
your heart’s content. A guiding principle of WildAgile should be “whatever
works for you.”</p>
<p>You are <em>encouraged,</em> nay, <em>required</em> to customize WildAgile
to meet the needs of your team.</p>
<h2><a name="wildagile-compliant"></a>WildAgile-Compliant</h2>
<p>Many teams are already WildAgile-compliant without even
knowing it. If you follow Scrum, you’re probably WildAgile-compliant. If you
follow XP, you’re probably WildAgile-compliant. If you do ad hoc development,
you may already be WildAgile-compliant. Don’t stress too much about it. I
don’t envision WildAgile-compliance courses. I don’t envision
WildAgile-certifications (though if you pay me enough money, I’m happy to
give a one-hour presentation and print up WildAgile-certifications for
you).</p>
<h1><a name="glossary"></a>Glossary</h1>
<dl>
<dt>Apprentice</dt><dd>A new developer becoming an expert on part of the system.<span aria-label="Open Footnote" class="open-dialog" id="open-dialog-2"> <i class="fa fa-clipboard fa_custom"></i> </span></dd>
<dt>Backlog</dt><dd>Tasks which have not yet been done.</dd>
<dt>Critical Issue</dt><dd>Something which must be done <em>now</em>.</dd>
<dt>Just Enough Process</dt><dd>Only enough process to provide structure.</dd>
<dt>Priority</dt><dd>Tasks which should be taken before other tasks.</dd>
<dt>Product Owner (PO)</dt><dd>The proxy for the customer. Maintains backlog and assigns Priorities.<span aria-label="Open Footnote" class="open-dialog" id="open-dialog-3"> <i class="fa fa-clipboard fa_custom"></i> </span></dd>
<dt>Stand up</dt><dd>An end-of-day “what I did, will do, and blockers” explanation for every developer.</dd>
<dt>Summary</dt><dd>The PO’s business-focused summary of the project status, given immediately prior to the stand up.</dd>
<dt>Task</dt><dd>Something a developer can do.</dd>
<dt>Team Lead</dt><dd>The code base expert. Should also understand business concerns.</dd>
<dt>Team</dt><dd>All developers, including the Team Lead.</dd>
<dt>Veteran</dt><dd>A developer who is allowed to work on all parts of the system.</dd>
<dt>WildAgile</dt><dd>“Real World” Agile.</dd>
</dl>
<p>There is very little terminology and most of this fits what you already
know.</p>
<h1><a name="summary"></a>Summary</h1>
<p>Shut up and write some code.</p>
<p>Seriously, there is nothing radical about the above and it mirrors what
people are actually doing rather than forcing them to adopt a new methodology
all at once. You might view it as a gentle transition to more formal Agile
methodologies. Or, if it’s working fine for you, it might remain your Agile
methodology. Its very loose structure presents some risks, but a key component
of managing risk is being aware of it.</p>
</article>
<p><strong>Please leave a comment below!</strong></p>
<p>If you'd like top-notch consulting or training, <a
href="mailto:[email protected]">email me</a> and let's discuss
how I can help you. Read my <a href="/hireme.html">hire me</a> page
to learn more about my background.</p>
</div>
</div>
<!-- End Document
–––––––––––––––––––––––––––––––––––––––––––––––––– -->
<div class="row">
<div class="two columns">
<p></p>
</div>
<div class="ten columns">
<hr>
<p>Copyright © 2018-2025 by Curtis “Ovid” Poe.</p>
</div>
</div>
<div id="disqus_thread"></div>
<div class="row">
<div class="twelve columns">
<script>
var disqus_config = function () {
this.page.url = "https://curtispoe.org/wildagile.html";
this.page.identifier = "wildagile";
this.page.title = "WildAgile";
};
(function() { // DON'T EDIT BELOW THIS LINE
var d = document, s = d.createElement('script');
s.src = 'https://https-ovid-github-io.disqus.com/embed.js';
s.setAttribute('data-timestamp', +new Date());
(d.head || d.body).appendChild(s);
})();
</script>
<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
</div>
</div>
</div>
<!-- footnotes https://bitsofco.de/accessible-modal-dialog/ -->
<div class="dialog-overlay" tabindex="-1"></div>
<script type="text/javascript" src="/static/js/Dialog.js"></script>
<div id="dialog-1" class="dialog" role="dialog" aria-labelledby="note-1" aria-describedby="note-description-1">
<strong id="note-1">Footnotes</strong>
<p id="note-description-1" class="sr-only">Note number 1</p>
<div>For added fun, note that there is only
one exit point in that workflow. If something proves unworkable <em>at the
specification step</em> or beyond, you have no official recources to abandon
that task. Needless to say, some developers at that company suffered from
very poor morale.</div>
<button type="button" aria-label="Close Navigation" class="close-dialog" id="close-dialog-1"> <i class="fa fa-times"></i> </button>
</div>
<script>
var dialogOverlay = document.querySelector('.dialog-overlay');
var myDialog1 = new Dialog(document.querySelector('#dialog-1'), dialogOverlay);
myDialog1.addEventListeners('#open-dialog-1', '#close-dialog-1');
</script>
<div id="dialog-2" class="dialog" role="dialog" aria-labelledby="note-2" aria-describedby="note-description-2">
<strong id="note-2">Footnotes</strong>
<p id="note-description-2" class="sr-only">Note number 2</p>
<div>I don't actually use this term in day-to-day work, but it's useful to make it clear who we're talking about.</div>
<button type="button" aria-label="Close Navigation" class="close-dialog" id="close-dialog-2"> <i class="fa fa-times"></i> </button>
</div>
<script>
var dialogOverlay = document.querySelector('.dialog-overlay');
var myDialog2 = new Dialog(document.querySelector('#dialog-2'), dialogOverlay);
myDialog2.addEventListeners('#open-dialog-2', '#close-dialog-2');
</script>
<div id="dialog-3" class="dialog" role="dialog" aria-labelledby="note-3" aria-describedby="note-description-3">
<strong id="note-3">Footnotes</strong>
<p id="note-description-3" class="sr-only">Note number 3</p>
<div>Also represents the projects stakeholders, a.k.a. 'the business'.</div>
<button type="button" aria-label="Close Navigation" class="close-dialog" id="close-dialog-3"> <i class="fa fa-times"></i> </button>
</div>
<script>
var dialogOverlay = document.querySelector('.dialog-overlay');
var myDialog3 = new Dialog(document.querySelector('#dialog-3'), dialogOverlay);
myDialog3.addEventListeners('#open-dialog-3', '#close-dialog-3');
</script>
</body>
</html>