Developers Guide to Sending Email (SendGrid vs Mailgun)

As a developer at some point you will likely need to send email from an application.  The days of handling that on your own are long gone.  There are a myriad of services out there that will save you time and make life easy.  Often times it comes down to SendGrid vs Mailgun.  I could wax poetic about the approaches and features of both, but honestly I think a picture would be easier.  So here it is the Developers Guid to Sending Email (or Evolution of Email).

 

Evolution of Email

Evolution of Email

Any questions?

MailChimp Christmas Gift (Minion Handbook)

At Integrum we use MailChimp to send out our AgileWeekly Newsletter.  We love the experience and the product.  One of the things that is apparent to me is that MailChimp knows how to have fun.  I suspect it has to be one of their values.

When I stopped by Gangplank over the holiday I found a package on my desk from MailChimp.  I opened it and was AMAZED. It was a nice box set. The first thing I pulled out was the post card.

Front of Card
Untitled

Back of Card
Untitled

This would be “normal” for a company to send. Impressive. Great design. Light hearted. Kudos.

However, that was the just the tip of the iceberg. Next was a full comic “Th’ Adventoorz of Freddie & Mannie”.

Cover
Untitled

Back
Untitled

Jacket Cover
Untitled

I don’t have any idea the meaning of the comic book, but it was brilliantly designed. A pure work of art. If this was all it contained I would still be writing this post, but oh noes. MailChimp knocked it out of the park by including the Minion Handbook.

Cover
Untitled

So what might you find in such a handbook? How about the Minion Oath?
Untitled

or maybe Dressing and Grooming Standards?
Untitled

or a Frequently Asked Questions, including how to read your leader?
Untitled

If all that wasn’t enough at the back of the handbook one can find a minions notes
Untitled

I can not tell you how impressed I am by the thought, care and design found in this. I am completely perplexed what we did to deserve receiving it, but it was by far and a way the most memorable gift a vendor has ever sent as a gift.

Well done. MailChimp. Well done.

Face to Face for Remote Team Members

Seeking Presence

Trying to do Agile practices on teams with remote team members is always a challenge. Especially when there is only one person on the team that this not physically co-located with the rest of the team. It is easy to feel disconnected from the rest of the team and even simple interactions feel painful. When you are the person left on the end of the phone after everyone else has left the room, asking if anyone is there, it is hard to feel valued. Digital tools for process management and video conference rooms are a good step, but they still leave a lot to be desired.

Virtual Team Member

Virtual Cookie Sharing.

Finding Face to Face

If we look at the Agile Manifesto‘s principles we find:

 “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

So how can we do that on a team with a single member that works remotely?

One solution I have seen that works very nicely is an iPad Mini plus a Nootle iPad Mini Flex Stand. This allows the team to pipe in the remote person to the iPad mini and have as close to face to face communication as possibly with out being physically present, with them all the time. The brilliance is that it is completely mobile. If the team goes to stand up they simply pick up the iPad and walk with the person to the standup. They can pass the person around as the token or prop them on the wall or a shoulder. When going into a meeting room for something like planning or retrospectives they simply put the iPad on the chair and the virtual member sits like everyone else. If they decide to take a team lunch no worries they just take the team member with them.

Recently, I caught a team using this solution trying to feed their virtual team member some home baked cookies that someone brought in to share with the team (see above photo). As you can see it doesn’t solve all problems, but it sure helps some with presence.  You may miss freshly baked cookies, but at least you will still feel like part of the team.

What is the Difference Between Scrum vs Kanban?

What Process is Right For My Team (Scrum vs Kanban)

I see a lot of new teams search endlessly for the best process for to use.  They tend to ask what is best for us?  Which usually devolves into Scrum vs Kanban. I am firm believer in experiencing them to understand, but one could argue you have to start somewhere.  For those seeking here is a very brief quick side by side view.

Copyright Klean Denmark

Copyright Klean Denmark

Similarities Between Kanban and Scrum

  • Both are Lean and Agile
  • Both use pull scheduling
  • Both limit Work in Process (WIP)
  • Both use transparency to drive process improvement
  • Both focus on delivering releasable software early and often
  • Both are based on self-organizing teams
  • Both require breaking the work into pieces (decomposition)
  • In both cases the release plan is continuously optimized based on empirical data (velocity or lead time)

From Henrik Kniberg’s “practical guide” comparing Kanban vs Scrum (pdf).

Quick Feature Comparison

Kanban Scrum Hybrid
Daily Stand-ups No Yes Yes
Artifacts None Backlog, Current Work, Burndown Charts Current Work
Metrics Lead Time/Cycle Time Velocity Lead Time/Cycle Time
Demo/Review Not used Required Optional
Skill Sets Specialized Allowed, Cross-Functional Optional Cross-Functional Prescribed Specialized Allowed, Cross-Functional Optional
Iterations Optional (can be event driven) Yes Optional (can be event driven)
Commitment No Yes (Per Iteration) No
New Work Prioritized Immediately (Optional) Prioritized at Sprint Planning Meeting Prioritized Immediately (Optional)
Retrospective Not used Required Optional
Work Decomposition No Size Limit Limited to fit within Iteration No Size Limit
WIP Limiting Per workflow state Per sprint Per workflow state
Estimation No Prescribed Optional
Work Visualization Board is persistent Board reset every sprint Board is persistent
Defined Roles None Product Owner, Scrum Master, Scrum Team Product Owner, Scrum Master (Optional), Scrum Team

How to Run a Lean Coffee Meeting

During a session at Agile Open Northwest convened by Arlo Belshee a number of us discussed good ideas (Lean Coffee, Core Protocols, Open Space Technology, Technical Practices and Team Practices) that needed to be spread.  These are things we take for granted in the Agile community, but when introducing them to people it becomes obvious that they are not as common as we think they are.

Agile Weekly put together this video showing you how to run a Lean Coffee meeting.

When you need a structured, but agenda-less meeting. Lean Coffee is a great way to allow participants to gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.

 

Agile Open Southwest Recap

Open Spaces always tend to amaze me.  They really are the right people in the right place at the right time.  When we kicked off Agile Open Southwest, I was a little bit nervous about what might come out.  As always, I was left absolutely amazed.  It was great seeing old friends and meeting new ones.  Finding everyone was a different place on their journey yet still able to be find common ground and learn from one another.

Alan Dayley led a great session on Permission Restriction.  What is holding us back?

Jade Meskill helped us articulate what the Phoenix Agile community could look like using Legos.

Roy van de Water helped us discover how we can learn together and what might be holding back internal improvement communities.

I was able to have a frank discussion about excellence and how it can propel us to the next level.

We broke bread together and got to know each other.

Most importantly we were human with other and left encouraged we are not alone in our quest for improvement.

I can’t wait for next year.




Should Senior Developers Pair Program?

I am a proponent of pairing (not just for programming). Anytime I introduce it to a new team I get a number of objections. The most prominent is that pairing slows me down (because I am so awesome and everyone else sucks so bad).

The logic goes something like, if I am good (and fast) and you are good (and fast) we could be just as fast alone as we are together. Since we are both good do we really need to pair? or I am good (and fast) but you are bad (and slow) so pairing with you means we will never get anything done because you are slowing me down too much. Maybe I am good (and fast) but you are okay (and not fast or slow) then maybe we should pair because we can be fast but I can make you better.

The problem here is that there is a belief that pairing is about going faster. It isn’t (at least not in the short term). It is about achieving something greater together than we could alone. A great African proverb goes something like “If you want to go fast, go alone, if you want to go far, go together“. Pairing is about improving together.

So I might slow you down. It means I am learning and by default you are teaching. Together we are both improving. If we think of it as a marathon instead of sprint we can see that together we can get much farther by slowing down to speed up.

Definitions of Pairing Partners: (Dreyfuss Model)

Novice (Advanced Beginner)
Has little domain and/or technical understanding. This is your classic n00b, junior developer or intern.

Competent (Proficient)
Has some domain and/or technical understanding. This is your standard developer.

Expert
Has deep understanding of the domain and/or technical aspects of the system. This is your senior developer.

Here is my theory on combinations of pairing:

Novice and Novice
In this match up the production will be very slow, but the learning will be tremendously high. This is because the pair is totally reliant on each other for discovery because they have no other choice and no existing knowledge.
Learning: High Production: Low

Novice and Competent
Production will be moderate as the competent programmer will often not try to explain too much and will work at close to a normal pace for themselves bringing the novice up to their speed. The learning will be fairly high because neither has all the answers and are dependent on each other.
Learning: High Production: Medium

Novice and Expert
Production will be low as the expert is often a poor teacher and goes into too much detail explain concepts too difficult for the novice. The novice likely will ask a lot of questions and be confused. However production will still be greater than two novices. The novice will likely learn a lot, but will be drinking from a fire hose while the expert will learn new things by teaching. Overall yielding a medium learning level.
Learning: Medium Production: Medium

Competent and Competent
Production will go at a good pace as the both participants are at the same level allowing for a cadence to develop. Learning will be good for both as their shared level will allow for maximum trust.
Learning: Medium Production: Medium

Competent and Expert
Production will be high in most cases as the expert will not have to explain things in detail. Learning will be medium as the competent participant is often reluctant ask questions and the expert tends to lean towards auto pilot mode.
Learning: High Production: Medium

Expert and Expert
Production will be high as the energy level will be strong and the cadence rhythmic. Learning will be low as neither participant will likely ask a lot of questions or seek new understanding.
Learning: Low Production: High

So why bother pairing if production is “High” in a majority of pairings? Because we are not worried about this iteration/sprint we are worried about 100 iteration/sprints from now. Below you can see the difference in production over time between teams that do promiscuous pairing of multiple types versus teams that do no pairing at all.

Together (Pairing)

 

Alone (Not Pairing)

 

 

 

 

 

 

 

 

Does your team want to go fast or do they want to go far?

Hacking Standups – I Feel Exposed

At Integrum we regularly find new things to try as a result of our regular team retrospectives.  Recently, the team had a lot of discussion about what it takes to make teams great.  There was a lot of discussion about the necessity to be vulnerable with each other in order build deeper levels of trust.

The team decided to add something to our daily stand up.  We added the question “I feel exposed because…”.

The results were interesting.  We found that often times the things that left people feeling exposed were early warning signs to problems in getting the work done.  Seeing these before they became road blocks actually had the effect of increasing productivity.

Additionally, it allowed many team members to express fear in a safe way.  Allowing others on the team to help them move through it.  Ultimately, we did not stick with the hack because our team changed significantly and the new team was much closer and didn’t feel the need to explicitly state how they felt exposed.

How are you hacking your SCRUM ceremonies?




Ruby Revolution Rebuttal

Mark Turner has made a great response titled “Ruby never powered a revolution” to counter my recent post “Ruby is Just a Bunch of Tools“.  Excerpts from Mark’s post bold.

“I decided he was wrong.”

Mark, I am never wrong.  However, I have been known to be mistaken a time or two. :)

“Ruby was never about revolution, Ruby is about making us, as developers, happy. For many of us it was a language whose syntax, expressiveness and quirks touched the right nerves. It was the feelings we got about the language that made us want to use it. It wasn’t it’s speed (lulz), it wasn’t it’s libraries and it sure wasn’t its popularity. For many of the people that have been using Ruby for a long time, at one point they dreamed of getting a job that paid them to write Ruby. Today they are plenty of jobs.”

I think I consider Rails, Ruby for right or wrong.  Ruby purists can bitch and moan about that all they want, but the reality is if Rails didn’t exist Ruby would have virtually no adoption and barely be considered a real language.  I think a lot of the idealism I speak about came from the Rails community.  Driving for testing, convention over configuration, etc.. Hell the fact that active record got people to the point where they aren’t writing SQL queries is simply an amazing feat.  Something Smalltalk and the likes were never able to get widely adopted.

Define plenty of jobs.  The Ruby community is microscopic in the grand picture of programming.  A quick search of Dice.com for ruby yields 1,735 results, .net yields 9,986, java 17,239. While this is impressive it’s still a fractional portion of the world today.

“At the heart of Derek’s argument it would seem that the abundance of tools, and the creation of those and new tools or workflows are somehow unrelated to changing the status quo or spreading new ideas. I don’t understand this argument. I get a smile whenever someone decides that a tool doesn’t fit their needs so they make their own. I get exited whenever someone brings a new idea to Ruby or is unhappy about the way a library/application they use works so they fix it.”

It is not the abundance of tools nor the creation of tools that is the problem.  It is that the community thinks technology is the answer to everything.  Instead of pushing against the status quo to think differently.  The drones are just trying to make the status quo faster or more efficient.  Making a better (speed, syntax, etc) test framework is not the same as introducing the concept of TDD or BDD for the first time in a meaningful way to get wide spread adoption.  I am not seeing any real creativity from the community, it is all geekery instead.  While a faster, cooler, automated foo is great, it’s not pushing the industry forward.

“Derek also has a point about the abundance of “non Ruby ideas” at regional ruby events.”

I articulated this poorly.  I was trying to say that we are too focused in on hearing speakers talk about tools they have written instead of talking about the possibilities of where the community can go.  Regional conferences used to be about people sharing cutting edge ideas and trying new things.  Now they are about the “speaking circuit” for tool/library authors to pimp their shit or the Ruby personalities to measure their community e-peen for organizing a conference.

Personally, I have seen other platforms start to catch up and people that are more language agnostic seem to be moving the industry forward the most.  I am finding the revolutionaries more in the Agile community than the Ruby community at this point.  Ruby has a special place in my heart (as does Rails) for inspiring me to stand up and fight for change.  To not accept the status quo as reality and champion the future.

I write this as I prepare to speak at Agile 2011 this week.  Am starting a new Django project with a team while doing agile coaching at a .NET enterprise client.  While still committing code to a Ruby project for a Fortune 50 client.  Guess I’m an innovation slut instead of a Ruby whore these days.

 




The Effects of Shifting/Resetting on Society

If you are listening. A lot of people are talking about a “new norm”, a “reset” or a “shift”.  Largely this discussion is around economics and growing concerns of debt.  In reality it is about a lot more than that.

Every so often a significant transformation happens.  Five recent transformations:

  1. The Industrial Revolution
  2. Age of Steam and Railways
  3. Age of Steel, Electricity and Heavy Engineering
  4. Age of Oil, Automobiles and Mass Production
  5. Age of Information and Telecommunications

During each one of these shifts/transformations/resets more than the economy was changed.  Social norms are impacted as well.

  • Homes
  • Work Places
  • Educational Systems
  • The Way We Govern
  • How We Spend Our Liesure Time

I am excited to be living in a period of transition and doing work with Integrum and Gangplank tackling how these issues play out.  I love talking abouf this stuff.  Let’s chat over a beer sometime.