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.
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.
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 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 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 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!
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.
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:
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:
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:
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: