/home/dkramer

David Kramer's high-entropy blog

Looking to partner with Agile Coaches, especially in the Northeast US

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’ve been a Software Engineering Manager or Team Lead for a long time, and I’ve been looking for another Software Engineering Manager position, but lately after speaking to some Agile Coaches I know well, I’m thinking of Agile Engineering Coaching 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.

I have a competitive advantage, having so much experience with the tools and best practices of software development, especially in Agile Java environments, eCommerce, big data, Linux, automation, cloud, etc. I can focus on the technical practices and tactics like release strategies, branching strategies, Jira configuration, prioritizing testing, technical knowledge management and transfer, technical practices training, and continuous integration automation. These are areas I can help with. I’m also great at technical documentation aimed at multiple audiences.

I am looking for opportunities to partner with other Agile Coaches and Consultants that don’t have the technical experience to guide that part of their engagements, and could benefit from a relationship with someone who does. I have done this before, so I’m not completely new to this. I’m in Boston, and engagements closer to there would certainly make things easier, but I’m not limited to the Northeast.

If you know anyone who could benefit from this kind of partnership, or you yourself would, please reach out to me. I also welcome discussions and advice on this, as this is a new direction for me.

Share

Knowledge Management Tips

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.

Lower The Barrier To Information Sharing

Creating and updating documentation is rarely the most favorite part of anyone’s job.  It’s rarely prioritized when the work is planned out, if it’s budgeted at all.  Starting to write documentation seems to be much harder than adding to it, so making it easy to get started is a big deal.  A little bit of good documentation can be a whole lot better than no documentation. There are several ways to make it easier:

  • Create a culture that values knowledge management at all levels: If the culture from the top does not value knowledge management, and time spend “not coding” is seen as wasted or overhead, then knowledge management will never get the time, resources, and attention required to do it right.  If team members know that time spent on sharing knowledge won’t be appreciated, they are less likely to focus on it.  It’s also important to convince the technical community of the benefits to them personally, like not getting stuck being “the database guy” or “the owner of the Therblug component”.
  • Create templates: You can either create generic templates for the kinds of documentation or information sharing you expect, or identify an existing one as an exemplar. “This is what a component documentation home page should look like”.   “Here is an example release communication”.  “Stories should have a format like this”.
  • Use a tool that makes it easy to iterate and easy to find information: If your way of creating documentation is to write a word document or PDF and upload it to a shared drive, it’s not very likely you’ll see a 1.1 version, let alone a 2.0 version.  In part that’s because a word document is not a very good collaboration tool, and shared drives don’t make it easy to find things.  I am a huge fan of wikis.
    • Wikis let you truly collaborate (some in real time)
    • Wikis allow endless hyperlinking, instead of forcing one path to each document like a shared drive, and dynamic links in the text to other pages and people.
    • Wikis make formatting very easy so the writer can focus more on the content
    • Wikis usually have subscriptions to topics to notify interested parties of changes and additions
    • Many wikis allow enough security that some sensitive information can be published to a limited audience
    • Many wikis are versioned, allowing everyone to see changes over time, and revert undesirable changes
    • Wikis often let you export pages as HTML, PDF, or DOC if you need to distribute the information externally
    • Creating a new page in a wiki is usually as easy as referencing the name on an existing page
    • Wikis have built in search engines
  • Maintain distribution lists: Recording the information is only half the battle. It needs to be delivered to the right people.  Relying on people to keep track of everyone in each group, and even which groups are interested in which topics, is error-prone, especially in a growing organization.  Mailing lists can be helpful, but the best tool for maintain distribution lists is something that can be used by several channels, like Active Directory/LDAP.
  • Divide up the work: Sometimes there’s only one subject matter expert in an area, but it’s often the case that different people know all, or different parts. Instead of putting the burden on just one person, you can have different people work on different parts, or have reviewers contribute to the initial effort.

Read on…

Share

Looking for Software Engineering Manager position

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.

Share

Doing Just What’s Needed

As a creative person (and as a geek), when building something (software or hardware), I often say to myself “For just a little more time and/or effort, I can add this cool feature.” There are many good reasons why this is a bad idea.  I would like to lead with the reason that has caused my blog to be stagnant for months, which is that doing more than you have to gets in the way of actually finishing.  An artist I almost knew once said “The hard part about painting, is not the painting, but knowing when to stop.

Since my last post, I’ve started about six posts that I never finished because I just wanted to add this one last point, or tweak that paragraph one more time.  The result was no visible work output, which is inexcusable for an Agilista. Read on…

Share

I am once again employed

Last week I started my new job as a Principal Software Engineer at Workscape.  I’m back in another Agile position, working on Java (and starting work on Flex, too), which are the two things I was looking for.  I would have settled for a position at a company that wasn’t Agile, but it would have been hard, knowing the benefits of it. I was waiting to post this until I got my first paycheck or did my first commit of fixed issues, whichever came first. Thursday and Friday I fixed three issues, so now it’s official.

Workscape offers HR services to other companies and their employees.

Share

Looking For Work. Again.

I am no longer at Litle & Co.  My separation agreement prevents me from discussing the details, but it’s fair to say I’m not very happy about it.

I have been a hands-on Manager, a Team Lead, and a Principal Software Engineer.  I’m looking for a full-time position in the Greater Boston area (but not downtown Boston) developing Java, preferably in an Agile environment.  I have extensive experience in software design and development, as well as hands-on management. My strengths are my diversity and depth of experience, perseverance, ability to learn new technologies quickly, and organizational skills.  My specialty is cross-platform development and tools.

You can read more about my skills and projects, and download my resume, on my portfolio page.

Share
Next Page »

Site info