A Halloween Story: The Imminent Death of an Enterprise

My last blog posting on Cutter...

http://blog.cutter.com/2010/10/29/a-halloween-story-the-imminent-death-of-an-enterprise/

Competencia en trabajo de conocimiento es algo malo

Wow! Such a long time without posting. Too much going on with the business and I feel ashamed for the lack of posting. Here's an email response I sent to a person in Peru regarding competence vs collaboration:

Agile nos recomienda que cuando tenemos que llevar a cabo una evaluación, tal como por ejemplo para determinar una herramienta a adoptar, es mucho mas efectivo evaluarlas todas al mismo tiempo en lugar de una a la ves. Esto es adecuado porque reduce el monto de tiempo que toma llevar a cabo las actividades de evaluación.

La manufactura lean (entiendase Kaizen) nos dice que el trabajo competitivo es bueno porque motiva a las personas a hacer mejor.

Esa labor de competencia en Lean es, sin embargo, aplicable solamente en tareas de naturaleza manual (i.e., manufactura) y no en tareas de carácter creativo tal como el trabajo de conocimiento. Hay estudios extensivos que demuestran que motivadores externos de hecho hacen que la ejecución sea peor que si no hay motivadores en absoluto. Afortunadamente ustedes no están utilizando como motivación el darles a las personas dinero sino el adoptar su trabajo. El problema con ese modelo está en que no es lean porque genera desperdicio. Todo el tiempo y labor del equipo que pierde el concuso se va a la basura! Si ustedes pueden darse el beneficio de tener dos grupos compitiendo entonces sería mejor tenerlos a todos como un grupo colaborando efectivamente para generar una solución, y el motivador que deben encontrar es un motivador interno y no un motivador externo. El motivador externo es ganar la competencia. El motivador interno que actualmente utilizan es el adoptar la solución mejor. Podrían agregar otro(s) motivador(es) interno(s). De esa manera el trabajo de todos los involucrados será de valor. Colaboración supera competencia siempre, por eso los modelos industriales de Japón y Korea superan los de los E.U. y muchos otros paises.

Competencia impulsa a apresurar las cosas mucho mas que impulsa a innovar. Motivadores internos motivan a innovar. El concepto de respeto a las personas e incremento de conocimiento (lo cual se logra muy bien mediante cooperación) supera por mucho la competencia. El grupo de trabajo que pierde la competencia perderá motivación en su grán mayoría y el grupo que ganará comenzará a tender a ver a otros por encima del hombro y se distrairá y se confiará durante la siguiente ronda de concurso, por lo que la efectividad de ambos grupos disminuirá con el tiempo. Ese acto de ganar y de ser mejor es una ilusión.

Some coming presentations

I will be in Mexico City the next two weeks (Feb 22 ~ Mart 5) and during that trip I will be giving the following presentations:

• Feb 24, Congress building. I will be giving my second presentation on lean-agile, this time to a larger audience that includes industry leaders and some congressmen. It is very likely that it will be broadcasted through the Congress TV channel.
• March 5, ITESM (Instituto Tecnológico de Estudios Superiores de Monterrey). I will give a lecture on lean-agile and innovation which will be broadcasted to its 33 campuses accross the country via satellite and internet.

Also, Feb 25 is the MexAPLN meeting at the Software Guru offices starting at 7:30 PM. Address is Temstocles 34, 3rd.floor, Col Polanco, Mexico City.

Ikiru and why some lean-agile projects fail

Many years ago when I was in college I had the opportunity to see the movie Ikiru (生きる) by Akira Kurozawa. As a nice way to finish my work week, I just finished watched it again while having dinner. The story is around an elderly man, Watanebe-san, who is a public office head of department who is diagnosed with terminal cancer. He immediately starts a desperate hunt to recover the 30 years he spend doing nothing as a public official, and after much soul searching he decides to help build a public park at a low income neighborhood. The park is finished shortly before his death, whose cause was unknown to his coworkers and family. At his funeral reception there are about a dozen other public officials of different ranks. It is there where an amazing display of bureaucracy is made clear, and after much drinking and discussing, those who remained at the room came to the realization of the reazon of Watanabe's death. Inspired by it they all determine to make their work as meaningful and really serve the public, only to get back to the same status quo once back to work.

There is a parallel to the story and why some lean-agile projects fail and, worse, why entire organizations fail in the adoption. Simply put, it is very easy to get back to the old habits. Many organizations claim to be doing agile, be it scrum, xp, kanban or whatever else, in reality they still do in good measure the same things they were doing before with minor modifications such as not sitting at their periodic meetings or using post-it notes for their use cases. This more often than not results in even worse dynamics than before the "adoption". If you want your organization to really adopt lean-agile then you have to fully embrace it and be willing to go through what it takes to really make the transition.

Book review: Agile Testing by Lisa Crispin and Janet Gregory

Agile testing is a great book to both new and seasoned test engineers and test managers. At 533 pages, the book might feel a bit heavy but it is actually a pretty light and practical read if you read it to get a solid foundation on agile testing and then as reference. Note that the book is not about test coding techniques.

Part I is an introduction to agile testing and proposes ten principles for agile testers. What I don't know is if there are really 10 principles or if Crispin and Gregory forced it to be that specific number because it sounds better than 9 or 11. In any case, this chapter is a must read for all. Part II discusses organizational challenges, specifically cultural, logistical, and transitional from typical processes. This is a must-read for managers and team leads, and highly advisable for engineers if you want to have a successful test organization fully integrated with an agile organization. I personally encourage the division between development and testing to disappear completely. Part III is about he testing quadrants proposed by Brian Marick (one of the Agile Manifesto signatories) a while back. This is the first time I see the quadrants treated in larger detail and highly recommend it as a must for all.

Part IV is about test automation. It is a good read to understand the advantages of test automation and proposes a test automation strategy. This is a good starting point for test organizations that are new to automation but for mature test automation organizations it might add little value. Test code writing techniques are beyond the scope of this book. Part V illustrates the previous parts and then some by following a tester's activities through an agile iteration and the activities prior to it.

One problem I see way too often in test organizations and the way companies treat their test organizations is due to a lack of understanding not only of the difference between Quality Assurance and testing but also because of the place testing has hi people's minds. This book is a big help to create a cultural shift for the better.

Book review: Agile Project Management: Creating Innovative Products (2nd Ed.) by Jim Highsmith

Jim Highsmith is one of those few people that have really been-there-done-that and continue to be a pleasure to meet, accessible and down-to-earth. But anyway, this review is about his new book and not about him so I'll get to it. From my perspective Agile Project Management has two accomplishments: It fills in the gaps left by other books on the same subject and brings us one step further on different ways to see and approach the way we manage agile projects, within and outside software development.

Chapter 1 contains one of the best introductory chapters I've seen in any book on management. It is both a great motivation to read the rest of the book with interesting real cases. This chapter also refreshes the audience on the basics of agile, including the declaration of interdependence, which is explained in detail throughout the book, and provides some lesser known and relatively recent basis such as the Agile Triangle (not the Agile Iron Triangle).

Chapters 2, 3 and 4 are a detailed study of leadership values: Value over Constraints, Teams over Tasks, and Adapting over conforming. Similar to the agile values in the manifesto, these invite a cultural change in the way we measure project performance, lead teams, and focus on customer needs. Highsmith explains how the quality of the product and the work environment is improved through these. He also emphasizes on the fact that fail-often-fail-early is of very hight value in building a successful agile organization.

Chapter 5 has two objectives, to introduce an agile enterprise framework consisting of four layers that is arguably more appealing to large organizations, and to introduce an agile delivery framework consisting of five phases. That Agile Delivery Framework is explained in higher detail within the following 5 chapters, one per phase: envision, speculate, explore, adapt, and close. The last part of this chapter provides important practical information on the delivery framework. Chapter 6 has one of the best prep work descriptions you might be able to find and includes a project data sheet and the Tradeoff Matrix, which you might find useful. Chapter 7 digs into the speculate phase. Its contents are useful for those new to agile but not necessarily for those familiar with its basics since it explains fundamentals such as the backlog and story cards. Chapter 8 is about release planning. It introduces some planning strategies and a product planning structure that goes from the roadmap to the iteration. I recommend everybody to read this chapter since it has a bundle of snippets of useful information. Chapter 9 explains the explore phase and includes iteration planning, estimating, management and monitoring. It also talks briefly about technical debt, continuous integration and refactoring at a level good for managers but too light for for technical people. A good portion of the chapter is dedicated to coaching, one of the best parts of the book. Chapter 10 deals with the last two phases: adapt and close. It discusses how diverse activities usually considered secondary are of great importance to successfully fulfill customer needs and rapidly adapt to add value, increase quality, improve performance, and have a realistic view of the project status.

Chapter 11 is about scaling agile projects. Scaling has been a hot topic within the agile community during the last couple of years and Highsmith takes the opportunity to introduce an agile scaling model within the software development organization (other areas of an organization are beyond the scope of the book). scaling is treated at both size and distance levels, which increase the level of uncertainty and complexity. The model has five components: business goals, agile values, the organization, the product backlog and processes. The last three of these are treated differently at product, project, and feature level. I recommend you to read this chapter even if you work with a small team because there is value in understanding what works in the small and what works in the large. It may help you improve what you do in the small.

Highsmith does a great job discussing on chapter 12 how to do governance within agile projects, an aspect most small companies might not have to worry about but most mid to large organizations have to. Chapter 13 is an overview of metrics at a high level. If you want to learn about this topic in technical detail you are better off reading other books such as the David J Anderson's book on agile management and conference proceedings. Chapter 14 is a rather motivational reading on the value of agile

In conclusion, this is a book of high value to get up to speed on agile project management and learn more, recent advances in agile that are useful beyond software development and both in the small and in the large. Although the book doesn't advocate a particular agile development framework it leans mostly towards scrum.

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.

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.

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:

• 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.

We also noted areas of improvement and action items for next year, such as:

• 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

We all look forward to an even better 2010. First meeting is Jan 19 and the activity is Chartering.

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.

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.

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.”

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.

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???)

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:

• trust
• relationship
• process

For more highlights on what went on, in the words of presenters check my tweets @masakmaeda.

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.

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.

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.

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:

• 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:

• software
• processes and organization
• data
• analysis

What his means for us is that Agile-lean management and software development, if implemented, can play a crucial role in all of them.

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.