Welcome to my blog! Please keep these three things in mind:

1. Everything on my blog is my point of view and does not represent the view of any company I've worked for, past, present, or future. 
2. If you want to respond to anything I've written, use my Contact form. 
3. The previous version of my blog is partially available online, but I put the best parts of it in my first book, Minority Tech: Journaling Through Blackness and Technology. You should buy it. It's fun.

Moving from Individuals and Time to Points and Velocity

posted Aug 26, 2015, 12:45 PM by Anjuan Simmons   [ updated Aug 26, 2015, 1:58 PM ]

I've been in meetings with many CIOs where the CEO demands to know when features will be done. CIOs inevitably resort to framing their answer in terms of individuals and time. This is fine in a waterfall environment, but this framing is often done on Scrum projects. I usually (in private) coach the CIO in a discussion or email that goes like this:

I wanted to share with you my thoughts about communicating to upper management when things will be done. During the last meeting I attended that included you and the CEO, this exchange happened several times:

CEO: When will this feature be done?

YOU: It will take one developer # weeks.

I think that communicating timelines to the CEO in terms of individuals and time estimates is, while common, sub-optimal. This is based on two theories:
  1. Finishing a feature takes more than the skills of a developer. Getting a feature to Done requires QA and often design resources. That's why Scrum uses story points to size features according to the Definition of Done which includes all of the work needed to get a feature to Done.
  2. Humans are bad at making time estimates even when using concepts like "ideal days". Also, upper managers tend to "do the math" with time estimates by trying to do calculations based on number of developers and how many days of work they get get out of a sprint. That's why Scrum uses velocity (a dimensionless value) as a measure of what the team can get done in a sprint.
So, based on these two theories, exchanges with the CEO would go like this:

CEO: When will this feature be done?

YOU: That feature is, relative to similar features we've done in the past, # points. The team has a velocity of X, so, if the team only worked on that one feature, it would take Y sprint(s).

By doing it this way, you give our CEO an estimate based on everything needed to truly finish a feature. Of course, it's even better if the size communicated to her comes from the team that will do the work. However, I know the investment of time required for team estimating may not be possible before giving an estimate to our CEO.

This exchange has to be done in the context of the team assigned to any given project. It is natural for velocities to vary widely between Scrum teams.

Of course, there is no way of communicating estimated times to complete that cannot be gamed or questioned by a CEO. However, I think that using points and velocity gives the CEO what she wants with a reasonable degree of accuracy.

Becoming a Paid Public Speaker

posted Jul 27, 2015, 11:45 AM by Anjuan Simmons   [ updated Jul 27, 2015, 11:46 AM ]

A friend recently asked me this question about becoming a hired speaker:

@anjuan: Where did you start with presenting yourself as a hired speaker? Organizations? Inner network? Free engagements then started to charge? Was it a massive email saying you were available? #seriousinquiry

Here's my answer:

• You’ll probably have to speak for free before you can speak for a fee. Start hitting up local meetups and bar camps and volunteer to speak. You won’t get money for these talks, but you will get extremely valuable experience speaking in front of crowds and honing your public speaking skills. Make sure you connect with your audience before, during, and after your talk. Post your speaker slides, notes and pictures to social media.
• As you get more experience, apply to speak at conferences. Ideally, you will have several talks that align with a conference track. Again, start local and branch out to your greater metro area. You will probably have to drive to these conferences and pay for your expenses. Continue to connect with people and project your content via social media. I think that creating a newsletter that people can subscribe to is a great strategy. Email marketing is very powerful.
• In time, you’ll find conferences that offer to cover your expenses when they accept your talk. However, even if not offered, you should *always* ask to have your travel (flight and hotel) expenses covered. Of course, your registration expenses will be covered as a speaker. Some conferences offer an honorarium, but that is fairly rare.
• You will eventually reach a crossroads. You can seek speaking gigs that offer more money, but that requires full dedication to life as a public speaker. While I know people who are full time public speakers, it is a life of constant travel and all the complications of life lived out of a suitcase. Or, you can enjoy a set number of speaking gigs that let you travel around the world and talk about your passions. You’re not making enough money to support yourself, but you are getting some nice air miles, hotel points, speaker gifts, and cool relationships. 

I’ve chosen to take the path of a handful of speaking gigs each year that require me to keep my day job but allow me to get in front of audiences around the country and share my ideas. This path supports my current professional and personal goals while gratifying my love of performing on stage.

Perfect Software vs Crappy Software vs Acceptably Shippable Software

posted Jul 15, 2015, 11:21 AM by Anjuan Simmons   [ updated Jul 15, 2015, 11:22 AM ]

As a Scrum Master, I often write emails to my Development Team to bring them back to First Principles. This is an email I wrote when we were struggling with a feature that we knew could not ship with the polish we all wanted it to have. The team had to meet a hard deadline so, as is the case when time is a constraint, scope had to be reduced.


I've been thinking about how to balance the implementation of this feature between Perfect Software (which never ships) and Crappy Software (which ships all too easily). How do we get to Acceptably Shippable Software?

I hope we can all keep in mind that this release won't be the last time we touch this feature. If we can find an acceptable implementation for the majority of our users, we can iteratively improve that implementation one to two sprints after the release. This will allow us to firm up our thoughts about the feature and also hear from our customers. In addition, shipping by our deadline will provide some internal relief that I think we can use. As I've said, "Shipping heals all wounds". The assumption, of course, is that you don't ship pain.

I trust that the team can find the right balance as we work together.

SXSW Maximization Tips and Serendipity

posted Jul 14, 2015, 10:29 AM by Anjuan Simmons

I was recently asked for my top tips for maximizing the experience of SXSW as well as a story of a serendipitous encounter. Here is my answer to both:

The best way to maximize your experience at SXSW Interactive is to plan to fail! By that, I mean that you should use the SXSW app and website to create a detailed schedule with several options for each time slot. Since South By is a multi-track event, you should have have multiple events scheduled for every hour so that, if any given event isn't working for you, you can easily move to another one. However, even the best laid SXSW plan is bound to fail so go with the flow and focus on enjoying the experience!

I also recommend having a back channel. Monitor Twitter and other social media outlets in the weeks right before SXSW, and you'll probably see people listing hashtags or Slack teams to follow or join. These back channels help you cut through the noise of SXSW and see what events like-minded people are attending. This is a great way to discover intimate events that fall under the hype radar and also that secret party that always is disclosed at the last minute!

I had a serendipitous encounter at SXSW when I was walking to a late night party and ran into a friend who I haven't seen since he came a book signing I had in Austin a couple of years ago. I totally didn't expect to see him, but that brief interaction further strengthened my friendship with him. You may not find your best friend forever at SXSW, but you will definitely have the opportunity to incrementally advance many deep and meaningful relationships.

Making Room for QA in Scrum Sprints

posted Jun 4, 2015, 7:50 AM by Anjuan Simmons   [ updated Jun 4, 2015, 7:52 AM ]

It is not uncommon for members of Scrum Development Teams who perform QA activities to complain about work being given to them at the end of a sprint leaving little time to complete tests of features. Here are some solutions that I have shared with one of my Scrum Development Teams to address this problem:

I've been going through the Retrospective feedback shared over the last few sprint and thinking of ways that I can address some of the problems that have been shared. One problem was the experience of having little time to QA features that were developed and code reviewed toward the end of the sprint. A correlated problem was the feeling that QA was relatively idle early in the sprint and then went into overdrive at the end of the sprint. These problems may have reduced in severity since we always have features in QA that move on to the next sprint. So, QA is busy finishing features that did not make it to Done in the previous sprint. However, I think that this is masking the problems rather than solving them. So, I wanted to present some solutions that I've used in the past that I hope will help once we have fewer cards moving across sprints.

The first solution is to turn the problem on its head by creating the tests for features before they are implemented. After we analyze and size features in Sprint Planning, instead of development immediately working on the feature, the QA team will create the tests (manual or automated) based on their understanding of the feature. This is a great way to make sure that any QA related questions about a feature are answered by the Product Owner. Once the tests are created, the features are implemented in code. Of course, there will still need to be an actual test pass once the feature is complete.

The second solution is an iteration of the first one. After features are analyzed and ordered during the Backlog Grooming session, the QA team can create tests for features at the top of the backlog. This will allow QA to "get ahead" of work that is likely to be worked on in a current sprint.

It's my understanding that the team has experience doing testing before implementation so I know that these are not new ideas. However, I hope that the team can use them to resolve some of the issues raised in past Sprint Retrospectives. 

Dealing with the Three Types of Haters

posted Jun 4, 2015, 7:23 AM by Anjuan Simmons   [ updated Jun 4, 2015, 7:28 AM ]

A colleague of mine has been doing a great job of speaking at technology conferences. I have been very impressed by her willingness to add her voice to the world of ideas that make technology conferences so special. However, she recently sent me an email about how some people have responded to her talks:

So I just got my reviews and the majority of them were pretty good, but there were 7 - 8 really mean spirited ones. And it really bummed me out. Comments like 'got automation wrong, unrehearsed ' etc. which is not true, i only talk about things i practice... ALWAYS. 

So I can't really shake it off , obviously I will get better as this was my first tech talk, ever. But how do you deal with haters ? I mean people trying to put you down in 'capital letters'- haters ? 

Here is my response:

First, thanks for reaching out to me. I am always happy to do what I can for my fellow technologists! And, congratulations on the development of your public speaking career! Your willingness to put yourself out there will inspire more people than you know.

With regards to haters, I've been there. I've read feedback, online comments, and tweets after I've given technical talks. What helps me deal with haters is understanding the different types of haters. Not all haters are created equal. I put them into three groups: Jealous Haters, Fanatic Haters, and Clueless Haters.

Jealous Haters

Jealous Haters wish they were you. They hate the fact that they you got a talk accepted into the conference. They hate that they (or their company) had to pay for their registration, but you probably got it for free. They hate seeing your name in the conference documentation because it verifies your expertise, and they feel that somehow reduces their own knowledge. Some of them even submitted a talk and got a rejection letter. So, Jealous Haters often project the anger they feel toward themselves at you. You're doing what they wish they could do.

I ignore Jealous Haters. There's nothing I can do for people who hate me just for doing my thing. All I can do is continue to shine while they hide behind shade.

Fanatic Haters

Fanatic Haters are people who spend their entire lives eating and breathing tech. They will knock you for missing some minute detail that they know because they do nothing but tinker with tech. You'll often see Fanatic Haters come to introductory sessions like the one you described simply so they can feel good about how much more they know than most of the people in the room.

I actually find Fanatic Haters useful. They often share deep insights if you read between the lines of their hate. So, I try to learn from their feedback and save it for more advanced sessions. I consider them almost like free sources of research. While I'm building my career and actually enjoying life with friends and family, they spend weekends in the lab discovering things that can make my life easier.

Clueless Haters

Clueless Haters are the opposite of Fanatic Hates. They simply don't know what they are talking about. However, their lack of knowledge does not stop them from trying to comment on a topic. You can identify Clueless Haters by just reading their feedback. It just doesn't make sense.

Like Jealous Haters, I ignore Clueless Haters. They have nothing to offer. But, reading their feedback is often funny.

I hope this helps! Don't let Haters (of any type) get you down. The work you do is too important to let people who don't even know you stand in your way. I am cheering for you!

Creating Meeting Free Zones at Work

posted May 28, 2015, 7:57 AM by Anjuan Simmons   [ updated May 28, 2015, 7:58 AM ]

There have been a number of recent posts that make the case for the mornings as the time of peak productivity. For the average person, that window is between 9 AM and 11 PM. However, what do most people do during those hours? They check email, browse Facebook, or sit in meetings. That is not the best way to use the most creative and productive hours of the day. However, most workplaces structure their day in a way that squanders the efficiency of their human capital.

I propose a better work day and an example is below. Since I work in software development and love Agile, I’ve included a morning Scrum in my example. In my experience, Scrums are best held in the morning before team members settle into their day. A Scrum should take no more than 30 minutes. The ones I run average around 7 minutes in duration, but I allocate half an hour for padding. You can replace that scrum time with whatever works for your industry.


Notice that the afternoon is reserved for meetings because people have usually spent their productivity doing their morning work. Also, notice that there are only 2 options for meetings: 3:00 PM and 4:00 PM. I call this the "Meeting Box" because that's the time box within which all meetings must be scheduled. I believe that meetings are massive wastes of time, and most of them are run poorly. So, limiting the number of meeting slots forces meeting organizers to schedule and manage them wisely. Of course, if your office has three meeting rooms, then you can have 3 meetings at 2:00 (one in each room). Or, if your organization uses virtual meetings, you can have nearly an unlimited number of meetings inside the Meeting Box as long as the attendees vary. However, they all should last no longer than one hour.

I also propose a rule that you cannot schedule a meeting any earlier than the next day. If something is urgent, instead of scheduling a meeting right now to discuss the problem, find a key decision maker and engage one on one. Afterwards, send an email summary of the problem and selected decision to all stakeholders.

I once worked at company that had a "Meeting Free Day" where no meetings could be scheduled. Our Meeting Free Day was every Friday. Having the Meeting Box and Meeting Free Day are great ways to unleash productivity by creating Meeting Free Zones at work.

Fixing Sprint Fatigue

posted May 19, 2015, 11:28 AM by Anjuan Simmons   [ updated May 19, 2015, 11:30 AM ]

A person in one of the Agile forums I follow asked this question:

In a casual conversation with a new client in the throes of implementing "scrum", one developer mentioned that they ran into "sprint fatigue" with several others from that team nodding in agreement. A member of another team sitting nearby also agreed. The fellow said that he was referring to the "routineness" of the sprint activities and that it was 'boring".

The term was expressed as though the malady is a common thing in agile or at least in Scrum, but I had not heard the phrase. Is anyone else familiar with the malady and can enlighten me about it's symptoms, causes and cures?

Here was my response:

I have encountered a number of organizations that have stated "Scrum isn't working for me" or "We're tired of Scrum". More often than not, these organizations are not really practicing Scrum. When I inquire into the length of their sprints, their Definition of Ready, what's the Definition of Done, how is the Product Owner performing, etc., I get a sense of the real problem. Scrum, by definition, is not a methodology and can absolutely be modified to fit the reality on the ground. However, at some point, an organization ceases to practice Scrum. Many never practiced Scrum in the first place.

I recommend taking a team through the Agile Values and Principles and asking if the team still believes in them. I would also ask the team if they are fatigued by taking complex work, breaking them down into user stories, and delivering features that have a high probability of being valued by customers. Are they tired of managing their work and directing their destiny?

I also recommend doing a Retrospective strictly on how the team has practiced Scrum. You can pull up the Scrum Guides (http://www.scrumguides.org) and do a simple compare and contract. You may solve a lot of this Sprint Fatigue by simply improving how the team practices Scrum.

What Agile Tool Should Be Used?

posted May 18, 2015, 3:46 PM by Anjuan Simmons

A member of an Agile group I follow on Linkedin asked about what Agile tool should be used to manage and report the work of the Development Team. The person who asked the question felt that Post-it notes and index cards on a whiteboard were best, but he has seen several Agile Practitioners advocate online tools like Jira, PivotalTracker, Trello, etc.  Here is the answer I posted:

As some have said, I think that the tool you use is considerably lesser in importance than how the team uses the tool. Even post-it notes or index cards that move on a physical board between lanes can be ineffective if the team does not use them well. Regardless of tool, I recommend that the following practices are in place:

* Everyone knows where the tool is and has access to it. This is a requirement for the members of the development team but is also suggested for the entire organization.
* Everyone understands how updates are made to the tool and who can make each type of update.
* Everyone rigorously keeps the data in the tool fresh. This usually requires daily updates.
* The tools should be the single source of truth for the work done by the team. Any other sources of information (Slack, FlowDock, memory, etc.) should be deprecated in favor of the tool.
* Any information those outside of the Agile team request beyond working software is provided in the minimum acceptable format. Efforts should be made to discard the reporting and replace with working software as soon as possible. This is often done through frequent demos of working software at the end of the sprint, but preference should be given to conducting a demo whenever a user story is done.
Put these practices in place and you'll increase the value of whatever tool you select and implement.

The 10 Planning Poker Commandments

posted May 1, 2015, 7:04 AM by Anjuan Simmons   [ updated May 5, 2015, 6:44 AM ]

In my role of ScrumMaster, I have coached several teams in how to use Planning Poker to size user stories. So, with tongue firmly planted in cheek and mea culpas prepared in advance, I have distilled the lessons I have shared with these teams into a crisp list:

“I am the ScrumMaster, who brought you out of Waterfall Development, out of the house of slavery."

  1. "You shall bring no time estimates to Planning Poker."
  2. "You shall not take for yourself a user story that does not match the likeness of the Definition of Ready. You shall not discuss or size such a story, for the software we build is jealous, visiting the iniquity of Un-Ready work on Developers, on the third and fourth sprints of those who size such work, but showing lovingkindness to thousands, to those who heed the Definition of Ready, to those who want to get work to Done within a Sprint."
  3. “You shall not take the Definition of Done in vain, for the work will not leave Developers unpunished who size ignorant of the Definition of Done."
  4. “Remember completed stories, to keep them holy. You completed stories of various sizes in previous sprints, and you should use those as a relative guide for estimating. You shall not size without considering completed stories, you or your son or your daughter, your tester or your designer or your programmer or the manager who stays with you. For in previous stories the team made the heavens and the earth, the sea and all that is in them, and sized them all; therefore the work has been made shippable and made holy."
  5. “Honor your fellow estimators, that your work may be Done in the upcoming sprint."
  6. “You shall not allow anyone to size stories who will not do work in the upcoming sprint".
  7. “You shall consult with the Product Owner."
  8. “You shall not steal the estimate of another."
  9. “You shall not prematurely show your estimate. That is an abomination."
  10. “You shall not base your estimate on how you think other estimators size cards. You shall not base your estimate on how little or how much work you think the team should do during the sprint. You shall only base your estimate on the merits of the story and on the merits alone."

1-10 of 33