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)
Friday, November 27, 2009
Lean-Agile could've saved this company
Air-Go was a software services company that went belly up. It's former CEO reported 10 reasons it failed. When I read about it I couldn't stop wondering where that company would be nowadays had it been an lean-agile company. I identified 8 of the reasons could've been fixed doing lean-gile
1. Poor people interaction. There was too much focus on personal benefit instead of team and business benefit. Also, interaction with customer was low.
2. Lack of vision. Chartering was never done and the company had no direction.
3. Different values. Individuals and teams were not on the same page with respect to what value should be added and how to add it.
4. Lack of focus. Teams handling too many projects at the same time instead of one at a time.
5. Overestimating. No knowledge of their teams' velocities.
6. Failed often but late. Most of their projects failed and failed too late.
7. Too much planing and very little execution. BDUF!
8. Overconfidence and designing for best-case scenario. Lack of planning and incremental/iterative development.
1. Poor people interaction. There was too much focus on personal benefit instead of team and business benefit. Also, interaction with customer was low.
2. Lack of vision. Chartering was never done and the company had no direction.
3. Different values. Individuals and teams were not on the same page with respect to what value should be added and how to add it.
4. Lack of focus. Teams handling too many projects at the same time instead of one at a time.
5. Overestimating. No knowledge of their teams' velocities.
6. Failed often but late. Most of their projects failed and failed too late.
7. Too much planing and very little execution. BDUF!
8. Overconfidence and designing for best-case scenario. Lack of planning and incremental/iterative development.
A recipe to improve enterprise success-fail project rate
Larry Gelwix has been the head coach of the Highland HS Rugby team in Salt Lake City for 36 years. Along that time he has accumulated a 413-9 win-loss record; the most impressive any sports coach—professional or amateur—has achieved ever. Wouldn't it be fantastic if our projects had a similar success-fail rate? Some aspects of his coaching style are well in tune with some agile-lean values and principles:
• High degree of teamwork: doing collaborative work with all stakeholders within and beyond the project boundaries makes much more likely to achieve team coherence.
• Horizontal leadership: to give room for self-organization, delegation, empowerment of the team to make better decisions, and boost skill improvement amongst team members. This fades away micromanagement and a command-and-control culture.
• Setting goals: short, achievable milestones which are goals on their own right. An incremental-iterative approach to create products foments discipline, increase quality, and motivate customers to provide feedback throughout the creation of the product they want.
• Realizing potential: by trusting and empowering the team we form motivated individuals. And a motivated person is usually more productive and less prone to make mistakes.
This recipe doesn’t ensure project success, but it can help your enterprise become hyperproductive and, as a consequence, successful. As Larry said: “good decisions don’t make life easy, but they do make it easier.”
• High degree of teamwork: doing collaborative work with all stakeholders within and beyond the project boundaries makes much more likely to achieve team coherence.
• Horizontal leadership: to give room for self-organization, delegation, empowerment of the team to make better decisions, and boost skill improvement amongst team members. This fades away micromanagement and a command-and-control culture.
• Setting goals: short, achievable milestones which are goals on their own right. An incremental-iterative approach to create products foments discipline, increase quality, and motivate customers to provide feedback throughout the creation of the product they want.
• Realizing potential: by trusting and empowering the team we form motivated individuals. And a motivated person is usually more productive and less prone to make mistakes.
This recipe doesn’t ensure project success, but it can help your enterprise become hyperproductive and, as a consequence, successful. As Larry said: “good decisions don’t make life easy, but they do make it easier.”
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.
Friday, November 6, 2009
What happened to self-organization and collaboration?
While at yesterday's Agile Journal seminar in Santa Clara CA it called my attention that all presenters who talked about how they do scrum (oh, yes, other practices were mentioned but not talked about) said something that made me question how much self-organization they allow their teams to have. One aspect is that of story assignment. A self organizing team is one that allows its members to self-assign the stories to be implemented during each sprint, considering of course priorities and upon agreement with PO and SM. The teams mentioned at the seminar were given the tasks to implement by the SM.
Since the seminar was primarily to promote software tools the presenters talked about how much the tools have benefited their projects and how great it is for stakeholders to have a tool to go to for, say, write a story to then be assigned. Nobody talked about the importance to maintain face-to-face collaboration. Based on their description it seems the tool ends up being at the center of activities instead of being a means to capture and track the activities to facilitate documentation and reporting. People must continue having close communication and collaboration. A story should be discussed, estimated, and assigned properly.
Since the seminar was primarily to promote software tools the presenters talked about how much the tools have benefited their projects and how great it is for stakeholders to have a tool to go to for, say, write a story to then be assigned. Nobody talked about the importance to maintain face-to-face collaboration. Based on their description it seems the tool ends up being at the center of activities instead of being a means to capture and track the activities to facilitate documentation and reporting. People must continue having close communication and collaboration. A story should be discussed, estimated, and assigned properly.
Thursday, November 5, 2009
A failed scrum project in pictures...
What could happen when a company doesn't take agile coaching..
(question is will they take coaching and the necessary training or abandon agile???)
(question is will they take coaching and the necessary training or abandon agile???)
Saturday, October 31, 2009
Cutter Consortium Summit Latinamerica '09
The Cutter Consortium Latinamerica Summit took place Oct 28~30. The first two days were for sessions and discussions panels, and the last day for workshops.
Tom DeMarco gave a great presentation on Collaboration during which he said that key aspects to build systems are: small pieces and collaboration, where trust is the bandwidth of collaboration.
There was then a session and discussion panel on Operational Excellence during which it was discussed what factors affect operational excellence in organizations. Some of the aspects brought to the table were better change management and fast delivery, better governance, do what is good enough vs. perfect, build on trust. I added to it the importance to pay much more attention to human interaction. An important metric is how much of the budget is used to support the front office vs. the back office. Trends that help are moving the architecture towards the business process, business process improvement, governance focused on end to end coverage, stress the idea of SLAs to reach company and customer. My personal preference is towards paying attention to these aspects in a light way. That is, yes, do them but don't make them big, heavy, and friction-adding (keep it within the Agile boundaries). An attendee mentioned that in Mexico the areas of innovation and process will be dismantled to then become part of IT.
Next was a session and a panel on SOA. Mike Rosen gave a great presentation in which he presented 4 case studies, one of them being a failed project. SOA is expensive and complex. Its architecture has to be oriented towards the business and not IT, and should be, arguably, centralized (and there were opinions towards the opposite). SOA doesn't only bring IT process improvement but long-terms ROI. E.g. Wells Fargo had $300MM waste in architecture until they got it right with SOA and the expense on it paid by itself. Wells Fargo can fully absorb a new bank in 6 weeks.
The first session of the second day was my own. I talked about competitive advantages of adopting agile-lean, even more so in times of crisis. I'll be posting the ppt on my website shortly.
Rogelio Oliva took then the audience through a wonderful exercise on how manage your boss in a crisis. A recommended book that was used for this exercise is Adventures of an IT Leader.
Michael Mah showed measurements that show the impact (not pretty) about outsourcing and the benefits of using agile practices. It was followed by a discussion panel on the same subject, where it was mentioned that even though nearsourcing makes the time zone differences be less significant there are still cultural and communication problems that need to be solved. We have to also take advantage of the fact that the world is better interconnected than ever before to find alternatives to improve the the way we communicate while at the same time improving the current state of the planet (ecological crisis).
The third day was for workshops. I attended Bob Benson's on Filling the Governance Gap. It was fun half-day with discussions and guidance. The three keywords are:
For more highlights on what went on, in the words of presenters check my tweets @masakmaeda.
Tom DeMarco gave a great presentation on Collaboration during which he said that key aspects to build systems are: small pieces and collaboration, where trust is the bandwidth of collaboration.There was then a session and discussion panel on Operational Excellence during which it was discussed what factors affect operational excellence in organizations. Some of the aspects brought to the table were better change management and fast delivery, better governance, do what is good enough vs. perfect, build on trust. I added to it the importance to pay much more attention to human interaction. An important metric is how much of the budget is used to support the front office vs. the back office. Trends that help are moving the architecture towards the business process, business process improvement, governance focused on end to end coverage, stress the idea of SLAs to reach company and customer. My personal preference is towards paying attention to these aspects in a light way. That is, yes, do them but don't make them big, heavy, and friction-adding (keep it within the Agile boundaries). An attendee mentioned that in Mexico the areas of innovation and process will be dismantled to then become part of IT.
Next was a session and a panel on SOA. Mike Rosen gave a great presentation in which he presented 4 case studies, one of them being a failed project. SOA is expensive and complex. Its architecture has to be oriented towards the business and not IT, and should be, arguably, centralized (and there were opinions towards the opposite). SOA doesn't only bring IT process improvement but long-terms ROI. E.g. Wells Fargo had $300MM waste in architecture until they got it right with SOA and the expense on it paid by itself. Wells Fargo can fully absorb a new bank in 6 weeks.
The first session of the second day was my own. I talked about competitive advantages of adopting agile-lean, even more so in times of crisis. I'll be posting the ppt on my website shortly.
Rogelio Oliva took then the audience through a wonderful exercise on how manage your boss in a crisis. A recommended book that was used for this exercise is Adventures of an IT Leader.
Michael Mah showed measurements that show the impact (not pretty) about outsourcing and the benefits of using agile practices. It was followed by a discussion panel on the same subject, where it was mentioned that even though nearsourcing makes the time zone differences be less significant there are still cultural and communication problems that need to be solved. We have to also take advantage of the fact that the world is better interconnected than ever before to find alternatives to improve the the way we communicate while at the same time improving the current state of the planet (ecological crisis).
The third day was for workshops. I attended Bob Benson's on Filling the Governance Gap. It was fun half-day with discussions and guidance. The three keywords are:
- trust
- relationship
- process
For more highlights on what went on, in the words of presenters check my tweets @masakmaeda.
Wednesday, October 21, 2009
Ultrasist
Just out of a meeting with Ultrasist, the first Mexican company to achieve CMMI Level 5. They are actually a very progressive company definitely ahead of the average Mexican software dev company. What was actually cool is that the innovative mechanism they utilized to achieve level 5 was apply the principles of XP at design level (pair design). They didn't go about doing pair programming though or any other agile practice. However it may not take long before they start doing some adoption.
Friday, October 16, 2009
Agile Open California: day one at Northern CA
The first day at Agile Open California was quite a treat (started yesterday). For those unfamiliar with the concept of an open conference, the premise it to start with the conference with one common theme, in this case it was Agile in Changing Times, and from there the first activity of the conference after an intro by the organizers is an open invitation to all attendees (I mean, participants) to suggest any topic of interest. All topics are introduced elevator-speech style and posted in the market place together with a room and time from pre-filled post-its to avoid overlaps (this can be considered a high-level planning. Everybody then goes to the market place and initials what they are interested on. From there people gather at the set place/time to work on the topic; be it a presentation, discussion, hand-on work, game or whatever else they feel is the right thing to do. Although time is fixed people are free to continue their discussions if they wish and can move to any available space indoors or outdoors.
Elizabeth McClellan is an artist who volunteered to do drawings of the event and during the planning session. The image below is the drawing from the intro and high-level planning.
I participated at a Scaling Agile session proposed by three people (including me) and covered three aspects: scaling teams, scaling challenges at enterprise level and enterprise-enterprise scaling. Highest experience was on the first case and there was quite a bit of feedback and opinions on it such as keeping teams and meetings small, having the extra meeting such as when doing scrum of scrums, distributed training, distributed retrospectives, collocating as much as possible and being careful with overcrowding spaces. For the second case there was a bit less feedback but still good ideas and practices such as how to increase buy-in, bottom-up vs top-down approach and when to use them, etc. For the third case there was even less feedback since the case is not as common ad the other two so it ended up being more of a brainstorming session; and some ideas were the parent Co demanding the contracted Co to do agile (forcing agile… hummmm), emphasizing buy in at top level first, having devs from both companies work collocated.
The next session was also on scaling at enterprise level and discussions where around how to interact with non-dev teams, the difficulties of getting customers involved, and budgeting.
Next I attended a session on team coherence given by Joanna Zweig. This is a very interesting and important subject that has a follow up session today and I'll write a blog about it afterwards.
Richard Marks led a discussion on Trust-based Collaboration within a team, between teams, and at enterprise level. The aha! moment to me was Cesar Idrovo's sharing a personal experience that is becoming an agile principle, namely value the productivity of your team above your own. This is something I experienced intensely during my six years in Japan but have found very hard to see happen anywhere else. This principle could be a key change that.
Last was a session on leadership by Davil Chilcott that also has a follow up today so I'll write about it later.
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).
Wednesday, October 7, 2009
A principle to a better you, a better team, and a better enterprise.
Larry Gelwix, coach of the Highland Ruby Team (with a 413-9 win-loss record between 1984-2009), motivates his team to never do anything that will lessen themselves, their team, or their families. This principle can be applied to agile teams to never do anything that will lessen themselves, their team, or their enterprise. I consider this to be a key ingredient to achieve hyperproductivity.
Key ingredients to hyperproductivity: executives
For an enterprise to achieve hyperproductivity it is key that executives:
- Buy-in agile-lean and ensure that adoption takes place at all levels of the enterprise, not just at the bottom. Team effort really means corporate effort.
- Be involved by actively and continuously participating in the creation of the products and services the enterprise offers to its customers.
- Delegate decision making to the downline ensuring that decisions are made where it matters most and where more value is added.
- Let go of command and control over their organizations, and instead guide them.
- Provide service to their organizations by ensuring their employees have the means (tools and knowledge) to get the job well done.
Sunday, October 4, 2009
Code Camp '09
Attended Code Camp '09, held at Foothill College in the San Francisco Bay Area, on the first day (missed Sunday... preparing documents for my next business trip). The amount of attendees was quite quite possible higher than originally expected since some sessions were relocated last-minute to larger rooms. Organizers did a great job is making it very flexible in terms of logistics, reducing costs and increasing efficiency.
I focused on attending sessions from the Agile track and they all were fun, very relaxed and informative. Most of the contents were at introductory level and adequate to most of the audience. A good aspect was that the subjects of discussion were atomic which allowed a discussion-and-participation format instead of a lecture or presentation format. As result the attendees got most of their questions answered. Unsure if and how presentation slides will be published. I'll post another blog with such info once I have it.
I focused on attending sessions from the Agile track and they all were fun, very relaxed and informative. Most of the contents were at introductory level and adequate to most of the audience. A good aspect was that the subjects of discussion were atomic which allowed a discussion-and-participation format instead of a lecture or presentation format. As result the attendees got most of their questions answered. Unsure if and how presentation slides will be published. I'll post another blog with such info once I have it.
Wednesday, September 30, 2009
Making great customer service even better
It was yesterday that I finally went to the Apple store to get Snow Leopard for my macs and in addition getting a Time Machine / Airport which I needed bad since my old router had become more than just a pain. I was a happy camper upgrading my MacOS but the happiness started fading away as I proceeded with the installation of the Airport and started running into problems. At first I thought the problems were with Comcast, my ISP, since that's where the problems have been in the past. I tried several ways and none of them worked. I went to sleep late last night frustrated by the fact that I couldn't fix the problem.
This morning I contacted Comcast and they said things on their end looked good so I tried once again to no avail, at which point I contacted Apple. Mind you, Apple has great customer care and effectively they helped me out right away. Oh, but the bump on the road became clear when the Apple representative told me there is a known problem when setting a guest network and so I should not set that network until the fix is published by Apple hopefully soon.
If Apple knew about it how come they did not make that info readily available to (a) keep customers happy with an effective temporary solution instead of frustrating customers who wasted lots of time trying to make things work, and (b) reducing their operational expenses related to this issue?
Lean-Agile enterprises make sure that efficiency doesn't stop when the product is done but goes beyond those boundaries to reach post-production. Customer care is a paramount aspect of it. Being proactive instead of reactive reduces inventory, movement, and unbalance.
This morning I contacted Comcast and they said things on their end looked good so I tried once again to no avail, at which point I contacted Apple. Mind you, Apple has great customer care and effectively they helped me out right away. Oh, but the bump on the road became clear when the Apple representative told me there is a known problem when setting a guest network and so I should not set that network until the fix is published by Apple hopefully soon.
If Apple knew about it how come they did not make that info readily available to (a) keep customers happy with an effective temporary solution instead of frustrating customers who wasted lots of time trying to make things work, and (b) reducing their operational expenses related to this issue?
Lean-Agile enterprises make sure that efficiency doesn't stop when the product is done but goes beyond those boundaries to reach post-production. Customer care is a paramount aspect of it. Being proactive instead of reactive reduces inventory, movement, and unbalance.
Thursday, September 24, 2009
BayAPLN September meeting update
Joshua Kerievsky gave a presentation entitled Agile Brushstrokes in which he made an analogy between software development practices, particularly agile practices, and painting styles. He mapped how certain art styles such as baroque (romanticism) and coco are rich, elaborate, and time consuming just the way traditional software development is; and some agile practices that get too heavy on governance or other controlling/monitoring activities could also get there. Compared also with expressionism, cubism, and impressionism. He mentioned that Impressionist Agile is the point at which the team moves so fast and fluently that aspects such as iterations and backlogs start fading away to allow room for more fluidity, but made sure to point out that to get there it is very important to get the basics well-rooted.
Make sure to assimilate the values and principles, understand fully the methodologies, and practice them for a period of time before venturing into exploring new forms otherwise you may end up in the same--or worse--shape than you were before adopting agile.
Make sure to assimilate the values and principles, understand fully the methodologies, and practice them for a period of time before venturing into exploring new forms otherwise you may end up in the same--or worse--shape than you were before adopting agile.
Wednesday, September 23, 2009
The chasm after the chasm
Agile is no longer a competitive advantage. It is at the summit of the Early Majority, meaning, either you do it or be left behind.
Monday, September 14, 2009
Micro-scrumming
Last week I visited Financiera Independencia (a large nation-wide microfinancing company in Mexico) after having trained 18 staff over a month ago. It caught my attention that one of the engineers had on his cubicle storage a micro version of a scrum table. He said it is very useful to him to manage his own tasks following the scrum structure. I thought it was both cool and cute.
Saturday, September 12, 2009
A good start, part 2: Get your executives on the same page
After training Bursatec on scrum and itroductory-level agile management, I had the opportunity to give a brief talk to the executive team of Indeval--the intitution in charge of financial assets within the Mexican Stock Exchange. All excecutives were very receptive and discussions were right on target although short due to time limitations. I think there was a good outcome and executives seem interested on learning more.
It was easy to see why Indeval is such a successful enterprise: executive involvement, timely decsion making, front-running, investment on infrastructure and personnel improvement. Their current work towards lean-agile adoption is an important step forward as well.
Their got a good start and I look forward to working with them on stage 2 of their lean-agile adoption consulting for them and providing more training.
Friday, September 4, 2009
A good start, part 1: Include your customers from day one.
I spent the last three days training around 30 people from Bursatec, one of the most important financial systems enterprises in Mexico, which is responsible for the software systems for most of the Mexican stock exchange . The attendants showed lots of interest through their continuous participation, discussions and questions. It was great how inquisitive they were because it showed legitimate interest on learning Agile-Lean, how to use it effectively, and identifying what is beyond its scope. One important area of difficulty they emphasized upon was governance; not from the agile-lean standpoint but rather from the regulatory side in terms of allowing things to be done that way.
Of all things, the one I particularly liked was that for the first time I had a group where participants included the actual customers (2 of them). That gave a great opportunity to both the P.O.s and the customers to better understand how important they are in the success of their projects and the right way to do their part to be successful.
Kudos to Bursatec for a good start!
Of all things, the one I particularly liked was that for the first time I had a group where participants included the actual customers (2 of them). That gave a great opportunity to both the P.O.s and the customers to better understand how important they are in the success of their projects and the right way to do their part to be successful.
Kudos to Bursatec for a good start!
Thursday, August 27, 2009
Company evaluations from latinamerican customers' perspective
One of the first activities with potential customers is to perform a company evaluation and to present a proposal. My first direct contact with potential customers is often through a presentation on agile-lean and the services I offer. As result, they usually request a quote. I offer them two options: either a rather shrink-wrapped quote or a customized solution that will require a company evaluation. The evaluation has a small cost and 75% of that amount is deducted if they accept my consulting services.
Paying for an evaluation is common practice in the USA and customers actually like a lot the option of the cost deduction. My experience in Mexico has been quite different. Most companies do want an evaluation but are reluctant to pay for it, arguing that it should be part of the bid effort to win a contract. I explain to them that the evaluation goes beyond a small set of questions focused only on a project; it is an in-depth analysis of diverse aspects of the company to understand and determine how agile-lean can significantly improve they way they create their products and services, and it will require two to three days worth of work. Furthermore, the evaluation provides them with information that can help them make better decisions on diverse aspects of the company and its projects. Their point of view remains unchanged and I had instances in which they were happy with the evaluation but didn't proceed with giving me a contract.
An strategy that I started applying recently for such case is do just enough to gather the information to generate a good proposal and report to them the results in a meeting (showing spreadsheet tables and diagrams) but don't give them the document itself. If they see value in it and want it then they have to pay for that service; and if by then they want it more detailed then I proceed to continue the evaluation at a deeper level only if payed in advance.
Sunday, August 23, 2009
Test-early, test-often
The recent news on instances of iPhone 3GS oveheating and even exploding brings an opportunity to revisit the importance of testing early and testing often. Every software and hardware technologies have aspects that are hard to test and it is not uncommon for a new product to have flaws that need to be fixed shortly after release to market. One reason for it is that the market itself is the best test environment possible. Most problems encountered have to do with either scalability, use flow, or extended usage. The second and third kind can be minimized if the product is used for as long as possible and played with at all times. A very important factor to increase the efficacy of this test-early test-often strategy is to make sure that feature prioritization takes into account risk-value factor. What this means is that the features that add more value and are of higher risk should be developed first so that the level of risk decreases over time thanks to intensive and extensive testing.
Thursday, August 20, 2009
This is a great time for Mexican enterprises to invest on technology
Carlos Slim, a mexican entrepreneur and one of the richest men in the world, invited Mexican entrepreneurs to invest and to be prepared for the recovery in the economy. Carlos said that this and next year are a great time to invest (quoting him: "Creo quye este año y el que entra son buena época para invertir"). He also pointed out that technology is a key industry on which to invest.
Click here or here for more information.
Click here or here for more information.
Tuesday, August 18, 2009
North BayAPLN August meeting note
I'm back home from this month's North BayAPLN meeting, which took place at the Salesforce building in Market St, San Francisco. David Chilcott, principal at Outformations, gave a presentation on Effective agile meetings. The premise is to apply lean thinking and to extrapolate scrum practices to the way we plan and conduct meetings, and that by doing so meetings become cost effective and productive.
David suggests to manage a meeting as a sprint where the agenda is the backlog, an agenda item a feature, the desired outcome a user story, the agenda item owner is the product owner, etc.. Amongst other things he also talked about having roles and responsibilities within the meeting attendants, which I think is cool because not only the roles can rotate bu also because, and this is my point of view, is a subtle way to get attendants more involved and as result more attentive and productive. His presentation is available at the Outformations website.
Same as with agile-lean, most of what effective agile meetings is about is actually common sense. And as with agile-lean, even being common sense meetings are rarely planned and done right (or just good enough, if you know what I mean) until it is presented in a "formal" way.
David suggests to manage a meeting as a sprint where the agenda is the backlog, an agenda item a feature, the desired outcome a user story, the agenda item owner is the product owner, etc.. Amongst other things he also talked about having roles and responsibilities within the meeting attendants, which I think is cool because not only the roles can rotate bu also because, and this is my point of view, is a subtle way to get attendants more involved and as result more attentive and productive. His presentation is available at the Outformations website.
Same as with agile-lean, most of what effective agile meetings is about is actually common sense. And as with agile-lean, even being common sense meetings are rarely planned and done right (or just good enough, if you know what I mean) until it is presented in a "formal" way.
Wednesday, August 12, 2009
SG article on Agile-lean with standards and models
Software Guru published my article on agile-lean with standards and models, which has two objectives. I try to clarify the distinction between standards, models, and values because I often see people use them as if they meant the same and because they are used the wrong way in practice. I also indicate some ways in which agile-lean can be used in enterprises that require governance under a standard or a model.
The contents of the article published are edited from the original article I sent, which is often the case when publishing articles on a magazine. For those of you who would like to read the original you can find it on my website's documents page under the title:
The contents of the article published are edited from the original article I sent, which is often the case when publishing articles on a magazine. For those of you who would like to read the original you can find it on my website's documents page under the title:
- Spanish version: "Beneficiando estándares y modelos mediante agile-lean"
- English version: "Agile-lean benefits standards and models"
The importance of good software development in Financial Institutions
Mario Sandoval, president of the AMFE (Asociación Mexicana de Entidades Financieras Especializadas) announced that real state development is key to reactivate the financial market. On a similar note, Stefano M. Stoppani, Principal Director or CRIFMexico and Regional Director for Latinamerica, mentioned back in February that proactive fianancial management infrastructure (for payments) requires the usage of four aspects to allow for the right decisions to be made and for efficient execution:
On the software side we have methodologies such as scrum, XP, etc. that increase the efficiency of teams and the overall quality of the software generated. On the process and organization side we have agile-lean project management which creates a better structure for all stakeholders, including customers, to collaborate and make decisions. Agile databases enables data modeling and their implementation to be done more effectively. Good modeling is crucial to good analysis and agile modeling provides waste-elimination ways to do so without consuming vast amounts of time and resources.
- software
- processes and organization
- data
- analysis
On the software side we have methodologies such as scrum, XP, etc. that increase the efficiency of teams and the overall quality of the software generated. On the process and organization side we have agile-lean project management which creates a better structure for all stakeholders, including customers, to collaborate and make decisions. Agile databases enables data modeling and their implementation to be done more effectively. Good modeling is crucial to good analysis and agile modeling provides waste-elimination ways to do so without consuming vast amounts of time and resources.
Tuesday, August 4, 2009
Partnership with Nagarro
The partnership with Nagarro was finalized last June 6. Nagarro (http://www.nagarro.com/) is an outsourcing company with offices in the USA amd Europe, and with software development facilities primarily in India. The partnership benefits Nagarro as a new opportunity to start penetrating the Latin American market. It allows Shojiki Solutions to offer high caliber outsourcing services to its customers in the USA and Latin America.
Jim Highsmith's new book
I had the opportunity to meet Jim Highsmith at the Marriott Hotel in Mexico City's Reforma, where he gave a course on Agile Project Management through the Cutter Consortium. Jim is a very enjoyable person with a great sense of humor and enough anecdotes on agile to entertain people for weeks.
Started reading the recently published second edition of his book Agile Project Management: Creating Innovative Products. This book is to become a must-read for all people interested on Agile, whether or not they already practice it. It covers from the basics to in-depth aspects of project management that are of high concern to enterprises of any size. The focus is very practical and it is organized in a way that introduces people new to APM in a fluent way. The first portion of the book, chapters 1 to 5, introduces some practical principles and a model as a means of introduction. The second part, chapters 6 to 10 explains the different phases in which a project can be structured. The third part focuses on scalability, governance, cost, schedule, and scope; all of them issues of high concern for companies considering agile adoption. The final chapter discusses the need for a shift in thinking about how we develop products.
Reading this book will save you the need to read a large amount of other literature oh the same subject.
Started reading the recently published second edition of his book Agile Project Management: Creating Innovative Products. This book is to become a must-read for all people interested on Agile, whether or not they already practice it. It covers from the basics to in-depth aspects of project management that are of high concern to enterprises of any size. The focus is very practical and it is organized in a way that introduces people new to APM in a fluent way. The first portion of the book, chapters 1 to 5, introduces some practical principles and a model as a means of introduction. The second part, chapters 6 to 10 explains the different phases in which a project can be structured. The third part focuses on scalability, governance, cost, schedule, and scope; all of them issues of high concern for companies considering agile adoption. The final chapter discusses the need for a shift in thinking about how we develop products.
Reading this book will save you the need to read a large amount of other literature oh the same subject.
Monday, August 3, 2009
Embracing scrum
I recently gave a series of training courses on scrum and XP to a company in Latin America which, after much negotiation, decided they only needed training but no consulting. The majority of the participants in the courses haven't had any contact with agile or lean in the past, including the 3 managers who were also attending. As I expected, there were 3 kinds of attendants: the enthusiastic ones, the "am here because I was sent to attend" ones, and the skeptic ones. The second kind of attendants got enthusiastic reasonably quickly. The skeptic ones, on the other hand, happened to be the managers and they were having a hard time just being there during most of the first day. Imagine their reactions when I talked about the need to let go of command and control, empowering the team, the "waiter" metaphor about what their role in the team should be, etc.
I should say I admire that non of them gave up on me and continued attending the course. I was trying to figure out a way to make them appreciate the concepts better and decided to do two things. The course includes two or three small exercises, and one 3.5-hour lon
g hands-on scrum session of 4 sprints. During the small exercises I made sure the managers were performing teammate roles instead of leadership roles because I wanted to recall what it is like to be on that side of the group structure. I typically do the same for the scrum exercise because it has proven to give me better results, however in this case I decided to assign the managers as scrum masters and as product owners. The strategy worked great. They were a bit confused at first trying to apply their command and control skills together with other ones they typically use, but throughout the exercise they allowed me to guide them through and by the third sprint all the teams were working fabulously.
The following week I paid a visit to the company and was pleasantly surprised to see one the managers applying things they learned during the training. There was one in particular who had embraced the methodology fully within his team and was pushing his boss hard to convince him that they needed to extend the scope to cover customers. The director agreed and I am now preparing the ground to start giving consulting to them and their customers.
I should say I admire that non of them gave up on me and continued attending the course. I was trying to figure out a way to make them appreciate the concepts better and decided to do two things. The course includes two or three small exercises, and one 3.5-hour lon
g hands-on scrum session of 4 sprints. During the small exercises I made sure the managers were performing teammate roles instead of leadership roles because I wanted to recall what it is like to be on that side of the group structure. I typically do the same for the scrum exercise because it has proven to give me better results, however in this case I decided to assign the managers as scrum masters and as product owners. The strategy worked great. They were a bit confused at first trying to apply their command and control skills together with other ones they typically use, but throughout the exercise they allowed me to guide them through and by the third sprint all the teams were working fabulously.The following week I paid a visit to the company and was pleasantly surprised to see one the managers applying things they learned during the training. There was one in particular who had embraced the methodology fully within his team and was pushing his boss hard to convince him that they needed to extend the scope to cover customers. The director agreed and I am now preparing the ground to start giving consulting to them and their customers.
Saturday, June 6, 2009
"...b b but I was only being agile"
A company I was working with had an important release to production coming. At the same time the CTO was working on a prototype for a future feature and everybody was clear on that. Since I was in charge of product releases I made sure everything was ready to "push the button" to production the day before the set date and went home with peace of mind, only to arrive to the company the next morning to discover that the push to production had included the feature the CTO was prototyping. Needless to say I was a very unhappy camper, and although the feature didn't break anything it was not production-ready. We had a meeting with executives about an hour later and I brought the issue to everybody's attention, to which the CTO replied that he pushed the feature without consulting anybody because, quote "...b b but I was only being agile", end quote. To which I replied "there is a big difference between being agile and doing something that has absolutel nothing to do with agile and could've createed a permanent scar on the company's reputation!".
Yes, I was quite bold and, yes, everybody had their eyes wide open because I confronted the CTO in a way others wouldn't dare to even consider. The company already had a long history of people trying to cut corners under the excuse of being agile and I knew that if managers and executives did not set the right example then individual contributors would also feel entitled to continue doing so. All features pushed to production from that day on went through the right process.
Yes, I was quite bold and, yes, everybody had their eyes wide open because I confronted the CTO in a way others wouldn't dare to even consider. The company already had a long history of people trying to cut corners under the excuse of being agile and I knew that if managers and executives did not set the right example then individual contributors would also feel entitled to continue doing so. All features pushed to production from that day on went through the right process.
Monday, May 11, 2009
Partnership with Version One
Shojiki Solutions has partnered with Version One. This will increase que quality of service to my customers. I like the tool because of its ease of use and its slim approach in that it allows users to spend more time doing agile than using the tool. :-)
Monday, May 4, 2009
Writing about agile while confined to avoid getting Swine Flu
Arrived to Mexico City on business last April 27 just two hours short of the WHO’s request to close Mexico's borders due to the swine flu. Not surprising, this has been the less productive of all my business trips: For example my last 10-day trip included 12 meetings and 3 presentations. This 14-day trip I ended up with lots of cancelations and so far have had 3 meetings and if nothing else is cancelled will have one meeting and one presentation before returning to the USA in six days. I even got to experience no traffic in Mexico City, wow! Better be safe than sorry, right? Streets are empty and remind me of a scene from the Spanish movie "Abre Los Ojos", remade as "Vanilla Sky" in English. Fortunately, I am staying at a very safe place, away from public contact and have been feeling as well as usual.On the bright side, this has given me time to take some rest and do some writing, including an article on agile, standards, and models to be published on the Software Guru magazine this summer, and preparing some more training materials.
Mexico City traffic, vendors and self-organization
Everybody who has ever visited Mexico City for sure remembers the traffic. Think New York City traffic is bad? ...think again! A few decades ago the expressways and highways, although small for USA standards, were fast and a joy to ride. Nowadays traffic is so bad that on a recent day while stuck in bumper-to-bumper traffic on Viaducto (an expressway) I saw locals walking in between lanes selling all sorts of things, from sodas to cigarettes, chewing gum, fruit, etc.; they even had banners posted on the expressway’s walls announcing products and prices.What amazed me the most was how efficient those people were. Keep
ing an eye on which lanes were moving more slowly to shift from one to the other so maximize the chances of making a sale. Monitoring the overall traffic to determine if they should step aside for a few minutes or stay put and increase sales. They are also distributed along the road so that each person has a “reasonable number of customers”. They knew intuitively that it was better to disperse along the road when cars where moving at a slow steady pace, and to get closer together but in between different lanes when cars were barely moving. I was amazed by the efficiency of their self-organization.I started thinking about how I’ve seen development teams be less efficient when they are being managed, thus waiting for a decision-maker to come and order changes, and how much more efficient they become when they self-organize. It is better to identify the demands of task-at-hand, assess the situation, determine a course of action, and act.
Thursday, April 30, 2009
Moprosoft and agile: can do
Back in 2001, the same year the Agile Manifesto was published, the Secretary of The Economy in Mexico created a national program for software development and called it Prosoft. The program's objective was for the software development industry in Mexico to reach levels that compete internationally; an ambitious goal with no execution plan. The initial efforts consisted on evaluating the ISO-9000, ISO 15504, SW-CMM, CMMI and concluded that none were adequate because "they do not comply with the requirements expressed by the national industry". I think it is good that their conclusion was not to use any of those standards or models although I fail to see what the difference would be between software development in Mexico and anywhere else in the planet, besides cultural aspects, to the point of needing a new model to be developed. Writing good software and being effective in developing it should be a basic premise anywhere. As result, the Mexican Association for Quality in Software Engineering (AMCIS) collaborated with the National University of Mexico to develop their own model for the Mexican small and medium size software companies and called it Moprosoft (http://www.comunidadmoprosoft.org.mx/).
In a nutshell, Moprosoft was developed over several years and in 2005 was declared a Norm to be utilized by the software industry in Mexico; it is documented in four volumes and most of its definition is a mapping of ISO/IEC 15504 and SW-CMM to what they considered adequate for software development within the boundaries Prosoft established. One addition they made was the inclusion of a large set of templates that need to be followed to document the design and implementation of the entire development cycle. There is five levels of compliance similar to those on some standards and models. Moprosoft definition is published in four volumes. Last but not least, the ISO is on its final stage of approval to accept it as one more of its standards. At industry level, this meant that the Secretary of The Economy established it as a standard that software development organizations in Mexico must follow and the ripple effect is on with adoption in several countries in Latin America.
Those of you who do agile might be thinking “oh no, it happened again” or something along those lines with respect to the friction dealing with standards and models. The question is how to do agile development under those circumstances. We have learned how to be agile even under an ISO or a CMM/CMMI environment and even some ISO auditors have learned the benefits of accepting documentation a-la-agile. The trick with Moprosoft is that the model not only establishes what to do but also includes detailed definitions on how to do it in the form of templates, think big-process-up-front.
The intention of this blog is to start a discussion and I’ll begin with some observations. Moprosoft adoption has serious disadvantages such as:
- BPUF. Four volumes of documentation and numerous templates imply a steep learning curve. For a software organization to be ramp up an achieve compliance it will be necessary to delay release dates
- Agility loss. The high level of detail to document imply that changes in the process will require big process adjustment effort, which will further delay projects and discourage software teams to do improvements over the products developed
- Slowness. Technologies evolve more rapidly than we can keep up with and having a heavyweight process in place makes it even harder to stay up to date
- Time to market is compromised. this is critical to business success and the friction that comes with compliance might just be the one thing that makes a company lose against the competition
- Productivity doesn’t improve. Because this is a repeat-for-each-project activity the friction remains no matter how many projects are developed under the model
- Creativity loss. Also, the time spent doing compliance work is time that could be much better spend doing creative work for the product being developed
One other aspect to consider is that in practice most teams use models as if they were standards, and that adds even more friction because standards establish a process to be followed whereas models recommend a methodology to take as starting point from which to customize. So, one interesting aspect with Moprosoft is that it was created as a model but it is now about to become a standard!
The best approach to the problem, IMO, is not to follow the model and instead adopt agile practices. For those teams who already have no alternative but to be in compliance my suggestion would be that instead of aiming for level 5 compliance they should be as lightweight as possible to remain within level 3, which is what is considered a good-practice level of compliance and use agile for the planning, estimating, and implementation/test process. Fit the practice within the templates and show auditors how the agile practice works within compliance and how it is also more effective than traditional practices.
Saturday, April 11, 2009
Lean Manufacturing for electric manufacturing companies
My last business trip to Mexico included meetings with two electric manufacturers. One of them had a fairly good level of manufacturing process in place, with an reasonably clean/ordered plant and a good skill set baseline. The other one had a rather chaotic atmosphere: overcrowded in some areas, extremely hot, and with some workers building several different items at the same time. The commonality they have is the quality of their products is hurting them although, and surprisingly, the first factory more than the second one. Although both companies are profitable they lose money in the faulty products they produce and one of them even lost it's most important customer.
Both companies keep ISO compliance but the time/money consuming compliance activities have done little, if anything, to fix their problems. One first one has made efforts to follow JIT and Six Sigma but to no avail. I noticed during the visit to their plants two common denominators. They both hace a genuine interest on improving their processes; and they have received very limited coaching on how to implement and enforce a good manufacturing process.
I gave them a presentation on Lean Manufacturing and how it may help them produce better products and potentially get their workers to be more productive. Their response was enthusiastic and now it is a matter of them deciding if they want to give Lean a shot.
Both companies keep ISO compliance but the time/money consuming compliance activities have done little, if anything, to fix their problems. One first one has made efforts to follow JIT and Six Sigma but to no avail. I noticed during the visit to their plants two common denominators. They both hace a genuine interest on improving their processes; and they have received very limited coaching on how to implement and enforce a good manufacturing process.
I gave them a presentation on Lean Manufacturing and how it may help them produce better products and potentially get their workers to be more productive. Their response was enthusiastic and now it is a matter of them deciding if they want to give Lean a shot.
Saturday, March 21, 2009
Hell's Kitchen needs some Agile and Lean lessons
I love cooking. Graduate school was overseas and the food at both the university's cafeteria and the local restaurant were less than appetizing despite of the great sea food, vegetables, and other goodies available at the market just a mile away, so I decided to take matters into my own hands and stated cooking. To my own surprise cooking was fun and easy; and I was good at it, thankfully because very few times I ate my food thinking I rather be eating at the cafeteria.
Although it is quite rare for me to watch cooking shows I have fun watching Hell's Kitchen. For those of you who don't know the show: there is this famous Chef Gordon Ramsay who recruits 16 contestants (8 women and 8 men) in two teams to compete cooking for guests at the restaurant under the same name as the show and eliminate one contestant from the losing team at the end of each episode. The winning team is treated big time with an outing to an upscale place, and the losing team has to do some quite nasty chores. The most fun part, from my point of view, is when the restaurant opens and the teams have to cook the orders because the entire kitchen turns chaotic very quickly. Food gets burned, undercooked, ingredients are missed, portions of one same dish are prepared at different times, contestants within the same team disrespect each other, customers get quite unhappy... and Chef Ramsay's shouting madly at the contestants until there is no way to save the night and the restaurant is shutdown for the night ahead of time. I don't watch the show all the time but from the couple dozen episodes I've seen out of five seasons service was completed only twice. That success record is embarrasing at the least.
Why does that happen? Both teams have strong motivation to win: not being eliminated and being treated like royalty. So, why things continuously turn bad? Here's my take on it:
- Poor communication: the team members don't communicate with each other to know who is doing what, keep their timings right, and help each other.
- Upfront planning: it would be a waste to plan how the entire evening will go because such plan would become obsolete within the first three minutes of receiving the first order; however they should all have a high-level strategy in place so that they know what to expect from each other.
- Slow to adapt: once one thing goes wrong problems escalate because they have a hard time adapting to the customer demands and the state of the kitchen
- Movement: as things start going wrong and escalate the contestants start moving around a lot more and more quickly. Such frenzy only delays things further and make it so much easier to make mistakes. They should help each other more instead.
- Lack of self-organization: were they better organized among themselves most problems would not occur.
- Lack of respect: Although it is a competition, if they respected each other they would work better as a team and significantly increase the chances of winning
Does that sound to you like what is going on in your organization or what happened at a previous job? I have many memories of projects going wrong for different combinations of the same reasons.
A very effective way to overcome those issues is by following the Agile and Lean principles. Effective communication facilitates self-organization which significantly reduces movement. High-level upfront planning allows the team predict each others actions more effectively and how to help each other. Continuously adapting to the current situation produces more and better results more quickly. And last but no least is the respect for each other, which not only makes working together more enjoyable but also increases productivity.
Although it is quite rare for me to watch cooking shows I have fun watching Hell's Kitchen. For those of you who don't know the show: there is this famous Chef Gordon Ramsay who recruits 16 contestants (8 women and 8 men) in two teams to compete cooking for guests at the restaurant under the same name as the show and eliminate one contestant from the losing team at the end of each episode. The winning team is treated big time with an outing to an upscale place, and the losing team has to do some quite nasty chores. The most fun part, from my point of view, is when the restaurant opens and the teams have to cook the orders because the entire kitchen turns chaotic very quickly. Food gets burned, undercooked, ingredients are missed, portions of one same dish are prepared at different times, contestants within the same team disrespect each other, customers get quite unhappy... and Chef Ramsay's shouting madly at the contestants until there is no way to save the night and the restaurant is shutdown for the night ahead of time. I don't watch the show all the time but from the couple dozen episodes I've seen out of five seasons service was completed only twice. That success record is embarrasing at the least.
Why does that happen? Both teams have strong motivation to win: not being eliminated and being treated like royalty. So, why things continuously turn bad? Here's my take on it:
- Poor communication: the team members don't communicate with each other to know who is doing what, keep their timings right, and help each other.
- Upfront planning: it would be a waste to plan how the entire evening will go because such plan would become obsolete within the first three minutes of receiving the first order; however they should all have a high-level strategy in place so that they know what to expect from each other.
- Slow to adapt: once one thing goes wrong problems escalate because they have a hard time adapting to the customer demands and the state of the kitchen
- Movement: as things start going wrong and escalate the contestants start moving around a lot more and more quickly. Such frenzy only delays things further and make it so much easier to make mistakes. They should help each other more instead.
- Lack of self-organization: were they better organized among themselves most problems would not occur.
- Lack of respect: Although it is a competition, if they respected each other they would work better as a team and significantly increase the chances of winning
Does that sound to you like what is going on in your organization or what happened at a previous job? I have many memories of projects going wrong for different combinations of the same reasons.
A very effective way to overcome those issues is by following the Agile and Lean principles. Effective communication facilitates self-organization which significantly reduces movement. High-level upfront planning allows the team predict each others actions more effectively and how to help each other. Continuously adapting to the current situation produces more and better results more quickly. And last but no least is the respect for each other, which not only makes working together more enjoyable but also increases productivity.
Sunday, March 15, 2009
More comments on SDWEST´09
Agile vs. Traditional
On Wednesday, March 11, Scott Ambler and Terry Quatrani gave a fabulous keynote about traditional vs. agile sw dev. The setting was Scott playing a ¨hello, I am PC" role representing the traditional approach, and Terry playing the "hello, I am Mac" role representing Agile. Those of you who know Scott Ambler can very well imagine how hard it was for him to play his role, given the strong advocate to Agile that he is. In a very entertaining fashion and with the help of some images they showed aspects of tradional sw dev and how agile approaches the same issues. Terry's catch phrase for the keynote was "...delivering what the customer wants!"
Scott then proceeded to show some of Dr. Dobb's survey results, showing some eye opening results showing that agile teams do more modeling and generate almost as much documentation as their Traditional counterparts. Maybe more surprising were the results showing that team distribution is less affected by agile than by traditional organizations; i.e., Agile teams have a higher success rate.
Note: Source for the following diagrams was taken from Scott Ambler's 2008 survey via Dr Dobbs. The modeling diagram is a manicured version of the table he published.
Strategy for modeling
Documentation
Success rate
Jolt Awards
The oscars of the software industry. For a list of this year's Jolt Awards visit http://www.joltawards.com/winners.html
On Wednesday, March 11, Scott Ambler and Terry Quatrani gave a fabulous keynote about traditional vs. agile sw dev. The setting was Scott playing a ¨hello, I am PC" role representing the traditional approach, and Terry playing the "hello, I am Mac" role representing Agile. Those of you who know Scott Ambler can very well imagine how hard it was for him to play his role, given the strong advocate to Agile that he is. In a very entertaining fashion and with the help of some images they showed aspects of tradional sw dev and how agile approaches the same issues. Terry's catch phrase for the keynote was "...delivering what the customer wants!"
Scott then proceeded to show some of Dr. Dobb's survey results, showing some eye opening results showing that agile teams do more modeling and generate almost as much documentation as their Traditional counterparts. Maybe more surprising were the results showing that team distribution is less affected by agile than by traditional organizations; i.e., Agile teams have a higher success rate.
Note: Source for the following diagrams was taken from Scott Ambler's 2008 survey via Dr Dobbs. The modeling diagram is a manicured version of the table he published.
Strategy for modeling
Documentation
Success rate
Jolt Awards
The oscars of the software industry. For a list of this year's Jolt Awards visit http://www.joltawards.com/winners.html
Monday, March 9, 2009
Software Development West conference and expo 2009, day 1
This year's SDWest (http://www.sdexpo.com/2009/) is being dominated by tutorials and classes on diverse Agile subjects.
Tutorials and Keynotes
Classes, case studies, and panels
The first session I attended started at 8:30 AM and the last activity ended at 8:30 PM. Needless to say I am happy to be back home relaxing at the couch. Here's some notes on what I attended:
a) Gerard Meszaros gave a tutorial on how things that need to be considered when going from concept to product backlog. Most practitioners have tend to pay attention to the activities closer to the implementation such as stories, use cases, and unit tests; and spend less time, if any, on the what needs to be done to translate the customer's concept into the right design. That is no design is as bad as BDUF because we end up with story blinders. Such lack of functionality not only delays projects but are a source for the need to redesign later on; and under-designing is as bad as over-designing. Projects require an iteration zero to do up-front planning. Five levers need to be covered: Product vision; product roadmap; release plan; iteration plan; and daily plan
b) Robert C Martin, a.k.a. uncle Bob, gave a keynote speech in his usual entertaining and engaging way about the state of the art of XP after ten years of existence (actually more since it started in 1995) . He is quite a showman as a presenter. Taking as starting point the xp diagram he pointed out that scrum covers the outer ring only. Scrum has been extremely successful because it talks at a business level in a way that the business people can understand and makes them more likely to buy in the methodology. The innermost layer is the geeky layer and the middle layer is the glue that sticks the other two together. The success of Scrum has been so tremendous that XP has been falling behind in terms of adoption. This is a very dangerous thing because agile loses effectiveness without good practices. The result is that blindly following scrum leads us to think we are moving fast whereas we are not because over time the cycles become harder to keep up with due to the code being harder and harder to maintain.. This doesn't mean agile is bad; it isn't because it exposes the problems and traditional/waterfall doesn't. What it means is that we need to raise the bar as programmers. This brings the central point of his presentation: we need to develop good software, period. Robert also pointed us to the Manifesto for Software Craftsmanship (http://manifesto.softwarecraftsmanship.org/main) which was put together very recently.
Raising the bar.
Manifesto for Software Craftsmanship As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009
c) Scott Ambler gave a tutorial on Agile Model Driven Development (AMDD) with two focus points:
The negative impact that traditional and waterfall approaches to software development have on productivity, quality, and deliverables. And the importance to drive our agile activities based on practice vs theory. Throughout the entire tutorial Scott went over and over again on the importance to plan and act honestly in the best interest of the success of the product and the organization. Regarding modeling he pointed out that the right model to use is the one that best communicates with the target audience keeping focus on the product's construction with the goal to develop a high quality system. Another important factor for large organizations is scaling distributed teams making sure that the minimum necessary up-front design is made. Note that this doesn't mean BDUF but that a larger amount of design is needed for larger teams than for small and for colocalized teams. Also, for remote teams it is more effective to divide the work based on product features than on job function because that reduces the amount of remote communication needed; although strong coordination will still be needed.
Tutorials and Keynotes
Classes, case studies, and panels
The first session I attended started at 8:30 AM and the last activity ended at 8:30 PM. Needless to say I am happy to be back home relaxing at the couch. Here's some notes on what I attended:
a) Gerard Meszaros gave a tutorial on how things that need to be considered when going from concept to product backlog. Most practitioners have tend to pay attention to the activities closer to the implementation such as stories, use cases, and unit tests; and spend less time, if any, on the what needs to be done to translate the customer's concept into the right design. That is no design is as bad as BDUF because we end up with story blinders. Such lack of functionality not only delays projects but are a source for the need to redesign later on; and under-designing is as bad as over-designing. Projects require an iteration zero to do up-front planning. Five levers need to be covered: Product vision; product roadmap; release plan; iteration plan; and daily plan
b) Robert C Martin, a.k.a. uncle Bob, gave a keynote speech in his usual entertaining and engaging way about the state of the art of XP after ten years of existence (actually more since it started in 1995) . He is quite a showman as a presenter. Taking as starting point the xp diagram he pointed out that scrum covers the outer ring only. Scrum has been extremely successful because it talks at a business level in a way that the business people can understand and makes them more likely to buy in the methodology. The innermost layer is the geeky layer and the middle layer is the glue that sticks the other two together. The success of Scrum has been so tremendous that XP has been falling behind in terms of adoption. This is a very dangerous thing because agile loses effectiveness without good practices. The result is that blindly following scrum leads us to think we are moving fast whereas we are not because over time the cycles become harder to keep up with due to the code being harder and harder to maintain.. This doesn't mean agile is bad; it isn't because it exposes the problems and traditional/waterfall doesn't. What it means is that we need to raise the bar as programmers. This brings the central point of his presentation: we need to develop good software, period. Robert also pointed us to the Manifesto for Software Craftsmanship (http://manifesto.softwarecraftsmanship.org/main) which was put together very recently.
Raising the bar.
Manifesto for Software Craftsmanship As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009
c) Scott Ambler gave a tutorial on Agile Model Driven Development (AMDD) with two focus points:
The negative impact that traditional and waterfall approaches to software development have on productivity, quality, and deliverables. And the importance to drive our agile activities based on practice vs theory. Throughout the entire tutorial Scott went over and over again on the importance to plan and act honestly in the best interest of the success of the product and the organization. Regarding modeling he pointed out that the right model to use is the one that best communicates with the target audience keeping focus on the product's construction with the goal to develop a high quality system. Another important factor for large organizations is scaling distributed teams making sure that the minimum necessary up-front design is made. Note that this doesn't mean BDUF but that a larger amount of design is needed for larger teams than for small and for colocalized teams. Also, for remote teams it is more effective to divide the work based on product features than on job function because that reduces the amount of remote communication needed; although strong coordination will still be needed.
Sunday, March 8, 2009
First Posting! Catching Up
Hello all,
This is my first blog posting so I am formatting it as a catch-up bullet list.
This is my first blog posting so I am formatting it as a catch-up bullet list.
- Mar 3: Software Guru magazine wants me to write an article on Agile for their special issue to be published this summer. I will be writing about Agile and how it fits with standards and models, particularly with MoProSoft
- Feb 1~12: Back to Mexico. Followed up with some companies on deciding to adopt agile. Some of them are still enthusiastic but are yet to decide, in addition that March is the time to plan budget for the year so delays are expected. One government company is going really slow and will need a lot of effort from my side to get them to put the proposal on the right hands for approval. Also had a first meeting with a couple of small companies, both curious to learn more about agile.
- Jan 12~22, 2009: First business trip to Mexico. Gave a presentation on Agile to the Asociación Mexicana de Informática (AMIAC) at the National University of Mexico. There was a lot of enthusiasm from the attendants and most of their question were related to how to make Agile function with standards (ISOs) and models such as CMMI. I met with executives from 3 companies, one of them government, to present my services. Also met with Hanna Oktaba, director of ProSoft, to talk about their MoProSoft standard. The central aspect of the trip was to learn that most Mexican industries are very tightly bonded with standards and small software service companies seem to have no much choice but to abide by those rules. What I found somewhat unfortunate is that there is no much awareness of Agile and its benefits; and although there are some big Mexican companies that already do agile (most of them banks) the existence and use of agile is yet to gain momentum there. On the bright side of things some people showed interest and communication with them is ongoing. In conclusion I realized that it will take a lot of effort to get Mexico to adopt agile.
Subscribe to:
Posts (Atom)