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.


The Definition of Done

posted Feb 25, 2015, 1:45 PM by Anjuan Simmons

One of the principles of Agile is the "Definition of Done".  This is a checklist of the things that must be satisfied before a user story is complete and ready to be deployed to customers. It's important that this include everything that needs to be complete before deployment from development to QA.

I found a great example Definition of Done on an agile Linkedin group I follow. It was submitted by Bruce K:

Bruce K.

Vice President Product Development @ QuadraMed

Everyone has or should have a definition of done. Here is one that I used: 

The purpose of a story is to deliver something of value to the business. So, in order for a story to be in the “done” status it must pass the following criteria. 

Feature Complete – A user can see and use the functionality outlined in the story. 
Code Complete – There is no tech debt that must be worked on in later sprints. 
Static profile, performance and security reviews/tests are complete. 
Code Review by Team Leader – All stories will be reviewed by your team lead (via Gerrit). They will be checking to make sure standards are followed. Standards in terms of architecture, code structure, and follow best practices. Code must pass this step before it is checked in. Please be sure to communicate about the code review with the reviewer to schedule this. This must be done TOGETHER. 
QA Complete – No bugs are open and QA or Team Lead has determined all story acceptance criteria are met. 
Approved by the Product Owner 
Production Ready – Code is buildable without errors and warnings and is deployable.

Filter Out Filler Words

posted Feb 18, 2015, 3:13 PM by Anjuan Simmons   [ updated Feb 18, 2015, 3:24 PM ]

I occasionally review websites for how usable they are on the UserTesting.com site. I enjoy user interface design, and UserTesting.com also pays for each site you review. It's a nice way to fund my Starbucks habit. :)

My feedback about how to be an effective user tester was recently posted on the site's blog. You can find it here.

I've reprinted my advice below:

Stop using filler words. Filler words are phrases like “ummm” and “you know” that we often use to insert into our speaking to avoid gaps of silence. The best way to remove them is to realize that silence is fine! While it may seem like an eternity in your head, taking one or two seconds to organize your thoughts will be almost unnoticeable to the people listening to your recording.

One reason I wanted to offer advice on using filler words is that I constantly work to remove them from my everyday speech. Even great public speakers occasionally use filler words in personal conversations. I see filler words as lazy mental shortcuts that we use to avoid silence and gather our thoughts. As I said in my blurb above, it's ok to have a little silence!

On a related note, I enjoy doing interviews because they give me a chance to hear my recorded voice. While I personally think my recorded voice sounds strange, I listen to recordings of my interviews to see how I'm doing with filler words. I used to use "you know" a lot, and I've worked to stop doing that. However, I now see that I'm using "right" as a filler word when I speak. For example, I need to stop using right, right? That is pretty irritating, right? You get my point, right?

It takes work to stop using filler words, but it's worth the effort. This is especially important for those of us who are public speakers, but it's also important for everyday conversation.

Co-Locating the Product Owner and the Scrum Development Team

posted Feb 17, 2015, 12:05 PM by Anjuan Simmons   [ updated Feb 17, 2015, 12:07 PM ]

A question was asked in one of the agile development groups I follow on Linkedin. Do you think the presence of the PO in the same room will affect the Dev Team results? And how? Here is the response I posted:

It's vital the the Product Owner have a collaborative relationship with the Scrum Development Team. However, there is a natural tension in this relationship. The Product Owner wants to deliver as much value to customers as can possibly accomplished in a sprint. The Scrum Development Team wants to commit to only the amount of work that they can finish at a steady velocity. I don't think this tension is negative. In fact, it should be embraced. The Product Owner and the Scrum Development Team should overcome this tension through disciplined estimating of the Product Backlog Items being considered for the upcoming Sprint Backlog.

It's totally fine for the Product Owner to want the Moon and the Stars. However, it is the responsibility of the Scrum Development Team to estimate how much those celestial objects weigh. And that is best done through cordial collaboration whether the Product Owner is in the next room our somewhere else.

My Certified Scrum Professional Application Essay

posted Jan 23, 2015, 4:56 PM by Anjuan Simmons   [ updated Jan 23, 2015, 4:58 PM ]

I became a Certified Scrum Master (CSM) in 2013, and I am in the process of applying to be a Certified Scrum Professional (CSP). One part of the application is an essay about my experience using Scrum. I still need to gain more Scrum Education Units (SEUs) to qualify for the CSP, but I wanted to share my application essay:

I was introduced to Scrum in 2004 when I managed a product support team for a large bank. I was a consultant, and my supervisor on the client side came into our work area one morning during the summer of that year and announced that we would be having a daily meeting called a "scrum". It would start at 8:45 AM each morning, and I have to admit that I was puzzled by the idea. This scrum seemed to just be a daily status meeting. Why did we need a daily meeting when we met every Friday to review the week? And why did we have to stand up?

I soon learned that this "scrum" was more than just a daily meeting. My supervisor laid out the simple constraints of the meeting. We would stand in a circle and share three pieces of information: 1. What we did since the last scrum; 2. What we plan to do today; 3. What blockers stand in the way of our plans. After just a few weeks, I began to see results. Issues no longer waited until the weekly meeting to get resolved. More importantly, our team stopped forgetting to discuss issues that occurred on Monday or Tuesday that they forgot about by the time Friday rolled around.

A few months after we started using Scrum, my supervisor asked me to facilitate the daily stand up. I soon realized that I had a knack for listening to the updates from the team and teasing out blockers that weren't obvious. This was due to my technical background, and I think my supervisor saw that as an asset I could better provide to the development team during the scrum. I didn't know it at the time, but I was functioning, albeit in a vestigial manner, as a ScrumMaster.

My role on the project ended a year later, and I worked on other projects from 2005 to 2008. Most of them were waterfall based, but every now and then I noticed a few teams doing daily standups. I left consulting in 2008 to attend business school, and it was during a class on project management that I really learned about agile development. The class presented agile development as an alternative to waterfall, and I realized that the scrums I first encountered in 2004 were part of an entire framework for delivering complex projects. I began to learn about events like sprints, artifacts like burn down charts, and roles like ScrumMaster (that was me!) and Product Owner.

After graduating from business school in 2009, I returned to consulting. I was keen to find an opportunity to use the full scrum framework, and I found one on my first project. While I was nominally the project manager, I served the team as a ScrumMaster. I organized the work into sprints, facilitated the daily scrums, involved the team in estimating work, and leveraged the principle of "iterate and inspect". My team enjoyed having a say in what they would commit to before each sprint, and we immediately began delivering better results through working software that the client would see in demos every two weeks. I found that scrum was a great framework for a consultant like me to use. I reported to clients who were employees of the company that paid for the project, and I managed contractors that did the work. So, three constituencies were involved: the client company, the consulting company that paid me, and the company that provided the contractors. Scrum provided a way for me to provide continual and iterative improvements to the company that chartered to the project, create an inclusive and motivated team of contractors, and send regular fees to the consulting company that provided me with gainful employment. Agile development became my secret weapon.

I left consulting again in 2012 to join a small construction software company. The Director of Technology hired me because he liked my blend of experience in Scrum and the structure of classical project management. He also paid for me to become a Certified Scrum Master in 2013. I ran our legacy projects using waterfall, and I used scrum for our next generation projects. I chose this dual method because the updates to our legacy products were quarterly and relatively small in size. However, our next generation products were complex and needed frequent releases to both the maintenance updates needed for our cloud infrastructure and the features requested by our customers.

It's 2015, and I have come a long way from the "daily meeting" I was introduced to in 2004. I love Scrum, and I enjoy helping teams practice it. I'm even working on a book about how Scrum can be applied to spiritual discipline and growth. I would like to become a Certified Scrum Professional to quantify my Scrum experience and gain more opportunities to help organizations and people develop and sustain complex projects.

My Thoughts on Smartwatches

posted Aug 29, 2014, 12:33 PM by Anjuan Simmons   [ updated Jan 12, 2015, 7:23 AM ]

Apple is widely rumored to announce a smartwatch at their event on September 9, 2014. If true, the company will join a market already crowsed with offerings from Pebble, Samsung, LG, and other players. However, Apple entered a crowded field with the iPod and almost immediately won the MP3 player market. Apple also entered a crowded field with the iPhone and soon dominated. The iPad faced a field with many tablet computers, but it essentially created the category. Do you see a pattern here?

I have the original Pebble, and I wear it every day. It's a great watch, robust (it survived my participation in Tough Mudder last year), and the notifications on my wrist are nice. However, I'm an early adopter so I know that Pebble style watches will never become mainstream. However, if companies can produce stylish smartwatches, I think those devices will catch on. The New York Times recently ran an article stating that kids going back to school are more interested in their tech gear than clothing. Millenials and Generation Z are starting to see tech as a statement of who they are, and I think style will win the day in the smartwatch category. I think Apple is well positioned to compete on style.


My Pebble after Tough Mudder 2013

Things to do in Maui

posted Aug 26, 2014, 10:04 AM by Anjuan Simmons   [ updated Nov 8, 2014, 9:11 AM ]

A friend recently asked about things to do in Maui, and, since my family was just there a few months ago, here's my reply to her:


I wanted to share the list of places my family and I visited in Maui when we went a few months ago. I hope it's helpful for your upcoming trip.

GENERAL
* I'm not sure where you're staying, but you'll probably drive a lot. If you're not staying in Lahaina (on the West side of Maui), then you will probably drive to Lahaina often.
* If you like nice pools and beaches, then the resort hotels in Lahaina are a great option for you. We wandered from hotel pool to hotel pool, and no one harassed us or asked if we were guests. Several hotels have spas if you're into that sort of thing. :-)
* Whale season had ended so Maui had just started letting water activity companies (wave riders, para-sailing, etc.) resume operations when we were there. If you're into water sports, then they may still be available if whale season hasn't started again by the time you travel to Maui.
* We started the "road to Hana", but my wife gets car-sick fairly easily and the switchbacks were too much for her. So, we had to turn back. Also, Hana is on the East side of Maui so the road is usually a cloudy and rainy drive to a cloudy and rainy part of the island. If you don't mind road trips (where you sometimes fear for your life), then it may be worth doing. If you do try the road to Hana, stopping every few miles and hiking or visiting one of the beaches is a good use of the time you'll invest in the trip. Hana is the destination but the journey is the point.
* There are certainly more restaurants and places than I listed below. These are simply the food establishments and locations that I personally experienced and enjoyed.

RESTAURANTS
* Da Kitchen (very close to the airport; not a bad place to have your first meal in Maui; large portions - 425 Koloa St. #104 Kahului, HI 96732)
* Mama's Fish House (expensive but great food, location, and atmosphere - 799 Poho Pl, Paia, HI)
* Flatbread Company (great natural pizza; near the airport - 89 Hana Highway, Paia, Maui, HI)
* Dazoo (71 Baldwin Ave, Paia, HI 96779)
* Ululani's Shaved Ice (I recommend trying a Hawaiian shaved ice at least once if you've never had one - 819 Front St, Lahaina, Maui, HI 96761)
* Kimo's Restaurant (845 Front St, Ste a, Lahaina, Maui, HI 96761)
* Koa's Seaside Grill (839 Front Street, Lahaina, Maui, HI 96761)

PLACES
* Maui Ocean Center (a surprisingly good aquarium)


My family and I in Maui

Goodbye, GoDaddy! Hello, Google Domains!

posted Aug 13, 2014, 3:44 PM by Anjuan Simmons   [ updated Aug 13, 2014, 3:45 PM ]



I just transferred my domains from GoDaddy to Google Domains. I was invited to join the Google Domains Beta, and I am quite pleased to leave GoDaddy behind. Here's why I made the switch:

  • While some dislike Google for the amount of private information they hoarde, I use many of their products and services from my Android phone to hosting for my websites.
  • The GoDaddy web interface is hard for me to navigate. Google Domains provides a simple and clean interface.
  • GoDaddy's private registration (which hides personal data from WHOIS) was through a third party with a different web interface. Google Domains uses a third party as well, but turning private registration on and off is done through the simple toggle of two radio buttons.
  • GoDaddy charged for private registration while it's free with Google Domains.
  • Google Domains charges me $12.00 per year for each domain. GoDaddy was all over the place with pricing and never as low as $12.00.
One important reason I made the switch was GoDaddy's exploitation of female sexuality in their advertisements. We've all seen their Super Bowl commericals, and I'm glad to do business with a domain registrar that doesn't use sex to sell their products.


Getting Started in Public Speaking

posted Aug 6, 2014, 12:32 PM by Anjuan Simmons

I enjoy public speaking, and I have been fortunate to have many opportunities to speak on a variety of topics. A friend reached out to me for advice about giving her first talk. Here was my response:

Thanks for reaching out. First, I want to say how proud I am that you are speaking about technology, especially when it comes to getting more women in technology. The only way to have true innovation in technology is to bring diversity of thought to the industry.

I have a few quick tips that have worked well for me in public speaking:
  1. Practice, practice, practice. This is best way to make sure your presentation flows. Also, practice is the best antidote for being nervous.
  2. Speak to the audience. Don't just read the slides. You've mastered the material (because, see #1, you've practiced) so the slides are just notes to guide your talking points.
  3. Connect with the audience. Your eyes should naturally scan the room and make brief eye contact with the attendees. This draws them into what you're saying. Too many presenters make the mistake of just looking down at their notes or at the projected image of their slides on the screens. Eye contact creates a personal connection.
  4. Smile. :-) Bring passion and excitement to your talk. If you're not hype about what you're talking about, then no one else will be.
  5. Absolutely use social media. This will increase the chance of people coming to your panel and also improve your personal brand. Even if 3 people show up (and make sure you knock the socks off those 3 people!), then people who scan your social media profile will see your growing history of public speaking on technology.
  6. If you make a mistake, keep going! Chances are, most people won't have noticed.
  7. Try to keep bullet points to no more than three per slide and make use of images and simple charts. Most people are visual learners and presenting your information visually works very well.
Here's a video of a friend of mine named Adria Richards giving a TEDx talk about women building careers with code. I think she did a great job of using visual images in her talk, and she laid it out well. 



I hope that helps. If you need more information, please feel free to reach out. I know you'll do great!

My Essential Travel Gadgets

posted Jun 19, 2014, 1:47 PM by Anjuan Simmons

I have 658,287 lifetime flight miles (and that's just with United Airlines) so I know quite a bit about travel. As a techie, here are my must-have travel gadgets:

Clamcase iPad Keyboard Case: When I'm not travelling, I use my iPad as a media consumption device to watch movies, play games, or keep up with the news. However, when I'm on long flights, I've found that encasing my tablet into its Clamcase Keyboard Case lets me use it to produce content. The keyboard is comfortable and gives me the ability to navigate complex spreadsheets, respond to emails, and, of course, work on my Great American Novel.

Wacom Bamboo Stylus: While the iPad is responsive enough to not need a stylus, I like to doodle in the air every now and then. So, I've found that travelling with a stylus lets me nurture my inner artist even when I'm 30,000 feet in the air. 

Mophie Juice Pack: I travel with a lot of gadgets, but my phone is the one device that I can't afford to let it run out of juice. The Juice Pack functions as both a protective case and a power source for my Samsung Galaxy Android phone. The Juice Pack has allowed my phone to even survive an eight hour flight from Houston to Honolulu!

NapAnywhere: I used to use those U-shaped travel pillows, but I recently switched to NapAnywhere. It's so much better! It even makes sitting in a middle seat enjoyable! I've even been tempted to give it to the person napping next to me when their unconscious head starts slipping toward my shouldar.

Uber: This is an app that makes arranging a car safe and easy. I simply display my location and a car arrives within minutes! Since Uber stores my credit card information, I can just get out of the car at the end of the ride.

A Great Team Doesn't Make You a Great Manager

posted Jun 10, 2014, 4:22 PM by Anjuan Simmons

I routinely hear performance reviews from managers that sound something like this:

"This team member is doing a bad job. I constantly have to give guidance, monitor, and make corrections to their work."

My response, although rarely spoken out loud is, "Yes, that's your job." The job of a manager is manage, but most managers prefer to report. Instead of managing a resource, they report on the resource's performance. Few managers understand this. Let's use the analogy of a car. If you pressed on the brake pedal, and a number popped up on your windshield displaying your current speed, would that be an effective braking system? Or, if you pressed on the accelerator, and your dashboard displayed your current compass direction, wouldn't that be considered a malfunction? However, despite operating like defective brake and accelerator pedals, we let managers off the hood for failing to govern the performance of their teams. 

Managers are supposed to decrease the weaknesses of their teams while increasing their strengths. Far too many managers I've encountered simply let their teams function in the way that they received them. Therefore, if a manager gets a great team, then the team produces great work, and we think that the team had a great manager. However, that is often not the case. Great teams tend to produce great work irrespective of the manager in charge of the team. Conversely, if a manager receives a poor team, then the team, unsurprisingly, produces poor results. Managers, in this situation, tend to blame the team and almost never admit that they are bad managers.

Effectively managing a team (instead of simply reporting the team's performance) requires the ability to deeply analyze each person on the team and understand how to make improvements. This is hard work which is why most managers avoid it. You have to understand how each person receives feedback, create performance improvement plans, and conduct regular checkpoints to measure progress. While every team member has to own his or her career, the manager has to be fully invested and accountable for the improvement of everyone on the teams they lead.

Far too many managers are content to simply be reporters. The only way to improve the number of great teams in the workforce is by teaching managers how to steadily improve the greatness of their teams no matter the condition in which they were received.

1-10 of 16