Search Results

What should your budget be for Agile? How much should you invest in outside help for training, coaching and consulting? Legitimate questions, worded incorrectly. Many have this perception that there is a diet called Agile. This is a dangerous mindset. We know from observing the weight loss industry that dieting does not work. Dieting results in an endless cycle of gaining and losing weight, which, in turn increases the risk of many obesity-associated diseases. Dieting is also the most important predictor of developing an eating disorder. Wait, are we suggesting Agile doesn't work? Yes, if you only focus on doing Agile. We know that a focus solely on weight loss is not a good strategy. We are much more successful if we shift the mindset towards a focus on greater health. Similarly, we need to shift our emphasis away from just doing the Agile diet. Instead, view agility as part of a larger strategy aimed at greater organizational health. So back to our original question. What is our investment in Agile? Let's substitute the word improvement for Agile. Say it out loud and see what a huge difference one word makes. Try these questions on for size: What is our investment in improvement? How many people do we need focused on continuous improvement? How do our stakeholders feel about improvement? Who do we need to help us with improvement?

I've been doing some research on companies for a while and what I've found is rather discouraging. Lots of unhappy employees who don't feel respected, appreciated or able to make a difference. Lots of management that is not paying attention, perceived as incompetent, and clueless to the pain of the people surrounding them. It's quite depressing, especially if you've experience this yourself. The fact is, stories of people who are engaged and happy with managers that they admire and enjoy working with are the exception rather than the rule. It really upsets me. Life is too short to be miserable like that. I know what it feels like and it hurts to think others are dealing with these problems. Nevertheless, when the economy is good most companies seem to be able to plug along just fine with a staff of unhappy employees and tone deaf management. If one tells them they have a problem, they look at you like you're an idiot. "We're making money hand over fist! We're not going to let a few disgruntled employees ruin that. They're just a grumpy minority." Why change at all? At this point, you realize that until they feel some sort of compelling need to change, nothing will happen. If there is any notion of change at all, it's usually, "Go fix those guys..." Managers want you to fix the employees, and employees want you to fix the management. Neither option works in isolation. So then we are at an impasse. There isn't a compelling way forward that either group will buy into, so the miserable status quo rules. I find this is very frustrating. Go to Glassdoor.com and read the reviews for many companies. It's depressing reading. If you have any empathy at all, it almost hurts physically to read those reviews. How do we get out of this cycle of maintaining the miserable status quo? In the last month I've seen the economy completely tank for what is now the third time in my life (2001 tech bubble, 2008 housing bubble, and now). Each time, many companies were devastated. Their business models were completely blown up. Some recovered, but many didn't. The same pattern is playing out today. It's very likely that your company has been adversely impacted by the pandemic. The markets have been blown up. If this is your situation, you are going to be in a rebuilding phase for months if not years to come. So why not build something better this time? If all the Lego pieces are already lying on the ground, isn't now a great time to build something better? Do you really think that building the old system again will be a competitive improvement? Of course not. Now is our big chance to create something better. Not just better products, but better environments for our people. Now is the perfect time to look at how we work and make it better. Think of it this way: we are at a historical inflection point. Some companies will come out of this depression stronger, having found ways to work together in ways that value their people and create opportunity. Others will simply try to rebuild what they had before. Which one do you think is going to be better off? Which one do you want to be a part of? I know where I'm placing my bets.

This pandemic is creating both short-term and long-term changes in the way we behave in groups. The most obvious change is that remote meetings from home are becoming the primary form of communication. For most agilists this represents a conflict, because our stated preference for 20 years has been face-to-face communication. That’s just not going to happen now, no matter what your preference. Using remote tools like Zoom, Teams and others will be the new default for the foreseeable future, like it or not. However, there is another change taking place that’s not quite as obvious, but still important: online work tracking tools. As a consultant prior to the COVID crisis, my preference always leaned toward using physical task boards rather than electronic ones. There is something magical about the tangible nature of a physical task board that leads to better conversations and interactions. A wall full of little yellow stickies just sets my heart a-flutter. Online tools are full of extraneous detail. They have icons, text fields, bells and whistles that often get in the way of productive and useful interaction. Don’t get me wrong, deep down I’m a tools guy. I’ve helped sell them for many years. I know online tools very well. But none of them can beat the simplicity and elegance of a sharpie and a stack of post-it notes. Let’s face it, by the time you are done logging into your online tool, I’ve already built a physical board from scratch and begun organizing the work for the day. Physical is faster. No contest. Guess what? All that has changed now. With everyone working from home we are all going to need some sort of electronic work tracking tool. Post-it notes and stickies are like, so totally 2019. Electronic task boards are going to become the standard. You better get to lovin’ JIRA, Trello, Azure DevOps, Rally (or whatever your favorite tool is), because it’s here to stay. The only effective way to track work with everyone at home is using an online system. Period. The only place you are going to find post-it notes is on your refrigerator. I’m selling my stock in 3M. Just for fun, I’m going to keep some of my post-it notes in a box to show to my grand-kids, “Back in my day, we used to use these things to organize how we worked…” Go ahead, convince me I’m wrong.

From time to time development teams will not finish all the work they’ve forecasted for a Sprint.  Typically, this occurs because a user story or two may have been more difficult than planned, leaving other work undone.  When it continues to happen Sprint after Sprint, we must begin to look at patterns that may lead us to a root cause.  While there could be many root causes, I will address only a simple, but common one for starters:  Development teams over-committing in their Sprint forecasts. Consider this:  A Product Owner must be able to communicate to stakeholders the status of their requests (user stories).  The communication with stakeholders takes place often, including right after Sprint Planning, to let stakeholders know that their requests (user stories) are part of the current Sprint.  It’s important for Product Owners to have some predictability as to the development team’s ability to deliver on the Sprint forecast so they can build confidence with their stakeholders.  Over time Product Owners and stakeholders may begin to lose confidence in the development team’s ability to deliver against its forecast if the pattern continues for long periods, resulting on low customer satisfaction. The development team’s average velocity is the average number of story points the development team can get “done” in one Sprint.  New teams have to “wing-it” to determine their average velocity until they develop a few sprints of empirical data allowing them to forecast their velocity.  Over time a team’s average velocity becomes more refined and more predictable.  Average velocity is the primary tool the development team uses when forecasting their work for a Sprint during Sprint Planning.  For example: if the development team’s average velocity is 50, then the development team should not forecast more than 50 story points of work for the Sprint during Sprint Planning.  New teams tend to be overambitious and over-commit on their forecast during Sprint Planning, well beyond their average velocity, because they haven’t built trust in the empirical data (average velocity).  The result is that the team may commit to 60 or more story points worth of work, but still only finish 50, with 10 or more story points carrying over to the next Sprint.  What do we do when this happens?  Unfortunately, developments teams will tend to underestimate the remaining effort for the 10 story points and likely pull in another 60 or more during Sprint Planning, even though their known velocity is 50, based on the empirical data.  The cycle continues until the team decides to put a stop to it or the Product Owner and stakeholders begin to get frustrated and confidence begins to drop. How do we fix this?  There’s a saying in the lean agile community; “stop starting, and start finishing”.  Sounds simple, but that’s exactly what we have to do.  In the scenario above, we still have 10 story points carrying over to the next Sprint.  Instead of over-committing with another 60 or more story points or even adding 50 story points which is our velocity, try only adding 40 story points, for a total of 50 (40 new, plus 10 carried over).  Yes, some of the work may have begun on the 10 story points that carried over, but that’s ok.  Let’s focus on finishing old work before starting new work.  Worse case, if the team is able to deliver the 50 before the Sprint ends and runs out of work, the Product Owner can ask the team to pull in an additional story from the backlog. Higher job satisfaction will emerge when a team delivers everything it forecasted.  Bottom line, forecast with care, and you, your Product Owner and your Stakeholders will be much happier.

Slack, Paper, Scissors is a simple game exploring three key concepts of capacity planning: slack, trade-offs and weighted shortest job first (WSJF). The game is very easy to run and requires just paper and scissors. It should take 15-20 mins including debrief. Materials (for each team): 3 pieces of differently colored paper (preferably letters or A4 size) 1 pair of scissors 1 marker If you don’t have colored paper or scissors you can improvise. Instructions Distribute the scissors and 2 of the 3 colors of paper to each team (size 2-5). For example, if you have green, pink and white paper distribute the green and pink and keep the white (for now). Tell each team to cut each piece of paper into 4 shapes of different sizes. They don’t have to be different shapes so long as they are different sizes. Ask each team to randomly number the 4 shapes on the first piece of paper 1, 3, 5, 7 and on the second piece of paper 2, 4, 6, 8. Note: Make sure you stress that the shapes are labelled randomly, if they label according to size it will interfere slightly with an important learning objective. Share with the teams that the shapes represent initiatives, the colors represent two customers and the labels on the shapes represent the relative value of each initiative. Hand out the 3rd piece of paper and tell teams that this represents capacity for the next quarter. The goal is to plan as much value into the next quarter without overlapping initiatives or going outside the bounds of the given capacity. Don’t tell teams to keep both customers happy, you can leave that for a debrief discussion. Debrief Go round the room and see who had the most value in their plan, remind people that because of the random nature of how we attached value there is a lot of luck involved Some questions to ask: How does this parallel the real world? Did anybody prioritize one customer over another? How would this work in the real world? What does the empty space represent? Is it good to have empty space? What do Agile organizations call the empty space? [slack] Is the largest initiative always highest value? Is it the best economic decision to consider only value when planning for highest throughput of value? [hey, we just learned WSJF] Can we reduce the size of backlog items while still retaining most of the value? [yes if we cut in the right place] What can we do to increase the size of the paper? [more people, greater productivity, less uncertainty] What are some of the gotchas? What can decrease the size of the paper? [less people, less productivity, greater uncertainty]. How can we mitigate? Conclusion Slack, Paper Scissors presents a simple, tactile method of experiencing the tradeoffs made during capacity planning the value of slack for enabling flow and a really simple and straightforward introduction to weighted-shortest-job-first (WSJF).

I’ve got a lasting memory from 2007 at the Agile Conference in DC. Leaders from the Agile community were delivering introductory sessions on key topics. I was thoroughly enjoying a session on XP until, it came to question time. One of the attendees expressed his enthusiasm for XP and asked the presenter what suggestions he might have for a distributed team. The brusque response was “you need to collocate your team”. The questioner responded that unfortunately that was beyond his area of influence and given that constraint, were there any suggestions. The second answer was even shorter than the first and that, was the end of that conversation. They say that if you won’t remember something in 10 years then don’t stress about it. This story for me highlights one of the problems in the Agile community. As a collective we subscribe to servant leadership as one of our guiding metaphor. So, it is surprising to see such a lack of empathy from so many so-called leaders. We are living in an imperfect world. We must do more to lift people up out of their mediocre work lives. We can’t do that, if we are not inclusive of everybody and refuse to speak to those who don’t fit our world view. It’s a myth that co-located teams are a pre-requisite for Agile development. Nowhere in the Agile Manifesto, or its underpinning principles is it stated that co-location is a requirement. The closest you will find is the sixth Agile Principles: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This statement can be backed up by so much empirical evidence that I think it is beyond doubt that face-to-face communication is more effective. However, it is harmful and misleading to infer that people can never work effectively when distributed. There are plenty instances in which the hard and soft benefits of distributed work outweigh the inefficiencies. Factors you should consider: Cost of Delay & Flow Efficiency Distribution incurs a delay in decision making. The greater the span of the distribution (distance and time-zones) the greater the delay. The economic impact of that delay needs to be examined from the perspective of flow-efficiency so that we are best positioned to make the correct trade-off decisions. Product Lifecycle The product life-cycle can have a big impact on what teams we deploy. If we are early in the product life-cycle where there are a lot of unknowns we will require much greater collaboration than we would have for a product approaching end of life. Capability & Desirability of Work Do we have a critical mass of skills to respond to an emerging opportunity? Maybe yes but, not all in one place. If not, do we get outside help? If so, do we completely outsource or do we adopt an out to in model where we initially get outside help and then transition to more inside help. Work-Life Balance & Social Responsibility We cannot ignore the impact of technology on our working lives and the planet. Allowing people the ability to work remotely allows employees a better work-life balance while the many benefits for employers include better retention, higher availability and higher utilization. When the stakes are high you should always strive to co-locate team members. For other work, knowing the key factors and the economic considerations will help you make better informed decisions. Remember though, not everything that counts can be counted so, don’t ignore the softer benefits of both colocation and distribution.

I first heard about Fist of Five voting back in 2006 from my colleague Nate who went to an event and returned gushing about the facilitation techniques he learned from a talk delivered by Jean Tabaka. Little did I know at that time that Jean would later become a friend and mentor through my many years at Rally Software. All of us who were at Rally owe everything we know about facilitation to Jean and though she sadly passed away tragically early back in 2016 she lives on through the many she touched over the years. For those not familiar with Fist of Five voting here is a brief synopsis. Let’s say that we’re trying to reach consensus on a quarterly plan a proposal might be: This is our plan. We all approve it. We are confident that it is the best plan we could come up with at this moment in time. Any more time we spend would be less valuable than starting work. Next we vote on the proposal using the five fingers of one hand. The facilitator uses their favorite technique to make sure that everyone votes at the same time so that we don’t defer to the authority in the room (a problem in some organizations). The number of fingers we show indicates the degree of consensus: 5: Wild, unbridled support 4: I think itʼs a great idea 3: I can live with that and support it 2: I have some reservations to talk about 1: I am opposed We used Fist of Five often at Rally. It meshed well with our culture. From the top-down we aligned to a servant leadership model so a consensus based decision making technique was a natural fit and our core values ensured nobody took advantage of the power granted to them. For many who adopt this simple technique it becomes not just a tool but a symbolic shift to a whole new way of decision making. However, consensus based decision making does have its limitations. As Frederick Laloux points out in his excellent Reinventing Organizations consensus based decision making [can often] degenerate into a collective tyranny of the ego. Anybody has the power to block the group if his whims and wishes are not incorporated; now it’s not only the boss, but everybody, who has the power over others (albeit only the power to paralyze). Attempting to accommodate everyone's wishes, however trivial, often turns into an agonizing pursuit; in the end, it’s not rare that most people stop caring, pleading for someone to please make a decision, whatever it turns out to be. Does this sound familiar? Are you finding that every time you try to use Fist of Five on your team it is always the same people blocking consensus and effectively grabbing power? If so, then a change needs to be made. Either you need to change the composition of the team or you need to change the way you make decisions. Laloux talks about a different type of decision making that he has observed in organizations he calls Evolutionary-Teal. Known by someone as the “advice process” it works like this: In principle, any person in the organization can make any decision. But before doing so, that person must seek advice from all parties and people with expertise on the matter. The bigger the decision, the wider the net must be cast. The agony of putting all decisions to consensus is avoided and everybody with a stake has been given a voice. Can we repurpose five finger voting to work with an advice process? It might be confusing to change too much but with a small adjustment we can make it work. We use the Fist of Five first to indicate how much we like a proposal. However, one or two fingers no longer blocks decision making. You can still use one (carefully chosen) finger to indicate your dislike for as proposal but with the advice process this does not block moving forward. If the proposal is popular we then vote with our other hand about whether or not the proposer has considered the input of all concerned parties. Thumbs up would signal yes and thumbs down would signal no.

A Release Train Engineer asked me which of team ceremonies she ought to attend. My answer was that she needs to attend many of them regularly but not every single one. Of course the reason behind the question is often more interesting than the question itself but first a little background. The term Release Train Engineer (RTE for short) has become well known for those followers of the Scaled Agile Framework where it is used to refer to the ScrumMaster of a Team of Teams also known as a Release Train. It is also a term used in many places where we see agility at scale. The RTE role belongs in the same family as ScrumMasters and coaches so we expect RTEs to exhibit many of the same servant leader attributes. Servant leaders have a passion for a passion for people and their continued development so we expect RTEs to mentor and help ScrumMasters. The sheepdog analogy is a popular one when explaining the ScrumMaster role and similarly we expect RTEs to use their enhanced vision to help them see the path ahead, spot dangers early and sometimes use their sharp teeth to protect their flock from predators. We can’t protect teams if we don’t know where they are and we can’t help them improve if we don’t understand them. The only way to get a good understanding of strengths and areas for improvement is through direct observation. In Lean parlance we call this going to the gemba: the place where the real work gets done. This can’t be a once in a blue moon sporadic event. If observers shows up only when there are problems then our gemba walks resemble oversight and we never build trust with the teams. Which brings us back to the original question. As it turns out, the team is reluctant to have the RTE observe their ceremonies. There are personality clashes within the team and the planning events and ceremonies are not going smoothly. There is not psychologically safety within the team and they would prefer to wait till things are a little more stable before they invite outside observers. I think we can empathize with the team, we might have been there before ourselves. But if we only include others when things are going well we miss a very important learning opportunity for everybody. When things are painful, a natural inclination is to decrease the frequency. For example deployment can be such a drain to all that we change from quarterly releases to just twice a year. For some of us this might result in a bestselling book but rest of us might not be so lucky. When events are difficult and distracting it is usually better to increase the frequency of the event. This applies to cleaning your house, system integration, product deployment and yes, also visiting the gemba. If the team invited outside observers more often they would begin to feel more comfortable with their presence, the observers would cease to be viewed as oversight and more as a valuable extension to the team. With greater transparency we create more opportunities for people to learn from each other and it can't just be the good stuff. If we don’t observe the downs as well as the ups then we end up like the Queen of England believing the whole world smells of fresh paint.

Schedule (verb) To plan an activity at a specific date or time in the future. Prioritize (verb) To arrange or list a group of things in order of priority or importance. Wiktionary.com Prioritization and scheduling are closely related activities with some key differences. Scheduling too early can lead to waste and missed opportunity. Many fall into this trap as they don't fully appreciate that Weighted Shortest Job First (WSJF) is a scheduling strategy. You can observe a classic scheduling algorithm in restaurants. For the most part, requests are processed in the order in which they are received; also known as first-come-first-served (FCFS). First-come-first-served works well for restaurants, airports and highways as the flow units are roughly the same size and of equal value. In product development, the units of flow vary greatly in size and value. It makes sense to do the most valuable unit of work first. But, what if the most valuable unit of work is really large and it takes a very long time before we realize that value. Perhaps in that same amount of time we could do five small units of work with much larger cumulative value. When scheduling, we need to consider the time it takes to realize value in order to ensure we are maximizing value throughput. A scheduling strategy well known to many in the Agile community is Weighted Shortest Job First introduced by Don Reinertsen in The Principles of Product Development Flow (2009). Weighted Shortest Job First (WSJF) is calculated as Cost of Delay (CoD) divided by Duration. WSJF can be a great aid to help maximize economic return from your portfolio. WSJF also introduces a lever that can greatly improve flow efficiency. With WSJF, huge initiatives that used to block the flow of value now have a low WSJF score and get bumped further down the to-do list. This might seem problematic if that huge initiative has very high value. However, those passionate about the value of the proposed initiative will seek positive ways to influence the WSJF score by reducing the effort. This is most likely through: a) breaking down the initiative into smaller parts ; b) looking for wasteful features and gold-plating that can be safely discarded. If we can organize to get the highest value into the smallest possible component we will have identified our MVP. WSJF has its limitations. We should not look at every decision through a WSJF lens. WSJF does not work well when we have a large variance in value and/or duration. Think about the decisions you make in your household. Yes paying the utility bills, the mortgage and buying food all have high value but if you never change the filters on your HVAC system eventually something bad is going to happen. Like your household budget, create separate investment categories for like things and then use WSJF within those categories. Early in the product lifecycle, especially when innovating, there will be enough uncertainty about who and how that any estimates about duration will be unreliable for decision making. Where this might be the case, don’t use WSJF to rank, use Cost of Delay. Or, in other words, don’t use a scheduling strategy when you are not scheduling. Lastly, a word of warning. SAFe advocates using job size (level of effort) as an approximation for duration. This is a good approximation when flow efficiency is very good (minimal value-stream delays). Ironically, poor flow efficiency is one of the reasons why many adopt Agile and SAFe. To sum up: WSJF is a scheduling strategy used to maximize value throughput WSJF can be an effective lever to help us identify our minimum viable product Organize your backlog items into investment categories so we use WSJF to compare apples with apples WSJF can be counter productive early in the product lifecycle When you are not scheduling, don’t use WSJF (a scheduling strategy) instead use Cost of Delay Be careful using WSJF when your flow-efficiency is poor. Only use job size as an approximation for duration when there is a good correlation

One of the interesting things we’ve found as we set up our businesses is that we also needed a number of others tools and services to get things done. What is nice is that these are often a click a way, and that the bigger issue is finding something that is good, and not expensive. Here are some tools that you might find useful as you set up your business: Trello: Useful Kanban board for all kinds of purposes. FiveWhyz people have used this to track personal and business work, business development pipeline, and so on. Slack: Chat tool for groups of people to discuss things. You may not find it useful for a one person business, but if you start collaborating with other coaches, for example, you will find a lot of coaches use this. Zoom: Effective web based video conferencing and webinar tool. It is always useful to be able to set up a video conference to work with people. Idea Boardz: Useful “card” oriented board to collaborate and brainstorm. Very useful for retrospectives, especially in remote situations. Instant Agenda: Useful tool “lean coffee” oriented tool to collaborate and brainstorm. Pexels: As you do presentations and build we sites, you will probably want to use high quality images. Pexels offers a searchable library of free images. Pipe Drive: Simple customer relationship management (CRM) system based on Kanban style cards. Dokuwiki Wiki system: I like the idea of a place where I can store information that is beyond a file service - a knowledge base if you like. This is a place to capture knoweldge and ideas. HansSamios for example. By Way of Context ... You are looking at a part of a series of blog posts. The series looks like: Decide on a business name Validate you can use the name Claim your domain Establish a legal business entity Establish your logo Set up federal taxation Establish your LLC as an S-Corp Establish your website Find a small business accountant Find a small business lawyer Establish a business banking account Setup accounting tools Get business insurance Other tools you might be interested in And remember, I am not an accountant. I am not a lawyer. You will want to get help from these experts and should defer to their opinion in the event that what you read on this page differs from their opinion.

Let’s face it, the work we do is not exactly life and death as, after all, the final decision to do something is still with the customer. This does not mean there isn’t any risk to you. No matter how good you are at what you do, sometime expect results don’t quite materialize, or your advice leads to a client losing money, with the result that your business can get slapped with a lawsuit. To mitigate this, you should consider getting business insurance. In fact, you’ll find that many companies will not contract with you unless have, and they have seen a certain level of business insurance. There are two basic types of insurance that you will need: Commercial general liability (CGL) insurance: this is broad coverage for lawsuits related to third-party bodily injury and property damage. This insurance covers the cost of paying medical bills and replacing damaged property, as well as your legal defense if you are sued. If you are required to pay a settlement or judgment from a lawsuit, your general liability policy pays up to your policy limits. Typical coverage required is $1M for an Agile coach. Business consultant professional liability insurance (or errors and omissions insurance) provide protection if a client sues you for negligence related to your work. It covers defense costs, settlements, and judgments. Typical coverage required is $2M for an Agile coach. There are two basic approaches to setting up business insurance: Website direct: There are a number of direct to customer insurance companies out there. Owners of FiveWhyz have had good results with HISCOX. Through a broker: Again, there are a number of brokers out there. Owners of FiveWhyz have had good results with Tech Insurance. The cost for both of these combined will be about $120-$150 per month. By Way of Context ... You are looking at a part of a series of blog posts. The series looks like: Decide on a business name Validate you can use the name Claim your domain Establish a legal business entity Establish your logo Set up federal taxation Establish your LLC as an S-Corp Establish your website Find a small business accountant Find a small business lawyer Establish a business banking account Setup accounting tools Get business insurance Other tools you might be interested in And remember, I am not an accountant. I am not a lawyer. You will want to get help from these experts and should defer to their opinion in the event that what you read on this page differs from their opinion.

Tracking your business so you can understand the profit, costs, how much tax to pay and so on is a necessary part of any business. There is no doubt that you can start a business with some pretty basic tools to track income and expenses such as Excel. In the end you will probably want something a little more robust than this. What you are looking for is a system that allows you (at a minimum) to: Track and categorize (e.g. consulting, reimbursement) income Track and categorize (e.g. marketing, travel, etc.) expenses Download data from your business bank account so you don’t have to enter all the data manually Generate and track invoices General accounting reports such as a General Ledger so you can complete taxation filings There are two basic tools you should look into: The cheap Quickbooks: The granddaddy in small business accounting tools is Quickbooks. The only real downside of this tool is the fact that it costs to use, say about $10 a month for a one person business. The free WaveApps: If you are worried about spending money WaveApps offers similar capabilities for free. FiveWhyz folks also use this FiveWhyz folks use either of these tools to good effect. If your accountant has a favorite tool, then the best bet is to go with that tool. By Way of Context ... You are looking at a part of a series of blog posts. The series looks like: Decide on a business name Validate you can use the name Claim your domain Establish a legal business entity Establish your logo Set up federal taxation Establish your LLC as an S-Corp Establish your website Find a small business accountant Find a small business lawyer Establish a business banking account Setup accounting tools Get business insurance Other tools you might be interested in And remember, I am not an accountant. I am not a lawyer. You will want to get help from these experts and should defer to their opinion in the event that what you read on this page differs from their opinion.