Jim Highsmith is one of those few people that have really been-there-done-that and continue to be a pleasure to meet, accessible and down-to-earth. But anyway, this review is about his new book and not about him so I'll get to it. From my perspective Agile Project Management has two accomplishments: It fills in the gaps left by other books on the same subject and brings us one step further on different ways to see and approach the way we manage agile projects, within and outside software development.
Chapter 1 contains one of the best introductory chapters I've seen in any book on management. It is both a great motivation to read the rest of the book with interesting real cases. This chapter also refreshes the audience on the basics of agile, including the declaration of interdependence, which is explained in detail throughout the book, and provides some lesser known and relatively recent basis such as the Agile Triangle (not the Agile Iron Triangle).
Chapters 2, 3 and 4 are a detailed study of leadership values: Value over Constraints, Teams over Tasks, and Adapting over conforming. Similar to the agile values in the manifesto, these invite a cultural change in the way we measure project performance, lead teams, and focus on customer needs. Highsmith explains how the quality of the product and the work environment is improved through these. He also emphasizes on the fact that fail-often-fail-early is of very hight value in building a successful agile organization.
Chapter 5 has two objectives, to introduce an agile enterprise framework consisting of four layers that is arguably more appealing to large organizations, and to introduce an agile delivery framework consisting of five phases. That Agile Delivery Framework is explained in higher detail within the following 5 chapters, one per phase: envision, speculate, explore, adapt, and close. The last part of this chapter provides important practical information on the delivery framework. Chapter 6 has one of the best prep work descriptions you might be able to find and includes a project data sheet and the Tradeoff Matrix, which you might find useful. Chapter 7 digs into the speculate phase. Its contents are useful for those new to agile but not necessarily for those familiar with its basics since it explains fundamentals such as the backlog and story cards. Chapter 8 is about release planning. It introduces some planning strategies and a product planning structure that goes from the roadmap to the iteration. I recommend everybody to read this chapter since it has a bundle of snippets of useful information. Chapter 9 explains the explore phase and includes iteration planning, estimating, management and monitoring. It also talks briefly about technical debt, continuous integration and refactoring at a level good for managers but too light for for technical people. A good portion of the chapter is dedicated to coaching, one of the best parts of the book. Chapter 10 deals with the last two phases: adapt and close. It discusses how diverse activities usually considered secondary are of great importance to successfully fulfill customer needs and rapidly adapt to add value, increase quality, improve performance, and have a realistic view of the project status.
Chapter 11 is about scaling agile projects. Scaling has been a hot topic within the agile community during the last couple of years and Highsmith takes the opportunity to introduce an agile scaling model within the software development organization (other areas of an organization are beyond the scope of the book). scaling is treated at both size and distance levels, which increase the level of uncertainty and complexity. The model has five components: business goals, agile values, the organization, the product backlog and processes. The last three of these are treated differently at product, project, and feature level. I recommend you to read this chapter even if you work with a small team because there is value in understanding what works in the small and what works in the large. It may help you improve what you do in the small.
Highsmith does a great job discussing on chapter 12 how to do governance within agile projects, an aspect most small companies might not have to worry about but most mid to large organizations have to. Chapter 13 is an overview of metrics at a high level. If you want to learn about this topic in technical detail you are better off reading other books such as the David J Anderson's book on agile management and conference proceedings. Chapter 14 is a rather motivational reading on the value of agile
In conclusion, this is a book of high value to get up to speed on agile project management and learn more, recent advances in agile that are useful beyond software development and both in the small and in the large. Although the book doesn't advocate a particular agile development framework it leans mostly towards scrum.
Showing posts with label scaling. Show all posts
Showing posts with label scaling. Show all posts
Tuesday, January 5, 2010
Wednesday, December 30, 2009
Book Review: Lean-Agile Software Development: Achieving Enterprise Agility
Authors: Alan Shalloway, Guy Beaver and James R. Trott.
Between December of 2008 and April of 2009 I participated on a series of 6 webinars on Lean-Agile Software Development given by Allan Shalloway, under NetObjectives, and knew that the book—same title as the webinar series—was being finished at that time so I was definitely looking forward to it. I was very glad when the publisher asked BayAPLN for a review, which gave me the opportunity take over such a pleasant task.
The basic premise of the book is a better approach to drive software development efforts to maximize realized business value. It pays particular attention to how to scale agile to the enterprise; a main topic of discussion within the agile community during the last two years. The book’s proposal is to use lean-agile instead of agile alone and to “extend” scrum to what the authors call scrum# which is, simply put, doing scrum while also doing lean thinking. Particular attention is paid to the lean principles of waste elimination and optimizing the whole. The authors put together a body of knowledge that would otherwise take lots of research, reading hours, and trial-and-error experience. The theme itself is not new, you can also consult, e.g., books on lean software development by Mary and Tom Poppendieck, and a book on scaling lean and agile development by Craig Larman and Bas Vodde. Shalloway, Beaver and Trott’s book is easy to read and very informative at a conceptual level and also at an anecdotal level. The cases they present actually add a lot of value to it. I consider this to be a must for executives, managers, and non-technical people involved on software projects because it will help them understand better what lean and agile can do for their organization. It is also helpful to software and QA engineers as a great informative reading.
The book consists of an introduction, three parts, and an appendix. The Introduction sets the tone for the book and revisits the basics of agile and lean (manifesto, principles, etc.). But make no mistake; this book is not for people new to agile or lean, and for those who are it is better to do some previous reading or they might get lost at times.
Part I starts with a discussion on why it is not preferable to think of software development as a science or a technique instead of as a discovery means to the end of satisfying a need, and gives a gentle introduction to some lean principles within software development. Chapter 1 nicely explains the transition of manufacture-based practices to software development. Chapter 2 addresses the business value added by agile and lean through better customer interaction, better delivery, and product focus. Chapter 3 gives some insights on how to get started with the transition to lean-agile, and chapter 4 dives into lean thinking for portfolio management, which I consider to be the most important chapter of this part because it gives a good deal of practical advice to do high value-added changes to your organization.
Part II Focuses on lean project management. Chapter 5 addresses some limitations of scrum that are particularly important when considering scalability. The authors propose what they call Scrum# as an extension of scrum that includes lean thinking. I personally think the problem is not scrum itself but rather how we put it into practice and what they propose as scrum# to me is nothing more than having a better (lean) way of applying the scrum framework; maybe because I learned about lean years before scrum came to be and so I have always used lean thinking when doing scrum. In any case, I would advocate to simply keep the term scrum as-is and encourage people to learn and apply lean to it rather than getting into new terminology, which I think might create confusion instead of clarity. I was very pleased to see that Kanban was added to the book and wish it had been explained in more detail, on a dedicated chapter, because kanban is very powerful in eliminating some disadvantages of scrum and it will gain importance as a highly effective software development framework. Chapter 6 is about iteration 0, which is the preparation phase before starting your actual scrum iterations. I entirely agree with the need to do the prep work but I have never been fond of calling it iteration because in people’s minds it time-boxes a very important phase that not necessarily—and almost never—takes the same amount of time as the actual scrum iterations (see, e.g., Jim Highsmith’s book Agile Project Management). Chapter 7 is a good explanation on how to do lean-agile release planning. Chapter 8 explains the importance of visual controls and information radiators, which is a subject that most executives have a hard time accepting from the lean-agile perspective but once they fully realize their high value regardless of their simplicity they usually embrace these fully. I definitely enjoyed seeing a chapter on the role of QA (chapter 9) because this is often under-treated in the software development literature in general, unless it is on a dedicated QA book. This inclusion goes well with the lean-agile principles of working in teams and optimizing the whole.
Part II addresses scalability at enterprise level on chapter 10 with a very effective discussion format. Management’s role in lean-agile is treated on chapter 11 with good arguments but I would’ve liked it better if it had elaborated further on this very important role. Chapter 12 was one of my favorite ones since it does a good job at discussing the Product Coordination Team, a relatively new approach that has proven to be better suited for scalability than scrum of scrums. Chapter 13 is rather a teaser about the importance of a better, lightweight, approach to software architecture and design, which is okay since it is beyond the scope of the book.
Part III consists of chapter 14 only and is an epilogue to the book that basically encourages people to explore and learn more about lean, primarily, and about agile.
Appendix A explains Steve Bockman’s Team Estimation Game. A dynamic, fun, and effective step further of what you can do with the Planning Pocker that is also scalable. Appendix B presents the authors’ model of lean-agile software development, a nice quick reference to refresh the key concepts.
Alan, Guy, and James wrote a fabulous book that is a must-read for those interested on a successful lean-agile adoption whether or not you need to scale.
Between December of 2008 and April of 2009 I participated on a series of 6 webinars on Lean-Agile Software Development given by Allan Shalloway, under NetObjectives, and knew that the book—same title as the webinar series—was being finished at that time so I was definitely looking forward to it. I was very glad when the publisher asked BayAPLN for a review, which gave me the opportunity take over such a pleasant task.
The basic premise of the book is a better approach to drive software development efforts to maximize realized business value. It pays particular attention to how to scale agile to the enterprise; a main topic of discussion within the agile community during the last two years. The book’s proposal is to use lean-agile instead of agile alone and to “extend” scrum to what the authors call scrum# which is, simply put, doing scrum while also doing lean thinking. Particular attention is paid to the lean principles of waste elimination and optimizing the whole. The authors put together a body of knowledge that would otherwise take lots of research, reading hours, and trial-and-error experience. The theme itself is not new, you can also consult, e.g., books on lean software development by Mary and Tom Poppendieck, and a book on scaling lean and agile development by Craig Larman and Bas Vodde. Shalloway, Beaver and Trott’s book is easy to read and very informative at a conceptual level and also at an anecdotal level. The cases they present actually add a lot of value to it. I consider this to be a must for executives, managers, and non-technical people involved on software projects because it will help them understand better what lean and agile can do for their organization. It is also helpful to software and QA engineers as a great informative reading.
The book consists of an introduction, three parts, and an appendix. The Introduction sets the tone for the book and revisits the basics of agile and lean (manifesto, principles, etc.). But make no mistake; this book is not for people new to agile or lean, and for those who are it is better to do some previous reading or they might get lost at times.
Part I starts with a discussion on why it is not preferable to think of software development as a science or a technique instead of as a discovery means to the end of satisfying a need, and gives a gentle introduction to some lean principles within software development. Chapter 1 nicely explains the transition of manufacture-based practices to software development. Chapter 2 addresses the business value added by agile and lean through better customer interaction, better delivery, and product focus. Chapter 3 gives some insights on how to get started with the transition to lean-agile, and chapter 4 dives into lean thinking for portfolio management, which I consider to be the most important chapter of this part because it gives a good deal of practical advice to do high value-added changes to your organization.
Part II Focuses on lean project management. Chapter 5 addresses some limitations of scrum that are particularly important when considering scalability. The authors propose what they call Scrum# as an extension of scrum that includes lean thinking. I personally think the problem is not scrum itself but rather how we put it into practice and what they propose as scrum# to me is nothing more than having a better (lean) way of applying the scrum framework; maybe because I learned about lean years before scrum came to be and so I have always used lean thinking when doing scrum. In any case, I would advocate to simply keep the term scrum as-is and encourage people to learn and apply lean to it rather than getting into new terminology, which I think might create confusion instead of clarity. I was very pleased to see that Kanban was added to the book and wish it had been explained in more detail, on a dedicated chapter, because kanban is very powerful in eliminating some disadvantages of scrum and it will gain importance as a highly effective software development framework. Chapter 6 is about iteration 0, which is the preparation phase before starting your actual scrum iterations. I entirely agree with the need to do the prep work but I have never been fond of calling it iteration because in people’s minds it time-boxes a very important phase that not necessarily—and almost never—takes the same amount of time as the actual scrum iterations (see, e.g., Jim Highsmith’s book Agile Project Management). Chapter 7 is a good explanation on how to do lean-agile release planning. Chapter 8 explains the importance of visual controls and information radiators, which is a subject that most executives have a hard time accepting from the lean-agile perspective but once they fully realize their high value regardless of their simplicity they usually embrace these fully. I definitely enjoyed seeing a chapter on the role of QA (chapter 9) because this is often under-treated in the software development literature in general, unless it is on a dedicated QA book. This inclusion goes well with the lean-agile principles of working in teams and optimizing the whole.
Part II addresses scalability at enterprise level on chapter 10 with a very effective discussion format. Management’s role in lean-agile is treated on chapter 11 with good arguments but I would’ve liked it better if it had elaborated further on this very important role. Chapter 12 was one of my favorite ones since it does a good job at discussing the Product Coordination Team, a relatively new approach that has proven to be better suited for scalability than scrum of scrums. Chapter 13 is rather a teaser about the importance of a better, lightweight, approach to software architecture and design, which is okay since it is beyond the scope of the book.
Part III consists of chapter 14 only and is an epilogue to the book that basically encourages people to explore and learn more about lean, primarily, and about agile.
Appendix A explains Steve Bockman’s Team Estimation Game. A dynamic, fun, and effective step further of what you can do with the Planning Pocker that is also scalable. Appendix B presents the authors’ model of lean-agile software development, a nice quick reference to refresh the key concepts.
Alan, Guy, and James wrote a fabulous book that is a must-read for those interested on a successful lean-agile adoption whether or not you need to scale.
Sunday, November 15, 2009
Agile seminar in Palo Alto: Coaching coaching coaching
Last Thursday, Nov 12, (yes, yes, I know, I know... last Thursday was ages ago but I'm still posting this) Serena sponsored an agile panel at the California Café in Palo Alto, within the Stanford Campus, which they called Agile Pigs and Chickens BBQ Silicon Valley. It was a nice event at a good venue and around 50 people attended . Panelists were Roger Brown, Jeff McKenna, Jorge Rodriguez, and John Scumniotales.
The panel had a Q&A format and que questions were case-based mostly. Some of the topics were:
- Dealing with legacy: yes it is possible to start adopting agile while dealing with legacy (most projects do) and a recommendable approach is to start new things agile and to transition legacy as it is revisited.
- Getting started with agile. Recommendation is to start small and grow layers gradually.
- Scalability. Advice was keep it as small and simple as possible and avoid outsourcing, otherwise the task becomes quite challenging
- Web 2.0 and agile. There's a misperception that agile doesn't require discipline and documentation when in fact it requires stakeholders to be continuously on top of their game--without overdoing things--and documentation as well as planning are necessary in agile. It is done differently and more effectively.
- Next challenges: Focus on design, value, outer layers of the organizational onion, creation of companies 100% agile.
One other point that is quite crucial is that agile adoption can be much better if companies have an agile expert coaching then for as long as necessary. This is way too often neglected, with companies assuming that training is sufficient only to go belly up at implementation time. See for example my recent posting on a scrum project gone bad.
Monday, October 12, 2009
Growing Pains
The invited speaker at the coming BayAPLN meeting (Oct 20) is Ed Kraay, whose presentation is entitled Growing Pains: Why scaling scrum hurts and what you can do about it.
Since I'll be out on a business trip that day I contacted Ed and we agreed on a symbiosis: he would give me the presentation 1:1 beforehand so that he could practice it, and I would give him feedback on the format and content of the presentation. We skyped Saturday morning and I highly recommend it highly to people about to scale agile at their enterprises and equally to those who are or have scaled since the presentation will give everybody great advice and pointers on what to do and what to avoid.
Thanks Ed , you are a good friend (and no, I didn't feel like a ginnea pig).
Since I'll be out on a business trip that day I contacted Ed and we agreed on a symbiosis: he would give me the presentation 1:1 beforehand so that he could practice it, and I would give him feedback on the format and content of the presentation. We skyped Saturday morning and I highly recommend it highly to people about to scale agile at their enterprises and equally to those who are or have scaled since the presentation will give everybody great advice and pointers on what to do and what to avoid.
Thanks Ed , you are a good friend (and no, I didn't feel like a ginnea pig).
Subscribe to:
Posts (Atom)