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

by ·2 Comments

I ended up talking about knowledge management quite a bit at Agile Games 2018 and Mob Programming 2018.  I don’t have a lot of formal training in this area, but it’s something that I’ve focused on a lot, and I’ve learned a lot from people who have studied it a great deal.  Rather than respond directly, I decided to add a blog post about it, to benefit more people.  This is an unordered list of these tips.  I would love to hear your additions or feedback on it.

Push vs Pull Communication Channels

There are two different general ways of communicating information: Push and Pull.  Push is when you send information out to recipients and they get notified (email, Twitter, Slack, etc) and Pull is when the recipient seeks out that information that was published earlier (Website, wiki, CMS, documentation).  Using the wrong type can prevent the recipients from having the most recent information in a timely manner.  The main deciding factor is, is it more important that people know about this information as soon as possible (changes to policy, status/availability updates, issues), or that people have the information when they need it (requirements, specifications, resources, environment details).  Many tools can do both, like wikis, which allow people to get notified of updates).  Email doesn’t work nearly as well as you would think at either push or pull, because most people in technical fields get so many emails that they find it hard to both notice and respond to timely emails and categorize those emails so they can find them later.Continue reading

by ·0 Comments

I am looking for Software Engineering Manager position in the Boston area, leading a team of (preferably) Java developers in an Agile environment.  My strengths are my diversity and depth of experience, perseverance, ability to learn new technologies quickly, and communication and organizational skills.  I’m happiest when I’m collaborating on hard problems, mentoring others, establishing best practices, and improving software.  I’m a strong believer in the Agile philosophies and principles, and valuing quality and teamwork.

If you are looking for someone like me, or know someone who is, please contact me at david@thekramers.net.

by ·0 Comments

This article is about The Dev group in relation to other business units in the company.  In this article, “the Dev group” is shorthand for whatever business unit the software development team is in (Technology, IT, …).

Many times in a company, the Dev group is seen not as a consumer of requirements and a provider of solutions, but as somehow subservient to other groups, like Marketing.  The Dev group has to be very careful not to challenge their statements in meetings, and just accept that they know what they’re doing, no matter how little it’s based on actual customer feedback, or how SWAG the finance estimates are, or how much of their input is colored by personal bias.  I’ve been taken off of meeting invites because I dared to challenge the statements about the Dev group and defending them from other business units.  We even say things like “Let’s find out what The Business thinks of these features” as a short hand for “the other business units”. But phrasing it that way implies that the Dev group isn’t a separate but equal business unit.

Continue reading

by ·1 Comment

I think a lot about process, process improvement, productivity, and efficiency vs effectiveness (believe it or not the difference is not universally understood).  Lately I’ve been thinking a lot about team composition and how it affects the productivity of the team.  In part I’ve been thinking about it because of the teams I’ve had in the past; in part because I’m currently hiring and having to make trade-offs like salary level vs skill level and overlapping skill sets, but also because I’ve been playing the game Overwatch a lot, where team composition essential.

Continue reading