Agile Project Management Insights
Published December 16th, 2009 Under Quotes | 1 Comment
I am currently reading the book “Agile Project Management” from Jim Highsmith. I will publish a review later on this blog, but in the meantime I would like to share some of the interesting quotes that I have found in the book. I am sure they will make sense to software project managers… and developers ;o)
About adding value
“When Ward asked Toyota’s American engineering and managers how much time they spend adding value (i.e., actually doing engineering work), their response averages 80%. The same question asked of engineers and managers at American automobile companies averages 20%. How can you compete with companies that are getting four times as much value-adding work from their development engineers.” (referenced from “Product Development for the Lean Enterprise”, Michael Kennedy, the Oaklea Press, 2003)
About technical knowledge
“As a software development consultant, I’ve never encountered a successful software company (although my sample size is limited) in which the team and project leaders were not technically savvy. [...] Championing technical excellence requires that the project leader, and team members in general, understand what technical excellence means – in the product, the technology, and in the skills of the people doing the work.”
About leading or managing
“Agile leaders lead teams, non-agile ones manage tasks. How many project managers spend hours detailing tasks into Microsoft Project and then spend more hours ticking off task completions? Unfortunately, many project managers like this task oriented-approach because it is concrete, definable, and completion seems finite. Leading teams, on the other hand, seems fuzzy, messy, un-definable, and never complete. So naturally some people gravitate to the easier – managing tasks.”
About self-organization and anarchy
“Self-organizing teams are at the core of the agile management, but the concepts have become corrupted – and counterproductive – in parts of the agile community. Although self-organizing is a good term, it has, unfortunately, contingent within the agile community who encourage an anarchistic management style and have latched onto the term self-organizing because it sounds better than anarchy. As larger and larger organizations are implementing agile methods and practices, the core of what it means to be agile – an empowering organizational culture – may be lost because large organizations will reject the cultural piece of agile.”
About the value of a plan
“When we “plan”, we expect the actual project result to conform to that plan, and then deviations become team mistakes or sign of the team’s failure to work enough. When we “speculate”, we take the opposite perspective – it’s the plan we suspect was wrong. The plan, or speculation, is a piece of information, but it is only one piece that we will examine to determine our course of action in the next iteration.”
About software malleability
“Software is the most malleable product. Companies need to use this characteristics to their competitive advantage, and sticking to traditional waterfall development negates this advantage.”
Reference: “Agile Project Management”, Jim Highsmith, Addison-Wesley, Second Edition
Finding a Good Agile Coach
Published September 17th, 2009 Under Quotes | Leave a Comment
“Agile is all about teams working together to produce great software. As an Agile coach, you can help your team go from first steps to running with Agile to unleashing their full Agile potential.”
“The art of Agile coaching is understanding the situation, the values underlying Agile software development, and how the two can combine. As an Agile coach, you don’t need to have all the answers; it takes time and a few experiments to hit on the right approach. We’ve worked with teams who’ve come up with great solutions, and we learn from every team we work with.”
“Don’t expect to get recognition for your work as an Agile coach. It’s a supporting role rather than one that delivers direct benefits. A good coach gives credit to the team. When you work on an idea with Frank, it’s Frank’s idea if it succeeds, and if it doesn’t, then commiserate together.”
Some good points to keep in mind the next time you will be looking for some help to transition to Agile.
Source: “Agile Coaching”, Rachel Davies and Liz Sedley, Pragmatic Bookshelf, 250 pages
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
Why Tester Won’t Like Agile
Published September 3rd, 2009 Under Quotes | 3 Comments
Following my thinking about the fact that functional testing was the dividing barrier between specialized developer and tester roles, I found in the book “Agile Testing” by Lisa Crispin and Janet Gregory an excellent list of fears that QA teams could express against agile adoption:
“Testers cling to the concept of an independent QA team for many reasons, but the main reason is fear, specifically:
* Fear that they will lose their QA identity
* Fear that if they report to a development manager, they will loose support and programmers will get priority
* Fear that they lack the skills to work in an agile team and will lose their jobs
* Fear that when they’re dispersed into development teams they won’t get the support they need
* Fear that they, and their managers, will get lost in the new organizations
We often hear of QA managers asking questions such as “My company is implementing agile development. How does my role fit in?”. This is directly related to the “loss of identity” fears.”
Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley, 2009
What is an Agile Tester?
Published April 2nd, 2009 Under Quotes | Leave a Comment
Here is a good definition of the Agile Tester, from the book “Agile Testing” of Lisa Crispin and Janet Gregory: “We define an agile tester this way: a professional tester who embraces change, collaborates well with both technical and business people, and understands the concept of using tests to document requirements and drive development. Agile testers tend to have good technical skills, know how to collaborate with others to automate tests, and are also experienced exploratory testers. They’re willing to learn what customers do so that they can better understand the customers’ software requirements.”
Source: “Agile Testing”, Lisa Crispin and Janet Gregory, Addison-Wesley, 2009
Three Thinking Gems for Software Development Projects
Published February 5th, 2009 Under Quotes, Software Development | 2 Comments
I have just started reading the book “Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” from Craig Larman and Bas Vodde. You will read the complete review later on this blog, but as the book is full of interesting wisdom from the beginning, I couldn’t resist to share some of them with you that you could apply quickly in you next project planning meeting.
“After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don’t’ do it.”
“We regularly coach groups that ask, “How can we calculate how many people we will need?” Our suggestion is, “Start with a small group of great people, and only grow when it really starts to hurt.” That rarely happens.”
The last is taken from The Fifth Discipline: “Dividing an elephant in half does not produce two small elephants”
Sources:
“Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum”, Craig Larman & Bas Vodde, Addison -Wesley
“The Fifth Discipline”, Peter Senge, DoubleDay Business
« go back — keep looking »