Abstract
When you hear about Agile software development, the talk is dominated by the planning game. Scrum, Kanban, and other popular frameworks define how to plan what will be produced and when. The focus is on how to choose the stories that will produce the most value for the customer. The stories are broken into small enough pieces that they can be completed within one iteration. The benefit is in working on the correct things and completing them in a somewhat predictable manner. Once the planning game is in place, attention is turned to how the work will be completed. Often we find that how the work is done is a limiting factor. That’s where the Agile engineering practices come in.
We’re tired of writing crap. We are tired of embarrassing ourselves and our employers by delivering lousy software. We have had enough of telling our customers to reboot at midnight. We don’t want bug lists that are a thousand pages long. We don’t want code that grows more tangled and corrupt with every passing day. We’re tired of doing a bad job. We want to start doing a good job.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
- 1.
Uncle Bob Martin, “Software Craftsmanship: What it’s all about,” Clean Coder Blog, January 17, 2011, http://thecleancoder.blogspot.com/2011/01/software-craftsmanship-what-it-all.html?_sm_au_=iVVWTj7qJf1MvHz7 .
- 2.
Kent Beck, Extreme Programming Explained: Embrace Change (Addison-Wesley Professional, 1999).
- 3.
A code repository is a place where the current version of the binaries (also known as source code) is stored. Think of it like a shared drive where people check in and check out the code as they work on it. Code repositories are connected to other functions and tools that are needed to make the code actually work. For example, dependency tools hold code for other applications that are needed to run the software.
- 4.
See Chapter 7 for a discussion of repurposed labor as a monetizable success metric.
- 5.
To a writer, that’s the same thing as spell check instantaneously pointing out misspelled words.
- 6.
D. F. Rico, The Cost of Quality (CoQ) for Agile vs. Traditional Project Management (Fairfax, VA: Gantthead.com , 2012).
- 7.
- 8.
Order-taking: a situation where the consultant is recast as a diner waitress.
- 9.
In Chapter 2, I explained how I was unable to verify the 85 percent rule as a research-based assertion. Anecdotally through my own experience as a performance consultant, that number sounds perfectly reasonable, if not conservative.
- 10.
Speaking of which, be sure to check out my blog, It Ain’t Training.
- 11.
Fowler wrote the book, with some coauthors, Refactoring: Improving the Design of Existing Code (Addison-Wesley, 1999). In Fowler, we are introduced to another of the original Agile Manifesto signatories. When you search for Martin Fowler, “refactoring” prefills after his name, leading me to the conclusion that he is best known as the refactoring guy. When you look up refactoring, the first prefill option is “refactoring Fowler.” I call this bidirectional prefill authority, or BPA. This is how you invent an esoteric engineering term.
- 12.
This explanation comes from refactoring.com , which is a section of martinfowler.com
- 13.
Fowler, Refactoring, 3
- 14.
The word thing may seem a bit colloquial, even by the standards of this book. However, there is a bit of a back story. Years ago, before I knew about Agile stories, our team was searching for an all-encompassing word to describe all of the different types of learning assets that we developed. We settled on thing. In engineer-speak, we might call these objects (as in, object-oriented design or the administration of learning management systems, which we will not discuss in this work)—but, to an English major, an object is a thing, and calling a job aid an object sounds just plain weird.
- 15.
I have never met Martin Fowler or seen him present in person, but I have spent many hours watching his presentations on YouTube. Self-styled on his website bio as a “loud-mouthed pundit,” Fowler’s stage persona sets him apart from many other Agile luminaries. First, he’s British, so his accent provides instant credibility. (As a friend of mine says, “the British accent adds ten IQ points in the mind of an American.”) Striking a professorial demeanor, he is tremendously articulate and engaging as a presenter. Once I start watching videos of him, I have a hard time stopping. In that respect, my impression of him resides in the same area of my brain as skateboard crashes, Sidney Crosby’s stick handling, and music videos from pop diva Ke$ha.
- 16.
Martin Fowler at OOP2014, “Workflows of Refactoring,” https://www.youtube.com/watch?v=vqEg37e4Mkw .
- 17.
Tosses it over the wall is a term of art used to describe this non-agile practice, with varying levels of sincerity, irony, or cynicism. The traditional lament of the quality engineer goes something like this: “I wait around for months until the code writing is done, then the programmer tosses it over the wall to me, two days before the deadline. They’re out drinking beers because their part is done, and I’m still here in the office. I’m pulling all-nighters trying to make sense of their crappy code, fix the bugs, and make their damn feature work. I’m so unappreciated.”
- 18.
Laura Williams and Robert Kessler, Pair Programming Illuminated (Addison-Wesley, 2003), pp. 27–28.
- 19.
Laurie Williams, Robert R. Kessler, Ward Cunningham, and Ron Jeffries, “Strengthening the Case for Pair Programming,” IEEE Software, July–August 2000.
- 20.
Kim Man Lui, “Pair Programming Productivity: Novice–Novice vs. Expert–Expert,” International Journal of Human–Computer Studies 64 (9): 915–925. doi: 10.1016/j.ijhcs.2006.04.010.
- 21.
VersionOne, 2013 State of Agile Survey, http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf .
- 22.
Alistair Cockburn and Laurie Williams, “The Costs and Benefits of Pair Programming,” Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000), 2000.
- 23.
Technical Editor Joe Richer adds: “I think with some engineers there is a creative pride component to this as well. Paired oil painting is probably not very popular because the artist craves personal recognition. I’ve no doubt paired oil paintings would often be superior . . . but that would be a product of the relationship.”
- 24.
The thought of encouraging managers not to meddle in team business came easily to me, but people without much exposure to Agile might be surprised. Clearly there are situations in which the manager should intervene. But overall the team should be left to figure out how to collaborate, how to do the work, and how to continuously improve. The role of the manager in an Agile environment is a topic unto itself, something that I address in more detail in Chapter 4.
- 25.
- 26.
This batting average metric around story points is not one that I’ve seen used in Agile. Mostly you hear the Agile gurus talk about velocity, which is simply how many story points were completed. But I think it’s important to consider how that velocity fits in with committed story points. Any story that is started but not completed involves some wasted capacity, even if that incomplete story is carried over to the next iteration. I provide a full discussion of batting average in Chapter 8.
- 27.
Following a little backlash and further consideration, Uncle Bob redacted this value to say “craftsmanship over execution.” I like the original wording myself.
- 28.
- 29.
See http://bit.ly/1AbbW0o .
- 30.
You are reading the words of a man who has signed all three: the Agile, Software Craftsmanship, and Serious eLearning Manifestos. Yeah, I know: with that and $2.50, I can buy a medium coffee.
- 31.
- 32.
The other instigators are Julie Dirkson, Clark Quinn, and Will Thalheimer.
- 33.
While I freely admit that Allen was the first (that I know of) to connect Agile to learning, there are some important differences between his idea and the premise of this book. Allen’s excellent book is focused on the practice of instructional design (thus the easy connection to Uncle Bob’s craftsmanship and clean code movement). This book is about connecting Agile to the practice of performance consulting.
- 34.
The AgileAlliance.org website offers an online Guide to Agile Practices that includes 59 practices, with an accompanying timeline that takes us back to 1968.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2015 CA
About this chapter
Cite this chapter
Winter, B. (2015). The Agile Software Engineer’s Toolkit. In: Agile Performance Improvement. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-0892-2_5
Download citation
DOI: https://doi.org/10.1007/978-1-4842-0892-2_5
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-0893-9
Online ISBN: 978-1-4842-0892-2
eBook Packages: Professional and Applied ComputingProfessional and Applied Computing (R0)Apress Access Books