Tag: Agile

Agile Open Northwest 2024:  a journeyman’s journey

Published on by paranoidmikeLeave a comment

Agile Open Northwest 2024, late March, dawn of Spring in Portland Oregon – and rebirth of the PNW agile community.

Overall Tone: relief & excitement (“we’re back in person! Love the energy in the room”) tinged by a lingering sense of loss (“what’s next for Agilists, if we’ve reached Peak Agile?”)

A typical day’s agenda at this Open Space conference

We’ve peaked Agile 

  • many coaches and Scrum Masters are “taking Agile off their resumes”
  • the market for professional coaching has suddenly bottomed out in the last six months
  • wondering what name or framework the Agile Principles & Values will reboot under

We’re starved for human contact

  • AONW hasn’t met in person for years
  • The momentum in this AONW conference community, and our Meetups and tribes, is definitely lower than pre-pandemic
  • We’re looking to rebuild a sense and a place of community, where we can gather and have those “hallway conversations” that literally spawned the Open Space movement https://en.m.wikipedia.org/wiki/Open_space_technology

The PNW Agile community is still mostly in hibernation

  • Attendees were down by 2/3 from pre-pandemic attendance
  • Much of our in-person Meetup gatherings are sparser, the venues less available, and the topics not nearly as elucidating (more mechanical than transformational)

My mentor and friend Ray remarked (something along the lines of), “I haven’t seen you in action since your baby PO days”. I took it as a high compliment – that compared to my days as someone who’d just been CSPO certified and had no experience outside of the Intel bubble, my fluency in the art and humility of Product Management is notable.

What did I talk about?

I facilitated two sessions this year: “Yell At a Product Manager” and “Teach Me Non-Violent Communication 201”.

Yell at a Product Manager

My first session, “Yell at a Product Manager”, I framed as an opportunity for Agilists to explore state of the art in Product Management, how that differs from Product Owners, and whether the PO (or PM) role have a future under our AI overlords. We had a rousing discussion on:

  • A definition of PO vs PM – PO more “tactical/short-term/eng-team-focused”, PM more “strategic/longer-term, outward-focused”, though the division of responsibilities varies in every org that has one or both
  • good and dysfunctional behaviours of Product Owners & Product Managers and the organisations that employ them – focus on “why” not how, taking accountability for the business outcomes without necessarily having to own and perform all or any of the work leading up to that outcome, and reinforcing customer need always at the forefront of the design/development/validation/launch
  • The prevailing attitudes in tech these days – “PM” has passed its peak (I wish AI could figure out what customers need, based on what customers tell us the solution looks like), PO is always perceived as lesser-than (not in my experience – disciplined execution doesn’t just happen with hands-free PRDs-over-the-wall), these two roles should be consolidated, no one person can be good at all three dozen domains in the Pragmatic Framework, and in certain organizations the PM organization is becoming subservient to Engineering or even “eliminated” entirely (but not really https://melissaperri.com/blog/2023/7/7/are-we-getting-rid-of-product-managers) 
my incredibly fastidious note-taking

Teaching Mike Non-Violent Communication

My second session was an act of vulnerability: admitting to this esteemed group that I’ve never learned about NVC (Nonviolent Communication), despite hearing this community advocate for it every chance they get. You ever have that feeling that you’re ignoring a fundamental paradigm at your peril?

So I volunteered to be the dumb catalyst for a group discussion to teach each other.

An incredible amount of insight was dump trucked in the circle in the space of a half-hour:

  • The “non-violent” phrase is a poor translation – most folks prefer “Compassionate Communication” or even “Precise Communication”
  • The most important thing is focusing on extinguishing judgment from any engagement on sensitive, controversial or divisive discussion
    • open-ended questions = more “what is the situation” than “are we screwed?”
    • seeking connection not differences = more “help me understand” than “why did that happen”
    • removing judgment = more “I love your dress” than “that’s a pretty dress”
  • The trick (on yourself, the practitioner) is cultivating a mindset of knowing that deep down, any two people have deep needs in common
    • finding that win-win can require a significant emotional and ego-less investment, especially when we start out with an explicit disagreement
    • “Why” questions will make the receiver defensive
    • offering choices creates agency, allowing the receiver to spontaneously align
    • requires being willing to recognize the receive as a human, not an opponent
    • relies on both parties being willing to find an acceptable outcome rather than “agreeing to disagree”
Another medium for words that resonated for me
Even more of these admittedly self-evident insights

My Personal Highlights

  1. People like me – with only a few minutes’ interaction with many folks, wrapping up AONW for me was like doing the receiving line at a family wedding. (hard to complain about it)
  2. I like people – and I was thanked more than once for making individuals feel welcome and included
  3. The spirit of Agile is unshakeable, but it’s going to have to dress up in a new costume to get traction in the post-Agile tech industry

Wherefore Product Owners?

Published on by paranoidmikeLeave a comment

I’m seeing a lot of talk in PM circles about the irreversible end-of-life of the PO – and even more radical, the consolidation of PdM and PgM roles – separate and alongside the PM.

There’s talk that the modern Product shop doesn’t need these two (edit: three) as an execution-discovery team, that AirBnb’s recent irresponsibly misinterpreted sleight against the Product Manager (PM/PdM) title portends a peak in Product roles, and that AI will inevitably make Product “more efficient” (aka “we’ll need fewer of you slobs”).

Product Owner (PO) is unfortunately chained to the yoke of Agile, which incredibly hasn’t changed in its maniacal focus on The Team (and still isn’t ready to embrace The Rest Of The Org, to its sorry detriment) – and is proof of the inevitability of Hypocritcal Irony in that Agile preaches relentless Inspect and Adapt but hasn’t Adapted its roles, rituals or manifesto in 23 years since those frustrated engineers fantasised about a world in which we all just got out of their way.

I’m seeing talk that the right way to make PMs more effective is no longer relying on a paired PO but leaning more heavily into EPMs (aka Program Managers aka PgM), ProdOps (Product Ops) and Continuous Discovery (aka “channel your customers and market” or “weaponise your critical advantage”).

I’m a little sad at the death (or at least dearth) of PO in the industry – that’s where I got my start ten years ago, and what catalysed my bias to experimentation, steel threading and “Scream Testing” – but it’s also a welcome sign that the rest of tech is ready to Inspect and Adapt. If something isn’t working, iteration/year after iteration/year, why shouldn’t we try something new that the evidence before us implies, and observe how that perturbs our intended outcomes?

So where can we look for inspiration? I’m still inspired by the radical refocus that is Modern Agile. What modes of thinking about value delivery and team effectiveness are inspiring you these days?

One AI’s rendering of PO getting left behind – amusingly vague

When will DevSecOps resemble DevOps?

Published on by paranoidmikeLeave a comment

https://www-forbes-com.cdn.ampproject.org/c/s/www.forbes.com/sites/jasonbloomberg/2017/11/20/mitigate-digital-transformation-cybersecurity-risk-with-devsecops/amp/

Another substance-free treatise on the glories of DevSecOps.

“Security is everyone’s job”, “everyone should care about security” and “we can’t just automate this job” seems to be the standard mantra, a decade on.

Which is entirely frustrating to those of us who are tired of security people pointing out the problems and then running as soon as there’s talk of the backbreaking labour of actually fixing the security issues, let alone making substantive system improvements that reduce their frequency in the future.

Hell, we even get a subheading that implies it’ll advance security goals in a CI/CD world: “The Role of Tooling in DevSecOps”. Except that there’s nothing more than a passing wave hello to Coverity (a decent static analysis vendor, but not the start nor the finish of the problem space) and more talk of people & process.

Where’s the leading thinkers on secure configuration of your containers? Where’s the automated injection of tools that can enforce good security IAM and correct for the bad?

I am very tired of chasing Lucy’s football:

lucy-football

I’m tired of going out to DevSecOps discussions at meetups and conferences and hearing nothing that sounds like they “get” DevOps.

DevOps works in service of the customers, developers and the business in helping to streamline, reduce the friction of release and make it possible to get small chances out as fast and frequently as possible.

I’ve asked at each of those discussions, “What tools and automation can you recommend that gets security integrated into the CI/CD chain?”

And I’ve heard a number of unsatisfying answers, from “security is everyone’s job and they should be considering it before their code gets committed” all the way through to “we can’t talk about tools until we get the culture right”. Which are all just tap-dancing dodges around the basic principle: the emperor has no clothes.

If DevSecOps is nothing more than “fobbing the job off on developers” and “we don’t recommend or implement any tools in the CI/CD chain”, then you have no business jumping on the DevOps bandwagon as if you’re actively participating in the process.

If you’re reliant merely on the humans (not the technology) to improve security, and further that you’re pushing the problem onto the people *least* expert in the problem space, how can you possibly expect to help the business *accelerate* their results?

Yes I get that DevOps is more than merely tools, but if you believe Gene Kim (as I’m willing to do), it’s about three principles for which tools are an essential component:

  1. Flow (reduce the friction of delivery) and systems thinking (not kicking the can down to some other poor soul)
  2. Amplify feedback loops (make it easy and obvious to learn from mistakes)
  3. Create a culture of learning from failure.

Now, which of those does your infosec approach support?

Hell, tell me I’m wrong and you’ve got a stack of tooling integrated into your DevOps pipeline. Tell me what kinds of tools/scripts/immutable infrastructure you’ve got in that stack. I will kiss your feet to find out what the rest of us are missing!

Edit: thoughts

  • Obviously I’m glossing over some basic tools everyone should be using: linters.  Not that your out-of-the-box linter is going to directly catch any significant security issues, no – but that if you don’t even have your code following good coding standards, how the hell will your senior developers have the attention and stamina to perform high-quality, rapid code reviews when they’re getting distracted by off-pattern code constructions?
  • Further, all decent linters will accept custom rules, disabled/info-only settings to existing rules – giving you the ability to converge on an accepted baseline that all developers can agree to follow, and then slowly expand the footprint of those rules as the obvious issues get taken care of in early rounds.
  • Oh, and I stumbled across the DevSecCon series, where there are likely a number of tantalizing tidbits

Edit: found one!

Here’s a CI-friendly tool: Peach API Security

  • Good news: built to integrate directly into the DevOps CI pipeline, testing the OWASP Top Ten against your API.
  • Bad news: I’d love to report something good about it, but the evaluation experience is frustratingly disjointed and incomplete.  I’m guessing they don’t have a Product Manager on the job, because there are a lot of missing pieces in the sales-evaluation-and-adoption pipeline:
    • Product Details are hosted in a PDF file (rather than online, as is customary today), linked as “How to Download” but titled “How to Purchase”
    • Most “hyperlinks” in the PDF are non-functional
    • Confusing user flow to get to additional info – “Learn More” next to “How to Download” leads to a Data Sheet, the footer includes a generic “Datasheets” link that leads to a jumbled mass over overly-whitespaced links to additional documents on everything from “competitive cheatsheets” to “(randomly-selected-)industry-specific discussion” to “list of available test modules”
    • Documents have no common look-and-feel, layout, topic flow or art/branding identity (almost as if they’re generated by individuals who have no central coordination)
    • There are no browseable/downloadable evaluation guides to explain how the product works, how to configure it, what commands to use to integrate it into the various CI pipelines, how to read the output, example scripts to parse and alert on the output – lacking this, I can’t gain confidence that this tool is ready for production usage
    • No running/interrogable sample by which to observe the live behaviour (e.g. an AWS instance running against a series of APIs, whose code is hosted in public GitHub repos)
  • I know the guys at Deja Vu are better than this – their security consulting services are awesome – so I’m mystified why Peach Tech seems the forgotten stepchild.

Edit: found another!

Neuvector is fielding a “continuous container security” commercial tool.  This article is what tipped me off about them, and it happens to mention a couple of non-commercial ideas for container security that are worth checking out as well:

Edit: and an open source tool!

Zed Attack Proxy (ZAProxy), coordinated by OWASP, and hosted on github.  Many automatable, scripted capabilities to search for security vulnerabilities in your web applications.

 

 

Occupied Neurons, November Kunst

Published on by paranoidmikeLeave a comment

What Trader Joes Figured Out About Work Culture That My Other Past Employers Haven’t

http://engage.guidespark.com/talent-and-culture/what-trader-joes-figured-out-about-work-culture-that-my-other-past-employers-havent/

Holy shit folks, I could study this like the Torah for the rest of my professional life.  Open every conversation with open-ended question?  “There’s 1000 ways to do it right”?  Yes yes and yes.

Saving The World From Code

https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/

One of the most frustrating things for me, a part-time coder, is having so much difficulty following the state of things as expressed in semi-linear Code (don’t even get me started with Functional and async). When I’m trying to piece together code fragments from multiple sources, it’s nearly impossible for me to reason the complete working model – I end up writing out a stepwise process model, or changing variable names one at a time and iterating forever until I see which piece contributes what to the whole machine.

So this piece – and the underlying theme of “software is beyond the reasoning capacity of great humans” – resonates like hell for me.

Uncle Bob and Silver Bullets

https://www.hillelwayne.com/post/uncle-bob/

There’s only so much “blame the victim” I can stand in this world, and Uncle Bob is one of the loudest offenders. Yeah we should all get better at coding, and yeah we should hold ourselves accountable when it doesn’t measure up.

But what about the interim? How’s about standing on the shoulders of giants? Or leaning on our elders? Or centralising expertise and leaving others to be good at what they’re good at?

I’m all for not being expected to master the universe before getting on with the job of getting something out into the world to learn from it. If everyone waited until they were the best at every discipline involved in the making of things…well, you can imagine how bereft the world would be.

It’s actually a good reminder to dial back the damned voice in my (and your) head telling us we’re not good enough yet. Let’s make something useful, and find out how wrong we are in someone else’s eyes, by encountering the actual evidence of feedback.

What’s the Difference between JavaScript and ECMAScript?

When Do I Know I’m Ready for Redux?

https://medium.com/dailyjs/when-do-i-know-im-ready-for-redux-f34da253c85f

One of many think-pieces about whether and when to add Redux to a React.js app, and a helpful guide for those not already steeped in the experience of doing so.

Understanding ReactJS-Component life cycle

https://medium.com/@baphemot/understanding-reactjs-component-life-cycle-823a640b3e8d

Far too abstract for a non-expert to follow – this is a documentation piece, and not even a good one at that. Re-examine this in a year, maybe it’ll make sense by then. Experts only.

Presentational and Container Components

https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

An interesting pattern to note for later, when the app I’m working on scales to the point I find myself passing props through component layers.

Optimizing React Rendering (part 1)

https://flexport.engineering/optimizing-react-rendering-part-1-9634469dca02

Optimizing?  Bah – definitely too early for optimization in my app.  Got one page working.  Let’s leave this as a breadcrumb for future Mike.

Javascript Arrow Functions for Beginners

https://codeburst.io/javascript-arrow-functions-for-beginners-926947fc0cdc

I’ll re-read this until it sinks in.  Lambda notation mystifies me, but probably I just need to implement it a hundred times or so and my brain will settle down.

WhoDidITalkTo: working ReactJS code!

Published on by paranoidmikeLeave a comment

You ever take a very long time to birth something small but ultimately, personally meaningful?

Me neither, but what I’m calling stage 1 of my ReactJS app is working to my liking.

WhoDidITalkTo is a personal work of love to help me remember all the wonderful encounters I have at Meetups and other such networking events.  It’s painful for me to keep forgetting the awesome conversations I’ve had with people, and have to confess I don’t remember someone who I very clearly made an impression on.  As someone with superhuman empathy, it’s crushing to see those hurt microexpressions cross their faces when they realize I’m no better than Leonard Shelby:

tumblr_m6igbdnbxr1qfola7o1_500
A little less dirty than him, usually

So I’m trying to remedy that, by giving myself a tool I can use from my phone to capture and review salient details from each new personal encounter I have at all the events I slut around to.

It’s prototype stage, and I have no dreams of monetizing this (so many startups have tried and failed to make this kind of “personal CRM lite” work and failed), and it’s a long ways from being fully functional in the field.  Still, I’m having fun seeing just how far I can stretch my rusty front end skills *and* treat this like a real Product Management project for myself.

If you’d like to peer inside my jumbled mind, this isn’t a bad place to see for yourself:
https://github.com/MikeTheCanuck/WhoDidITalkTo/projects/1

WhoDidITalkTo prototype v1

Highlights from latest Lean Coffee

Published on by paranoidmikeLeave a comment

A lively crowd around the table at last Sunday’s Lean Coffee session, and fresh faces to the discussion (thank you to Scott for inviting your colleagues, and to all for coming out).

There’s no way I can do justice to the breadth and depth of the discussion, so I’m just going to mention those things I wrote down on sticky notes to myself – the things that I thought, “Boy, I should get this tattooed on myself somewhere”:

  • Don’t Automate Waste – a killer principle from the Lean camp that Dan Walsh graced us with, it speaks to the tension of not optimizing early, and to my instinct not to assume you have the solution without experimentation
  • “Agile/Scrum is a Problem Discovery Framework, not a Project Management Methodology” – courtesy of Scott Henderson, every word here lends subtle meaning to the mental shift it encourages
  • Lean Coffee has been used successfully in at least two settings I haven’t tried – as the basis for both the Retrospective and Brainstorming sessions (which helps get ideas on the table that might be ‘swallowed’ by the time attention comes around to the less-confident individual)
  • Code 46 and Sully were the two movies that came up in conversation, so off to Netflix I go

2016-12-04 11.59.58.jpg

I posed a question to the group which came back with some great thoughts: “how to workaround a situation [which I’ve observed at many software companies] where the testing infrastructure/coverage isn’t reliable, and there’s no quick route to addressing that?”

  1. Ensure that you at least have Unit Tests included in the Definition of Done
  2. Try an experiment where for a single sprint, the team only works on writing unit tests – when this was tried at one organization, it surprised everyone how much progress and coverage could truly be made
  3. Try a regular “Game Day” exercise – run tabletop simulation of a production bug that takes out one or more of your customer-facing services.  This identifies not only who must be involved, but also how long it can take to execute corrective action once identified, and ultimately can result in significant time savings by making upstream changes in product/devops.
  4. Run an occasional discussion at Retrospective to ask “what’s the worst thing we could do to the product?”  This can uncover issues and concerns that otherwise go unspoken by folks who are worried about retribution or downplaying.
  5. And the most obvious, start out future sprints by planning tests up front (either via TDD or manually between QA and Dev)

Occupied Neurons, November edition (late)

Published on by paranoidmikeLeave a comment

Docker In Production: a History of Failure

A cautionary tale to counter some of the newbie hype around the new Infrastructure Jesus that is Docker. I’ve fallen prey to the hype as well, assuming that (a)Docker is ready for prime time, (b) Docker is universally beneficial for all workloads and (c) Docker is measurably superior to the infrastructure design patterns that it intends to replace.

That said, the article is long on complaints, and doesn’t attempt to back its claims with data, third-party verification or unemotional hyperbole. I’m sure we’ll see many counter-articles claiming “it works for me”, “I never saw these kinds of problems” and “what’s this guy’s agenda?”  I’ll still pay attention to commentary like this, because it reads to me like the brain dump of a person exhausted from chasing their tail all year trying to find a tech combo that they can just put in production and not devote unwarranted levels of monitoring and maintenance to. I think their expectations aren’t unreasonable. It sure sounds like the Docker team are more ambitious or cavalier than their position and staffing levels warrant.

Wat

This is one of the most hilarious and horrifying expeditions into the dark corners of (un?)intended consequences in coding languages.  Watching this made me feel like I’m more versed in the lessons of the absurd “stupid pet tricks” with many languages, even if I’d never use 99% of these in real life.  It also made me feel like “did someone deliberately allow these in the language design, or did some nearly-insane persons just end up naturally stumbling on these while trying to make the language do things it should never have done?”

Is Agile dying a slow death?  Or is it being reborn?

This guy captures all my attitudes about “Agile according to the rules” versus “getting an organization tuned to collaborate and learn as fast as possible”.  While extra/unnecessary process makes us feel like we have guard rails to keep people from making mistakes, in my experience what it *actually* does it drive DISengagement and risk aversion in most employees, knowing that unless they have explicit permission to break the rules, their great new idea is likely to attract organizational antibodies.

Stanford’s password policy shuns one-size-fits-all security

This is better than a Bigfoot sighting! An actual organization who’ve thought about security risk vs punishing anti-usability and come up with an approach that should satisfy both campaigns! This UX-in-security bigot can finally die a happy man.

A famed hacker is grading thousands of programs – and may revolutionise software in the process

May not get to the really grotty code security issues that are biting us some days, and probably giving a few CIOs a false sense of security.  Controversial?  Yes.

A necessary next step as software grows up as an engineering discipline? Absolutely.

Let’s see many more security geeks meeting the software developer where they live, and stop expecting em to voluntarily become part-time security experts just because someone came up with another terrific Hollywood Security Theater plot.

A Rebuttal for Python 3

Why are some old-school Pythonistas so damned pissy about Python 3 – to the point of (in at least one egregiously dishonest case) writing long articles trying to dissuade others from using it? Are they still butthurt at Guido for making breaking changes that don’t allow them to run their old Python 2 code on the Python 3 runtime? Do they not like change? Are they aware that humans are imperfect and sometimes have to admit mistakes/try something different? I find it fascinating to watch these kinds of holy wars – it gives the best kinds of insights into what frailties and hot buttons really motivate people.

The best quote’s in the comments: “Wow, I haven’t seen this much bullshit in a “technical” article in a while. A Donald Trump transcript is more honest and informative than that. I seriously doubt Zed Shaw himself believes a single paragraph there; if he actually does, he should stop acting like a Python expert and admit he’s an idiot.”

How The Web Became Unreadable

It’s painful to see some designers slavishly devote their efforts more to the third hand fashion they hear about from other designers, than to the end users of the sites and services to which they deliver their designs. I love a lot of the design work that’s come out the last few years – the jumbled mess that was web design ten years ago was painful – but the practical implications of how that design is consumed in the wild must be paramount.  And it is where I am the final decision maker on shipping software.

Lean Coffee September insights report

Published on by paranoidmikeLeave a comment

That’s our Sunday morning Lean Coffee practice. Here’s where we landed after a good 1.5-ish hours of structured-and-friendly conversation.

 On the subject of landing a job as a Scrum Master

  • You must be very familiar with the SCRUM Guide, and especially the “Why” behind each practice – so that you can address real questions about when you’ll recommend a practice and when you’ll recommend evolving past it
  • Should be very comfortable with trying new things AS EXPERIMENTS
  • Must avoid “always pitying the SCRUM team” at the expense of the overall business goals, or else business will hamstring your influence and bypass your role
  • Relies heavily on Situational Leadership abilities
  • Starts with CI, graduate to Continuous Learning

On the subject of what’s changed and what is changing

  • According to our discussion of Crossing the Chasm, once those beyond the chasm start adopting, then rather than chasing the downward slope, you should chase a new curve starting from the other side of the chasm
  • We’re seeing signs that other non-software disciplines are adopting Agile practices eg. Marketing functions, DevOps
  • Perhaps we’re merely waiting for the rest of the org to catch up to those of us who are post-Agile and delivering continuously
  • The VUCA model (Volatility, Uncertainty, Complexity, Ambiguity) made it into a Harvard Business Review article
  • Neurodiversity is getting broader consciousness

 On the subject of creating success as a Scrum Master

  • The basic SM is a “boundary manager”
  • They’re there not only to help the team “learn to be a team” and more to help the team “learn how to be Agile as a team”
  • They’re there to work with the team and enable them to determine what process solutions to try, rather than dictate or even “guide” the team to specific outcomes
  • Tip: should be very familiar with the Agile Fluency model
  • When interviewing for a SM role, an insightful question is to ask what are the inputs and outputs of the engineering team?
  • Geoff Watts published an article asking What kind of support a Scrum Master would need?

On the subject of no estimates

  • Analogy of a cook: asking for precise estimates is like asking them to cook a dinner with a menu they’ve never cooked before
  • Analogy of car mechanic: they can only give predictable, tight estimated of when the repair will be completed for operations they’ve already done before (enough time to have codified the standard timeframe) and with mechanics who are highly experienced

Miscellaneous Insights

  • Meetup (as in the collection of fluid communities) is like a grand ongoing Un-Conference – people announcing a topic they’d like to talk about, those who wish to attend come, people obeying the law of two feet as the meetup’s theme no longer keep their attention
  • Check out Rachel Davies’ Agile Coaching book
  • There’s growing insight that SAFe can find better flow mechanics across the portfolio if it uses Kanban rather than SCRUM – but that a prerequisite is that the teams must already have in place high-quality technical practices (eg. low big output, continuous integration, short distance from idea to value) and functioning teams before Kanban at scale will create consistent results
  • Book: check out the free mini-book on Scrumban by Henrik Kniberg

See you there next time (if you’re lucky).

Occupied Neurons, late September edition

Published on by paranoidmikeLeave a comment

Modern Agile (Agile 2016 keynote)

https://www.infoq.com/news/2016/08/agile2016-modern-agile

This call out for advancement of Agile beyond 2001 and beyond the fossilization of process and “scale” is refreshing. It resonates with me in ways few other discussions of “is there Agile beyond SCRUM?” have inspired – because it provides an answer upon which we can stand up actual debate, refinement and objective experiments.

While I’m sure there are those who would wish to quibble of perfecting these new principles before committing to their underlying momentum, I for one am happy to accept this as an evolutionary stage beyond Agile Manifesto and use it to further my teams and my own evolution.

Forget Technical Debt – Here’s How to Build Technical Wealth

http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth

I had the pleasure of meeting and talking with (mostly listening and learning intently on my part) Andrea Goulet at .NET Fringe 2016 conference. Andrea is a refreshing leader in software development because she leads not only through craftsmanship but also communication as key tenet of success with her customers.

Andrea advances the term “software remodelling” to properly focus the work that deals with Technical Debt. Rather than approach the TD as a failing, looking at it “as a natural outgrowth of occupying and using the software” draws heavily and well on the analogy of remodelling your/a home.

Frequent Password Changes Are The Enemy of Security

http://arstechnica.com/security/2016/08/frequent-password-changes-are-the-enemy-of-security-ftc-technologist-says/

After a decade or more of participating in the constant ground battle of information security, it became clear to me that the threat models and state of the art in information warfare has changed drastically; the defenses have been slow to catch up.

One of the vestigial tails of 20th-century information security is the dogmatically-proscribed “scheduled password change”.

The idea back then was that we had so few ways of knowing whether someone was exploiting an active, privileged user account, and we only had single-factor (password) authentication as a means of protecting that digital privilege on a system, that it seemed reasonable to force everyone to change passwords on a frequent, scheduled basis. So that, if an attacker somehow found your password (such as on a sticky note by your keyboard), *eventually* they would lose such access because they wouldn’t know your new password.

So many problems with this – for example:

  • Password increments – so many of us with multiple frequently-rotating passwords just tack on an increment img number to the end of the last password when forced to change – not terribly secure, but the only tolerable defense when forced to deal with this unnecessary burden
  • APTs and password databases – most password theft these days don’t come from random guessing, it comes from hackers either getting access to the entire database at the server, or persistent malware on your computer/phone/tablet or public devices like wifi hardware that MITM’s your password as you send it to the server
  • Malware re-infections – changing your password is only good if it isn’t as easy to steal it *after* the change as it was *before* the change – not a lot of point in changing passwords when you can get attacked just as easily (and attackers are always coming up with new zero-days to get you)

I was one of the evil dudes who reflexively recommended this measure to every organization everywhere. I apologize for perpetuating this mythology.

Do You Demo? Do you act on the feedback? No? Then you ain’t agile

Published on by paranoidmikeLeave a comment

I am convinced that there are few practices in Agile (aka SCRUM to most people) that can’t be revised, bent, paused or outright abandoned – in the pursuit of a healthy, adaptive and productive engineering squad.

However, the end-of-iteration demo is one I am vehement about.  If you aren’t doing demos well, it’s my believe that you shouldn’t be calling yourself agile (let alone Agile(tm)).

Aside: AgilePDX is a local meetup community of people zealous about improving our employers’ ability to deliver better product – faster, more transparently and most importantly, with more value to our customers.

Our last pub lunch roundtable discussion was “The End of Agile?”, and Billy McGee posed a great question that still rings in my head:

Which of the rituals/rules/ceremonies can we abandon and still call ourselves Agile?

My initial (silent) response to this was “almost all of them”.

As I actually contributed to the discussion, I still claim that one of The Most Important ceremonies to stick with is the end-of-iteration DEMO. Get your feedback early and often (if more frequently than end-of-iteration, even better), and for dogs’ sake get at least *one* person to say something who’s from *outside* the team.  Then take an action on that feedback.

code demo

Until you get outside-the-team inspection, you can’t hope to truly adapt to the trouble you’ve just gotten into by being away from outsiders for that long.  Groupthink, too-close-to-the-problem, love for the solution you derived – it all clouds the objective reality that you’ve almost certainly done it wrong.

If you do this one thing [demo/feedback/react] consistently/more-than-haphazardly, and *act* on the feedback (discuss, change a story, throw away code, replan your roadmap), you will have done more to imbue confidence in your team from the rest of the organization, and they’ll give you a lot more room to be experimental and not “plan-to-perfection” drowned.

The most frustrating thing for management/leadership that aren’t there every day is feeling like we have no CONTROL over getting the right things delivered more effectively.  Not seeing the work that goes into delivering the product, the engineering process becomes just a black box – even for those who’ve been in the trenches, distance + time just leads the mind to question.

When things feel out of control, leaders use what few tools they have to do what they can to keep things steered correctly – demand reports and metrics to give them *something* to wrap hands around, start dictating process to get more ‘structure’ around this messy process, and asking for more detailed plans.

These are all proxies for “how can I help make sure we’re doing the right things?”  And like they say, a picture’s worth a thousand words.  Heck, a customer’s reaction is worth at least that much too.

I’ve seen myself react *far* better to the growing uncertainties when I get to see what’s been delivered so far – live UI, screenshots, even a tour of the source code.  Takes away so much anxiety just to *see* something is there, let alone whether it truly meets my personal objectives.  Give me something – anything – to comment on, and the fact that I engage in comments on the thing means (a) I’m asking for help to buy in, (b) I’m getting committed to the thing in front of me and (c) you’re getting early clues what I’ll want to see before the last responsible moment.

Even this is better than no feedback, no matter how painful it might be:

code quality

Coda: one of my colleagues asked me, “So, abandon retrospectives?”  It’s a good question.  They’re one of the few rituals that’s meant to help the team evolve to better performance and outcomes.  And here’s where I’m going to take a radical/lazy/wait-and-see position:

Personally, I’m inclined to skip (the process part of) the retro until and unless the team gets behind the “inspect and adapt” angle on the product in response to what happens during demo. My experience, engineers are more likely to start in that habit if it’s focused on their code, and if they’re not even willing to engage for the technology, I’m less inclined to skate uphill on the process side of things – as a PO/PM participant/observer, I’ve seen retro degrade quite often into a “here’s what happened”, “good/bad/ugly” historical review, and lose sight of the “what would you like to try changing next time?”