Software Quality Attributes
Published February 8th, 2011 Under Quotes | Leave a Comment
I am currently reading the excellent book “Managing Software Debt – Building for Inevitable Change” written by Chris Sterling. The book deals with the debt that created at every stage of software development. In its introduction, the book offers an interesting list of the software quality attributes. Even if the author does not claim for completeness, this list is a very good starting point for your software improvement initiatives. Here is the list of software quality attributes proposed by Chris Sterling: Read more
Project Management and Project Manager Definitions
Published December 14th, 2010 Under Quotes | Leave a Comment
“One way to simply and intuitively define project management is that it is a set of tools, templates, and processes designed to answer the following six questions:
1. What business situation is being addressed by this project?
2. What do you need to do?
3. What will you do?
4. How will you do it?
5. How will you know you did it?
6. How well did you do?”
“What the client wants is probably not what the client needs. The project manager’s job is to make clients want what they need”
Source: “Adaptative Project Framework, Managing Complexity in the Face of Uncertainty”, Robert K. Wysocki, Addison-Wesley, 355 pages, ISBN 978-0-321-52561-1
Agile Coach Failure Modes
Published November 1st, 2010 Under Quotes | 2 Comments
I have just finished reading the book “Coaching Agile Teams” by Lyssa Adkins. This book is full of excellent content but I just want to share some of her honest thoughts on coach failures with you. Read more
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, 463 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
« go back — keep looking »