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.
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:
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:
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!".
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:
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:
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.
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:
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:
I was recently asked a question by a colleague who is a professor at AACSB University. Here it is:
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:
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:
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:
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:
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.
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: