Thursday, July 29, 2010

Haegwan Kim interviews Jeff Sutherland


 Law of Success 2.0

To Make The World A Better Place Where All Human Beings Can Achieve Success
For first part of the interview click here ...


Conclusion:
HK: Time moves on, so I want to have few questions about success. What is the definition of your success as an engineer?

JS: Well my definition of success has to do with making the world a better place. If I can make a contribution so that people are happier, better motivated, more successful then I’m successful. Scrum’s goal was based on work I have done with micro-enterprise lending. Professor Yunus in Bangladesh came up with a program where he’d give really poor people a little bit of money and they’d create their own business plans and then execute them. They eventually could boot strap themselves. Scrum was designed to do the same thing. Let’s give the team a little bit of capability and then let them figure out how to go really fast. So Scrum was designed to take development teams who were always late and under pressure and turn them into teams who were having a lot of fun, a lot of energy, building great products. And so the goal was actually to release the teams from their chains. They were under pressure from management; they were getting beat up all the time by management. I said to them, “You could live a better life. You could have a life where you’re innovating, where you’re having fun, where it’s a joy to come into work.” You can do it in a way that you can build so much software, you’d have five to ten times more software so you could do a lot more with a lot less work. It’s a much better life, and it empowers the people to take the initiative. That thrust is relevant to work, it’s relevant to politics, it’s relevant to the health and wellbeing of the people. That’s success. It’s to help people be great, that’s my goal. And Scrum is doing that for people. It’s amazing what’s happened. It’s a huge surprise to me. It works in every culture, it works in every country, and it works in every company. It’s just an amazing thing. And people have taken it and they’ve taken it there themselves. So it’s not me, it’s them doing it. So my success is that I’ve helped facilitate making that possible.

HK: Just mind-blowing. So your success is not about money.

JS: Here’s the secret and the core of real success. It comes from the heart, it comes from giving, it comes from expansively helping others. If you do that well you will have plenty of money. I don’t have any problems with money. I don’t have more money than Bill Gates, but I have enough money. Scrum has given me that. People all over the world want me to come and talk about Scrum everywhere all the time. Every time I need some money I just go someplace. People always want to hear about it.

HK: Can you give me your advice to be successful in general?

JS: Things today are built by teams. Obviously individuals are still a direct source of inspiration and innovation. But individuals can’t even execute really good ideas without building a really good team around them. So people need to learn to work with teams, that’s what Scrum is all about. They need to figure out how they can actually help people. We learned that in Silicon Valley. I spent some years working there and that’s affected Scrum as well. How do those companies in Silicon Valley get started? It’s always by a small team. It’s always with a great idea. It’s a world-changing idea. They are having fun at Google, and they have more money than they know what to do with. But it wasn’t for going after the money; it was actually a world changing idea and creating an environment where people could have a lot of fun executing it.

HK: Thank you so much for your time.

Thursday, July 22, 2010

Estimation Accuracy: Extraneous information and anchoring effects


The Simula Lab in Norway has supported research on estimation error. Stein Grimstad's Ph.D. thesis on this topic has spawned several papers and references are provided below from the IEEE Digital Library in response to requests for sources.

In particular, irrelevant information in a specification will lead to larger estimates and telegraphing an expected size of an estimate will skew results (anchoring effect).


Avoiding Irrelevant and Misleading Information When Estimating Development Effort
Found in: IEEE Software
By Magne Jorgensen , Stein Grimstad
Issue Date:May 2008
pp. 78-83
Software development effort estimates are reported to be highly inaccurate and systematically overly optimistic. Empirical evidence suggests that this problem is caused to some extent by the influence of irrelevant and misleading information—for exam...

The Impact of Irrelevant Information on Estimates of Software Development Effort
Found in: 2007 Australian Software Engineering Conference (ASWEC'07)
By Stein Grimstad , Magne Jorgensen
Issue Date:April 2007
pp. 359-368
Combination of expert opinion is frequently used to

A framework for the analysis of software cost estimation accuracy
Found in: Proceedings of the 2006 ACM/IEEE international symposium on International symposium on empirical software engineering (ISESE '06)
By Magne Jørgensen,Stein Grimstad
Issue Date:September 2006
pp. 58-65
Many software companies track and analyze project performance by measuring cost estimation accuracy. A high estimation error is frequently interpreted as poor estimation skills. This is not necessarily a correct interpretation.

The Clients' Impact on Effort Estimation Accuracy in Software Development Projects
Found in: 11th IEEE International Software Metrics Symposium (METRICS'05)
By Stein Grimstad , Magne Jorgensen , Kjetil Molokken-Ostvold
Issue Date:September 2005
pp. 3
This paper focuses on the clients' impact on estimation accuracy in software development projects. Client related factors contributing to effort overruns as well as factors preventing overruns are investigated. Based on a literature review and a survey of ...

Understanding of Estimation Accuracy in Software Development Projects
Found in: 11th IEEE International Software Metrics Symposium (METRICS'05)
By Stein Grimstad
Issue Date:September 2005
pp. 42

Thursday, July 08, 2010

HICSS 2011 Agile Papers - Need Reviewers!


We need good reviewer for a series of Agile papers submitted to the HICSS Conference. Reviews are due by 14 August. If you are interested, send email to jeff@scruminc.com and let me know which papers you would like to review. You must set up an account for yourself at the HICSS submission site before emailing me: https://precisionconference.com/~hicss/ 

Agile Development at ABC – What Went Wrong?
Abstract: Agile development methods continue to enjoy widespread use, with more and more companies transitioning to agile methods. Current literature suggests that most of those companies are successful in making the transition, but others are not so successful. This paper examines one such company – referred to within as the ‘ABC Company’ to maintain their privacy – and analyzes and discusses their struggles with implementing agile methods. In short, it appears that lack of firm leadership commitment to agile, absence of a clearly defined customer to provide clearly defined requirements or push for additional software capabilities, failure to provide adequate initial or ongoing training and support to the organization as a whole, and underestimating the change management requirements were contributing factors to ABC’s struggles with implementing agile methods. These conclusions were reached based on a series of interviews with company employees, review of the relevant literature, and comparisons with other similar case studies.

Management guidelines for Scrum agile software development process
Abstract: This paper explores critical issues and challenges that might arise in Scrum agile software development processes and provides management guidelines to help organizations avoid and overcome barriers in adopting the Scrum method as a future software development method. A qualitative research method design was used to capture the knowledge of practitioners and scrutinize the Scrum software development process in its natural settings. An in-depth case study was conducted in two organizations where the Scrum method was fully integrated in every aspect of two organizations’ software development processes. One organization provides large-scale and mission-critical applications and the other provides small- and medium-scale applications. Differences between two organizations provided useful contrasts for the data analysis.

Integrating Software Quality with Earned Value Management in Projects, Programs and Portfolio Management using AgileEVM Techniques
Abstract: Agile practices integrate software quality attributes into the development process. Earned Value Management (EVM) includes cost management while Agile processes do not. Integrating Agile and EVM provides a more comprehensive management capability for software development. Operating in an environment without integrating software quality puts entire portfolios and programs at high risk. Schedule slips from quality problems, such as late integration often become known when it is too late to react and resolve without significant impact.
AgileEVM is a robust integration of Agile and traditional earned value that integrates quality with cost, scope and schedule management. Because each item in a Scrum product backlog is sorted according to highest value, claiming done with established quality levels enables AgileEVM to truly measure outputs of value.
AgileEVM supports all 32 EVMS guidelines directly or relies on external systems like financial accounting. AgileEVM scales and can integrate multiple control accounts, including the portfolio level.

An Educational Testbed for the Computational Analysis of Collaboration in Early Stages of Software Development Processes
Abstract: Agile software development processes are widely adopted in software engineering projects. Their low organizational overhead and iterative nature make them ideal choices for small development teams. The application of those methods in software projects that require collaboration between multiple sub-teams, however, is a challenging task. Especially the initial phases of such projects are crucial for project success and a problem-free inception period generates a basis for efficient development later in the process.
We introduce a testbed that allows analyzing the collaboration processes during those early stages of software development within a low-risk, educational environment. Participants of a software engineering lecture form development teams of considerable size and develop real-life applications within a realistic, yet controlled, environment. By combining manual observations with the computational analysis of digital collaboration artifacts we are able to gain insights into distinctive patterns of collaboration activity and reason about their triggers within the process setup.

Supporting Scaling Agile with Portfolio Management: Case Paf.com
Abstract: This paper is a descriptive case study of how one company, Paf.com, introduced portfolio management to help support scaling agile software development. Paf.com had experienced problems with long time-to-market due to thrashing, which was caused by frequently changing priorities due to an ad-hoc prioritization process. Also, there was lack of visibility into projects entering and progressing in the development pipeline. No structured way of starting projects was enforced company-wide, and too many parallel projects got started. As a result of introducing a structured portfolio management process, the number of ongoing projects has dramatically reduced, from over 200 to 30. Listing all projects in priority order in the Paf.com backlog provides visibility into what is currently ongoing. The portfolio follow-up function provides progress data on the projects in the Paf.com backlog, which helps managers make more informed decisions, considering the whole portfolio.
Embracing or Constraining Change: An Exploration of Methodologies for Maintaining Software
Abstract: This study uses a grounded theory research method to explore how IT professionals define and select a methodology to maintain existing software. The findings contribute to a better understanding of how standard methodologies are applied in software practice and the critical factors used by professionals when choosing an appropriate methodology for software maintenance activities. This research underscores the need for incorporating the full software life cycle in information systems development research as well as highlighting the need for more comprehensive education in software methodologies.

Improving Trust in Information Systems Development Using Agile and Formal Practice
Abstract: This paper posits that Implementing a balanced portfolio of Agile and formal project practices will strongly support the cognitive trust-building processes necessary to promote good development and O&M decision making for information systems, programs, and projects. The mechanisms enhance decision making by moderating the potentially negative effects of executive, managerial, development team, and end user distrust. Research has shown that establishing and maintaining an environment of trust can be improved by using effective trust supporting and trust building practices in appropriate situations.
This paper argues for employing a set of trust building practices and processes from both formal and Agile methodologies that varies depending upon three factors: the need to develop a new or full replacement system, the experience of the user/purchasing organization with the development team, and the O&M status/working capabilities of the solution in use by the target organization.

Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft
Abstract: Scrum teams use lightweight metrics like story points, the burndown chart, and team velocity. The inventor of Scrum was a fighter pilot and used the Scrum burndown chart to help teams land a sprint properly. Recent work with hyperproductive teams shows they are like modern jet fighters in multiple ways. They have two engines that produce velocity--alignment of the team and team spirit. A hyperproductive team uses careful measurement of aspects of performance and prioritization to make slight adjustments in flight. Just as modern jet fighters are inherently unstable without computers to fine tune flight parameters, hyperproductive teams require daily adjustment based on key metrics. Careful attention to the metrics described--velocity, work capacity, focus factor, percentage of found work, percentage of adopted work, original commitment, final commitment, commitment accuracy, estimate accuracy, and target value contribution increase can develop and sustain hyperproductive teams.

Measuring the Impact of Scrum on Product Development at Adobe Systems
Abstract: Over the past several years scrum has grown to become the most commonly used product development method at Adobe Systems. Large desktop software products like Premiere Pro and After Effects, Platform tools like Adobe AIR, and Software as a Service products like Omniture SiteCatalyst are using scrum to become more effective at delivering the right solutions to customers with higher quality. This paper discusses the methods used to measure the impact scrum has had on these teams.

Towards the Understanding of Effective Agile Practices in Distributed Software Development: An Empirical Study
Abstract: Although the application of agile approaches in distributed development is expected to be beneficial, the mechanics of combining agile approaches with distributed development is not well understood. There has been little research to identify which agile practices are identified as effective in different distributed software development environments. This paper investigates effective agile development and management practices for distributed software development project success. We report on our initial efforts to identify to what extent these agile practices are related to project success in co-located, not colocated or in offshore/ outsourcing software development. Our analysis into effective agile practices agrees with existing experience reports although some agile practices surprisingly did not appear to be as effective as expected. We conclude with future research directions.




-----------------
HICSS-44 PAPERS FOR REVIEW - reviews due 14 Aug 2010
January 4-7, 2011
The Grand Hyatt Kauai Resort and Spa
Kaloa, Kauai, Hawaii

HICSS-44 offers a unique, highly interactive and professionally challenging environment that attendees find "very helpful -- lots of different perspectives and ideas as a result of discussion." HICSS sessions are comprised primarily of refereed paper presentations; the conference does not host vendor presentations. All papers are peer reviewed and accepted papers are published in the IEEE Digital Library.

Track: Software Technology
Minitrack: Agile Software Development: Lean, Distributed, and Scalable
Co-Chairs: Jeff Sutherland and Gabrielle Benefield

Agile software development processes have been influenced by best practices in Japanese industry, particularly by lean product development principles implemented at companies like Honda and Toyota, and knowledge management strategies developed by Takeuchi and Nonaka, now at the Hitotsubashi Business School in Japan, and Peter Senge at MIT.

This minitrack will focus on advancing the state of the art or presenting innovative ideas related to agile methods, individual practices and tools. Accepted papers will potentially enrich the body of knowledge and influence the framework of thought in the field by investigating Agile methods in a rigorous fashion.

The track is open to research papers on multiple aspects of agile methods, particularly those that bring best practices in knowledge management and lean development to scalable, distributed, and outsourced Scrum, eXtreme Programming (XP), and other agile practices.

Papers of interest include these topics:

*Research on existing or new methodologies and approaches: informal modeling techniques and practices, adapting/trimming existing methods, and new product/project planning techniques.

*Research on existing or new techniques or practices: pairing, war-rooms, test-first design, paper-based prototyping, early acceptance test driven development, exploratory testing, refactoring, or others.

*Research on special topics or tools: configuration and resource management, testing, project steering, user involvement, design for agility, virtual teams or others.

*Research on integrating ideas from other fields, e.g. interaction design, requirements engineering, cognitive science, organizational psychology, usability testing, software security, into agile processes.

*Research studies of development teams using ethnographic or social research techniques.

*Research on agile software engineering economics.

*Quantitative and qualitative studies of agile methods, practices, and tools.

*Research on agile compliance and cost benefits within CMMI, ISO 9000, and FDA certified development projects.

Papers are particularly relevant when agile processes are shown to produce quantitative and qualitative benefits across multiple implementations.

Jeff Sutherland
Scrum Training Institute
Boston, MA USA
jeff@scruminc.com
+1 617 606-3652

Gabrielle Benefield
Scrum Training Institute
London, UK
gbenefield@gmail.com