If you’re interested in knowing about how Toyota became the world’s most profitable car manufacturer then this book is for you!

For more than 50 years Toyota has applied and refined it’s lean manufacturing principals, also called TPS or the Toyota Production System. Without going into the details of this book (for now) here are some Japanese terms I thought would be very suitable for agile developers and the agile community at large.

Kanban – Card or ticket or sign board. Used to signal to the previous step when its part needs to be replenished. Kanban is a signaling system to trigger action. This creates a “pull” system

Heijunka – Level out the work load. A production scheduling and load leveling tool. Distribute kanban cards in an efficient manner.

Muda – Waste or non-value-add work. Eliminate waste or non-value-add is a top lean philosophy and is said to be the focus of most lean efforts.

Muri – Overburden or pushing beyond limits. Overburdening machines causes breakdowns and defects and pushing a person beyond their natural limits causes safety and quality problems.

Mura – Unevenness. Muda will be a result of Mura. Unevenness results from an irregular production schedule or fluctuating production volumes, indicating internal problems. In lean manufacturing you need to balance production volumes.

Jidoka– Built-in quality. Also referred to as “autonomation”, equipment endowed with human intelligence to stop itself when it has problems. Used as a quality control system to build a culture of stopping to fix problems and getting quality right the first time.

Andon  – Light signals or cords that could be pulled for help. Used to stop or warn the production line in a specific section or work center.

Kaizen – Continuous improvement. The process of making incremental improvements, no matter how small, to add value. Defines Toyota’s basic approach to doing business.

Genchi Gembutsu – Go to the source to thoroughly understand the situation.

Nemawashi – Literally translates to “going around the roots” or closely translated as “laying the groundwork”. Discussions between many people giving input and helps everyone to be in agreement when a decision or change is made.

Hansei – Reflection, become a learning organization through relentless reflection. Hansei go hand in hand with kaizen, without reflection you cannot have continuous improvement.

Hoshin Kanri – Policy deployment. Directing and motivating organizational process by cascading objectives from the top of the company down to the work group level.

Sensei – One who provides mentoring, teacher who has mastered the subject.

There’re probably some more Japanese terms in this book that I missed but these ones stood out to me the most. I see many resemblances to Agile Software Development thinking, processes, methodologies, etc. in the terms above. Can you do the agile translation of the of these Japanese words/phrases?

Like Firefox 3.0? Need a quick and easy-to-use prototyping tool? Just download this add-on called The Pencil Project http://www.evolus.vn/Pencil/ for Firefox 3 and sketch away! I wanted a tool that is lightweight and unobtrusive that allows me to quickly sketch my prototypes without the need for visual studio or a similar developer tool. This add-on to Firefox was just that! I was able to get good looking interfaces within minutes of downloading the tool. It’s free, only 400 KB and it’s platform independent. If you (like me) find that other tools out there are too complicated or do too much for your simple prototyping needs then try this one!

I thought this would be useful “swag” for any teams out there starting Agile estimating techniques or any teams who want to improve at estimating development tasks.  I’m not going into the details of how it’s done, you can read for yourself http://www.planningpoker.com/detail.html. I first read about planning poker in Mike Cohen’s book Agile Estimating and Planning. You can also get actual planning poker cards from his company’s web site http://www.mountaingoatsoftware.com/products/planning-poker-cards, what a great idea!

Back when our team was learning Agile estimating I had these documents made to help us play planning poker. I thought these would be useful to anyone in the learning phase or wants some tools that can help with the process. So here it is, FREE planning poker cards that you can take to your favorite print shop and get printed (download the attached PDF’s).

Planning Poker Playing Cards pg01_front – Planning Poker Page 1 Front

Planning Poker Playing Cards pg01_back – Planning Poker Page 1 Back

Planning Poker Playing Cards pg02_front – Planning Poker Page 2 Front

Planning Poker Playing Cards pg02_back – Planning Poker Page 2 Back

Then I took this one step further and made use of our company’s business cards which needed to be reprinted anyways! Instead of just getting new business cards printed, why not take this opportunity to make planning poker cards out of them? Dual purpose Agile business cards! The front of the cards have the generic company branding as well as the individual contact information. The back of the cards have our division brand (ThirdAngle) and a unique number used for estimating. It’s also a good conversation starter when you give out your business cards :-).

Next time you see the team you’ll have to ask for each of us for our business cards so you can have the set.

Here’s a good 5 minute video from www.outsystems.com on the time-value of Agile Software Development titled “Why does Agile Software Development pay?”…

In my opinion, at the point where traditional software development makes it’s first release versus where Agile is at that time (many releases in), I think the Agile value is much higher than the video suggests because of the empirical feedback the end-users have put in along the way and the ability to change quickly based on real-time prioritized business needs. It’s a powerful visual representation of Agile Software Development that businesses wishing to build software, either in-house or using a vendor, should really look into. For businesses that are currently building software, can you ask yourself these questions?

• Are you able to use and go into production with your software at consistent intervals (weekly ,bi-weekly, or at most monthly)?
• If you do get software at consistent intervals, are you recommended to give feedback without it costing you more money?
• Is working software that meets business needs in a timely manner more important than contract negotiation?
• Are changes in priority and/or features embraced by the development team?
• Does software development respond to your business changes in a real time manner? The time it takes for your business ideas to be turned into revenue generating software is weeks not months or years?
• Does communication occur daily between the business and the development team, can it, is it face to face?

If you can answer “yes” to all of these then that’s great, if not then wouldn’t you want to? At least give it a try with an experienced Agile shop to see if your business can achieve a much higher return on investment and client satisfaction.

The Certified Scrum Master course doesn’t get offered very often in Calgary but as agile software development becomes more mainstream I am starting to see the course offered more and more. IMHO Scrum is quickly becoming the de facto standard for managing successful software projects today. Check out this course at http://www.scrumtraining.com/upcoming-events/ or http://www.scrumalliance.org/courses/2655-certified-scrummaster.  It’s a good introduction to agile project management using Scrum. Scrum is not technical at all since it concentrates on the management side of software projects. But when performed in conjunction with the technical software engineering practices of Extreme Programming, you’ll find they compliment each other very well.

I remember taking the course in the summer of 2005 with Kert Peterson and back then I think there were only around 3000 or so Certified Scrum Masters in the world. I think there’s at least 25,000 registered members now, here is the list of Scrum Masters (mind you not everyone here is practicing it though)http://www.scrumalliance.org/community/csms_only. You can also get trained in the Practitioner, Coach, or Trainer certifications as well.

This course is entry level (2 days only) so don’t expect to come out an expert. However, it does give you a good basis to start becoming an agile project manager. I would suggest this course not only to project managers, but project leaders, developers, product owners (although there’s a separate course just for PO’s now), and probably anyone in the software management domain who wants to know more about how to run an agile project.

You might be interested in this list of companies that claim to be practicing Scrum for project managing software projects. I say “claim to be” because it could be only a small team in the company that is practicing it, nevertheless some of these companies are very large so it shows how Scrum also scales to large organizations: http://scrumalliance.pbwiki.com/Firms-Using-Scrum

I finally got back to some reading after busy weeks moving offices and getting comfortable in the new  environment (I also changed employers!). This book was borrowed for an extended amount of time so I thought it was time to finish it and give it back or pass it on (thanks Mo)…

This is the Second Edition of the book where the author, Kent Beck, takes a lighter less “extreme” approach to introducing Extreme Programming. Still, if you don’t already know the values, principles and practices of Extreme Programming (XP), this book will help you question what you’re currently doing in software development and if it’s truly what you believe is the most humanistic approach. It’s not that this book tries to convince you on doing things a certain way, but rather, Kent Beck portrays values as universal truths then relates them software development through principles and practices that simply make sense. Values like communication, simplicity, feedback, courage, respect, … are some of the most important values of XP. Practices like co-located team members, visual informative workspace, pair programming, continuous integration, test-first programming, … are engineering practices that lead to better software. Then bringing everything together are principles like humanity, baby-steps, continuous improvement, mutual benefit, reflection, flow, quality, …  puts a software development context to the values and gives purpose to the practices that are being performed. All these work together and complement each other and without the values, principles, and practices as a whole the team lacks the true benefit of XP, actually I think it could lead to some very dangerous situations where XP could fail as an agile methodology. Other interesting points I noted in this book are:

• Identifying the highest priority user stories and building them first will yield the most business value and satisfaction for clients. It only takes 20% of the most important features to yield 80% of the business value (the 80/20 rule).
• Metrics in XP are different so be careful of how you measure it as compared to traditional business practices (you will get what you measure). Two suggested metrics are defect rate per deployment, and the elapsed time between the start of an investment idea and the time that idea starts generating revenue. I’ve witnessed many one week iterations with our team that demonstrates to our clients that given only a week we can turn their ideas into reality.
• The Theory of Constraints states that in a system there is one constraint at a time… find it… improve it or offload the workload or remove it entirely. Then move onto the next constraint and do the same.
• XP uses the “pull” model of developing software where stories are designed in detail right before they are implemented.
• More time at a desk does NOT equal increased productivity for creative work. Yes, software development is very creative!
• Plan for work based on past experience (your velocity in the last iteration), and adjust the plan when new information arrives.
• When faced with a big ball of mud (code design and complexity) begin by improving the design where you walk (lighting the lamp). Consistently performing small improvements is better than one big refractoring iteration where little or no business value is delivered at iteration-end.
• Members in an XP team share the same fate. Success and failures are shared amongst every member. The whole is truly more than the sum of it’s parts. Realizing the potential in software relies on teamwork. A deep change in values and relationships is encouraged.

Like everything in life, don’t expect a silver bullet to solve your problems or improve your situation. There is no prescription with steps that say “do this… then you’ll get exactly that…”, XP is something you should try then customize it to work for your organization. If it works then keep it and improve it, if it doesn’t work then figure out why and try something else. To me, at the end of the day, XP brings about an empowered software developer who continuously searches for better ways to improve business value. They are able to quickly estimate, implement, and deploy reliable software at incredible consistency. I leave you with a quote from the book:

“Tools and techniques change often, but they don’t change a lot. People, however, change slowly but deeply”

Agile is truly about simplicity and it is most apparent in the tools and practices our team uses everyday. Take our visual workspace for example, the place where high collaboration occurs on a daily basis. It doesn’t have to be a complex software package like some of the tools I’ve seen in the marketplace (I still have yet to try them all, but I do have a list and a reminder to try them out to see if they have potential). I find that once you put information in electronic format you have to do a lot of management (and reminding) to get people to read it. If you can get away with having it up front and center where everybody involved on the project can quickly and easily find out these 4 pieces of information, then you’ve got it made:

1. What’s planned for this iteration?

2. What’s done so far?

3. What’s remaining?

4. What’s the progress?

If a stranger can walk into the room without prior knowledge of the project, and within seconds know what tasks are complete, what tasks are remaining, and what the progress is… imagine the collaboration this environment would generate for the team and customers working on the project?

So how do you setup the simplest collaboration environment? Well, you don’t have to go to the “outer most reaches of Calgary” to find it, as Adam wrote in his blog. But you do have to put a little sweat into it! Trust me it’s well worth it if you need big custom boards and only want to spend a fraction of the cost. I’ve setup two offices (my old office and just last week my new office)using this environment and will probably do the same for my office at home. Here’s the details:

Whiteboard Purchase:

• You can go to your favourite home building/renovation store like Rona or Home Depot and look for 4×8 feet sheets of white Tileboard. This material is also called Melamine Tile. It’s typically used to build shower stalls, but the finish is basically the same as regular whiteboards found at office supplies stores. Make sure the surface is smooth and glossy (and bring a dry erase marker to test, I didn’t tell you to though). The board will run you about $72 each. You’ll need a truck (thanks Joel) with a 6 foot bed because these 4×8 sheets don’t bend very well.

Materials:

Counter clockwise from the top left of the first picture: 3 foot level, tape measure, hammer, two sided tape (holds down parts of the board that are not flush against the wall), Tim Hortons Timbits and coffee (mandatory), power screwdriver, wall anchor screws, screw head holders/covers, pencil, whiteboard marker (to test the surface), utility knife, drill bits and miscellaneous bits/screws.

Putting it up:

At least two people are required to put it up but with three it makes it even easier. You’ll need about 30-40 minutes for each board. Basically level it, put some pilot holes into the board and wall, drive in the anchor screws, place the screw head cover holder in, drill the screws until the back opens up and tightens, finish it off with screw head covers. There you have it, “the simplest collaboration environment” (I recommend putting at least one in each office, you can never have too many whiteboards). They look like this:

@ the old office:

@ the new office:

Usage:

Here’s a little more information on how to use your simplest collaboration environment from Mike Cohn: http://www.mountaingoatsoftware.com/task_boards. Instead of the typical index cards we use sticky post-its by 3M, not just the regular ones but the “Super Sticky” type (I think 3M made these especially for agile task boards). You don’t have to worry about tasks falling off the walls and getting lost. They actually work very well and you don’t need thumb tacks or magnets like with regular index cards.

That’s it!

This is the group photo during last weeks “Nothin But Agile Project Management” course March 3-6th at the Sheraton Eau Claire in Calgary, Alberta. From left to right: Rob from Petro Canada, Maria from Shaw, Me, Nina from CGI, Mark from Petro Canada, Kelly from Hatsize, Wendy from Petro Canada, Jason from IBM, and of course Jonathan the course instructor in front. The course was put on by Jonathan Rasmusson, an active participant in the agile community. Jonathan walked through an entire mock project “Bubble Battle” based on agile project management methodologies and best practices from inception to closing and hand-off. The course was an intense 4 days with workshops and group discussions on agile experiences both good and bad, as well as very important lessons learnt (which I love to hear about). View the rest of the pictures from the course at  http://www.flickr.com/photos/59259399@N00/sets/72157604097180657/. I highly recommend the course to new and existing project managers who want to know more about how agile works and what it looks like because soon I truly believe it won’t be called “Agile Project Management” anymore but instead just “Software Project Management”. Why you ask..? It works, it has proven itself to me, it makes the team happy, it makes clients happier, it reduces waste, it produces high business value software quickly, it continues to improve in whatever ways it can and will not be the same today as it was yesterday and it will be even better tomorrow… I can go on and on but I will stop now :-).

I’ve been practicing Scrum as an agile project management methodology for a while now and in the last year I’ve been lucky and able to implement many grass roots “pure” style methodologies. So, it led me to think “where did Scrum come from” (the software version not a scrum from the sport of Rugby) and what significance it has in influencing the software management/development community? What was it before the likes of DeGrace and Stahl referred to it in Wicked Problems, Righteous Solutions? What was it before Ken Schwaber and Jeff Sutherland used it in their companies then presented a whitepaper on the topic at OOPSLA’95? These questions lead me to this article “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka. The article was published in a 1986 article of The Harvard Business Review. That struck my interest so I immediately ordered it from the original source. The article has this intro:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method – as in rugby, the ball gets passed within the team as it moves as a unit up the field.

The article goes onto identifying the 6 characteristics of the holistic approach to new product development.

1. Built-in instability – management sets challenging goals but doesn’t specify exact work plan.
2. Self-organizing project teams – autonomy, self-transcendence, and cross fertilization.
3. Overlapping development phases – Type B, Type C, sashimi, rhythm, and pulse.
4. Multi-learning – multi-level learning and multi-functional learning.
5. Subtle control- self control, group control, and control by love.
6. Organizational transfer of learning – transfer to other divisions and other new product development projects.

For more details you’ll have to read the article (ask me for hard copy). It also mentions many scenarios where the holistic approach to product development many not work such as; requiring constant team effort throughout the development process, scaling to large projects like those in the aerospace business, or in an environment where a genius makes the invention and hands down a well-defined set of specifications for people to follow (in software development AKA “code monkeys” who follow predefined design documents written by a master architect weeks/months prior).

Managerial behavioural changes also need to occur in order for the company to achieve high speed and flexibility. The article points out 3 things that need to change in a company:

1. Companies need to adopt a top management style that can promote the process.
2. A different kind of learning is required. From a depth-based individual learning (highly competent few) to breadth-first group learning across different levels of the organization.
3. Management should assign a different mission to new product development. Most companies treat new product development as a means for future revenue, but sometimes it should be a catalyst to bring about organizational change.

The article references projects from these large multinational companies like Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard. The original context was in the manufacturing industry but I found it really interesting that for such an old and very rigid process structured on Taylorism that the software industry (which is a lot newer) is behind in times when it comes to updating it’s process engineering methodologies. The manufacturing industry has revolutionized their processes, which is evident in the lean manufacturing principles of the Toyota Production System (TPS), while the software industry is only now (in the last few decades) starting to catch up!

I leave you with the last sentence from the article:

What we need today is constant innovation in a world of constant change

I thought this was very funny. No offences to the guys I work with but maybe this will get us thinking about making our own song so that people will know how we work, what we do and who we are? There’s one particular guy on the team that can actually play an instrument and is even in a band (they play live shows). Joel, I am talking about you! Maybe your band can help us create our own agile development rock song? Or a song about the benefits of test driven development? Ha Ha! Check out the song “Code Monkey” by Jonathan Coulton. You can find other songs found on his website: http://www.jonathancoulton.com/. I wonder if there’s original songs written specifically about agile software development…?