My Agile adoption story, and why it matters to you

Every person has their own different story of how they found out about Agile and how they came to experiment and ultimately adopt it in their projects.
Mine is also different than most, I started as a skeptic. I was one of those that said "it will never work". But I did come around. Here's the story of how it happened

The downfall of traditional waterfall

As many of the people that entered the software development industry during the 90's, I also had my first job in a small company. A start-up that was growing very fast and exhibited all the usual growth pains: more projects than people, lots of extremely hard-working but not experienced people, egos to match, etc.

As it happens, the typical way start-up companies deal with the growth pains is to hire a couple of experienced people that come in and "install the process" that will deliver us from all problems. And that's what happened to us. The company hired a few experienced project managers, they slashed the number of projects and created a process to structure and organize our work. We badly needed it.

However after a while we figured out that the new process was not helping us finish projects on time or with the right features or quality. It was better than chaos but not really that good. At this time I got interested in processes and organizational issues. My thinking was: "there must be a better way".

Re-discovering the wheel

What followed was something many of us in the industry have gone through and will continue to go through in the future. I started reading about other companies that had faced the problems we faced and discovered that it was not only us, and especially it was not only the software industry that was trying to apply the same old ideas and finding that they failed when applied in real projects.

I discovered Deming first, then Toyota, Six Sigma, the whole nine yards. I started understanding some of our problems: focusing on schedule and forgetting that quality is more important; separating work and creating handovers architects to designers, to developers, to testers, etc.

It was clear that what we were doing at that time (Rational Unified Process) was not a good option for us. That's when I started experimenting with different approaches.

My Path to Agile

I started by using simple RUP and focusing on managing the scope, but this not your garden variety of scope management. This was aggressive scope management, negotiated from start to finish of the project. The whole idea was to plot the progress against expected progress and remove content every time we saw a deviation.

This solution was OK for schedule-driven projects, but we still had the same basic problems of leaving risky or valuable things to later in the project, our teams were still very much silos working on partial features which lead to a lot of work partially done. This was not the droid solution we were looking for.

Agile appears on the scene

At that time a local research institute was pushing for more research on Agile Software Development projects. As luck would have it I was switching projects and the new project was selected as one of the pilots. Now, keep in mind that this was 2004, not the heyday of Agile yet, and I was a skeptic. I decided to take the project and prove conclusively that Agile was not the success story we were being told it was. Boy, was I wrong!

The Agile pilot project

We decided to do everything by the book to ensure that we really learned from the project execution and would then be able to find better ways of working based on that experience. A new team was hired, and we started slowly designing the process based on Scrum. Other teams were using XP for comparison's sake.

Then, a funny thing happened. As I read more and more about Agile, I started to find similarities between Agile and what I had read in Deming and Jeff Liker's work. There was the uncompromising focus on the customer, the respect for people, the empowered team with a Product Owner to steer the scope (which I had learned could work well), and more.

I was starting to feel that Agile was no longer a small thing to improve a dead wrong process. It was much more. It was, and is a paradigm shift the consequences of which are still dawning on me today, a good 5 years after the first project.

This is my story

I wanted to share this story with you because I know that many have had similar experiences or are going through that transformation right now. There are a lot more of us, going through the evolution and learning from our application of Agile. That collected knowledge and learning will hopefully improve our industry in the long run.

Agile Finland, a Finland based non-profit association wants to support more of these transitions and that's why we put together a program to support those of us that have started the Agile transition process.

Agile for the experienced

Myself and a group of other Agile Finland members decided that we would create a program to support those of us that have started the transition to Agile and are at a cross-roads, looking for improvements that cannot be found in the available literature. We also don't want to visit every single conference on Agile Software Development we can find. We want to learn from each other and from the top practitioners and researchers in the industry.

The Agile Coaching and Leadership Academy was created from this cooperation. But this is no longer a project by a small group of Agile practitioners. Agile Finland was able to attract a much bigger training institution to help us and vouch for the curriculum that we are putting together.

University of Helsinki joins the effort

Together with the Computer Science department at the University of Helsinki we created the basic program for the course, but now we need the most important ingredient: you, the people who want to learn and improve the performance of your organizations. We want to offer this opportunity to 15 people interested in not only listening to the best minds in the field, but also actively contributing by sharing your experiences and learning from other's experiences.

Check out the program and the details of the training program here and join us in improving our Agile knowledge.

Photo credit: jillclardy @ flickr

Does Toyota really use waterfall for software development?

I saw this post and could not resist leaving a comment. Here's what I wrote as a comment to that post:

How can they [Toyota] apply waterfall and be predictive, fast and high-quality? Those are all qualities that waterfall lacks.

Predictability is lost because of lack of visibility into quality until it is too late (the test phase). Not to mention that trying to predict how a software project will go is like playing Lottery blindfolded and selecting a ticket to the wrong draw!

Speed is lost because writing requirements up front leads you to create a lot more requirements than you really need because you don't have the feedback of running software.

High-quality is lost because waterfall leads to slow and late integration which leads to many defects being left in the software! Not to mention that you can't inspect quality in, you have to build it in!

Now I'm curious about how you get out of that "they use waterfall but they provide all of the "goodies"!

Oh, and you can't say "they said they used waterfall but did not actually do that"! ;)

What do you think? Do you agree that Waterfall can be used with predictability, speed and high-quality.

What makes a great company? Recognizing you are not one yet...

The statement in the title is true even for those that are commonly recognized as great, as they say "here today gone tomorrow". If you really want to be great you should not shout it out loud at every opportunity, you should recognize what your strengths are, play to them and always, always be on the look out for what you can learn to do better.

Follow the example of Toyota: get back to basics, visit the Gemba and be faithful to the only thing that can help you succeed: Learning.

The Demise of modern management

Modern managers think they are good and infallible because, after all, they were promoted or head-hunted to manage. Well, reality is a bit more complex than that. Managers can only do their job properly if they visit the Gemba often. You need to understand deeply the problems at hand before you can make good decisions. And this is true for all levels of management, but especially for the highest levels.

Modern managers, especially top-of-the-pyramid ones need to be more "workers" and less managers (which nowadays translates to bean-counters with fat wallets).

Learn or else...

Through Elisabeth Hendrickson I got to Brett Pettichord's post about the role of feedback in Agile.

Read it if you haven't yet.

Here are the pearls that made me post this:

“If you don’t have meaningful feedback then you’re not agile. You’re just in a new form of chaos.”

and

“Agile practices build a technical and organizational infrastructure to facilitate getting and acting on feedback. If you aren’t going to adapt to feedback, then this infrastructure is waste that will only slow you down.”

This is very much in line (or even the same) with one of the tenants of the TPS (Toyota/Thinking Production System), the PDCA cycle. In order to improve you need to learn, feedback is the fuel for the process of learning. No feedback no learning.

If you are not learning, you are not Agile. No matter what you are doing!

Admitting mistakes is the first step to learning, not just for you, but also for your team and company

Here is an excellent piece from the blog Evolving excellence about how a worker at Toyota battled his fear of admitting a mistake and was rewarded by his pears and supervisor for not hiding, but rather disclosing the mistake he had done.

Admitting you committed a mistake is a very important part of continuous improvement. The andon cord (a sort of error alarm) should be pulled as soon as an mistake/error/defect is created or found.

Finding mistakes is not a blame game in Lean thinking, it is a key part of finding ways to avoid mistakes altogether through poka-yoke or mistake proofing our work methods!

Behind this willingness to show and learn from mistakes we make are some concepts in the Toyota Product System (TPS):

1. If the student has not learned the professor has not taught.
2. Most mistakes are caused by the situation or the system and not by people's incompetence or willingness to do their best.
3. Respect for people (one of the key pillars of the TPS)
   

These concepts together with other key concepts in TPS allow people to concentrate and focus on continuous improvement and not play the very ineficient and unproductive blame game that mostly impedes learning.


Updated: with a link to the Respect for people principle in Toyota's website.

Blogged with the Flock Browser

Adaptive Path discovers Apple's Mojo, but Toyota got there first

In a post called "Apple’s Design Process Through a Keyhole", the blog over at Adaptive Path mentions one technique used at Apple when designing product. The basic idea is that in Apple, designers come up with 10 possible designs for a new feature (and I bet more than 10 for a new product). Then diligently choose the best 3 and then continue to iteratively improve all 3 options they chose for some set period of time. Once they have worked for a while in all 3 options they finally decide on 1 and perfect it.

Even though this seems to be "amazing" and "innovative" for the folk at Adaptive Path (and I bet they are not the only ones thinking that way), this is actually a very old technique called Set-Based Concurrent Engineering (SBCE, also in software).

This technique is similar to techniques used in brainstorming sessions where participants are encouraged to generate many ideas (broaden the horizon), improve on them incrementally by "using" other people's ideas and enhancing them (improve on other's ideas), and finally to select the most appropriate idea for implementation (narrow and select).

Set-Based Concurrent Engineering is also used to ensure quality when a team (or set of teams) must meet a hard-deadline (as in a deadline that cannot be changed) with a solution that is much better than if you would just go with your first impulse/idea and try to improve on that.

One of the key advantages for Apple in using this technique, is that when they get to the 3 mid-step ideas they actually have syntethized all of the best points of all the other 7 ideas into those select 3. And then they still improve on those!

Good to see that Adaptive Path picked up on this technique, I hope that many other UI/UX people start paying attention to this old, but proven technique!