by ·0 Comments

The best working definition of technical debt I know is “Work you purposefully put off now, knowing that doing so will create more work in the future“. That’s a bad thing, right? Well, not always. Creating technical debt can be like borrowing money; you know you will have to pay it back with interest in the future, but what you can do with the money today can be more valuable than the future cost. Similarly, getting that feature out the door in this release, knowing you have edge cases it won’t handle or a clunky implementation that will come back and bite you if not refactored soon, can be well worth it. It means being more agile, capturing market share sooner, and getting feedback from the customer sooner. Creating technical debt is sometimes necessary because “Perfection is the enemy of good” (or done).

Just like that loan, you have to pay it back, and generally speaking, the longer you wait the harder and more expensive it is to do so. This can be hard to do, because

  • You have to remember it to fix it
  • Just like defects. the longer they exist the harder it is to get back in that context and remember all the details
  • That technical debt is competing for resources with shiny new work that people want to work on, and others want done
Continue reading

by ·0 Comments

I’m a pretty organized person. I try to strike a balance between having things planned out and being flexible. There’s a cost to overplanning and putting more effort into organizing than strictly necessary, but I thin most of the time I’m glad I put in the effort.

One reason I do this is that I have learned the hard way over the years, that you can waste some effort capturing too much information and never using it later, but you often can’t go back in time and capture that information if you later find you need it handy. It’s like taking lots of photographs at a special event because it will never happen again, so anything not captured can’t be captured later. The same is true in monitoring and logging your computer systems.

I have found MANY occasions where having recorded details about current and past transactions from my job search has paid off, and I have made that as quick and painless as possible to reduce the burden.

Continue reading

by ·0 Comments

Friends, I am looking to lend my expertise to other companies, having ended my last engagement.
My main focus is empowering teams to become more effective and fulfilled. I have done so through various roles, including Software Engineering Manager and Agile Coach, and am open to both.

I have been on the Board of Directors of Agile New England, a community-focused not-for-profit group focused on promoting agile and lean, for about 10 years, and a member for 15, driving/contributing to agile and digital transformations of companies. My technical background means I can implement actionable changes in practices, processes, and tools to increase agility, specifically tailored for the situation.

My decade of leadership experience focuses on empowering teams, including all voices, to find the best ideas and get to the true nature of impediments to happy and effective teams. I didn’t just rise to management; I have a degree in it, and leadership has been my goal throughout my career. I have extensive experience in the technical and organizational sides of software team management, and success in turning around ineffective and disgruntled teams. My technical background and R&D experience supports deep involvement in the technologies and their use, quality best practices, and troubleshooting.

You can read more about my management background at http://www.thekramers.net/r/mgt and more about my Agile experience at http://www.thekramers.net/r/agile.

If you know of a company that can benefit from my experience, please let me know. I would prefer full time employment, but am open to contract work. Thanks in advance.

by ·0 Comments

I volunteer in the HATCH maker space in Watertown, MA. I learned how to use pretty much everything there but the sewing machines (which was on my list) and even teach classes there. The things I used for myself the most were the 3D printers and the laser cutter.

With the Coronavirus lockdown, though, there are no more volunteers on site. As of 10/2020, volunteers and patrons can spend limited time in the facility, which is the best they can safely do, but it’s hard to try things and iterate and experiment in true maker fashion. I decided I needed to buy my own 3D printer.

Continue reading

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