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.
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.
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.
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.
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:
- Story estimates are used to see how much work can be fit into the sprint you’re planning.
- Story estimates are used to track how much the team did during the sprint, to adjust how future sprint capacities are estimated.
- 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.
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.
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.