by ·0 Comments

In Agile, we are often told that everything we do should add value to the user. When you’re building something large and complex like an eCommerce or FinTech product, some work just isn’t user-facing, and it feels very forced and unhelpful to word the story in the “As a user I want to ___ so that ___” format.

We’re also told that stories should be as small as possible. But sometimes it takes several stories to get things working end to end to the point that users will gain some benefit from it, even if it is customer-facing. It’s also easier to do this in a published, working system you’re mostly adding small features to, but harder when you’re working towards your MVP, or early releases after that.

One solution to these seeming contradictions is to widen your definition of “user” to include the development community. Now, stories that make the system more testable, more flexible, more inspectable, more reusable, are all providing user to the user in a meaningful way. Adding functionality to lower systems, taking care of technical debt, adding logging, are all adding value to the user.

Continue reading

by ·0 Comments

This is a HOTLY contested topic. One of the reasons is that story estimates tend to get used for multiple purposes that have very different implications:

  1. Story estimates are used to see how much work can be fit into the sprint you’re planning.
  2. Story estimates are used to track how much the team did during the sprint, to adjust how future sprint capacities are estimated.
  3. Story estimates are used to track how much to “credit” the team with compared to previous sprints (velocity). It’s actually a pretty bad practice to “credit” the team with work output, and much better to have some measure of the outcomes of that work, or value added. But it’s still the norm because people would rather use less meaningful but easier to compute numbers than more relevant but hard to quantify numbers.

Methods for calculating story points may be good for one, both, or neither of these purposes.

Continue reading

by ·0 Comments

Agile Intro for Regulated Medical Software

Ideal for those new to Agile who need proven strategies for handling risk management, regulatory documentation, integration with hardware and with usability design. We show you the fundamentals that underlie all the various Agile methodologies, and how Agile practices are inherently safer and easily meet both FDA and EU regulatory requirements.

Agile Next Steps for Regulated Medical Software

Perfect for those with Agile experience or training who need to go deeper into the mechanics of how to achieve regulatory compliance in the areas that make medical device work different from other industries – hardware-software integration, documentation, risk management to name a few.

by ·0 Comments

Back in 2016, I attended the Agile Alliance Technical Conference (since renamed Deliver:Agile, which I think was a HUGE mistake, but that’s for another article) I saw a keynote by Uncle Bob Martin called The Future Of Programming (video of that keynote here). It was powerful, insightful, and not ashamed to point fingers. The other day, I found a video on Youtube of a similar talk by Uncle Bob here, and I felt compelled to spread the word about his message, even more relevant in 2019.

The overarching theme of the talk was the history of computers, from the “beginning” to the present, but also who was designing them and programming them, how that was done, and how all of those changed over time, for better or worse. He also does an interesting approximation of the number of computers and number of developers through the years.

Continue reading

by ·0 Comments

I’ve been a Software Engineering Manager or Team Lead for a long time, and Agile coaching has been part of all of those jobs. I’m on the Board of Agile New England, and have been for about 10 years. I’ve been supporting the Agile community for about 13 years. Having helped multiple companies with their agility, I also have a feel for what works in specific situations, and a pragmatic approach to what and how implement it.

I enjoy management,  but after speaking to some Agile Coaches I know well, I am looking to for Technical Agile Coaching positions instead. They both focus on something I am passionate about, which is focusing on the effectiveness and happiness of the entire team. They’re just going at it from different angles.Continue reading