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