Many years ago when I was in college I had the opportunity to see the movie Ikiru (生きる) by Akira Kurozawa. As a nice way to finish my work week, I just finished watched it again while having dinner. The story is around an elderly man, Watanebe-san, who is a public office head of department who is diagnosed with terminal cancer. He immediately starts a desperate hunt to recover the 30 years he spend doing nothing as a public official, and after much soul searching he decides to help build a public park at a low income neighborhood. The park is finished shortly before his death, whose cause was unknown to his coworkers and family. At his funeral reception there are about a dozen other public officials of different ranks. It is there where an amazing display of bureaucracy is made clear, and after much drinking and discussing, those who remained at the room came to the realization of the reazon of Watanabe's death. Inspired by it they all determine to make their work as meaningful and really serve the public, only to get back to the same status quo once back to work.
There is a parallel to the story and why some lean-agile projects fail and, worse, why entire organizations fail in the adoption. Simply put, it is very easy to get back to the old habits. Many organizations claim to be doing agile, be it scrum, xp, kanban or whatever else, in reality they still do in good measure the same things they were doing before with minor modifications such as not sitting at their periodic meetings or using post-it notes for their use cases. This more often than not results in even worse dynamics than before the "adoption". If you want your organization to really adopt lean-agile then you have to fully embrace it and be willing to go through what it takes to really make the transition.
Feb 4, 2010
Cutter predictions 2010
Cutter published its 2010 predictions back in mid December, which includes a prediction by yours truly.
Agile-lean will become the new mainstream approach to project management and software development. Latin America will become aware of this and will start investing heavily on its adoption towards the end of the year in an attempt to bridge the IT gap between developing and developed countries.
You can see the full list at:
http://www.cutter.com/predictions/2010.html
Agile-lean will become the new mainstream approach to project management and software development. Latin America will become aware of this and will start investing heavily on its adoption towards the end of the year in an attempt to bridge the IT gap between developing and developed countries.
You can see the full list at:
http://www.cutter.com/predictions/2010.html
Jan 26, 2010
Presentation at Mexico's Central Bank
Mexico's Central Bank (Banco de México) asked me to give them a presentation on Lean-Agile today. The experience was awesome starting with the venue. The Central Bank counts with a cluster of Colony Epoch buildings within the downtown Mexico City area (see photos for an example), which are as beautiful on the inside as they are from the outside. The presentation took place at a small but well-equiped auditorium and I had an audience of roughly 60 people. The audience was great and attentive during my 60-min talk, which consisted of Lean Agile fundamentals, case studies, hard data on agile benefits, reflections, and short speech about my services. I was then asked a series of good questions on some lean-agile aspects, on governance, and on comparison with other methodologies.
Next I had lunch with 11 executives and managers from the Bank at its private restaurant, which gave me the opportunity to have closer conversations with them and gave them the opportunity to ask lots of questions. To my surprise I received a limited-edition art book on Frida Kahlo (a famous Mexican surrealist painter) sponsored by the bank.
I have to admit the people I met and the bank itself exceeded my expectations and it would be great if I get to have the opportunity to work with them.
Next I had lunch with 11 executives and managers from the Bank at its private restaurant, which gave me the opportunity to have closer conversations with them and gave them the opportunity to ask lots of questions. To my surprise I received a limited-edition art book on Frida Kahlo (a famous Mexican surrealist painter) sponsored by the bank.
I have to admit the people I met and the bank itself exceeded my expectations and it would be great if I get to have the opportunity to work with them.
Jan 23, 2010
mute-deaf at Innovation Game online
I was all exited about the opportunity to participate on an online Innovation Game with folks from APLN and BayAPLN while still abroad on business. I logged in and proceeded to dial in to the conference from a telephone only to come to a halt because the conference call requires a "#" at the end of the code and the long distance service at the place where I am staying interprets it as a call to operator so there was no way I could reach the conference call.
But where there's a will there's a way. I thought it would be an interesting experiment to see how effectively I could go about participating on the game while on a mute-deaf state. The game started and I felt I was at at real disadvange at first but soon after I realized that the entire environment provided an quite complete and friendly environment such that I soon forgot all about the audio feedback. For sure there were interesting conversations going on that I was missing, but the information I was getting through the game board itself, the text tab, and the actions tab were providing enough information for me to not only follow through but to also contribute!
Comparing the online experience with a face-to-face experience I would say that:
But where there's a will there's a way. I thought it would be an interesting experiment to see how effectively I could go about participating on the game while on a mute-deaf state. The game started and I felt I was at at real disadvange at first but soon after I realized that the entire environment provided an quite complete and friendly environment such that I soon forgot all about the audio feedback. For sure there were interesting conversations going on that I was missing, but the information I was getting through the game board itself, the text tab, and the actions tab were providing enough information for me to not only follow through but to also contribute!
Comparing the online experience with a face-to-face experience I would say that:
- Face-to-face has the benefits of not only more effective verbal communication but also body language and higher encouragement for all stakeholders to participate.
- Online has the benefits of counting on a log, making it easy for people to think more carefully about something or re-visit something without breaking the rhythm or distracting others.
Jan 19, 2010
MexAPLN meeting: January 2010
The second meeting of the MexAPLN was way better than the first one. The meeting was at the IDS offices. IDS is one of the two oldest sw dev services businesses in Mexico. Its building has a beautiful view of the 4th and 5th highest mountains in all of the American Continent.
This being the second session it was obviously very org related and the main subjects were:
Once this is done we'll have the foundation and a good start to become a relevant chapter.
Thanks to everyone who has contributed.
*** Important Note:
Paul Culling from VersionOne wrote a comment on the original posting, on which I used the workd "demands". My response is: Paul, I apologize if the word created some interpretation. One of the definitions of "demand" is "the requirement of work". The communication through Cesar has been quite clear and I informed at the meeting that VersionOne will be happy to become a sponsor, but first we have to prove that we are an active community of practitioners of agile and lean, and that is what is the requirement of work we have to do to earn your sponsorship.
I edited the posting in hope that you agree with the new wording, otherwise let me know and I'll be happy to rephrase it.
~Masa K Maeda
This being the second session it was obviously very org related and the main subjects were:
- Alejandor Escamilla from Software Guru reported that they received over 400 responses from a member's blog posted on its website
- 12 people (including myself) attended the meeting, 5 of them first-time. One person actually drove 180 miles one-way just to be there and headed back to his city of origin, Morelia, the next morning! ...and I used to think my 60-mile drive was significant.
- We talked about what we need to do to be accepted as an actual chapter, about sponsorship and about logistics on meetings.
- I reported that VersionOne showed a lot of enthusiasm about becoming an sponsor once we are ready for it
- Main topic was Chartering. Since we were running out of time we decided to do some off-line work, discussing via web-conference to get more done and by the next meeting at which time we'll give it thumbs-up or down.
- We decided to use Google groups instead of Yahoo groups as one of our comm tools.
- Next meeting is at the offices or Software Guru.
Once this is done we'll have the foundation and a good start to become a relevant chapter.
Thanks to everyone who has contributed.
*** Important Note:
Paul Culling from VersionOne wrote a comment on the original posting, on which I used the workd "demands". My response is: Paul, I apologize if the word created some interpretation. One of the definitions of "demand" is "the requirement of work". The communication through Cesar has been quite clear and I informed at the meeting that VersionOne will be happy to become a sponsor, but first we have to prove that we are an active community of practitioners of agile and lean, and that is what is the requirement of work we have to do to earn your sponsorship.
I edited the posting in hope that you agree with the new wording, otherwise let me know and I'll be happy to rephrase it.
~Masa K Maeda
Jan 11, 2010
MexAPLN meeting: January 2010
The January 2010 meeting of the MexAPLN meeting will take place at the IDS offices at 7:30 PM on January 19 (Tuesday). Theme of the meet is Chartering.
Adddress: Av. Insurgentes Sur 1388, 11th floor.
See you there!
Adddress: Av. Insurgentes Sur 1388, 11th floor.
See you there!
Jan 6, 2010
Book review: Agile Testing by Lisa Crispin and Janet Gregory
Agile testing is a great book to both new and seasoned test engineers and test managers. At 533 pages, the book might feel a bit heavy but it is actually a pretty light and practical read if you read it to get a solid foundation on agile testing and then as reference. Note that the book is not about test coding techniques.
Part I is an introduction to agile testing and proposes ten principles for agile testers. What I don't know is if there are really 10 principles or if Crispin and Gregory forced it to be that specific number because it sounds better than 9 or 11. In any case, this chapter is a must read for all. Part II discusses organizational challenges, specifically cultural, logistical, and transitional from typical processes. This is a must-read for managers and team leads, and highly advisable for engineers if you want to have a successful test organization fully integrated with an agile organization. I personally encourage the division between development and testing to disappear completely. Part III is about he testing quadrants proposed by Brian Marick (one of the Agile Manifesto signatories) a while back. This is the first time I see the quadrants treated in larger detail and highly recommend it as a must for all.
Part IV is about test automation. It is a good read to understand the advantages of test automation and proposes a test automation strategy. This is a good starting point for test organizations that are new to automation but for mature test automation organizations it might add little value. Test code writing techniques are beyond the scope of this book. Part V illustrates the previous parts and then some by following a tester's activities through an agile iteration and the activities prior to it.
One problem I see way too often in test organizations and the way companies treat their test organizations is due to a lack of understanding not only of the difference between Quality Assurance and testing but also because of the place testing has hi people's minds. This book is a big help to create a cultural shift for the better.
Part I is an introduction to agile testing and proposes ten principles for agile testers. What I don't know is if there are really 10 principles or if Crispin and Gregory forced it to be that specific number because it sounds better than 9 or 11. In any case, this chapter is a must read for all. Part II discusses organizational challenges, specifically cultural, logistical, and transitional from typical processes. This is a must-read for managers and team leads, and highly advisable for engineers if you want to have a successful test organization fully integrated with an agile organization. I personally encourage the division between development and testing to disappear completely. Part III is about he testing quadrants proposed by Brian Marick (one of the Agile Manifesto signatories) a while back. This is the first time I see the quadrants treated in larger detail and highly recommend it as a must for all.
Part IV is about test automation. It is a good read to understand the advantages of test automation and proposes a test automation strategy. This is a good starting point for test organizations that are new to automation but for mature test automation organizations it might add little value. Test code writing techniques are beyond the scope of this book. Part V illustrates the previous parts and then some by following a tester's activities through an agile iteration and the activities prior to it.
One problem I see way too often in test organizations and the way companies treat their test organizations is due to a lack of understanding not only of the difference between Quality Assurance and testing but also because of the place testing has hi people's minds. This book is a big help to create a cultural shift for the better.
Jan 5, 2010
Book review: Agile Project Management: Creating Innovative Products (2nd Ed.) by Jim Highsmith
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.
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.
Jan 2, 2010
Good kanban tool
LeanKitKanban (http://leankitkanban.com/) is a simple but powerful tool to do Kanban. It is fairly good in that it allows you to create your kanban boards very easily as it is also to add users (with avatars if so desired) to it with different roles. Users can subscribe to board events via email or RSS feed.
It is at beta and collecting suggestions.
Check it out!
It is at beta and collecting suggestions.
Check it out!
Dec 30, 2009
Gotta love Apple's service :-)
All my experiences with Apple Computer's customer care service have been no less than awesome, and my last one topped them all.
Two days ago I brought my MacBook Pro to the Los Gatos store because I wanted to see if it was possible to give it a general clean up. There was nothing operationally wrong with it. The person who took care of me told me they do not offer service that consists of just cleaning the machine up from the inside, so I thought that was to be the end of the story and I would go back home with the machine as-is. To my surprise he had a second look at the laptop, noticing some dust specs on the monitor that I have pointed out and also noticed a good amount of wear on the keyboard. He decided to accept the machine reporting those issues and told me the machine was going to be ready in 5 to 7 business days.
Well... just two days later (today) I got a phone call from the Apple store to inform me the laptop was ready for pick up and so I assumed the technicians looked at it and set it for pickup without having done anything to it other than replacing a missing screw on the back. What a surprise when I picked it up. Apple replaced both the screen (the entire part, including the shell which I noticed because the original one had a dent) and the keyboard. The laptop is now as good as new and the cost of parts and labor was nothing... zeppo... nada because it is still under its 3-year warranty. I honestly expected the warranty to cover actual damages that required repair and not the minor issues my laptop had due to wear and tear.
Apple, you rock!
Two days ago I brought my MacBook Pro to the Los Gatos store because I wanted to see if it was possible to give it a general clean up. There was nothing operationally wrong with it. The person who took care of me told me they do not offer service that consists of just cleaning the machine up from the inside, so I thought that was to be the end of the story and I would go back home with the machine as-is. To my surprise he had a second look at the laptop, noticing some dust specs on the monitor that I have pointed out and also noticed a good amount of wear on the keyboard. He decided to accept the machine reporting those issues and told me the machine was going to be ready in 5 to 7 business days.
Well... just two days later (today) I got a phone call from the Apple store to inform me the laptop was ready for pick up and so I assumed the technicians looked at it and set it for pickup without having done anything to it other than replacing a missing screw on the back. What a surprise when I picked it up. Apple replaced both the screen (the entire part, including the shell which I noticed because the original one had a dent) and the keyboard. The laptop is now as good as new and the cost of parts and labor was nothing... zeppo... nada because it is still under its 3-year warranty. I honestly expected the warranty to cover actual damages that required repair and not the minor issues my laptop had due to wear and tear.
Apple, you rock!
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.
Dec 22, 2009
Cutter Consortium 2010 predictions
The Cutter Consortium just published its 2010 predictions.
http://www.cutter.com/predictions.html
Three of them are related to Agile.
http://www.cutter.com/predictions.html
Three of them are related to Agile.
Dec 20, 2009
APLN chapters in Latinamerica
Back last June I came up with the idea of staring an APLN chapter in Mexico. After talkng about it with several people in both the USA--at the BayAPLN mainly David Chilcott and Cesar Idrovo--and Mexico (polling people to see how much enthusiasm there is about it) I decided to go for it. Coincidentally an agilist from Costa Rica, David Alfaro, contacted BayAPLN in October and so we held a teleconference USA-Mex-CR (since I was in Mexico on business those days) to brainstorm how to get those chapters started. I suggested David A and I to keep in close contact to share experiences and help each other out in addition to getting coaching from David C and Cesar.
Then in November I had the opportunity to meet a group of Brazilians let by Guilherme Chapiewski, who were in San Francisco for the QCon conference, and invited them to the BayAPLN meeting to be held the following day (talk about good timing). They all attended and loved it. Guilherme told me he would like to get a chapter started in Brazil.
Long story short, David A has been actively increasing awareness on agile in Costa Rica and is working towards getting the first meeting. We learned that a chapter in Brazil was started a while back but didn't succeed and current efforts are towards re-starting it. From my side the first MexAPLN (unofficial for now) took place on Dec 8th in Mexico City and was a great start, with 8 executives from diverse enterprises attending.
Several ideas I have in mind are:
Then in November I had the opportunity to meet a group of Brazilians let by Guilherme Chapiewski, who were in San Francisco for the QCon conference, and invited them to the BayAPLN meeting to be held the following day (talk about good timing). They all attended and loved it. Guilherme told me he would like to get a chapter started in Brazil.
Long story short, David A has been actively increasing awareness on agile in Costa Rica and is working towards getting the first meeting. We learned that a chapter in Brazil was started a while back but didn't succeed and current efforts are towards re-starting it. From my side the first MexAPLN (unofficial for now) took place on Dec 8th in Mexico City and was a great start, with 8 executives from diverse enterprises attending.
Several ideas I have in mind are:
- Leveraging the fact that we have close relationship with BayAPLN (with me now being part of the Coordinating Committee) to figure out ways to help those chapters get up and running.
- Growing the MexAPLN to become the prime chapter in Latinamerica
- Create a latinamerican APLN metachapter to have higher impact in that geographical area and organize world-class events.
Last BayAPLN meeting of 2009
The last BayAPLN meeting, held a the Tacit Knowledge offices, was a retrospective of the year. There were 24 people at the meeting, which is low for BayAPLN meeting standards but understandable given that lots of people are either out of town, shopping, or wrapping things up at work to finish the year in balance.
What was done and accomplished throughout the year was quite impressive, for example:
What was done and accomplished throughout the year was quite impressive, for example:
- 329 registrations at the yahoo group
- 394 registrations at the linkedIn group
- Average attendance per meeting was 44, and topped around 70.
- We had a pretty good number of Agile-Lean celebrities giving presentations at meetings on topics related to agile and: current economy, adoption patterns, group coherence, learning games, agile transition styles, scaling scrum, Personas and story maps.
- Co-sponsored the Agile Open California 2009 open space.
- Better task distribution
- Make presentations more easily available on our website
- Increase knowledge, e.g., adding terms on Wikipedia
- Give support to new APLN chapters such as those in Mexico, Costa Rica, and Brazil
- etc
Subscribe to:
Posts (Atom)
