Nine Questions for a Good Scrum Team Structure
Published August 24th, 2010 Under Quotes | Leave a Comment
In his book “Succeeding with Agile”, Mike Cohn present nine questions that you should ask for a current or proposed team. Questions should be asked iteratively… until you answer “yes” to each. Here are the questions:
* Does the structure accentuate the strengths, shore up the weaknesses, and support the motivations of the team members?
* Does the structure minimize the number of people required to be on two teams (and avoid having anyone on three)?
* Does the structure maximize the amount of time that teams will remain together?
* Are component teams used only in limited and easily justifiable cases?
* Will you be able to feed most teams with two pizzas?
* Does the structure minimize the number of communication paths between teams?
* Does the structure encourage teams to communicate who wouldn’t otherwise do so?
* Does the design support a clear understanding of accountability?
* Did team members have input into the design of the team?
Besides the cultural bias (in Italy, one pizza will usually feed one person but it might be different in the USA…), you could use these questions for every project that you are currently running or plan to run.
Reference: “Succeeding with Agile”, Mike Cohn, Addison-Wesley, 262 pages, IBSN 978-0-321-57936-2
Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk
Agile Software Development Adoption Obstacles
Published May 31st, 2010 Under Quotes | Leave a Comment
I have just started reading the book “Succeeding with Agile” by Mike Cohn. Here are some quotes from the initial pages that deal with the difficulties of transitioning to Agile.
“I’ve personally witnessed several failed agile adoptions that could have been prevented. The first was in a company that had spent more than a million dollars on its transition effort. Executives brought in outside trainers and coaches and hired five people into an “Agile Office” to which new Scrum teams could turn for advice. The company’s failure was the result of thinking that the implications of adopting Scrum would be restricted to only the development organization. The executives who initiated this transition thought that educating and supporting developers would be sufficient. They failed to consider how Scrum would touch the work of salespeople, the marketing group, and even the finance department. Without changes to these areas, organizational gravity pulled the company back where it had started.” Read more
Lean: Results are not the Point
Published March 3rd, 2010 Under Quotes | Leave a Comment
I have just finished reading the great book “Leading Lean Software Development” by Mary and Tom Poppendieck and I wanted to share with you two quotes excerpted from it.
[...] I started a conversation with the question that had been bothering me: “How do you reconcile the lean view that tests are waste with the need for tests in software development?” Mary’s immediate response: “Unit tests are what let you stop the line.” (quoted from the Foreword by Dottie Acton)
In our experience, the most common causes of policy-driven waste in software development are:
1. Complexity
2. Economies of scale
3. Separating decision making from work
4. Wishful thinking
5. Technical debt
The strategy of designing the effort to fit the constraints, rather than computing the constraints form the design, is absolutely the most effective way to achieve reliable delivery.
Reference: “Leading Lean Software Development – Results are not the Point”, Mary and Tom Poppendieck, Addison-Wesley, 278 pages, IBSN 978-0-321-62070-5
It could seem very provocative to propose an approach based on the slogan ” Results are not the Point”. In their book, the Poppendieck defend the idea that there are many good managers around that could foster the adoption of lean practices. From my personal experience, most of the managers thinking “results are not the point” do this because they think “costs are the most important point”. This is why I think that companies that adopt agile or lean approaches want results…. and quickly! We could all wish that more managers and developers take the time to read book like this one, but even if it was the case, I am very dubious that many companies will really abandon their “command and control” and “short term vision” culture.
Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk
How Do You Refactor Untested Code?
Published February 9th, 2010 Under Quotes | 3 Comments
I am currently reading the excellent “Debug It!” book written by Paul Butcher and I wanted to share with you some of the little gems that I have found in it.
“Bug fixing often uncovers opportunities for refactoring. The very fact that you’re working with code that contains a bug indicates that there is a chance that it could be clearer or better structured.”
“As a rule of thumb, for every user who tells you about a problem, there will be between 10 and 100 other users who experienced the same problem and didn’t think to get in touch.”
“Once you start to get on top of your quality issues, you’re going to want to start refactoring the old, crufty, untested code. And you should – the point of exercise is to clean up problems, and refactoring is a key element of that process. Remember, however, that refactoring crucially depends upon the support of an extensive suite of automated tests. Without tests, you’re not refactoring. You’re hacking. So, how do you refactor untested code? You don’t. The first thing you do is to write the tests.”
Source: “Debug It!”, Paul Butcher, Pragmatic Bookshelf, 214 pages
Changing Perspectives
Published January 26th, 2010 Under Quotes | Leave a Comment
“In the early days of our industry, programmers wrote in assembly code, selecting registers in which to place variables and managing memory explicitly. If we had magically provided these programmers with a Smalltalk compiler, they might have asked, “How does this help us select registers? How do we allocate memory?” They might have concluded, “”We don’t want no stinkin’ Smalltalk!”
Old and new programmers are still writing programs, but the technology to achieve the goal has changed. When a new technology is sufficiently different, you can’t evaluate it in terms of the old technology.”
Source: Stephen J. Mellor, Letters section, IEEE Software, March/April 2004
Sometimes new ways of doing things come in our life and it might be difficult to adapt. If you are used to drive a car and you take a train, you don’t ask how you are going to “turn left”: the train just follows the tracks. However, you have now to go to a station, buy a ticket, look at timetable, etc… This could be the same thing with some of the software development approaches that have recently become popular.
Functional programming, domain driven design or frameworks that favors convention over configuration like Ruby on Rails can offer a new perspective about what you have to do to develop software. If you have the time (and the energy) I would like to strongly encourage you inform you about these approaches or even better to try them. Ironically, the above quotation was in reply of a letter about UML and Model Driven Architecture. Six years after, there is not a lot of people still caring about this way of developing software, as it is for Smalltalk or assembly languages.
Resources
* Wikipedia.
* Articles
Functional programming – HaskellWiki
Functional Programming For The Rest of Us
An Introduction to Web Development Using the Ruby on Rails Framework
An Introduction To Domain-Driven Design
An Introduction to Domain Driven Design
keep looking »