David Morrow

Mark C. Layton, "Mr. Agile®," is an executive and BoD advisor. He is the Los Angeles chair for the Agile Leadership Network, a Certified Scrum Trainer (CST), and founder of agile transformation firm Platinum Edge. Mark is also coauthor of Agile Project Management For Dummies. David Morrow is a Certified Scrum Professional (CSP), Certified Agile Coach (ICP-ACC), and an executive agile coach.

Articles From David Morrow

page 1
page 2
page 3
26 results
26 results
Scrum and Your Customers: The Most Crucial Stakeholders

Article / Updated 07-20-2018

Your customers are the perfect addition to your scrum because they are great sources of product innovation ideas and improvements. Alienating them not only creates ill will, but also cuts off a crucial feedback loop that can lead to innovation. Internet service providers, phone companies, and local utilities consistently rank among the highest in customer service complaints. Where service providers are limited, customer service is commonly (although not always) weaker than in other industries. Customers frequently encounter long hold times, frustrating service, and labyrinthine automated service menus. Pressures on the bottom line have caused many companies to cut the budget for customer service, yet customers are the most crucial stakeholders in any business, and they need to be provided good service. Without the customers, there’s no business. Comcast is an example of a company that has experienced bad press regarding the quality of its customer service. Instances of customers unable to get refunds for bogus charges, wait times forced until closing, and an inability to cancel subscriptions are just a few of the claims that have been made over the years. Although the need for service is enormous, quality is often lacking, and millions of people are willing to spend the time to make others aware of their experience. Customer complaints about the handling of their service calls abound. The service conundrum Perhaps the number-one failure in service is that customers often report that their issues aren’t even solved by the agent. Customers need and expect service representatives to be able to answer questions and solve problems regarding their companies’ products. Unfortunately, all too often, training in companies fails to provide the customer service representatives with the knowledge they need to meet this need of the customers. The service representative may not understand the problem because the customer explains it poorly, or the representative simply doesn’t understand the situation the customer is describing. Seventy-eight percent of customers state that their good customer service experience was due to the knowledge the rep had, while only 38 percent said it was due to personalization. Knowledge matters. Training development for representatives is a high priority. Preplanned answers don’t carry the weight of true depth of knowledge. The cost of losing a customer is far more than the customer’s annual subscription rate. Customer service divisions are often thought of as being cost centers, but in fact they save and make their firms huge amounts of revenue. Following are some statistics that reflect how customer service can affect a business in ways that you may not have considered: It’s more than six times more expensive to gain a new client than to keep a current one. 78 percent of customers have forgone a purchase or transaction due to poor service. Loyal customers are worth up to ten times the amount of their initial purchases. Twelve positive experiences are needed to make up for one negative one. For every customer who takes the time to complain, 26 others tell their friends instead. Information overload In this day and age, too much data is quoted as a source of call center failures. Too much information can paralyze the effective functioning of a service representative. Service representatives can become overwhelmed with too much data that’s hard to use, and many centers haven’t managed this information so that it’s useful to representatives. Perhaps you’ve been on a call with one representative and been transferred to another, only to find that you had to explain the issue all over again. Often, a client’s historical data doesn’t get fed to the rep. It’s frustrating for the customer to rehash his situation or to hear the ominous words “I have no record of your claim here.” Getting the right information to the right people is part of the problem. Sixty percent of customer service centers say they aren’t even able to get certain pieces of customer information (for example, portions of customer history) to service representatives. On top of this, more than 30 percent of representatives don’t gather and record customer satisfaction data. Sometimes, data isn’t consolidated between organizational divisions, or the data is hard to find. Firms are experts at gathering information, but timely and effective distribution of that knowledge is a problem.

View Article
Scrum in Action in Customer Service

Article / Updated 07-20-2018

Many companies use scrum but haven’t applied it to their customer service departments. These firms could greatly improve their customer service, and their bottom line, if they used scrum across the board. If an organization already uses scrum, it should have enough experience and knowledge to share with other departments. Integral to the scrum transformation is making sure that a customer service rep is present in every sprint review for product development scrum teams. Transparency and awareness stem from this integration between customer service and product development. Service representative scrum teams can plan training and other process-improvement activities during sprints. Additionally, service representatives can learn from the product development sprint reviews and share this information with their teams. L.A. Water and Power and scrum The Los Angeles Department of Water and Power implemented the scrum framework without calling it scrum. The goal was to enhance customer satisfaction in its net meter Solar Incentive Program. The program offers incentives to offset the cost of installing a solar rooftop system at your home or business. The department wanted to reduce delays, streamline the overall customer experience, and increase transparency. To increase transparency, the department implemented two dashboards, called Mayor’s Dashboards, to help customers stay abreast of changes and improvements. One dashboard included weekly updates on metrics, including the status of rebate checks. The second dashboard displayed the Feed-in Tariff 100-megawatt program, which the city used to purchase third-party solar power. The time and process involved in processing FiT contracts was displayed, and both dashboards displayed issues, solutions, and response times. A huge increase in transparency occurred. These sprint backlogs were made available to all stakeholders and customers. The department also consistently inspected and adapted its process to streamline the process for reviewing applications. Results of this inspection and adaptation included increased staff to handle applications and hotline service, removed dependencies between rebate payment and turning on service, reduced review time of lease agreements through a lease compliance form, and automation of routine email communications with customers and contractors. The main improvements streamlined existing systems and increased clarity. By enhancing the customer experience, the department greatly increased customer service. It targeted the causes of issues and set about to fix them with scrum principles.

View Article
The Scrum Sales Process

Article / Updated 07-20-2018

Scrum can be used as part of the sales process. Successful salespeople are exceptional listeners and have keen observation skills. One goal is to discover prospects’ problems and then show how the product or service solves those problems. To make this connection, a salesperson needs to establish a relationship based on trust. People buy things from people they know and trust. Scrum selling is about gaining trust through teamwork. The supporting players may include presales, business development, account executives, field engineers, installers, inside sales and support, and service people. Any combination of these people can make up a scrum team and swarm to synchronize communication, supporting the effort to get the client to sign a deal. Swarming activities might revolve around the following: Preparing for a trade show Following up with trade-show leads Developing time-bound proposals to potential solutions for a sales pitch to out-class the competition Saving an at-risk sale by brainstorming and prioritizing action items Sales cycles are more successful when a potential consumer or business is pulled toward a product or solution as opposed to responding to a pure outbound “cold call” approach. Pull strategies involve content marketing, webinars, trade shows, and social media marketing. The scrum sales process is high-touch and commonsense. It mirrors the roadmap to value as follows: Vision Example: Grow gross sales in Dallas by 20 percent this fiscal year by increasing the company’s social media presence and analytics. Follow up with a personal phone call or email to everyone who provides contact information. Product roadmap (high-level) and product backlog (broken down) Example: High-level and low-level lists of changes are needed to make the vision a reality, such as Sales strategy development Acquisition of tools Development of collateral Sales process development and fine-tuning Execution needed for specific deals in the process Assigning key (detailed) social media sites to a team member Finding a tool for tracking sales funnels that the team will use Defining such reporting processes as analytics workflows Release planning Example: Prioritize backlog items by month and/or quarter. Sprint planning Example: As a team, create tasks and assignments for the backlog items. Sprint Example: Hold daily stand-up meetings to coordinate swarming tasks for the day and identify impediments. Sprint review Example: Demonstrate to the stakeholders (such as the vice president of sales) that the sprint is complete (the Facebook page is operational, for example, or mailing lists of past customers are compiled). Sprint retrospective Example: Review what worked well and facilitate knowledge transfer. Service/installation people are learning how new customers are being acquired, for example, which helps them continue the company messaging that leads to the sale.

View Article
Scrum in Action for Marketing

Article / Updated 07-20-2018

Scrum is widely used in marketing today with astounding success. Scrum fits the wild and wooly world of shifting customer needs and technology. Check out these examples of scrum and marketing. CafePress and scrum CafePress sells gifts and merchandise that a customer can customize, such as mugs with pictures and/or memes. A layer of versatility was uncovered in CafePress’s scrum implementation. The legal implications of customizable products meant that marketing needed a close alliance with the legal team to facilitate quick response to legal inquiries and concerns. The marketing team needed to be aware of what it could and couldn’t say to avoid taking on unnecessary legal liability. The legal department became an integral part of CafePress’s marketing scrum team, making sure that marketing could get any queries answered in 20 minutes. CafePress’s strategy of bringing legal and marketing together is a great example of the benefits of aligning business with development. Sometimes, the departments’ goals seem to be at odds, but with scrum, they’re directly aligned with making a better product and creating more satisfied customers. Xerox and scrum Xerox is a household name, usually associated with office photocopying. Over the years, this firm has branched into other products and services, such as IT, document management, and software and support. The original photocopy process of making paper copies from documents and visual images is called xerography. Electrostatic charges are used on a light-sensitive photoreceptor to transfer powder onto paper, thereby copying the images. Heat then seals the deal, literally. Who invented xerography? A company called Xerox. Xerox’s global interactive marketing team integrated scrum into its business framework to simplify and prioritize demand from customers and marketing teams throughout the world. The team knew that it had to respond to the changing market and customers’ changing needs, and they needed to respond as fast as smaller competitors that could respond and pivot more quickly. Scrum provided the framework for Xerox to self-organize, iterate, inspect, adapt, and deliver more often. Similar problems existed in portfolio management. Projects weren’t prioritized, so developers were thrashed from project to project, and the loudest stakeholder received his product first. When new initiatives came along, the teams couldn’t pivot quickly enough to take advantage of potential benefits. The teams thrashed employees across multiple projects or stopped projects to reallocate people to new ones. With scrum, Xerox segmented the type of work to be done into three queues: new development, creative projects (such as artwork), and rapid response (service issues that take eight hours or less to resolve). Short sprint cycles and the inspect-and-adapt process enabled team members to focus each sprint on only one queue rather than all of them. The Xerox marketing team was thrashing between sprints, but at least it was no longer thrashing within sprints. The focus during each sprint enabled the team to deliver increments across the three queues and prioritize those that were most important. Speed to market increased because the team didn’t get sidetracked before completing a project. Employee morale also increased, and customer satisfaction improved because customers got what they wanted sooner and better.

View Article
How to Use Scrum for Marketing

Article / Updated 07-20-2018

The world of marketing offers many opportunities for scrum. Within the waterfall project management style, it’s difficult to know whether the correct product is being built. Little to no user feedback has been sought along the way, so it’s anybody’s guess whether the product will be a big success. Here’s the catch: Organizations traditionally have a fixed annual marketing plan. Firms come out with a product with no clear idea whether it’ll be a success, yet marketing is often planned a year in advance. Additionally, markets change frequently. Given the speed of technological advances today, change is even more frequent now. Even for products that have been vetted and proved to be what the customer wants, companies might need to have their marketing angle changed along the way. Sometimes, customers don’t even know what they want until they get a product in their hands and use it. Despite the company’s best intentions, a mystery remains about how and what to market. Also, a firm may be dealing with millions of customers who have varied tastes and desires. Consider how many different styles and models of cars, clothes, and gadgets are sold in any one year. Each year, new models come out. For every buyer, marketers want to appease individual tastes. Although the future is impossible to predict, prediction is exactly what traditional marketing asks people to do. Marketing evolution Like most industries and business functions marketing has evolved. As Anna Kennedy, author of Business Development For Dummies (John Wiley & Sons, Inc.), told us, recent changes in marketing include the following: Prospects can self-serve information to the extent that two-thirds of the buyer’s journey happens before any formal engagement exists with the company. Marketing has shifted to being responsible for generating leads. Any chief marketing officer who isn’t will soon be out of a job. Technology allows marketers to assess where prospects are on the buyer’s journey and nurture them on a one-to-one basis. Social media provides a forum for conversations among brands and their influencers, prospects, and customers. Given those trends, how can scrum help marketers embrace the changes and develop agility in responding to this shifting world? Perhaps customers can research more on their own before engaging with a seller, which may seem to be a challenge from the seller’s point of view. A marketing scrum team that makes its marketing materials trackable, however, can use analytics to inspect and adapt its marketing to fit instantaneous feedback. In the past few years, marketing has become a primary consumer of Big Data. Being able to consolidate, analyze, and react to market data and moving trends makes scrum an ideal framework to use for marketing. Access to feedback (potential customers’ actions and interaction with marketing materials) enables a scrum team to respond and pivot more frequently and quickly than before. This feedback doesn’t require a customer to attend a sprint review. A product owner has access to this feedback in real time, thanks to marketing analytics technologies. Scrum and social media Marketers are responsible for managing the social media images of their brands. The speed at which posts become viral is astonishing, requiring immediate tactical response. An example of this dynamic played out during the 2016 U.S. presidential election. The campaigns used social media to track and respond to trends. A popular global charity recently faced a social media crisis and was able to respond effectively because of its investment in marketing expertise and rapid deployment strategies. A false public statement was made about the charity. Within hours, the rapidly growing false narrative endangered the charity’s ability to do good in the world it served and negatively affected its donations. Also, within hours, the charity’s brand managers began producing content to correct the misconceptions. Making a social media response wasn’t enough, though. The brand managers worked with all the organization’s sites and developers to make sure that the charity’s official position was clear and coming from the newly created content. Because the site developers were part of scrum teams, the new content became the highest priority and was deployed across the various platforms within days. If the changes had gone through a waterfall development and testing process, the story might have had an unhappy ending. Instead, the organization’s message of acceptance became clearer, and a negative event was turned into a positive outcome. This story repeats on an almost-daily basis for small businesses and Fortune 500 companies. Scrum in marketing Like annual budgeting plans, the annual marketing plan is a guess that is refined throughout the year as the organization learns and adapts. With scrum, marketing plans can be monthly, weekly, and even daily. After each iteration, inspection and adaptation are applied based on feedback from sprint reviews and retrospectives. Marketing plans can be adjusted, change can be thought of as progress, and customers can be marketed to in a way that speaks to their changing needs. New marketing strategies can be tested with actual users before they’re released to broader audiences. In the same vein, brands can be tested within sprints, saving huge costs because branding is developed together with customers rather than presented to them at the end.

View Article
How to Use Scrum to Achieve Fitness and Weight Goals

Article / Updated 07-20-2018

If fitness is a goal, using scrum to achieve your vision is one of the best ways to succeed. The struggle many people have with weight loss and fitness is the so-called yo-yo effect. Many people can start a fitness-and-diet regimen, but often after achieving the result they slowly but surely slide back to where they began. One reason why this happens is focus. The drawback is that in weight loss, this focus is often on an extreme, regimented situation. After you fall off the wagon, so to speak, you immediately begin unraveling your hard-earned work. Scrum allows for focus, but that focus is in small, measurable, and achievable segments. In other words, scrum is about taking steps toward your goal and achieving it sustainably, not just jumping on an extreme roller coaster and then burning out. Work through the roadmap to value, just as you would with any other major project. Following are some examples of applying the roadmap to value to weight loss and fitness, which you can tailor to your own vision and goals: Set a vision. You want to be back to your physical shape in college, which was 185 pounds, 32-inch waist, running a mile in 7 minutes, and bench-pressing 200 pounds. Create a product roadmap. Initial roadmap items may include things such as losing 10 pounds (you may have this item several times, because incremental improvement is the goal), running 3 miles without stopping, or lowering your blood pressure. Create a product backlog. This backlog might include making new recipes to cook, joining a gym, and having diet and exercise plans. Set your first release goal. In two months, you may want to have lost 3 pounds and be able to run 1 mile. Determine sprint lengths. A sprint may last a week, for example. Choose what to bring into the first sprint. You may decide to cut soda volume by 50 percent, eat dessert only three times a week, walk a mile three times a week, and do aerobic activity at least once a week. At the end of each sprint, review your progress toward the goals, update your product backlog with what you have learned throughout the sprint, and adapt the next steps to be in line with your release goal. Even after one sprint, you should use the sprint retrospective to inspect and adapt. Ask yourself the three sprint retrospective questions: What went well? You might say, “The cooking website I used has good recipes. I should keep using it. The mobile calorie tracking app is easy to use. my family is being really supportive.” What do I want to change? You might say, “I don’t like to do cardio on days I eat sweets. Nighttime workouts are hard to stick to. my lunch group gives me a hard time about my new health goals, which is discouraging.” How can I achieve that change? You might say, “I’ll establish set days of the week for sweets, which won’t be cardio days.” You might try morning workouts the next sprint to see whether it’s easier to be consistent at that time of day, cut lunch groups to once per week or not at all, or find a new lunch group. Run your next sprint incorporating both what you want to improve and the new items from your backlog. At the two-month mark, review the whole release to examine whether you’ve achieved your goal and to determine your next release goal. The key in using scrum to move forward on your weight-loss goal is recognizing that each step is a small but truly incremental step. At any time, not meeting your goal isn’t a failure, but an opportunity to find a new way to move forward. Even if you fall back on bad habits, getting back on track isn’t a massive commitment because the sprint cycles are so short. Consider a high-visibility task board for items that have the specific status of Done. To continue the preceding example, you could have three workout tasks, each of which gets moved over each time you complete your exercise. Giving yourself a visual depiction of completing also helps you identify opportunities (exercises that you enjoy) and bottlenecks (exercises that you avoid), and it helps you create ideas for your next sprint. An example of a visible and achievable plan which has brought success to many is a novice plan to participate in a half-marathon. Every week the Sunday goal is clear and incremental.

View Article
Scrum at Scale

Article / Updated 07-20-2018

This model facilitates alignment through roles with Scrum at Scale. The Scrum at Scale approach for scrum teams working together is a form of the scrum of scrums model for scrum masters and product owners, coordinating communication, impediment removal, priorities, requirement refinement, and planning. Using a scrum of scrums model for the scrum master and product owner enables daily synchronization among teams across programs. Scaling the scrum master Following the vertical slicing model of scrum of scrums, Scrum at Scale groups five scrum masters into a scrum master scrum of scrums. It mirrors the daily scrum for scrum teams to surface and remove impediments. With Scrum at Scale, narrowing the scope of a scrum of scrums to five scrum masters from each of five scrum teams limits the complexities for effective cross-team communication. A scrum master scrum of scrums coordinates release activities as the release team. When a project has more than 25 teams, an executive action team (EAT) supports a third-level scrum of scrums of scrums to remove the organizational impediments that the scrum of scrums groups can’t remove themselves. The EAT is the scrum of scrums for the entire agile organization. Scaling the product owner The product owners organize in a similar and aligned way through meta scrums. A first-level meta scrum brings five product owners together for meta scrum meetings to refine and plan priorities. Each meta scrum has a chief product owner (CPO) who oversees the bigger picture of the vision and product backlog and facilitates the coordination among product owners (POs) in the meta scrum. At the second- and third-level meta scrums, the grouping aligns with that of the scrum master scrum of scrums of scrums. An executive meta scrum (EMS) supports the meta scrums by owning and communicating the organizationwide vision, taking in technical priority feedback from the meta scrums and providing priority decisions for the program. A meta scrum should be a synchronization meeting that includes stakeholders. All stakeholders at the CPO level should be present to ensure alignment across the organization and support of the CPO’s product backlog prioritization during every sprint. Synchronizing in one hour a day In an hour or less per day, an organization can align priorities for the day and accomplish effective coordination of impediment removal. At 8:00 a.m., each scrum team holds its daily scrum. At 8:45 a.m., the scrum masters hold their scrum of scrums, and the product owners hold their level-one meta scrum meetings. At 9:00 a.m., scrum masters meet in scrum of scrums of scrums, and the product owners meet in level-two meta scrums. Finally, at 9:15 a.m., the scrum master scrum of scrums of scrums meets with the EAT, and the product owner meta scrum representatives meets with the EMS. Visit Scrum@Scale for a complete understanding and walk-through. The beauty of scrum is that it is designed to be flexible and to scale. Scrum at Scale is the simple way to maintain the autonomy of each scrum team within a wider program context, but it’s just one of many scaling models available.

View Article
Using the Scrum of Scrums Model

Article / Updated 07-20-2018

The scrum of scrums model facilitates effective integration, coordination, and collaboration among scrum teams by means of vertical slicing. You can use scrum of scrums to enable daily coordination among scrum teams. People on one team coordinate daily with people in the same roles on other teams regarding priorities, dependencies, and impediments that affect the broader program team. The scrum of scrums for each role is facilitated by the integration-level person for each role. Thorough integration and release efforts establish a consistent, regular scrum of scrums model. Each day, scrum teams hold their own daily scrums at approximately the same time, in separate locations. Following these daily scrums, scrum of scrums meetings occur. Product owner scrum of scrums Each day, following the scrum teams’ daily scrums, the product owners from each team meet with the integration team product owner for no longer than 15 minutes. They address the requirements being completed and make any adjustments based on the realities uncovered during daily scrums. Each product owner addresses the following: The business requirements that each product owner has accepted or rejected since the last product owners’ meeting The requirements that should be accepted by the next meeting Which requirements are impeded and need help from other teams to resolve (example: “John, we won’t be able to do requirement 123 until you complete requirement xyz from your current sprint backlog”) The integration team product owner makes the cross-team prioritization decisions necessary to ensure that the impediments are addressed during the daily scrum of scrums. Development team scrum of scrums Each day after the teams’ daily scrums, one development team representative from each scrum team attends the integration team’s daily scrum (which is the scrum of scrums for developers) and participates with the integration development team members in discussing the following: The team’s accomplishments since the last integration team scrum The team’s planned accomplishments between now and the next meeting Technical concerns with which the team needs help Technical decisions that the team has made How to prevent potential issues Consider rotating the development team members who attend the scrum of scrums (the integration team’s daily scrum), daily or for each sprint, to ensure that everyone stays tuned in to the integration efforts of the portfolio. Scrum master scrum of scrums The scrum masters from each scrum team also meet with the integration scrum team scrum master for no longer than 15 minutes to address the impediments that each team is dealing with. Each scrum master addresses the following: The individual team-level impediments resolved since the last time meeting with the integration team and how those impediments were resolved (in case other scrum masters run into the issue and can implement the solution) New impediments identified since the last meeting and which impediments the team needs help resolving Potential impediments that everyone should be aware of The integration team scrum master makes sure that escalated impediments are addressed after the daily scrum of scrums. A single product backlog exists in a vertical slicing model, and team attributes are assigned to those requirements as they’re broken down and move to the development scrum team. With this model, you can see the overall program and quickly filter down to your own team’s piece of that program.

View Article
How to Use Scrum to Plan Travel

Article / Updated 07-20-2018

Vacations are amazing opportunities for relaxation, exploration, and connection as a team…and for using scrum. Even travel for business can accomplish similar objectives. All too often, however, teams, families, and friends struggle with frustrations about financing and finding time for travel, as well as differing opinions on what to do and how to relax. Also, circumstances can change at any time with travel, both before and during the trip. Scrum is a major planning tool that is perfect for this kind of project. Think about it: You have an exact date and often a fixed budget; everything else is prioritization of the scope of the trip. Instead of one person calling all the shots and hoping that everyone likes the decisions made, working together as a team brings about engagement and satisfaction from everyone. For example, everyone would work together to come to a consensus on the following things: Create a vision plan of the trip or vacation. Set calendar dates. Know your budget. Create a vacation backlog of items from the stakeholders (such as family members and travel companions). Prioritize the backlog to achieve the best result possible. With family travel, every member of the family can and should participate in what an ideal vacation looks like to them. Keep in mind that if taking a trip becomes a family habit, this year’s vacation vision may not have the same ideal qualities as last year or next year, and that is the point. Reviewing the plan as a family provides insight on how to focus the budget. As in any scrum project, the vacation budget is the factor that you want to fix first. If family members are focused on activities that cost a higher value, the family can examine more budget-friendly places to do them. If a specific location is the highest priority as a family, the vacation can be planned around more budget-friendly options in an ideal location. Don’t be afraid to include children in discussing priorities according to budgeting. Although they may or may not have the responsibility of saving the money in the bank or setting the total budget, they should be involved in a trade-off decision as a team. You might say, “We can snorkel in Hawaii or go ziplining, but not both. Which would you like to do? It’s important to teach kids that setting financial priorities and sticking to a budget are major family life skills. Scrum thrives when everyone involved has ownership of decisions. Rather than a simple vote structure, in which each member only says yes or no, try fist of five, followed by dot voting. In fist of five, you show your support for an idea. Putting up one finger means total resistance to the idea, whereas displaying five fingers means it’s a great idea. For a decision to pass, everyone in the family should at least have three fingers up, meaning that even though they may not love it, they don’t hate it and are willing to support the decision. Using fist of five voting first allows narrowing a pool of options that no one in the family hates. You follow with dot voting for a final decision. In dot voting, all family members have five votes each. They put dots on the choice they want vote for, and they can put all dots on the same option or one on different options, indicating a preference for certain decisions. Items from the product backlog need to be executed by each family member. Reservations need to be set, but changes based on the reality of availability or price, or perhaps changes in expected weather, need to be addressed on an ongoing basis. This approach allows the major items with higher risk to be done early, with risk declining as the date gets closer. As dates for vacation grow closer, fewer large decisions will be in progress, and vacation planning will evolve into tasks that need to be accomplished before departure. Keep an eye on the calendar and establish short sprints to accomplish any remaining items. Break the product backlog items down so that items are easily moved to the Done column. Shopping for the appropriate clothing and also packing for the trip can’t be done in the same week without causing stress and chaos, for example. Place shopping in a sprint that’s long enough before the trip so that when it’s time to pack, items are available. In fact, in an earlier sprint, do a mock packing activity to help you identify things that you’ll need to shop for so that no surprises occur during the real packing the night before you leave.

View Article
Using Scrum for Big Data and Large-Scale Migration

Article / Updated 07-20-2018

Scrum can help manage the heaping mounds of data in the modern world. The sheer scale of data is astounding, and it’s only getting bigger. Trying to get your head around the size of Big Data is much like trying to picture a huge mathematical phenomenon such as the speed of the expanding universe. Big Data is so big that it goes beyond what most people can imagine. The following numbers are just a few examples of how big Big Data can be: Walmart conducts 1 million transactions per hour, feeding databases of more than 2.5 petabytes (about 167 times the size of the data in all the books in the Library of Congress). Facebook houses more than 40 billion photographs. eBay handles 50 petabytes of information every day. Decoding the human genome requires analyzing 3 billion base pairs. The first time, the process took ten years; now it takes one week. Cisco estimates that in 2016, the annual run rate for global Internet traffic was 1.2 zettabytes (ZB) per year or 96 exabytes (EB) per month. Annual global Internet traffic is expected to reach 3.3ZB per year, or 278EB per month, by 2021. The importance of Big Data can’t be overstated. Much of this data is highly personal and sensitive, and it can affect lives as well as bottom lines. The challenge is to gather, manage, and interpret data quickly, effectively, and correctly. Also, possible future uses for this data must be considered in the design of storage and retrieval processes. This data needs to become useful intelligence, not just data. A significant challenge is that 80 percent of this data is unstructured (such as emails, blogs, spreadsheets, text documents, images, video, voice, and search logs). This unstructured segment is growing faster than structured data. In other words, the majority of data is a huge mess. Data security and protecting privacy are more important than ever; at the same time, security is more difficult to ensure than ever. Traditional data management frameworks and processes aren’t capable of processing this quantity. Speed, flexibility, and instant feedback are needed. Six months is too long to hope that a new, untested system works. And chances are that in six months, the requirements will have changed, or a new gap will be identified. To deal with this tsunami of data, many firms and organizations are moving to the cloud. Many organizations have their own in-house clouds or virtualized environments. Data warehouse project management Data warehouse projects are traditionally thought to be difficult to manage. Although each segment or phase of the project may have a discernible beginning and end, the data warehouse itself is never finished; it’s continually growing and changing. A data warehouse isn’t some barbed-wire-fenced building on the outskirts of town. Rather, it’s a process or framework for handling data within a firm or organization, or a knowledge-based applications architecture that facilitates strategic and tactical decision-making. A further complexity is that continuous merger and acquisition activity creates enterprisewide data-integration issues. New assets and groups are acquired or spun off, and corresponding data and processes need to be managed. Maintaining diverse legacy applications that don’t integrate well can be costlier than conversion projects. Enterprise resource planning Enterprise resource planning (ERP) is a suite of integrated and dynamic software applications that organizations and corporations use to gather, manage, interpret, and integrate business processes, including planning, purchasing, manufacturing, inventory, marketing, sales, distribution, finance, and human resources. Implementing an ERP system usually means doing simultaneous development across various functional areas (such as marketing, sales, inventory, and purchasing) to conduct a specific business transaction. Implementation involves the design and configuration of many modules simultaneously. These modules, while being developed individually, must also be designed for cross-functional application. During design of the sales module, for example, careful consideration is given to both upstream and downstream processes. Think about how sales fits in the overall end-to-end process. You start with inventory, and subsequently, you need to be able to bill your orders. Therefore, the sales module must seamlessly integrate with your inventory module and your finance module (and your inventory module must integrate with your manufacturing and purchasing modules, which must integrate with your finance modules, and so on). Unfortunately, designing and building these individual modules traditionally takes years before the integrated testing phase begins. By this time, any gaps between modules require even more time to identify and fix. One small gap between sales and finance can result in months of extra work. Commonly, this fix may not integrate perfectly with another module somewhere else in the process. When everyone works in silos until the integrated testing phase, early detection of gaps and misfits is difficult. Traditionally, ERP providers handled this interdependency by locking in a specific development sequence. In fact, even parameters that weren’t going to be used needed to be configured in the order defined by the ERP provider. Now, with scaled scrum teams, you can do that customization in parallel, with each scrum team focusing on a specific functional area and using automated integration testing to ensure that the business transaction works across the modules. Following agile techniques allows integration testing to occur every day (from the first day) as opposed to months or years into the project. Although these modular interdependencies may seem to be liabilities, they make it easier to divide the work into chunks that fit separate scrum teams running synchronized sprints. Product backlog prioritization is set at program level, and incremental requirement changes are minimized. Sprint backlog prioritization also falls in line. You maintain the flexibility of scrum and dramatically accelerate the pace of implementation. ERP systems architecture is increasingly becoming oriented toward Software as a Service (SaaS), which means that monolith components are more modular than they used to be for client installations. Also, the tasks required to configure ERP systems are usually repetitive, so cadence and estimation can be established early and provide accurate sizing and timing predictions. To tackle more of an ERP implementation project at once to speed delivery, multiple teams may work on each business-function component at the same time. Effective use of scaled scrum enables multiple scrum teams to structure their definition of done to include integration, regression, performance, security, and regression testing at the sprint level rather than release. Alignment of definition of done is required because ERP systems are difficult to correct when conflicts are introduced into production. Teams learn to be disciplined in their definition of done. Srum works well with these types of projects when they focus on delivering business intelligence for the organization. Visual reports of data have a clear business-focused requirement for users. The work of preparing the data (such as aggregation and manipulation) makes up the tasks supporting the delivery of a report to the specified user (such as an executive or manager). Multiyear ERP implementations used to be common, but organizations can’t wait that long in today’s fast-paced market. Organizations need solutions faster and cheaper. Customers want to see a return on their investment as quickly as possible, with improved customer satisfaction. Iterating, inspecting, and adapting through scrum make shortened implementations possible.

View Article
page 1
page 2
page 3