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.
Dec 8, 2009
Dec 1, 2009
Nov 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.”
Nov 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.
Nov 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.
Nov 5, 2009
A failed scrum project in pictures...
Oct 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.
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.
Oct 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.
Oct 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.
Oct 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).
Oct 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.
Oct 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.
Sep 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.
Subscribe to:
Posts (Atom)