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.

What happened to self-organization and collaboration?

While at yesterday's Agile Journal seminar in Santa Clara CA it called my attention that all presenters who talked about how they do scrum (oh, yes, other practices were mentioned but not talked about) said something that made me question how much self-organization they allow their teams to have. One aspect is that of story assignment. A self organizing team is one that allows its members to self-assign the stories to be implemented during each sprint, considering of course priorities and upon agreement with PO and SM. The teams mentioned at the seminar were given the tasks to implement by the SM.

Since the seminar was primarily to promote software tools the presenters talked about how much the tools have benefited their projects and how great it is for stakeholders to have a tool to go to for, say, write a story to then be assigned. Nobody talked about the importance to maintain face-to-face collaboration. Based on their description it seems the tool ends up being at the center of activities instead of being a means to capture and track the activities to facilitate documentation and reporting. People must continue having close communication and collaboration. A story should be discussed, estimated, and assigned properly.

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.

Ultrasist

Just out of a meeting with Ultrasist, the first Mexican company to achieve CMMI Level 5. They are actually a very progressive company definitely ahead of the average Mexican software dev company. What was actually cool is that the innovative mechanism they utilized to achieve level 5 was apply the principles of XP at design level (pair design). They didn't go about doing pair programming though or any other agile practice. However it may not take long before they start doing some adoption.