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!
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.
Tuesday, December 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.
Sunday, December 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
Monday, December 14, 2009
Journey to the Centre of the Ministry of the Economy in Mexico: part I
I started traveling to Mexico on business last January with the objective of injecting Agile and Lean practices into Mexican businesses. By the end of my first 12-day trip there I came to the conlusion that way too little was known about these and so instead of focusing on getting some contracts it was necessary to first evangelize about them, thus I decided to change strategies. As result, between January and April I gave 17 presentations on agile-lean at technical and leadership interest groups, associations, academia, and companies. The presentations were received with great enthusiasm and business-level meetings came out from some of them.
I was glad with the outcomes until another reality hit. Numerous Mexican businesses in the high tech, financial, and other white-collar sectors have to face a situation I expected to see on blue-collar sectors only, namely that of government mandated corporate governance such as ISO, CMMI, et-cetera. There is even a recent new regulation under the name of MoProSoft, a mexican model to regulate software development maturity that the Mexican Government approved as a norm for software development. Furthermore, it is undergoing evaluation by ISO to be accepted as a new standard. By now you might be wondering, is MoProSoft a model or a standard? Well, I wonder that myself and haven't got an answer for that yet. What I can indicate is that MoProSoft is, in good measure, a 1:1 mapping between some aspects of ISO and CMMI, plus the addition of a set of templates that need to be followed to fulfill its compliance requirements. Sounds heavy? It is! All those initiatives have been backed up by the Ministry of the Economy in Mexico.
I came to the obvious conclusion that if Agile-Lean are a great alternative to the aforementioned approaches to software development, and if corporate culture in Mexico is still heavily guided by government regulations then the obvious move to be effective was to reach that same government organization to get it to back up agile-lean. So, I took upon myself the quest for it. In March of this year I started talking to people in industry, academia, friends of friends, and so on trailblazing through professional networks, and going through numerous frustrations until by the end of November I got the luck to meet a person who connected me with a congressman directly who is directly connected with the Ministry of the Economy (this part is a great anecdote but I'll hold on to it for an article I'm writing). I met with the congressman, who liked what I have to offer so he asked me to give a presentation to other folks at the Congress building before bringing this to the attention of the Ministry of the Economy; and so I did. As result, those who attended gave to my proposal a thumbs-up and they agree this should be escalated to the Ministry. The congressman asked me to give another presentation, this time to a larger audience to then bring it to the Ministry of the Economy next month.
It's been an arduous journey but I am glad that I finally got to get some progress done before the end of the year. Hope things will move faster next year and that my objective of getting agile-lean be backed up by the Ministry of the Economy so that we can penetrate market more effectively.
I'll make a part-II posting when the time for it comes.
I was glad with the outcomes until another reality hit. Numerous Mexican businesses in the high tech, financial, and other white-collar sectors have to face a situation I expected to see on blue-collar sectors only, namely that of government mandated corporate governance such as ISO, CMMI, et-cetera. There is even a recent new regulation under the name of MoProSoft, a mexican model to regulate software development maturity that the Mexican Government approved as a norm for software development. Furthermore, it is undergoing evaluation by ISO to be accepted as a new standard. By now you might be wondering, is MoProSoft a model or a standard? Well, I wonder that myself and haven't got an answer for that yet. What I can indicate is that MoProSoft is, in good measure, a 1:1 mapping between some aspects of ISO and CMMI, plus the addition of a set of templates that need to be followed to fulfill its compliance requirements. Sounds heavy? It is! All those initiatives have been backed up by the Ministry of the Economy in Mexico.
I came to the obvious conclusion that if Agile-Lean are a great alternative to the aforementioned approaches to software development, and if corporate culture in Mexico is still heavily guided by government regulations then the obvious move to be effective was to reach that same government organization to get it to back up agile-lean. So, I took upon myself the quest for it. In March of this year I started talking to people in industry, academia, friends of friends, and so on trailblazing through professional networks, and going through numerous frustrations until by the end of November I got the luck to meet a person who connected me with a congressman directly who is directly connected with the Ministry of the Economy (this part is a great anecdote but I'll hold on to it for an article I'm writing). I met with the congressman, who liked what I have to offer so he asked me to give a presentation to other folks at the Congress building before bringing this to the attention of the Ministry of the Economy; and so I did. As result, those who attended gave to my proposal a thumbs-up and they agree this should be escalated to the Ministry. The congressman asked me to give another presentation, this time to a larger audience to then bring it to the Ministry of the Economy next month.
It's been an arduous journey but I am glad that I finally got to get some progress done before the end of the year. Hope things will move faster next year and that my objective of getting agile-lean be backed up by the Ministry of the Economy so that we can penetrate market more effectively.
I'll make a part-II posting when the time for it comes.
Editor's pick at Cutter Consortium
I wrote a short article for the Cutter Consortium, based on a previous blog, which ended up being the Editor's pick for this month. www.cutter.com
Tuesday, December 8, 2009
First MexAPLN meeting
The first MexAPLN meeting took place today at 7:45 PM at the Marie Callender's restaurant in Mexico City located on Insurgentes Avenue. Attendees were executives from diverse entities: Sergio Eduardo Duran Rubio (Accival), Martin Villalba Paredes (FIDEM), Alejandro Escamilla (Software Guru magazine), Armando Peralta and Ivan Carlos Rivera (Infotec), Jesus Flores, Jennifer Vazquez and René Molina (Bytline), and myself.
After introductions I talked briefly about how agile got started under a bottom-up approach and how as time has passed by, the practices matured, and the chasm has been crossed, executives are taking a more important and proactive role towards adoption thus the increase of top-down adoption. I then talked about what APLN is and, as a case, how BayAPLN operates. Next explained the benefits that MexAPLN can provide to industry and to us as professionals by bringing awareness on agile-lean.
Last we talked about the success factors and did some action planning for the next meeting, that time to be held at a company instead of at a restaurant.
To finish we did an intro planning pocker exercise for those new to it.
After introductions I talked briefly about how agile got started under a bottom-up approach and how as time has passed by, the practices matured, and the chasm has been crossed, executives are taking a more important and proactive role towards adoption thus the increase of top-down adoption. I then talked about what APLN is and, as a case, how BayAPLN operates. Next explained the benefits that MexAPLN can provide to industry and to us as professionals by bringing awareness on agile-lean.
Last we talked about the success factors and did some action planning for the next meeting, that time to be held at a company instead of at a restaurant.
To finish we did an intro planning pocker exercise for those new to it.
Tuesday, December 1, 2009
.jpg)
.jpg)
Subscribe to:
Posts (Atom)