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.


Cross-Functional and Cross-Fungible Scrum Teams

posted by Anjuan Simmons   [ updated ]

One of the hardest aspects of Agile Software Development is the alignment of design and engineering. This is because design is usually seen as purely a creative exercise while engineering is formal and structured. Of course, most people who have been exposed to both the design and engineering aspects of software development understand that creativity and structure exist in both competencies.

Scrum outlines a "cross-functional" Development Team that, at the minimum, has all of the skills needed to move a feature from user story to working software. However, a higher level of "cross-functional" is "cross-fungible". That means that members of the Scrum are interchangeable and everyone can perform UX, visual design, software development, testing, etc. However, it takes most Scrum teams months to reach cross-fungibility. In the interim, tight integration between roles is the next best thing.

I constantly strive to help my Scrum Teams become more tightly integrated, especially by aligning design and engineering. Here is a good article about that:

How to Create a Winning SXSW Panel Proposal

posted Apr 24, 2015, 3:07 PM by Anjuan Simmons   [ updated ]

I had the honor of serving on the Advisory Board for the 2015 SXSW Interactive festival. In fact, you can read my tips about how to make the most of SXSW Interactive here.

As an Advisory Board member, I was responsible for evaluating 200 panel proposals, and I saw so many amazing ideas! However, I was only able to vote for a small percentage of these submissions so I saw firsthand how hard it is to get an idea accepted into Interactive. Having gotten four panel proposals successfully accepted in previous years, I knew how to create a winning proposal. However, evaluating proposals provided me with newfound insights.

Here is my advice for creating a SXSW panel proposal with a maximum chance of being selected for presentation:

  • Create a catchy title that is focused and specific. Combine ideas to express them in new ways.  "What Captain Picard Taught Me about Public Speaking" is better than "Rock Your Next Speech!". Also, be careful about using current events in your title because those events may be obsolete by the time March comes around.

  • Attach a well produced video that matches the context of your title to Supporting Material section of the PanelPicker. Ideally, the video should feature the speaker (if a solo panel) or several of the panel members (if a dual or panel presentation) listed under Proposed Speakers. It's even better if the video shows the speaker(s) talking about the topic of the panel. Remember, you can link to several videos!

  • Make sure that Company links for the Proposed Speakers link to a page that says something about the Speaker. Don't just say that he/she works for Google and include a link to Google.com. Link to a sub-page at Google.com that lists them. You can label the link Google.com but have it actually go to their sub-page. If such a page isn't available, then it's better to link to the About Me page on their personal website.

  • Write a focused Description (specific is better than general). This is especially important for a panel discussion because it can be difficult for multiple people to address a topic with the appropriate amount of depth if it's too broad.

  • Beef up your Questions Answered! A lot of the fields in the PanelPicker have strict limitations on the number of characters you can type. However, there is quite a lot of space available for the Questions Answered section, and you can use that space to include things you had to cut from your Description due to space constraints. In fact, use the Questions Answered space to introduce a topic you'll cover in your presentation and then frame it in the form of a question.

  • Generally, fewer speakers are better.

  • Generally, advanced topics are better than beginner.

  • Don't neglect your tags. They can help evaluators understand the positioning of your panel with a deeper level of granularity than the Theme alone may allow.

  • Grammar and spell check your proposal. Multiple times. By multiple people.

  • Include slides showing that you have talked about the topic (or a similar topic) under Supporting Materials using tools like SlideShare.

 

Ready to Burn

posted Apr 13, 2015, 12:40 PM by Anjuan Simmons   [ updated ]

I've been holding out on my Development Team. However, I've been doing it with a purpose in mind. Often, the best way to learn something is to experience life with the absence of that learning. Take programming for example. If you're teaching someone who has never programmed before, you may want to jump into teaching them about object oriented programming. However, as their eyes glaze over, you realize that you are confusing them more than educating them. So, you help them understand relatively easier concepts like variables, strings, input/output, reading files, functions, conditionals, and loops. Maybe you'll tease them a little with lists and dictionaries. You'll pat them on the head and send them of to try building a few programs. You smile as they create a few choose-your-own-adventure type games using lists and functions. Then you wait. You wait for them to come back to you and complain about having to update their code in multiple places just to make a small change. Their code is so complex and unreadable that they are thinking about giving up. Then you say, "Ah ha!". 

ah-ha

Photo Credit Paramount

You show them how to use classes and methods. They marvel at how they can clean up their code. You teach them constructors, and they squeal with delight. You barely finish explaining inheritance before they start cackling with glee. Understanding object oriented programming was something they could grok and appreciate because they had experienced what its like to try programming without it.

Similarly, there are several aspects of Scrum that I haven't explained yet because I wanted the Development Team to experience practicing Scrum without them. Also, I would have to stop the team for several days if I tried to explain everything I think we need to understand about Scrum. So, I'm taking an iterative approach to improving our practice of Scrum by doling them out in digestible chunks. Based on the Sprint Retrospective feedback, I think we're ready to understand the Definition of Ready and the Sprint Burndown chart. 

The Definition of Ready

We've covered the Definition of Done (DoD), and the Definition of Ready (DoR) is a similar concept. Like many aspects of Scrum, the DoR is just a checklist. However, the DoR is used before the sprint even begins. All user stories must meet the DoR before they are analyzed during the Sprint Planning meeting. Like the DoD, the DoR is collaboratively created by the Product Owner and the Development Team.

The DoR evolved in Scrum to address the same concerns shared during the last Sprint Retrospective. This includes items like:
  • "Feel like there needs to be more time spent on cards before they hit planning poker (UI work, QA, OPS, Documentation)"
  • "Trouble splitting work for stories, caused us to pull in more points"
  • "I think we may have moved too quickly to bring in more work at the beginning of the sprint"
  • "I feel like cards not matching the DoD at the end of sprints will be common and that we need well defined process here" 
Teams often look to the DoD for guidance in creating the DoR. This is reasonable, and you can find our current DoD here. However, a more useful guideline is the INVEST criteria for user stories. INVEST is often useful for splitting user stories, but it also provides good characteristics for user stories of any size. The INVEST criteria recommends that users stories are:
  • Independent, not tied to another user story
  • Negotiable, based on what we now know and open to change (before the sprint starts)
  • Valuable, based on the desires of the Product Owner
  • Estimable, able to be sized
  • Small, able to fit in a sprint
  • Testable, able to be translated into QA assets.
The ultimate goals is to not let anything into our sprint that is not Ready and to not let anything leave our sprint that is not Done. We'll further discuss the DoR during our next Sprint Retrospective.

The Sprint Burndown Chart

The Sprint Burndown Chart is far more canonical to Scrum than the DoR, but it can be a discouraging artifact because it often shows problems before it starts showing success. This is because the Burndown Chart is often a lagging indicator of the team's success at practicing Scrum. In other words, the Development Team is often better than what is currently being shown by the chart.

Ideally, the chart is self-explanatory. The ideal line is formed by dividing the story points we committed to in this sprint by the number of days in the a two week sprint. So, if we completed roughly an even number of story points per day to finish by the morning the day after the sprint, then our work would follow the ideal line. 

I should pause here to say that we will never match the ideal line. Never. Ever. It is just a guideline.

The blue bars show the amount of work that is left to be done in the sprint. Every morning I update this chart for the previous day. Any cards in the Done lane are deducted from the blue bars based on their point value. So, this chart will be updated for what happened today sometime tomorrow morning. That is because the blue bar should represent a full day's worth of work.

So, that's the DoR and the Sprint Burndown Chart. I'll share more techniques when the team is ready for them.

Meeting Investors and People in Tech

posted Apr 9, 2015, 1:11 PM by Anjuan Simmons   [ updated Apr 9, 2015, 1:12 PM ]

A friend recently asked me this question:

Hello, Anjuan! I'm in a bit of a pickle. I went to law school and in law now but want to pursue tech. As such, I'd love to attend networking events with other entrepreneurs, angels and VCs but haven't a clue where to look and where to RSVP. I want to meet other amazing people in tech and get my product out there for feedback and possible investment! Can you possibly suggest a starting point?

Here's my response:

First, use sites like Eventbrite and Meetup to find networking events centered around a topic of interest. There are many technology and entrepreneurship based events happening, and they are probably only a few miles (or, right around the corner!) from where you live or work.

Second, once you get a few events that you find useful enough to regularly attend, I advise getting "behind
the scenes". Get to know the organizers of these events and offer to help them find speakers and plan meetings. I think a heart to contribute to networking events and not just take from them is a great way to meet investors, partners, and possibly customers.

Third, I recommend writing content about your area of speciality. You can do this on your blog and also contribute to other publications. I'm a fan of public speaking so I highly recommend speaking at events that tie to your product. This is a great way to get exposure and establish yourself as an expert and increase the visibility of your product. Often, visibility is the key to viability.

I hope this helps!

Should Bugs Be Sized?

posted Apr 9, 2015, 12:59 PM by Anjuan Simmons

A user in one of the Agile Linkedin groups I follow posed this question:

Could some one provide me the information about story pointing bugs? Is it right way? or when can we?

Here's my answer

Here are the principles I apply to this:

* Nothing goes into the sprint until its Ready. So, user stories should be properly detailed and sliced as needed. They should also be sized. If you slice the stories properly, you should get an idea of other similarly sized stories in other parts of the application and also get an idea of how many bugs you can expect. So, the size of the story should be relative measure of getting it to done (code complete, code reviewed, debugged, etc.). Also, the Definition of Ready should include any information about the bug history of that part of the application that should be recognized by the Development Team.

* The Definition of Done should include everything needed to get a story in a state that could be released to the customer. This includes the fixing of bugs.

* Nothing is worked on unless its in the Sprint Backlog. If, in the act of creating a feature, one or more bugs are generated, then the point value of the story should reflect fixing the bug.

* So, nothing enters the sprint unless its Ready. Also, nothing leaves the sprint until its Done. Bugs should be taken care of through Readiness preparation and Doneness completion.


Should Scrum be Taught to Management Students?

posted Apr 8, 2015, 11:45 AM by Anjuan Simmons   [ updated Apr 8, 2015, 11:50 AM ]

I was recently asked a question by a colleague who is a professor at AACSB University. Here it is:

Hi Anjuan,

I hope this message you doing well! I read the information on the link you provided. I am interested to know if you think SCRUM should be taught to management students? I was thinking about adding this practical application of problem solving and management to design thinking To foster creative thinkers and problem solvers – people who will have to tackle complex challenges like the ebola epidemic, data security breaches, climate change...

Here's the answer I sent to her:

I absolutely think that Scrum should be taught to management students. While Scrum is primarily used in software development, the principles behind it have been applied to building things from cars to fighter jets. If you're involved in tackling any complex problem, then Scrum is a great tool to understand.

I'm reading Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland, one of the creators of Scrum. I think this would be a great textbook for management students studying Scrum.

The Referee/Coach Scrum Master

posted Mar 26, 2015, 2:54 PM by Anjuan Simmons   [ updated Mar 26, 2015, 3:00 PM ]

When people ask me what a Scrum Master does, I often use the analogy of a referee. In any sport, the referee is not the center of attention and often disappears into the mechanics of the game. However, the impact of the referee is present in every play. The role of the referee is to make sure that everything happens in accordance with the guidelines of the game.

Scrum Masters do the same thing. We make sure that the Scrum Development Team works in accordance with the guidelines of Scrum. That means that we actively remove practices that are against the guidelines of Agile Software Development (specifically, Scrum). 

However, Scrum Masters are more than just referees. We are also coaches. We coach the Product Owner about ways to manage the Product Backlog. We coach the Development Team in how to practice Scrum more effectively. Also, we coach the organization by tailoring other Agile methods to the needs of the company.

Here's an email I received from a client asking for clarity about how the Development Team would practice various aspects of Scrum. I've removed any identifying information from the exchange, but it's a good example of an email driven coaching session:

Great questions! My answers are below:


Below I have summarized what I believe is true for a sprint-would you mind giving it an eye and then correcting any confusion that I have or adding to it?  I would greatly appreciate it.

1.  Planning- sounds like what it is- getting together to determine what cards to current sprint board

Yes, we get together with the Product Owner and take cards of the top of the Product Backlog, solve them, size them, and then see what we can commit to for the Sprint Backlog.

2.  Tasking- This where you will assign cards to me for testing in addition to ad hoc testing for this sprint

-during this time after tasking is where we are testing, reporting, and documenting

-half way through the testing is the next meeting

Tasking is the process of taking the cards that were sized during the Sprint Planning meeting and breaking them into tasks. These tasks are the things that need to be done for the card to meet the team's Definition of Done.

3. Backlog Refinement- Where the entire team reorders, reassess and then line up the next important cards in the backlog for the next sprint? 

Yes, this is similar to Sprint Planning, but it is for the next few sprints. This makes the next Sprint Planning meeting more efficient and effective. 

4.  Review and Retro-  Reflection meeting- what we did well, what we can do better.

Yes, the Sprint Review is where the team reflects on the work that was done (with the Product Owner) and the Sprint Retrospective is where the team reflects on the people and processes (the Product Owner is not required to attend).

Questions:

When do we release into production?

This is still being determined. We are currently looking at a few Release Candidates that will happen every few sprints. Stay tuned! :-)

Once we release, did we build in a cushion to address customer support issues?

We size customer support issues into every sprint, and we probably should plan for more than usual after a release.

As always, thank for your help and insight.

Thanks for these great questions!

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.

1-10 of 23