Outsourcing has long been a tool for reducing costs. Scrum changes the economics of outsourcing and helps build a strong business case for keeping development at home. If you can achieve an eighty-fold improvement in velocity with corresponding quality, why would you spend a shipload of money to set up shop in a country where labor costs are just 70% lower? However, outsourcing is a reality of the global economy and companies are going to do it. So, if you’re going to do it, don’t suck.
Configure Your Team
Scrum has three different distribution models: isolated, overlapping and integrated. The variable in choosing the best model for your company is communication. How much will the remote teams need to coordinate with head quarters?
Isolated Teams: In this set-up, the remote team has all the same characteristics as a functional Scrum Team. It self-organizes, is self-managed with a Scrum Master and Product owner and has all the skill sets necessary to deliver product every Sprint. What it doesn’t have is a
relationship with the mother ship.
There are plenty of projects where an isolated model can be used but if any part of the organization needs to coordinate with the isolated team, this set-up could be a recipe for disaster. Isolating teams often creates impediments that result in constraints, delays and bugs.
Networked Cross Functional Teams: If project coordination is necessary, a better model is networked teams. In this configuration, individual teams still have their own responsibilities but they are networked through a Scrum of Scrums and are working from the same Backlog. This means that a Chief Product Owner is meeting as often as necessary with Scrum Masters from the remote teams. Also, all developers and designers should feel comfortable talking across teams to insure smooth integration.
Integrated Scrum Teams: The best distribution model for Scrum is to integrate individual team members in multiple locations. Integrated Scrum Teams work from the same Sprint and Product Backlog. The best practice is to have roughly half the team in one location and the other half in another so they are forced to work together across time zones and geography. It is also important to allow teams to form and gel like co-located teams. Bringing the two halves of the team together for the first few Sprints can facilitate this process.
Communicate
Distribution creates communication and coordination problems but well-designed Daily Scrum meetings and high-bandwidth tools can help close the communication gap. In the beginning bring the teams together for a few sprint so they can find a rhythm, videoconference a lot and use cloud-based tools that the entire organization knows how to operate.
Using the right configuration and tools can really improve productivity and quality of work. Scrum Inc. has helped a number of organizations achieve great results with distributed teams. However, we still recommend only outsourcing when you are looking for a skill set that isn’t readily available in your home market or if the company plans to operate in the market they are outsourcing to.
In many companies, agile software development is misunderstood and misreported, causing taxation increases, higher volatility in Profit and Loss (P&L) statements and manual tracking of programmer hours. One large company’s confused finance department expenses all agile software development and capitalizes waterfall development; projects in this company that go agile see their headcounts cut by 50%. This discourages projects from going agile.
Scrum’s production experiment framework can align well with the principles of financial reporting. In this article, the author explains the basics of capitalization and expensing, and offers a financial framework for capitalizing agile projects that can be understood by both accountants and agile teams.
Software development is an investment in the long-term future. Some software development projects are not long-term investments; it depends on whether the software remains an asset. Agilists should learn proper capitalization and teach their colleagues. Companies can usually save on taxes, hire more developers and create value more rapidly when they capitalize software development correctly.
Companies can gain tax advantages by capitalizing software development; by deferring costs they typically offset more taxable revenue and gain more interest income.
Corporate agilists need to help finance departments capitalize agile software development properly. ScrumMasters and agile department heads who understand capitalization and depreciation can generate millions in tax savings. Responsible agilists must work directly with their own corporate finance departments and auditors to craft acceptable capitalization processes.
Because recommended accounting practices ignore Agile, the article discusses how to classify costs as capital or operational expenses and gives guidance on how to make the transition from waterfall to Agile in a way that pleases management, accountants and auditors.
Making the case for agile capitalization will reduce your company’s tax burden, increase available funds for engineers, and make your auditors happy.
-- Vince Mills (Guest Blogger)
Next weekend the sponsor AngleHack and two student groups at UCLA are throwing a huge hackathon. LA Hacks will bring together students and alumni from Southern California’s premier technical schools in hopes of fostering a more cohesive start-up community. It seems that So Cal is struggling to create the same kind of start-up magic that Boston, New York City, and the San Francisco Bay area have achieved.
Hackathons are becoming more popular and are a Scrum Pattern for good reason. First, they bring people together in a creative and voluntary environment. This encourages people to bond over activities of their choice, helping team members to form stable relationships, which can lead to better team performance and collaboration.
Second, they produce interesting results. Facebook has been throwing hackathons since 2007. These all-night coding sessions have produced many valuable features for the social media giant including the Like Button, Timeline and Chat.
Third, if used strategically, Hackathons can slow development down a bit, allowing the organization to deal with constraints in other divisions.
But most importantly, they help developers merge their personal interests with their company’s financial interest. Hackathons give workers the opportunity to have a meaningful relationship with their employer by giving them the autonomy to master features and products that they enjoy while creating value for their company. Research shows again and again that mastery, autonomy and contributing to a community motivates people much more than higher salaries. Hackathons allow workers to help their company and colleagues, plus they aid in recruiting and retaining a motivated workforce.
Scrum Inc. recommends that companies throw hackathons regularly to free people up to be more creative and interactive. The value of hackathons is hard to quantify but one quick look at Google, which allows their employees to work on personal projects 20% of the time shows that when a company emphasizes creativity, awesome things happen.
-- Joel Riddle
There has been a lot of debate within the business world about the merits of time sheets. Some think tracking hours is an important metric while others feel that they are a waste of time. In the Scrum community there is a similar debate: should the team use points or hours when estimating backlog items?
Scrum Inc. recommends using points because hours are problematic on a number of levels. One difficulty when estimating in hours is that time measures input, and Scrum is concerned about output. We use a variety of examples to illustrate this, but two recent news headlines drive the points home, so to speak.
The first story surfaced several weeks ago and involves the big law firm, DLA Piper. In an effort to collect fees, the firm sued a client. The client refuted the billing. During the ensuing discovery process a number of incriminating e-mails surfaced revealed the lawyers on the project overstaffed and had the team performing gratuitous tasks.
“Now Vince has random people working full time on random research projects in standard ‘churn that bill, baby!’ mode... That bill shall know no limits.”
The second example involves healthcare. This week a case study released in The Journal of the American Medical Association showed how medical errors actually increased one hospital group’s bottom line. A mistake like forgetting to remove a gauze pad from a patient during surgery results in further interventions and longer hospital stays, forcing insurers to cover costs created by the hospital’s own mistakes.
Much of the outrage involving these stories focuses on ethical lapses. Let’s not forget bloating time sheets is not only is it unethical, it is poor business.
If the lawyers had instead focused on the quality of their work (the output in this case) and not billable hours, the client, rather than suing them, would have gladly paid the bill. The business value is in serving the client’s needs, not in wasteful or fabricated services. For the hospital group business value is derived from healing people and not from long hospital stays and unnecessary surgeries. This is why many efforts to reign in healthcare costs focus on quality of outcome rather than quantity of care given.
Both industries have business models that measure input (billable hours or number of services provided) rather than outcome and both professions are currently in crisis. Business probably won’t improve until they start to focus on quality of outcome rather than quantity of input.
Let’s not forget that time is finite, another problem with estimating in hours. After all, there is a reason lawyers and doctors sometimes work upwards of 100 hours a week. If their business models incentivized quality of outcome, doctors and lawyers could simply improve their efficiency, make the same amount of money working a lot less.
Work less! Estimate in points.
Learn more about how estimating in Points can vastly improve your Scrum at our April Webinar.
-- Joel Riddle
I’ve been reading Viktor Mayer-Schoenberger and Kenneth Cukier’s stimulating new book Big Data: A Revolution That Will Transform How We Live, Work and Think. The premise of the book is, now that civilization has the tools to both collect and analyze huge amounts data, correlation is far more telling than causality. Meaning, that when dealing with billions of data point rather than hundreds, knowing the what, rather than why is good enough.
One example the authors use frequently is how Google was able to comb its massive trove of search queries on common flu symptoms to discover where the 2009 H1N1 flu epidemic was spreading.
The CDC was doing the same thing using traditional sampling techniques. Google’s method was more accurate and in real-time (two weeks ahead of the CDC survey,) a huge advantage in controlling the outbreak. Thanks to Google, the CDC learned the what (ironically the where in this case) but not the why (which H1N1 carrier was the vector.) And that was good enough to help stem the spread of the virus.
Despite the messiness of Google’s data, it was far more effective because of its size. Big data analysis was made possible by easy access to Google’s search engine (3 billion searches a day,) large servers to store the information and clever algorithms to sort the data into something meaningful.
A corner stone of Scrum is its ability to measure work output i.e. Velocity. As the authors of Big Data point out, much of human knowledge is based on the ability to measure a given phenomenon. Once we can measure it, we can start to manipulate the input and determine if we’ve improved something by the resulting output. (Doing this again and again is continuous improvement, the impetus of Scrum.)
Because Scrum has made work measureable in more accurate ways than ever before, we could digitalize the metrics and create a huge searchable data set. For example, Microsoft has had over 3000 Scrum team members for several years. Imagine the possible insights if all that data were pooled and subjected to smart algorithms. Or, if companies that build and maintain virtual Scrum boards started storing all Sprint data from every client using their tools.
Perhaps we could see that adding a new team member results in a temporary drop in productivity but an overall long-term gain. Managers could hold off adding a team member before a key product release. Or perhaps the data might show that teams were more productive when working only 6 hours a day instead of eight. The possibilities are really exciting.
By using big data techniques, no longer would thought leaders in the Scrum community have to conduct case studies or theorize about what might create a process improvement. Nor would Scrum Masters need to tweak their process and wait until the end of the Sprint to see what the results were. Rather, they could simply query the data set and get an answer immediately.
Big Data is a big deal.
-- Joel Riddle
About a week ago we posted a blog on the pros and cons of positive and negative feedback and how people with different levels of expertise respond.
Scrum hangs its hat on feedback. Teams need it to improve their processes and Product Owners need it to help better define features in the backlog. The hope being that feedback from end users will help improve the technology and how people interact with it.
End user feedback really can make the difference between failure and success. And not just of an individual company or product but in an entire industry. The Times recently posted a blog that illustrated this perfectly.
The post profiled the rise and disappointment of what has become known as the mHealth industry. The m stands for mobile. About a decade ago, as mobile phones were starting to handle more data and provide Internet connectivity, a lot of public health officials in Africa had high expectations that the new technology would create a two-way conversation between health care providers and patients in remote villages.
Examples include sending pre-natal advice to expectant mothers via voice mail, reminding HIV patients to take their medication by text and tracking disease as it travels through the desolate landscape.
Pilot programs bloomed across the content. In fact so many projects were established that both Uganda and South Africa banned any new programs.
Unfortunately the industry seems to have flopped. Many projects worked at first but weren’t scalable. Often there were compatibility issues between local and national cell networks. Some programs weren’t able to get off the ground because end users only knew how to use their devices to make simple phone calls. Another pilot failed because it didn’t take into account that villagers share their phones so when the relevant health information was sent, the mobile device was next door.
It seems none of the pilot programs got the feedback they needed.
However, there was one bright spot:
One of the few projects that has been successful on a large scale is Mwana. . . . It was . . . developed with its users – Mwana’s designers moved for a month to the town of Mansa, Zambia . . . and built the system alongside local community health workers. This co-creation may be even more important when an mHealth project works with patients instead of health workers. “We spend tons of time under the mango tree in Ghana working on refining the messages,” said Tim Wood, the director of mobile health innovation at the Grameen Foundation . . . “It took many, many rounds of going back – even now we’re looking at how people are using messages and refining them.”
Feedback made all the difference. If more mHealth projects had used this common Scrum practice, mHealth may have met its high expectations, and who knows, saved some lives. Get feedback. It can save lives.
-- Joel Riddle
This month, Scrum Inc.’s monthly webinar focuses on fundamentals and correcting bad Scrum habits. While a majority of us feel like we get the basics right, Scrum Inc. surveys and independent polls find that while most Teams understand the basics, many skip at least one key practice.
Most commonly, respondents indicate that their teams don’t calculate Velocity. Without Velocity, there is no way to measure improvement, have transparency and visibility into your process or properly plan a Sprint or fix a release date.
How it Works
Break work into small tasks. Give these tasks, called User Stories, a point value by estimating their relative sizes. (Relative size is important because studies show that humans are incredibly poor at estimating jobs in hours.)
During Sprint Planning, the Scrum Master plays dealer in a game of planning poker. The Scrum Master starts the game by taking a User Story and having all members of Team chose a card with a number they believe relates the relative size of the task. The Scrum Master counts to three and all Team members reveal their cards simultaneously. The Team members with the lowest and highest cards debate the reasons for their choices and then the team plays another round. The process repeats until a consensus is reached. The Team continues the game until every task has a point value.
During the Sprint, as each task is moved to done, the Scrum Master can plot the points over the length of the Sprint. At the end of the Sprint all the points added together is the Velocity.
As the Team completes more and more Sprints, the Scrum Master can compare how much the Team has improved. Although velocity tends to oscillate over time, as a rule it should trend upwards about 10% per Sprint.
Remember, just because the team has gotten better at any given task, the point value you should remain the same. If the Team starts to estimate tasks at lower values because they have incurred substantially more experience and the tasks seem easier, Velocity will never seem to improve. This is one big reason why estimating in hours doesn’t work.
Teams shouldn’t obsess about how many points something is worth. Estimating points is just an exercise to help quickly evaluate relative effort. The important thing is that you are consistent and that the entire team has a common understanding of their system for sizing.
Whether you are new to Scrum or a long time practitioner, getting the basics right will definitely improve your Velocity. On Tuesday, March 26th we will be exploring Velocity, Retrospectives, Backlog Grooming and the rest of the Scrum Fundamentals. Please join us.
-- Joel Riddle & Christine Hegarty
There was an interesting radio piece on American Public Media’s Market Place the other day. Host Kai Ryssdal talked with Stephan J. Dubnar of Freakonomics fame about what the latestacademic research on feedback tells us.
Here’show it breaks down: to get people to commit, positive feedback is shown to be really helpful. So if you have a new Team member,the Team and the Scrum Master should see substantial improvement in that new member’s commitment by focusing comments on what that team member is doing well.
However, once that Team member is fully on board, a Scrum Master would see diminishing returns from continued positive feedback. To get increased performance at this point, critical feedback is the only game in town. Basically, if you want improvement out of a committed Team, you have to point out what they are doing wrong and help them find a better way to complete their tasks.
The other interesting finding is that the more expertise someone has, the more they tend to filter out positive feedback. So if you have a great coder with 20 years experience, giving him or her props isn’t going to do much.
You can read all the research the story was based on here.
-- Joel Riddle
The Certified Scrum Master class attendees were off and running on a self-organization exercise. The drill was simple: plan, build, and test as many paper airplanes as you can in 3 minutes.
I was busily preparing for the next class module when I gradually became aware of what was transpiring: “Twenty-four”, “Twenty-five”, “Twenty-six”… like the coxswain of an Olympic crew team, the Product Owner called out the production count. With heartbeat regularity, every two seconds another paper airplane floated gracefully across the room, nosed into the exact same spot on the projection screen and settled gently into a tidy pile on the floor.
Their product design? Standard. Their manufacturing process? Pretty conventional. But for 180 seconds in Munich, aptly-named “Team Front” achieved the perfect state of Flow that we wish for all our Scrum teams.
 |
|
Congratulations to “Team Front” on their new world record! Pictured (from left to right) are: Oliver Heerdegen, Chris Holland, Todor Ganebovsky, Karla Korb, Thomas Bohne, Katrin Sulzbacher, Norbert Toth-Gati, and Klaus-Rüdiger Hase.
|
Flow is that transcendent state where, with very little explicit communication, team members mesh into perfect formation, each contributing equally and to their utmost toward a singularly shared goal. Eight individuals who had been complete strangers only hours before were working in complete unison as if they had trained together for years.
When the clock stopped, the tidy pile of planes had reached 32…shattering the previous Scrum record of 28.
We spend so much of our time in the Scrum community focused on the nuances of running Scrum: How do I manage teams across multiple locations? How do I balance a sustainable pace with Velocity? But sometimes it is important to take a step back and just appreciate the simple joy of achieving Flow.
Wanna take a crack at breaking the record? Click here to take course with Jeff.
Every week starts with a family meeting. Kids and parents self-organize and self-manage (kids even help decide on their own incentives and punishments) and every week they have a retrospective to determine what they can do better next Sprint. Turns out that kids think their parent’s stress levels can improve.
Scrum: savior of the modern American family? Watch and decide for yourself.
You can listen to an NPR review and an interview with Bruce Feiler here and here.