2011 Prediction

Masa's 2011 prediction as posted on the Cutter Consortium page

• A Move Toward Value Innovation

  Under pressure from the continuing economic crisis, enterprises are struggling to maintain their level of competitiveness, or even remain in the market. What has been considered key to success will begin to shift, from the search for effective methodologies to the realization that innovation and value are the most important differentiators for success.

  For many years, enterprises have considered effective management of scope, schedule, and budget as the key to success. This has been proven over and over to be incorrect. (Just ask the professionals you know. How many projects have they been involved with where scope, schedule, and budget were really effectively managed?) Furthermore, there are projects that accomplish this goal and still do not succeed. (Think "no sales.") The success-failure reports from some well-known firms are misleading because they are based entirely on those evaluation parameters and continue to guide enterprises in the wrong direction.

  One of the contributions of Lean and Agile has been the realization that emphasis on quality is much more important than the three parameters of scope, schedule and budget. More recently, attention has been brought to value to customer as the main driver to increasing the chance of success. These contributions are helping enterprises better evaluate what is considered success and what is considered failure. More successful products will be created as enterprises around the planet continue to adopt Lean and Agile. This success will not only help those companies flourish, but will also contribute to better the world economy. Observe, for example, the tremendous level of enthusiasm over Kanban and Scrum adoption in South America where the economy of countries like Brazil, Peru, and Chile is growing surprisingly fast. Entrepreneurs are seeing the benefits of Lean and Agile, and are adopting their methodologies at a rate that may match North America and Europe soon.

  Innovation has been brought in as the newest player. Value Innovation puts innovation, quality, and value together to better both the customer-facing and the business-facing sides of the enterprise, with particular emphasis on the human factors of competitive advantage and enterprise success.

  2011 will be a year of maturity in the way we understand success and the beginning of a change in direction to follow Value Innovation.

Book Review: Continuous Delivery

Book: Continuous Delivery

Authors: Jez Humble and David Farley.

Addison Wesley, 2011

I had two simultaneous impressions when I browsed Continuous Delivery. The first impression was “is there anything really new here?” and the second was “humm… I have actually never seen a book that puts together all these topics that do have an important relationship.” Throughout my career I encountered over and over the continuous struggle between diverse teams to successfully develop and deliver software. Communication, coordination, and collaboration have always been an often-ignored important factor that affects the effectiveness of organizations. Add to that the lack of a coherent infrastructure to make design, development, testing, integration, and deployment fit seamlessly and the end result is the nightmares way too many organizations deal with on a daily basis. I decided to read on because I appreciate the importance and complexity of those issues, years ago when I built QA organizations for diverse companies, and the last couple of years coaching and consulting enterprises in the adoption of Lean-Agile practices and the importance of Value Innovation.

Jez and David did a very good job at addressing the infrastructure coherence issues and propose effective ways to bring order. The novel aspect is not the fact that, say, good configuration management, continuous integration, and testing are very important to the increase of software quality, and to both managers and engineers mental health. The value is in the way to make this happen successfully and with minimal effort. They rightfully use the term Delivery Ecosystem and put together innovative thinking with strong bases on the importance to optimize the entire process, increasing quality, reducing technical debt and, best of all, making work life easier to technical stakeholders. The single automated pipeline approach is in agreement with current practices influenced by Lean and Agile.

Part 1 is a very god compendium of practices necessary to every software development organization, which the authors present as the challenges to deliver software. Jezz and David begin by presenting some release antipatterns and what to do about them. Then they address configuration management and continuous integration, where they describe diverse types and practices, pointing out essential characteristics and making suggestions to make them more effective. The last chapter of this part points out the importance of testing and explains it in terms of the test quadrants as proposed by Brian Marick and mention some real life situations.

Part 2 focuses on the deployment pipeline. Jez and David begin with its components—or anatomy—from practices to its stages. They did they right thing by including automated and manual test strategies. The following chapter focuses on scripting for build and deployment by first mentioning some build tools and then guiding the reader by the hand on the basics to get builds and deployments automated; and is complemented by a short chapter on the commit stage wraps it up. The next two chapters focus on testing, automated acceptance and nonfunctional requirements. These topics are not comprehensive due to the extent and complexity of the topics but the authors made a good job at bringing the key factors to motivate the reader to understand their importance and to explore further. This part is concluded with a chapter on deployment; an activity taken way to lightly most of the times and a main point of failure for most organizations. The authors cover zero-downtime releases, emergency fixes, and other.

The last part of the book is on the delivery ecosystem. This is the most important part of the book. I would say that very senior leaders and very senior technical staff with rich, broad and in-depth experience may be able to browse through Parts 1 and 2, but should slow down and read in more detail this part. This is the glue that puts things together.

Concluding. This is a vey good boo that should’ve been written many years ago to avoid so much waste and pain by so many technical organizations because it puts diverse parts of the software development organization puzzle together in a way they actually fit together. The only aspect I wish was also there, but isn’t, is the human factor. That is, how to get not only the complexity of processes and infrastructure to work together coherently, but also how to get the people behind the process and infrastructure to also work together coherently. In any case, that wasn’t an objective of this book.

Masa to give courses at The University of California at Berkeley

Masa to begin giving extension courses at The University of California at Berkeley in 2011.

Cutter Consortium 2011 Predictions

Here's the main page to Cutter's 2011 predictions:
http://www.cutter.com/predictions/2011.html

and here's my prediction posted on the same page:
http://www.cutter.com/predictions/2011.html#maedam

Kanban book in Spanish

The best book on Kanban: David J Anderson's is now available in Spanish
http://agilemanagement.net/index.php/kanbanbook/
Translated by Masa K Maeda


English Cover Spanish Cover

A case of Lean-Agile Kanban adoption with value innovation

I did Lean-Agile Kanban adoption with Value Innovation at a 90-people organization back in mid September. Around 60 people where at the headquarters and the other 30 at a neighboring city just a 1.5 hour drive away. The training was given at the headquarters with the away team receiving instruction remotely taking advantage of the remote-training infrastructure they themselves developed. I myself didn't feel very comfortable with the remote training because my training technique includes doing games and, believe me, conducting team games for training purposes remotely is not for the faint of heart. Even more so when you also have a group to teach in person.

Coaching followed the training. The local group was difficult to train and coach because they allowed themselves to be distracted and continuously left the room to attend work related matters, even against my strong recommendation to focus entirely on the training by pretending they were doing this out in San Francisco instead of at their offices farther south. To make matters worse, the coaching wasn't done at their work area but at a training room with mixed teams. As result the employees and leaders treated the coaching as if it wasn't part of their every-day activities and the results weren't carried to their actual work. And then, there was lots of politics going on such that the leaders were more focused on how to position themselves to get a higher position in the coming elections than on getting the job done.

The remote group, on the other hand, was less preoccupied with political capital and more concerned with operations. When I got to their offices to do the coaching I was concerned with how effective it could be given how limited the success of the remote training was. The group was somewhat disfunctional. It became clear to me that they were segregated. Teams did not communicate or collaborate well. Leaders and individual contributors did not communicate well. It was a typical command-and-control environment. They continuously struggled to get projects finished and had a long list of pending projects.

Instead of going straight to the Kanban face-to-face training I started by conducting exercises to remove the communication and collaboration impediments. Fist, I conducted some NLP exercises to get them to mix and talk to each other at same level (no hierarchies or roles). Then I got them to create a snapshot of the organization using innovation games. By then they were already communicating much better. Next activity was to crate a value-stream map of their core process and by the time they were done the director told me this was the first time in the history of the organization that everybody knew the entire process in detail, him included. I proceeded to solidify lean-agile thnking some more. The following day we talked about Value Innovation and then worked on learning Kanban.

I followed up via email with the teams. The teams at headquarters didn't carry on any activities but the other group did put effort on the adoption, not without struggle, but keeping in close communicaton with me they managed to get Kanban implemented. I visited them last week and was no less than astonished by the amazing implementations they have made. They started with one Kanban board to get all in synch and then implemented custom team Kanban boards that were in agreement with the common board to communicate efficiently. One team actually had two team boards and each team member had his own board in perfect synchronicity without any extra effort. The team they interacted with had its own two boards also in agreement with the other team's main board. It was a mastery of coordination. They asked me some fine tuning questions.

There was one team whose manager deviated from Kanban, not on purpose, in an effort to be original and creative. Nor surprising, this team was struggling to get things done smoothly. I gave my opinions and recommendations to the team, and then talked to the manager in private to help him realize the creativity has to go towards adding value rather than over thinking a Kanban design and letting the Kanban board evolve naturally. We spent the rest of the day digging into the activities around the Kanban board: the meeting, analysis, discussion, decision-making, and execution.

A director from headquarters had joined me on this visit upon instructions from the CEO, who had considered making a dedicated effort to bring Kanban to the most progressive team at headquarters after I reported to him the progress at the remote location. The director was so impressed that on the way back to headquarters discussed with me a strategy to make the adoption at the entire headquarters instead of just one team. :-)

In a Kanban Adoption, Go Lean

Recent posting on the Cutter blog

http://blog.cutter.com/2010/12/06/in-a-kanban-adoption-go-lean/