Dec 30, 2009
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!
Between December of 2008 and April of 2009 I participated on a series of 6 webinars on Lean-Agile Software Development given by Allan Shalloway, under NetObjectives, and knew that the book—same title as the webinar series—was being finished at that time so I was definitely looking forward to it. I was very glad when the publisher asked BayAPLN for a review, which gave me the opportunity take over such a pleasant task.
The basic premise of the book is a better approach to drive software development efforts to maximize realized business value. It pays particular attention to how to scale agile to the enterprise; a main topic of discussion within the agile community during the last two years. The book’s proposal is to use lean-agile instead of agile alone and to “extend” scrum to what the authors call scrum# which is, simply put, doing scrum while also doing lean thinking. Particular attention is paid to the lean principles of waste elimination and optimizing the whole. The authors put together a body of knowledge that would otherwise take lots of research, reading hours, and trial-and-error experience. The theme itself is not new, you can also consult, e.g., books on lean software development by Mary and Tom Poppendieck, and a book on scaling lean and agile development by Craig Larman and Bas Vodde. Shalloway, Beaver and Trott’s book is easy to read and very informative at a conceptual level and also at an anecdotal level. The cases they present actually add a lot of value to it. I consider this to be a must for executives, managers, and non-technical people involved on software projects because it will help them understand better what lean and agile can do for their organization. It is also helpful to software and QA engineers as a great informative reading.
The book consists of an introduction, three parts, and an appendix. The Introduction sets the tone for the book and revisits the basics of agile and lean (manifesto, principles, etc.). But make no mistake; this book is not for people new to agile or lean, and for those who are it is better to do some previous reading or they might get lost at times.
Part I starts with a discussion on why it is not preferable to think of software development as a science or a technique instead of as a discovery means to the end of satisfying a need, and gives a gentle introduction to some lean principles within software development. Chapter 1 nicely explains the transition of manufacture-based practices to software development. Chapter 2 addresses the business value added by agile and lean through better customer interaction, better delivery, and product focus. Chapter 3 gives some insights on how to get started with the transition to lean-agile, and chapter 4 dives into lean thinking for portfolio management, which I consider to be the most important chapter of this part because it gives a good deal of practical advice to do high value-added changes to your organization.
Part II Focuses on lean project management. Chapter 5 addresses some limitations of scrum that are particularly important when considering scalability. The authors propose what they call Scrum# as an extension of scrum that includes lean thinking. I personally think the problem is not scrum itself but rather how we put it into practice and what they propose as scrum# to me is nothing more than having a better (lean) way of applying the scrum framework; maybe because I learned about lean years before scrum came to be and so I have always used lean thinking when doing scrum. In any case, I would advocate to simply keep the term scrum as-is and encourage people to learn and apply lean to it rather than getting into new terminology, which I think might create confusion instead of clarity. I was very pleased to see that Kanban was added to the book and wish it had been explained in more detail, on a dedicated chapter, because kanban is very powerful in eliminating some disadvantages of scrum and it will gain importance as a highly effective software development framework. Chapter 6 is about iteration 0, which is the preparation phase before starting your actual scrum iterations. I entirely agree with the need to do the prep work but I have never been fond of calling it iteration because in people’s minds it time-boxes a very important phase that not necessarily—and almost never—takes the same amount of time as the actual scrum iterations (see, e.g., Jim Highsmith’s book Agile Project Management). Chapter 7 is a good explanation on how to do lean-agile release planning. Chapter 8 explains the importance of visual controls and information radiators, which is a subject that most executives have a hard time accepting from the lean-agile perspective but once they fully realize their high value regardless of their simplicity they usually embrace these fully. I definitely enjoyed seeing a chapter on the role of QA (chapter 9) because this is often under-treated in the software development literature in general, unless it is on a dedicated QA book. This inclusion goes well with the lean-agile principles of working in teams and optimizing the whole.
Part II addresses scalability at enterprise level on chapter 10 with a very effective discussion format. Management’s role in lean-agile is treated on chapter 11 with good arguments but I would’ve liked it better if it had elaborated further on this very important role. Chapter 12 was one of my favorite ones since it does a good job at discussing the Product Coordination Team, a relatively new approach that has proven to be better suited for scalability than scrum of scrums. Chapter 13 is rather a teaser about the importance of a better, lightweight, approach to software architecture and design, which is okay since it is beyond the scope of the book.
Part III consists of chapter 14 only and is an epilogue to the book that basically encourages people to explore and learn more about lean, primarily, and about agile.
Appendix A explains Steve Bockman’s Team Estimation Game. A dynamic, fun, and effective step further of what you can do with the Planning Pocker that is also scalable. Appendix B presents the authors’ model of lean-agile software development, a nice quick reference to refresh the key concepts.
Alan, Guy, and James wrote a fabulous book that is a must-read for those interested on a successful lean-agile adoption whether or not you need to scale.
Dec 22, 2009
Dec 20, 2009
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.
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
Dec 14, 2009
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.
Dec 8, 2009
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 1, 2009
Nov 27, 2009
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.
• 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
- 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.
Nov 6, 2009
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
Oct 31, 2009
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.
Oct 21, 2009
Oct 16, 2009
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
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
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.
- 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
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
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.
Sep 24, 2009
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.
Sep 23, 2009
Sep 14, 2009
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.
Sep 12, 2009
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.
Sep 4, 2009
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!
Aug 27, 2009
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.
Aug 23, 2009
Aug 20, 2009
Click here or here for more information.
Aug 18, 2009
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.
Aug 12, 2009
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"
- processes and organization
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.
Aug 4, 2009
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.
Aug 3, 2009
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 long 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.
Jun 6, 2009
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.
May 11, 2009
May 4, 2009
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.
What amazed me the most was how efficient those people were. Keeping 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.
Apr 30, 2009
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.
Apr 11, 2009
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.
Mar 21, 2009
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.
Mar 15, 2009
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
The oscars of the software industry. For a list of this year's Jolt Awards visit http://www.joltawards.com/winners.html
Mar 9, 2009
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.
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.
Mar 8, 2009
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.