Virtual Camera and OBS for Zoom

With the SARS-CoV-2 pandemic, the Zoom conference software gained significant popularity in 2020. With more and more events happening online, the demand for a better online experience grew. With a virtual camera and OBS for Zoom to control your picture, you can provide a better experience for all participants.

In real-life meetings, you, the organizer is in full control what and how your audience sees you. Online, the challenge is that all of your participants are using different devices to watch and listen to you. Even worse, in Zoom, your audience can adjust the layout of the screen.

Diagram of a common problem in Zoom: you have no control over what your participants see.
Your participants control what and how they see your Zoom call.

The solution to this problem is to tell the participants to switch their Zoom to your image and set it to full screen. This way, you are in full control of what they are seeing. The problem here of course is that the only options Zoom provides you to control your own image is to select a camera.

The solution is to use a software to control your appearance, and have it act like a virtual camera. Instead of sending your camera picture directly to Zoom, you send it to this software which edits your image, and forwards that image to Zoom.

This way, you can, for example, show your main speakers (or singers) prominently and your other participants on the side–just like you would assign seats to the audience and to your speakers or singers on the stage.

Techniques to accomplish this have been around for years. It has been especially popular among role play gamers who streamed their games online. With some effort, you can not just assign positions of your participants on the screen, you can also add fancy borders and backgrounds to your video stream.

Example of the use of an overlay for a conference call.
Screenshot from “Episode 1 – Roll20 Presents: Ghosts of Saltmarsh: The Final Enemy”,

To accomplish that, we first need the Virtual Camera and OBS for Zoom:

  • Download and Install Open Broadcaster Software OBS from here
  • If you are using Windows, make sure to also download and install the OBS virtual cam plugin installer from here
  • Start OBS.
  • Click on Tools / VirtualCam and make sure the VirtualCam is running. For this, make sure “AutoStart” is selected and click on “Start” if possible.
Setting up the virtual camera in OBS.

Once started, the VirtualCam acts as a virtual camera you can use in Zoom. We shall now test whether the VirtualCam works:

  • Click on the arrow beside the video symbol and select “OBS-Camera”.
Selecting the virtual camera as the source in Zoom.

Now, Zoom shows the output of OBS. To test, let us connect our webcam to OBS:

  • In OBS, click on “+” in the “Scenes” window in the bottom left corner.
  • Let’s call the new scene “Main Scene” and press OK.
  • Next, click on “+” in the “Sources” window at the bottom.
  • Select “Video Capture Device”, select “Create new”, name the entry “Main Camera”, and press OK.

Congratulations, both Zoom and OBS should now show your happy face, and you are in full control of what other people see when they maximize your picture in Zoom.

Using OBS as a virtual camera for Zoom.

The next step is a bit tricky. You now want to show other participants as well. For this, you need to capture your Zoom window, and import it to OBS. Ideally, you have a second monitor exclusively for your Zoom meeting window, while controlling OBS on your main screen (or vice versa).

To illustrate, the process looks like this:

Information flow for using OBS to grab the screen from Zoom to arrange the participants' images.

To show other participants as part of your image, you need to grab the screen from the Zoom window. For this, we need to add a separate “Window Capture” source for each participant.

  • Click on “+”,
  • select “Window Capture”,
  • name the source, for example, “Participant 1”,
  • select Zoom as the Window, and
  • press OK.

Next, we want to add a filter to each of those sources to show only a certain part of the window. Select the source, right-click on it, select “Filters.” In the new window, click “+”, select “Crop/Pad”, and adjust the values for Left, Top, Right, and Bottom until only the participant in question is shown. Repeat this for every place in the gallery of pinned Zoom participants, and move each source to the right place in the OBS window.

As a finishing touch, you could add a background image as an overlay. You can do this by clicking again “+”, select “Image” (or video, if you have one), and select the Overlay image. An overlay image has frames around the people participating in the call, for example:

Overlay for use in OBS as a background for Zoom meetings.
image source: Shutterstock

That’s it!
Any questions? Feel free to contact me at


Daily Scrum with Jira

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

The daily operation of Scrum is where the more personal qualities of a Scrum Master shine: Humans, not machines, working together to create a product. Here, I want to discuss a number of small unrelated points that can easily be implemented. Each of them has only a minuscule effect, yet if you implement them one by one over the course of several weeks, you might improve the efficiency by a few percent.

Small steps!

First, when using Jira—or any other computerized tool—encourage people to use a profile photo and, ideally, their real photo. In an organization, people come and go all the time. It saves a few minutes to quickly identify who the person behind the ticket or email is. It encourages people to approach a person “IRL” (in real life). Not everyone is outgoing; some people are shy and might prefer not to discuss something (or to use email instead of direct face-to-face contact) rather than investing energy in finding out who that person is in reality.

Second, attitude. There are two kinds of people: in “socionics” (a personality type theory), there are “democrats” and “aristocrats.” The latter type prefers to be asked, the former prefers to ask. No matter who you are as a Scrum Master, you have to be on the asking side. Don’t say “If you have a problem, just come to me.” Instead, try to find out about problems proactively. If this is not your area of specialty, perhaps someone from the team has a knack for picking up what problems are currently going on. Talk to him or her!

SOCIONICS ·  Socionics is an advanced personality theory that examines and explains relationships between people. It can be used to explain communication problems and conflicts of interest within a project.

Third: A job well done? Some companies try to bribe team members to perform according to certain goals. But I think money is the last and probably most ineffective way to motivate people. What people want is recognition. Give small (!) bonuses for good performance! Sometimes, a meal, snacks, or simply an honestly meant “Good work!” is much more effective than a monetary bribe.

Fourth, a point from stakeholder management: Allow everyone’s opinion to be heard. Even if they disagree, they will more likely cooperate if they were given the chance to provide some input. For some decisions, this can be crucial. Maybe refrain from being too proactive, and instead learn to listen. Someone whose voice is not heard might find ways to be heard by causing problems or acting as an obstacle, consciously or unconsciously.

Fifth, some (or all) of your team members might work remotely. This can make especially the daily Scrum meetings take longer than necessary. Have them prepare their update in advance in written form for everyone to see. Also, if remote work is a frequent or even permanent situation, consciously use the first five minutes of the daily Scrum for smalltalk. Have the team exchange what they are doing privately, just like they would if they were on site. This is a crucial component for open communication and team building.

Sixth, for longer meetings, use breaks. If you, as a Scrum Master, are an active part of the discussion, it is recommended to use a clock to remind yourself to take a break. One proven method is the Pomodoro technique, which advocates 25 minutes of meeting followed by five-minute breaks. Get a “buy in” from the team to not use their smartphones during those 25 minutes. Some go even as far as collecting them before the meeting and handing them out during the breaks. That sounds silly, but we all know how dependent we are on them.

POMODORO TECHNIQUE ·  The Pomodoro Technique is a simple time management technique that allows focus on one task, followed by a break, then moving on to the next task [Cirillo, 2017].

Seventh, in the daily Scrum, try to NOT use Jira. If your Scrum board is clean, use stickers, even if this is information-doubling. Nobody notices when you move a story in Jira, so have people physically move tasks from one column to the next to demonstrate what they did. And don’t forget to discuss the progress of working off the impediment log! It might not be on the board, but these are details that will motivate people as they see that the process is improving.


When Growing Gets Tough

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

Handling Multiple Teams in Scrum

Applying the principles of Scrum in a larger organization with multiple teams can be challenging. First, it’s simply bigger, and having more people involved makes things more complex. Second, while there is literature on the subject(like Larmann and Vodde [2016]), you can hardly call it a mature system. Third, software support is lacking. So, how do we approach it, using Jira as our preferred tool?

The central element of Scrum is the customer’s need—the customer being someone who wants to buy a product from you. The first step is to actually identify what parts of your project are shippable products. If you identify that you have several distinct products, you don’t need large-scale Scrum, you can have the teams work independently on the products. Given the easier management, you might even think of splitting existing larger products into smaller ones, but that is a decision requiring knowledge of the architectural details of your project.

Another important element of Scrum is learning. If you have set up multiple teams, they still operate within the same framework, namely the same organization, the same building, or maybe even the same room. Each Scrum Master is running an improvement project that gathers requests by the team and removes impediments (ideally proactively), but at least in my experience, they are hardly ever sharing, except maybe informally through meetings. Much better is to set up one global Scrum Master Jira board that lists the impediments of all teams and have the Scrum Masters work on these tasks as a team. Depending on the volume, you may even require an assistant to help keep that board clean and up to date. This will help the Scrum Masters to encourage each other and reduce duplicated work. Just do not make the mistake of actually physically removing the Scrum Masters from the teams and putting them in their own room: they need to be there for their respective teams, ready to solve any issues. But while they are waiting for problems to arise, they could help out the other Scrum Masters clean up the global backlog, or they could work on impediments found by other teams.

Now, one big issue is specialists, or very experienced people in general. They are a rare resource. Previously, we found that it might be a good idea to keep them on a team instead of moving them into a management position. With multiple teams, the pressure from the business side to share specialists among the teams is heavy, as it is expected that other teams will need to access a particular resource as well. What to do?

Support team

Of course it depends on the business environment, but if possible, form a “support team” ready to answer questions from any of your teams—including questions about architecture, legal issues, or technology. This support team works much like traditional customer support. It builds up a knowledge base and answers questions, ideally as quickly as possible (using management techniques other than Scrum). This will be the central “brain” of the company for really hard questions. Depending on the product and the way your company works, you could even merge the support team with your traditional customer support, as they are building up the same kind of knowledge base, although with the emphasis on the customer. Last but not least, provide them with the authority to quickly hire external freelancers in order to have access to specialist knowledge.


With multiple teams and (if applicable) the support team, you might want to reorganize your communication as well. Which tools you use for that depends on your organization and needs. The question is who is accessing the support or Scrum team. Ideally, for the initial request, you will want no direct communication between individual team members and the rest of the organization. Instead, gather the requests at a central place and have a manager or the product owner sort through the issues. I jokingly call this “removing the red telephones” from the desks of the developers.

The most flexible solution is to use a separate email address for questions and problems. This address then can be used by everyone in the company, even those usually not familiar with Jira. This ensures requests will be channeled and minimizes initial training. Then, have either your product owners or Scrum Masters manage those email accounts manually, or use Jira’s automatic task creation system. You could promote this email address within the company by arguing that this way, nobody has to figure out who to contact on the team and that there is always somebody who answers questions expediently.

While there is a relatively new functionality in Jira to handle support tickets (service desk), I suggest giving the existing functionality a try. For the internal Scrum and support team communication, you already have many registered in Jira, so little to no extra configuration is required:

  • Set up a POP3 email address (e.g., Gmail)
  • In Jira, go to Settings / System / Incoming Mail
  • Add POP / IMAP mail server
  • For Gmail: Protocol: SECURE_POP, Host name:, POP / IMAP port: 995
  • Add incoming mail handler
  • Handler: Create a new issue or add a comment
  • Strip Quotes, Catch Email Address, Bulk: Ignore the email and do nothing, Create Users, CC Watchers

With this configuration, people can use your email address, are automatically added to your Jira user base (to receive comments and make comment themselves via email), and a task is created in the specified project. If you have set up a default assignee in your project (e.g., the product owner), that person gets notified and can then decide whether or not to move the issue to the backlog or to escalate it as a critical bug.

Project Organization

Besides communication, you might want to think about project organization. I strongly suggest keeping the organization logical and assigning a Jira project to an actual shippable product. With shippable, I mean really shippable. For example, if you have a mobile app and a connected server system, you cannot ship the mobile app on its own. Likewise, installing only the server system without an app might yield zero business value even though it is physically shippable. Think outside the box, split the “server team” and “app team” into two teams consisting of both “server people” and “app people,” holding on to the idea of creating multidisciplinary teams. Then, split the project into two features. This could be communication and design, with both teams regularly exchanging code bases or, ideally, working on the same code base. Much more could be discussed in this regard; my point is to really focus on keeping your teams Agile and not fall back into the old Waterfall thinking of compartmentalized teams working in product phases.


Sprinting to Delivery

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

That Is Waterfall, Not Scrum

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Working software is the primary measure of progress. Continuous attention to technical excellence and good design enhances agility.

— Principles Behind the Agile Manifesto [cf. Beck, 2001]

When it comes to Scrum, a central concept is deployment. As a consultant, looking at the deployment process gives me helpful insight about a company’s grasp of Agile and Scrum. Depending on the depth of understanding of Scrum and the maturity of the team, the deployment process falls into one of four categories:

  • The deployment happens when there is time and when testing is complete and all the features are merged. A point in time is chosen when the whole project becomes stable or when the team is forced to release for business reasons.
  • Deployment happens after a separate testing phase after each sprint, maybe even with a separate release manager.
  • Most of the time, the team is ready with testing at the end of the sprint. If it is not, overtime is invested.
  • Features are deployed and tested independently of each other and independent of the sprint.

Ultimately, the question is a philosophical one. What is commitment? And what is a sprint? Is it an actual software package delivered to the next department? Is it for business to review? Or is the end of the sprint just a status report to stakeholders?

Let us examine:

If the result of a sprint requires an additional confirmation by upper management, why not have them included in the sprint? If the feedback to features comes only at the end of a sprint, valuable time is lost. Additional phases like approval from people outside of the team go against the principles of Scrum. It is the job of the product owner to act on behalf of the stakeholders.

Likewise, it is not the job of the product owner to test each story in order to determine if all the acceptance criteria have been met. The very idea of coming up with acceptance criteria is that the team itself can make decisions about whether or not they met the required function or quality, requiring less interaction with the product owner over time. Finished stories can be demo’d to the product owner throughout the day, getting valuable feedback immediately instead of waiting for the end of the sprint. Even a half-finished story can be shown to the product owner if it is clear that the remaining work will not need more input (like documentation, testing additional special cases, etc.).

Approval is one of the jobs of the product owner. And in order to improve the likelihood of achieving approval, acceptance criteria and the definition of done are formulated. But the workflow should never include assigning testing tasks to the product owner. If you do that, not only does the product owner become the bottleneck, but also you transfer responsibility of the finished story to him or her. You would train the developer to think that if there were any open issues left, it would be up to the product owner to find them, which moves responsibilities away from the team.

To summarize:

  • Neither management nor the product owner should be a phase in development.
  • The product owner should review current work during the sprint and give valuable feedback.

Now, back to deployment. Is the goal of the sprint to produce a software package? No! If it indeed produced something at the end, you would actually be employing Waterfall. You would have to do a separate architecture meeting at the end of each sprint to combine all the stories and take care that there are no conflicts, and then do another round of testing to make sure that each feature did not affect another.

Delivery and sprints are independent from each other. The purpose of a sprint is merely to better organize planning. You could hold planning and review meetings for each single story separately, but that would result in significant overhead. Delivery or deployment can be done for each individual story, given you invest enough effort into your continuous integration system. Educate your team in proper branching techniques, organize the code into separate modules, and create stories that do not overlap.

Good luck!


A Closer Look at the Numbers

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

Speed Is Not Necessarily the Issue

A common argument in favor of Scrum is that, once established, the process will produce numbers for business to use in calculations and planning. This is true, and this is the goal: a well-run Scrum process can give you excellent feedback about the “health” of your organization as well as the progress of your projects. But, especially with automated tools like Jira in the background, you can lose perspective. Here, I want to explain statistical, mathematical, and process-related connections to give you reasons for many of the ideas implemented in Scrum.

I remember a question from my math classes: if five workers build a house in 30 days, how many days do 10 workers need? From a project management point of view, this question is of course laughable, as the answer would probably be 30 days because of all the phases involved. Maybe the critical path is 30 days, no matter how many people you throw at the project. From an Agile point of view, the question is very different. Here, it is not about managing cost, quality, or time to fulfill a pre-planned project. Instead, it is about the generated business value per time unit.

The workers could start with the garage so that the family moving into the house could park their car. Maybe they could set up the a mailbox so the family could move their postal address. Maybe they could start by planting the grass early so that when the family moves in, the garden already looks pretty and won’t need another month to grow.

Let’s say we have a test team and a development team of five people each. Both teams follow every piece of advice inherent in Scrum, except for the fact that they are two teams working on the same thing. When the development team completes a sprint, it delivers the product to the test team for QA. Let us further suppose developing and testing both take the same amount of time on average, and that one sprint takes one week.

Upper management then assumes that they have a product ready every two weeks. Compared to what they had before, namely no numbers or release cycle, this system is celebrated as a success. Everyone pats each other on the back.

At the end of the year, the actual numbers are compared with prior year’s numbers (without any “controlling,” as they had numbers only at the end of each year). Then management will find that the situation has not improved by much. Likewise, nobody wants to lose face and they just continue as it is and find excuses. It might be said that it was a bad year, it is difficult to find talented people, the lead programmer has quit (but why?), people got sick a lot (but why?), etc., and management leaves things as they are. New Scrum Master hirees are told that the company uses its own version of Scrum and that their proposals to change the process rock the boat too much.


What happened?

Imagine you have an empty bottle and a full bottle. How do you fill the empty bottle with the water from the full bottle without making a mess? Of course, you use a funnel! But what is a funnel actually? It is a buffer with a limited capacity that ensures a steady flow of water into the other bottle. Having phases with specialized teams is just that: trying to pour water from one into the other, making a huge mess. And there is no funnel to fix that, except to pour so slowly and steadily that no air bubble can form.

What is the “air bubble” in the case of project management? When the first team works faster than the second, work piles up at the second team. When the second team works faster than the first, the second will be idle.

What to do about it? Do you smooth things out by having individual features drop from one team to the next? That helps, but slows things down, and work could still pile up. Do you send your testers to the developers to help out or have developers start testing? You can’t do that, can you? Imagine your top software architect using her time for testing the UI. Or imagine an inexperienced tester taking four times as long as your average programmer to fix a bug in the code. Is there no way but to make a big mess?

What is missing in this evaluation is the business value of things—that is, the value, over time using the product, that the consumer gets. That is a much better indicator of evaluating someone’s work than individual speed or efficiency. It doesn’t matter if one part of the whole business works four times faster than the rest; the only thing that matters is how early the final product (or feature) can be used by the customer. So, instead of focusing on local optimization, look at the global picture. No business value is created as long as no customer can use your feature. The goal should be to get one feature through your complete pipeline as quickly as possible, even if that means that some of your resources are under-utilized and not working at 100 percent efficiency.

Scrum solves this by building multidisciplinary teams. But even when you merge two teams (or create two feature teams), you usually end up with each person working on one story, doing everything including programming, writing tests, releasing, etc. While you certainly have solved the problem of idleness of teams—one person is 100 percent involved in the whole chain of production—each story still takes a long time to be developed. In addition, there is little communication between the team members; knowledge management, additional testing (simply by having additional people looking at the work), and additional ideas are excluded.

Figure 7.1:Comparison of the accumulated business value of different strategies letting the team members work individually on individual tasks vs. focusing the whole team on individual tasks.

So, are we back at square one with Agile? Let us first draw an example situation into a graph. The challenge is bringing high-value tasks quickly to market (but is that really the challenge in your company…another question to ask yourself!). Figure 7.1 shows the accumulated business value of three features if worked on independently by three people, and the accumulated business value of the three features if implemented one after the other by the whole team (first with 75 percent productivity, then with 33 percent productivity). As you can see, if the productivity is still high enough despite the necessary overhead, focusing on finishing individual tasks as a team as fast as possible ultimately shows higher business value returns on top of advantages like team building and knowledge sharing!

To summarize, throw the whole team on a task, even if their “productivity” (completed tasks per day) suffers. If it speeds up the delivery of that single crucial feature, you might ultimately end up with higher productivity. Obviously, some calculations are required. But it is important to unlearn the idea of putting individual people on individual tasks simply because they are the ones who can implement them most quickly individually. And we have not even taken into account the internal value of knowledge sharing, more testing, and ultimately higher quality!

Speaking of throwing people on a task: if your team is involved enough in business (a multidisciplinary team involved from design to sales), the team will understand the value of a multidisciplinary team. If it does not, you have another indication that the team is disconnected from the product as a whole, doing local optimizations on their own work without having the larger picture in mind.

How does your team share work among themselves? Do you have specialists, like a “super-programmer”? What is their approach to work optimization?


Keep Some Energy in Reserve

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

What Is the Goal of a Scrum Sprint?

A sprint consists of a number of stories that the team needs to complete, and each story has a number of points assigned to it. But what is the goal of a sprint? Some stories might not be finished at the end, so is it to produce as many story points as possible? Let’s examine this more closely. Let’s assume that indeed the goal of a Scrum sprint would be to produce as many story points as possible. Force the team to work overtime! OK, that does not work because it is not sustainable. On average, you will end up with decreased productivity as the bugs will pile up and your team will be demotivated or even get sick.

What else can we adjust? We could be optimistic: let’s just add as many stories as possible into the sprints. If the team was able to do X story points before, it might be able to do that again!

What is the result of this? Even though you might end up (at least, in the beginning) with more finished story points on average in your sprints, consider the following disadvantages.

You will end up more often than not with unfinished sprints. There will be constant pressure on the team to be faster (as opposed to producing more value for the customer—which is not necessarily the same). There is no longer a goal. If the sprint cannot be completed because of too many tasks, the sprint as a concept loses its meaning and becomes more like a backlog.

Because in Scrum the team decides which tasks to work on and in what order, “uncomfortable” (but maybe valuable) tasks might remain unfinished (there is always something “more important” coming up) and dragged along to future sprints. The product owner then has to require people to conduct work in a specific order, and the concept of a sprint again loses its meaning, and the team loses its responsibility for the sprint.

The point is that you can fool yourself into thinking that an increase of story points per sprint (if that happens at all, considering the first two points in the list above) actually leads to a higher business value. The concept of “more story points = better” is actually the cause of delay.

If you are dragging half-finished stories along, their business value will remain at zero, no matter how much work has been put into them.

Stories that are worked on over the course of many sprints become more expensive, as their business value remains unrealized and people have to remember again and again what they were about. They also slow down planning and impede the focus of the team when selecting the next story to work on. “Management thinking,” that 100 percent workload of the team will maximize the business value of the project, is faulty.

From a management point of view, this idea has a scary outlook: your team completed its work and now…what? Do you send them home? Do you have them start another sprint? Do you add new stories to the completed sprint?

It’s important to get away from the idea of 100 percent workload being optimal. That is local optimization to a more global problem. When the team is done with the sprint, the team is done! Let the team decide what to do with the remaining time. People are self-motivated, they generally like to learn. Give them the opportunity to read books, attend conferences or seminars, research new technologies, or just take a break. Use the time for team-building, improving the office atmosphere, or generally cleaning up things that have piled up (there is always something). Encourage them to discuss what projects or program parts could be scrapped. But let it be the team’s time. Set the completion of sprints as the goal and have the team celebrate their success!

If you are afraid that, with such a positive outlook, they will aim for less and less each sprint, re-examine your own views and ask the five “why” questions, beginning with: Why are they not motivated to want to work on the project? Asking that question of yourself is much more productive than trying to coerce your team into working more…which usually just means having them spend more time in the office staring at the screen without really being more productive. Yes, the team has to lead the project; it is theirs. If you are uncomfortable with that idea, maybe Agile methods are not for you. But if you want to tap into the power of Agile, team ownership of the product is essential.

As a side note, if you really want to maximize the story points, maybe eXtreme Programming (XP) is for you (this is another Agile method). Here, there are no “sprints” but the team works together on one task at a time—with the product owner determining the sequence of the tasks. The advantage is that individual tasks are finished as quickly as possible, with the whole team behind them. You get quick returns, although at the cost of not being able to utilize parallel work, plus the possible overhead—just imagine seven people standing around a single computer telling the eighth what to do. On the upside, you will have a strong emphasis on knowledge sharing and will possibly improve team communication.

EXTREME PROGRAMMING ·  eXtreme Programming is a project management method on the team level. It consists of a set of techniques to improve software development speed by having the team work on only one task at a time, having developers work in pairs, and releasing individual features instead of waiting for the full product. It requires an advanced continuous integration system.

XP is a powerful method to consider. Even if you prefer Scrum, I would suggest testing XP as a team exercise. Have your team work on one task together until it is finished, and only then move to the next. It might actually be fun for the team to sit around a single computer and combine their knowledge, solving each problem together.


In Scrum, Ownership Matters

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

Moving from “Command and Control” to “Innovative Agile Management”

“Ownership” describes how a knowledge worker needs to be part of the whole process and not just a specialist in a department.

The concept of “business” has changed dramatically since the Industrial Era. The idea of business as we know it was created in the early 20th century. There was (simple, mechanical) work to be done that could not be done by the machines that launched the Industrial Revolution. Instead, the work required tactile fingers or human strength. The people who carried out the work received exact instructions on what to do, according to a clear plan.

As the economic process became more complicated, no individual person or team could work on completing a single product. Competition was harsh, resources had to be delivered just in time, and ultimately, the idea of a “knowledge worker” was created. Problems were no longer solved on the business level, products were no longer clones, every product was individually crafted and new. Workers ceased to be “copying machines” and became inventors, communicators, and researchers. In today’s highly technical world, micromanaging a knowledge worker is only possible if you already know the solution and all the steps involved. A low-risk project with expectable outcome: perfect for the Waterfall method. But if you do not know the market or technology, it is up to the team to work out the solution on their own, ideally with an Agile technique.

Scrum recognizes this change by putting the Scrum team at the center of development. In order to produce something relevant for the customer in a quickly changing market, the team needs to feel a sense of ownership, not only in the confines of their specialty or department but also of the overall product.

This connects to what I have written about multidisciplinary teams. The development team is seen by management as incapable of making the right business decisions—and often rightfully so, because HR hired developers, but not people with business, marketing, or sales experience! Last but not least, upper management tends to see moving people from teams “up” to middle management as a reward.

In reality, the situation is more complex. Striking the right balance between business and development is difficult. But this difficulty is mostly rooted in the fact that in order to implement these Agile ideas, established systems within the company have to move away from the Waterfall method.

It comes down to the ultimate question: Do you really want an Agile team? Or do you want to keep important decisions outside the team and enforce a system of command and control, moving and managing work packages from team to team?

Now, to get back to the ground, which parts of Scrum are affected by this? Or, a better question would be: in your existing implementation of Scrum, how do you recognize symptoms relating to a team’s lack of feeling of ownership?

I will explain three examples to illustrate:

A demand for commitment and overtime. Directly or indirectly, a manager might interpret the idea of “commitment” as a contract of delivery. On first glance, Scrum very much seems like an external company contractually bound to deliver a certain set of features in a certain amount of time (a sprint). This leads to a lot of failed sprints, high employee turnover, higher salary demands, the installation of the Scrum Master as the team cheerleader to motivate the team to perform, or a combination of these. This led to an update of Scrum in 2011: the word “commitment” was replaced with “forecast.” The idea of Scrum is not to be able to create perfect sprints which will, in the end, deliver exactly as promised. If that is required, and if your business depends on such a model of planning, use a different method. If you need the output of Scrum in another department exactly at the “promised” date, you are practicing the Waterfall method, not Scrum! Even in large-scale Scrum, the planning of the new sprint does not start weeks ahead, trying to include the results of other teams. It starts on the first day of your sprint.

Additional meetings. Beyond your regular Scrum meetings, a lot of other meetings might happen that involve the Scrum Master, product owner, or members of the Scrum team. This is usually taken as something normal. But I suggest carefully logging and looking at each of these meetings. The findings might hold valuable information about the quality of your Scrum process. Ask the questions:

– Why exactly is this meeting being held? A meeting with upper management about the course of the product might point to a lack of ownership on the part of the team.

– Who exactly is needed for the meeting in question? If meetings always include everyone, this might point to a lack of scope and planning. Maybe two or three people are enough to discuss an important technical issue. Maybe backlog grooming requires only part of the team.

– What about non-formal meetings that interrupt the work of the team? Some meetings could be delayed and made part of the regular Scrum meetings.

Deployment, demo, or installation issues. Encountering issues at the very last “phase” of the project is a common problem, yet it points to a much larger issue, especially if the demo is seen as work that can be squeezed in at the end of the sprint. As with all bugs, you can and should trace these particular issues back to the origin and find out the reason they were made (for example, was the demo made at the end of the sprint during overtime hours?). Given an issue’s particular place of occurrence, you should focus on:

– Project and test planning. Having bugs in one particular place means that there is an imbalance in the parts of the program you test. In the Waterfall method, the parts developed first underwent more testing and more changes than the later parts. In Agile, your goal should be to have all parts equally tested.

– Non-involvement of the team in the deployment phase. Looking back at my history as a programmer, I always felt the need to take extra care when I was the final person responsible for delivery. I took extra care because I would be the one staying up late at night (yeah…) to fix the issue when customers came complaining.

– Scrapped projects or features after development. This happens. Unfortunately, often way too late because no decision could be made within the company and responsibilities were pushed from one desk to another within the company hierarchy. Why does this happen?

Ultimately, it is due to a lack of connection between the customer and the Scrum team. It might point to non-involvement of the team in the final phase of the project. And that is not testing or deployment, it is getting the product to the customer! If it is an internal project, it means getting it to upper management. If you see an increase in developed projects or features being scrapped, you are either increasingly falling back to the Waterfall method, or your team does not have marketing or sales expertise.

To summarize: Keep your eyes and ears open. Situations such as a lack of motivation or ownership by the team should not be accepted, but the cause of such issues often lies much deeper, below the surface. As a Scrum Master, you are like a medical doctor, looking for clues about the underlying issues.


Team Communication

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

Developing an increased level of trust with other teams can enable the harder things.

—David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business [Anderson, 2010, p. 1]

In StarCraft, as in an organization, a big danger in terms of teamwork is when people draw circles around their field of expertise and stop feeling responsible for the world outside. Statements like “it’s my game, if you are getting overrun by the enemy, that’s your problem” sum up a common attitude among amateur team players. When the teammate is in trouble, instead of using the opportunity to either help to defend against or attack the enemy, new players tend to blame their partner.

In Scrum, this problem is approached by making the core team into a multidisciplinary team which is able to deliver the whole product without having to coordinate every step with other departments. Its members work on all tasks, as opposed to being nothing but specialists in their respective fields of expertise. There might still be outside specialists providing expertise in a support function, but they are not actually working on project tasks. There still is a bubble, but it is set up in a smart way.

In StarCraft, a comparable element to specialization can be found in the early part of the game, when one player decides to follow a single-minded build order to rush the enemy with a certain advanced type of unit instead of also building basic units to help the teammate against an early attack. Yes, you might be faster by focusing on just your own base, but ultimately, you will sacrifice the advantage of joint team operations. These kind of strategies are called “cheezy” for a reason: they have a good chance of working if you are lucky, but in general, if your teammate does not protect your back and can fend for himself, you might lose.

In Kanban, the “bubbles” around the Kanban teams are being removed. When the work in one project phase is piling up, either this can serve as a signal for upper management to fix the bottleneck, or the one team simply helps the other until the number of “work in progress” items is again below the limit. This is nothing different than helping out your teammate in StarCraft by defending against an attack.

Now, how do you interact with your Agile team? The best team knows how it thinks; it knows how every team member acts and reacts without having to check. The basic principles of Agile ring true here as well: personal contact is better than abstract communication. The most effective teams have moved from sharing text messages to voice chat. And they have not done it because text messages would not convey the necessary information. Voice chat simply offers a means of constant communication and synchronization. It reduces the possibility for errors when you describe what you do and also re-focuses the team constantly on the objectives instead of getting lost in details and micromanagement—a common novice mistake.

The downside of voice- as well as text-chat is the immediacy, which can also be distracting. In your Agile teams, make sure to log and reduce external distractions by channeling them in one place (e.g., a central email address for all questions to the team) or focusing them in regular meetings.

Beyond mere information exchange, a critical factor of good teams is trust. If they do not know each other, people on a team will have trouble knowing whether the other team members will come to the rescue. Working with teams, my recommendation is to make sure that they can build a healthy, trusting relationship with each other. One symptom of unhealthy team relationships is when one of the team members plays the “hero,” thinking the team or project needs to be saved. Here, Kanban can help by predicting the workload of individual team members and explaining how a “hero” will eventually become a bottleneck.

As with teams in StarCraft, teams in your business also have to “play” together. It takes a while until a team has formed, and formed teams usually consist of compatible personality types who know each other’s strengths and weaknesses. Be aware when, due to some management decisions, teams are broken off: new teams will have to invest a significant amount of time to form themselves.

Finally, StarCraft and Kanban have the most important thing in common: respect. While you can find mean and self-centered people everywhere, in StarCraft, there is (or was) a certain culture of respect. A common courtesy is to wish your opponent good luck at the start of the game, and tell him that it was a good game at the end—instead of hurling insults against him. Respect is also a pillar of Kanban. Of course you respect your team, but you should also respect all the project stakeholders instead of plotting or scheming against some of them. This does not necessarily mean agreeing with everyone, but at least hearing them out and trying to take their views objectively. And treating them like human beings. When you leave a project, thank the stakeholders for their trust in you and for the work you both managed to do together. Likewise, if someone from your team leaves, thank them for their work rather than complaining about people leaving the team.

Who are the stakeholders in StarCraft? Well, obviously the enemies! Sure, you could build your great base and gather all the resources from the map, but where is the fun in playing alone? Your enemy helps you to become a better player. Your enemy helps you to shape the actual product you are both working on: an exciting game to play and watch. That is the reason you both started the game. Your enemy stands symbolically for the “market demand,” just like (some) stakeholders can represent the market. Show them respect. Build trust between each other in order to enjoy the game together.


Scouting the Market

This is an excerpt from the book Kanban Remastered: Agile Lessons from Strategy Games. You can get a copy here.

One significant element of the game StarCraft is using is a “fog of war.” As opposed to games like chess, where the whole situation is visible and you can act strategically, in StarCraft, you have to constantly visit the enemy’s bases to check what they are doing. Only with constant feedback can you adapt your own strategy to be ready when they try to attack you. You need to have the right force, at the right time and place, to counter your enemy. In business, it is the same. It may be with the difference that you have a lot more time to “scout” your competitors, but it is often much harder to get reliable information.

Given that your competitor also scouts you, this results in an interesting dynamic. Depending on how fast and competitive the industry you are working in generally is and how reliably information can be gathered, this can require different approaches. Often, over time, the most flexible and adaptive product wins. If you can change strategies quickly, you have an easier time countering your enemy’s change of strategy (or adapting more quickly to a changing demand from the market). Kanban can help when those changes are coming from the demand side pulling through the company, or by small changes (e.g., turnover) within the company, which are also manageable by the Kanban workflow.

In terms of investment into market research, you might want to wait until you have scouted the enemy before you decide what type of units you will build. This way, you keep the risk to a minimum. On the other hand, when you have scouted the enemy and have the information, it might be too late to react. You might have some sort of product life cycle management (PLM) in place to first determine the feasibility of the product. This is sometimes easy to do when all you have to manage is resources. Sometimes, though, you are wandering in the unknown and only by implementing your plan will it show if it is feasible or not; an example would be engineering (cars, scientific instruments, rockets, etc.). Now, this is similar to scouting. While you can certainly make projections that the enemy will not attack you with a battle cruiser within the first few minutes because you know precisely with what resources they have started, you do not know their exact strategy.

Ultimately, you have to make a balancing choice. If risk is what you want to minimize, wait with any choice or investment until you have the information you need, until you know what is feasible. Your product will be on the market later, but you will save any initial investment you might have lost if it turns out it is not feasible. But keep in mind that risk stems not just from feasibility, but also from the marketplace. If you miss the window of opportunity to sell your product, you will have spent a lot more money and get no return.

The best approach is to divide your product into modules whose feasibility can be determined independently. Once the feasibility of one module is established, you can start with its implementation while you are still determining the feasibility of the next. You would already have begun building your resource gatherers, supply depots, and basic technological buildings even though you have not established the feasibility of your strategy. It is a risk, but a lower risk than if you waited.


Automate Your Definition of Done

This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams. You can get a copy here.

Reduce Repetitive Work by Employing a Smart Workflow

I am a fan of automatization. Because I am lazy. That is a good thing, because the human brain should not be used for doing the same thing over and over. At least mine should not. That is why I use a solution to automatically add acceptance criteria and definition of done to stories. For that, usually, people use a variety of approaches, like copying them into the description, printing them out, discussing them in meetings, or even adding them again and again as subtasks.

Well, there are better, automated solutions—with Jira.

Let’s first talk about what the “acceptance criteria” and “definition of done” are. Technically, they are not needed. Just write down all the steps of a story, including testing, documenting, deploying, product owner approval, code quality, etc., as subtasks. Done!

Now, that is an impossibly laborious task for anyone involved, but we need to make sure that all the points are accepted by the product owner. What to do? We could rely on the team to memorize at least the most common steps. After all, we do not include specific programming steps in the subtasks. But in contrast to acceptance criteria and definition of done, code is self-explanatory and all the steps of the actual work are already recorded in your versioning system. Part of the definition of done can be enforced by the continuous integration system. Every commit could be automatically checked for unit tests or code quality in general (e.g., using the tool Checkstyle). While I encourage this very strongly, it will not cover everything…what to do with the acceptance criteria and definition of done?

Let us define our concepts. In Scrum practice, we have basically four kinds of tasks the team can work on:

BUG REPORTS ·  Bug reports are added by anyone testing a released version of the product. They refer to either previous incomplete or erroneously implemented stories or to legacy code not developed with Scrum (or errors resulting from using third-party libraries). For the former, we refer back to the original story; for the latter, we might have to write a new story describing the expected behavior that the new bug contradicts.

ACCEPTANCE CRITERIA ·  The acceptance criteria are a story-specific set of conditions that need to be met in order for the story to be accepted and checked off by the product owner. A better expression for acceptance criteria is actually “business-facing tests.”

SUBTASKS ·  Subtasks are specific and usually unique pieces of work related to a specific new feature. If we find that, over the course of many stories, certain types of subtasks repeat, we can elevate them to “definition of done”—like “updated documentation” or “added unit tests.”

DEFINITION OF DONE ·  The definition of done is a story-independent list of general tasks that apply to all stories to ensure proper quality assurance, documentation, testing, and so on. This list can grow over time.

How do we implement these in Jira? Implementing subtasks and bug reports should be obvious. For story acceptance criteria, they go into the description of the corresponding story (see more below). But the definition of done is usually made available to the team as a regularly updated document at some other place. So, how can we merge this definition of done document into Jira?

First, some organization is required. Even if we find a way to add the definition of done automatically, the list is typically in bad shape and requires additional thinking by the team when implementing stories. For example, maybe it is a story with business value but it does not need any programming. Think of editing a page in a content management system like WordPress: asking for unit tests might cause some bewildered looks. Hence, we need categories. And with epics, we have already created such categories. We might just have to double-check and cross-reference with our definition of done. For example, a publishing company might require that all WordPress articles show a featured image. We have an epic called “WordPress article” and for each epic like this, we add that definition of done element to newly created articles.

How do we do that in practice?

We look at the easy part. Instead of adding subtasks for each definition of done item to a story, we add them to the story as checkboxes. For this, we need a plugin. There are two options, depending on whether you run your Jira in the cloud ( or on your own server.

ISSUE CHECKLIST FOR JIRA ·  The Issue Checklist for Jira add-on allows users to add simple ToDo list items to an issue and watch the progress when items from the list are completed. It is only available on the Atlassian Marketplace for a Jira Cloud installation [che, 2017]—check sim [2017] for a similar plugin for a Jira Server installation.

This way, the programmer can easily mark which parts of the definition of done are already done, and the product owner can track the progress as well. In addition, we can add the acceptance criteria to the list. All nicely integrated into the workflow with templates! This even makes the description box mostly superfluous; remember that the story itself goes into the summary line!

In case you need more control of the story creation process (like adding special instructions to the description), you need to change the workflow yourself. This is a little bit of hacking as we need to add a separate transition for each type of story. Any global instructions can be added to the initial “Create” transition of your workflow. Those will be added to all new stories. If your instructions differ only from project to project, not from epic to epic, you can create individual transitions for each project. If you use the epic-based approach, mentioned before, you will need to add another state. Let’s call it “Ready,” meaning that the definition of ready is fulfilled (all the acceptance criteria and definition of done are entered and the story is formally correct).

DEFINITION OF READY ·  The definition of ready is an agreement between the team and the stakeholders (represented by the product owner) that new stories have to conform to a certain standard before they are added to a sprint. It is up to the product owner to make sure that the team has sufficient information to know what the individual story is about and when it is accepted (acceptance criteria, definition of done). Obviously, the Scrum Master can help to clean up the stories so that they also conform in terms of visual and grammatical formatting.

From the initial “Open” status, create one new transition for each group of epics, with individual “Update Description Field” commands. You can even combine the global instructions from the “Create” transition with the later “Ready” transition. Another option is to directly fill out the epic field by the transition, with a lot of buttons in your initial detail view of the issue.

Whether you use the plugin’s features or the manual workflow approach (or both), a big plus of this approach is that you can centrally control the instructions you want to add to stories. All new stories of all your teams will automatically contain the current set of instructions. You won’t need to waste lengthy meetings to update every single user of your Jira system to include a proper list, nor will you have to spend endless hours fixing invalid entries.