Agile Otter Blog

 CSS really is fun.  No, seriously. I'm not being sarcastic here.  Even though I've been in software a long, long, long time, I hadn't really studied CSS before last year (shocking, I know) and so I've been behind in my training.  I had an opportunity to dive in more, and all was going well until I started playing with media queries and ran into a specificity problem that wasn't so obvious (to me, though it may have been to you). So, to help people who are treading the same path, here are some aids on specificity: * W3 Schools has a fun "try it and learn" approach to general CSS Specificity * Saucelabs specifically breaks down specificity and media queries * Halodoc provides some best practices  to avoid troubles. * Specificity with Darth Vader and Stormtroopers and stuff at smashing magazine. These should get you past the worst of your troubles nicely. If you do get stuck, then it's always nice to experiment with a local HTML/CSS document or maybe fi...

 After many times looking up various resources on code smells and code smell taxonomies, I finally decided to make a listicle (list article) of these.  Enjoy: Industrial Logic's Code Smells album is carefully curated and deftly explained. A winner. Industrial Logic also has a cheat sheet for code smells (recommended) The OG Wikipedia's extensive listing A nice taxonomy at Coding Horror A nice writeup at Refactoring Guru The Samman Coaching List has nice descriptions. There is a longish list without explanations at DevIQ, as a jumping off point for many interesting web searches. Arjan Codes (a nice channel, recommended) has a video introduction to Python Code Smells. On the "positive" side of the ledger, we also have virtues: The original Code Virtues article from Pragmatic Programmers, republished at Medium. The explainer article (feel free to start here) at Industrial Logic.

 A big thread erupted, all full of misunderstandings and miscommunications, about the idea of "private" methods.  It all started quite innocently (I maintain) when someone asked how we felt about testing private methods. Some people jumped in with "Absolutely Not! Never! That's wrong! Test via public interfaces." I thought a little longer, and said "I'm not sure" and then later "I'm not sure that 'private' is even needed." This is where the problems started, and maybe here I can clarify what I meant by it all.  People assume (and insist) that I could only possibly mean that they should substitute 'public' for all protected and private members, polluting the interface, and inviting the violation of a class' internal state.  That was never my intention and still isn't. Still, this is what people insist that I must have meant from the start. I suppose this is because that's what they imagined me to mean and it...

 I've noticed that for several years now, one of the most frequently asked questions in agile forums deals with the splitting of stories.  We simply can't create a feature, epic, or improvement in a single gesture. If we are going to make progress, we have to start somewhere and build in small pieces. One way or another, whether we release after each piece or not, we have to make progress in bits and pieces.  In the bad old waterfall days, the analysts and designers would come up with a system with functional decomposition. It would essentially describe a tree with upper-level modules calling lower-level modules all the way down to individual functions. After the designers have done a top-down design, the developers would start building the system starting from the bottom-up. They would build the pieces and the higher-level pieces that use those pieces until they had components, sub-assemblies, subsystems, and eventually the entire product.  This "top-down design, bo...

I was chatting with a manager who was once a PO on a team I coached many years ago. This is only my best memory of the conversation (I didn't record it at the time). I may have slightly embellished it with snippets from conversations that followed over the course of days or weeks, but I try to be faithful. One day she took me aside and asked what she should be doing to accelerate the team and get more work pushed through. “Nothing,” I said. “Nothing? But I thought that I’m supposed to be getting maximum work and speeding up the team…?” “Nope. Your job as PO is to maximize the value of the work, not the quantity of the work. Given that they’re doing roughly the same amount of work each week (barring emergencies and vacations), your job is to make sure that what they are working on is the most valuable work that they could do that week - that it is impactful and useful.” The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Te...

Including delivery/deployment in the definition of done I'm told is unfair because teams aren't in control of what gets delivered or when. "Their work might be completed, but be only a fraction of some larger scatter-gathered effort, so it's not their fault." "They may be dependent on work from another group, say FE or BE or database, or something, so it's not their fault the work isn't done." "They may have worked on a dozen things, but only one was delivered. It's unfair that it doesn't represent all of their efforts." "Releases aren't done every sprint/increment/week/whatever, so it will look like uneven velocity if we only count work actually delivered." "They should be able to count the points for everything they worked on, whether it's delivered or not." "A manager may decide not to release their feature and leave it in the branch -- maybe never release it. It's not their fault so...

So a given web application has an architecture that involves a UI and an API and under that some domain objects, data, etc. When a new feature comes up, there is a gherkin test that does NOT go through selenium, but directly to the API. In developing the gherkin test, the team drives out the changes needed by the API and gets it working. The gherkin test is a "story test" and checks to see if the system (behind the UI) works correctly. It does data, persistence, etc in a safe way. But to build the code, you are doing TDD directly on the API and the deeper domain objects. As you do, you are refactoring and committing (of course). The microtests and the gherkin tests together are super-fast, so you run both in the auto tester . The auto tester re-runs the tests any time the code is changed and compile-able. This means the tests are run many sometimes more than once a minute. You're always clear where you stand. But of course, there is a web page to deal with. You create r...