Looking Back: Creating a Software Factory – Part 3

This is the final post in my three part series (see parts one & two) about creating a software factory.

After some research I discovered that the practices I saw in India belonged to a larger group of practices named Agile software development. I wanted to start to using these practices locally with my team. Since I had a running factory, I couldn’t retool in mid cycle. I create a small pilot/swat team to try out the practices and find the best way to incorporate them into the team overall. The pilot team consisted of a designer/business analyst, developer, and a QA tester. After a short ramp up time this team was able to easily do lean design, test first / test driven development (TDD) and collective code ownership. Paired programming and continuous integration were going to be more tricky due to some corporate policies in place. The team was quite fast since the department’s heavy weight process didn’t impede them. Less defects from development meant less time in QA and faster turn around times for projects. This team was special in that it had people who could do all roles well and often rotated being a BA, Dev, and QA person when the need arose. They were mostly self-organizing as well. This model wouldn’t work for the entire department since not everybody could be a sweeper. We started to roll out these practices to the whole department.

3 months later…

Unlike last time a significant change was implemented, overtime dropped dramatically. We still had phases design, dev, and QA. However, the design team was more in control of each project now - instead of the process directing things. With few notable exceptions the factory was running smoothly. This model was able to scale. Since I was spending less time managing people and process I was spending more time with my customers.

Spending time with my customers pointed me to the next step in the department’s evolution. By meeting daily with the customer I was getting to see the sales pipeline and upcoming work in real-time. Also, the customers and I could manage the effects of new, high priority projects and delayed projects quickly. I implemented a Kanban style system for my customers. Instead of visual cards I could show the customer how much work each team was busy with now, when they would be free next and who could swing between roles. We also created some tools that allowed “what if” scenario planning. If things got complicated in our daily meeting we could jump on to a web application and do analysis. Within about 20 minutes we could re-plan the entire 45 person department’s work schedule – which happened more than once. This allowed for detailed adaptive planning that our customers had never been able to do before. We could prioritize and determine the impact to the business almost in real-time. Customers were intelligently pulling work from the factory rather than pushing it down and hoping things will be delivered on time. In a very real sense the development group and customers were in a partnership.

In summary, my team created a template for success that you can reuse in your development department or projects. Below are the key practices that made us successful:

• Eliminate waste – intelligently decide who should start work and where it should g
• Limit work in progress – only work on stakeholder’s most critical initiatives
• Focus on TDD and quality code – production bugs become non-existent
• Open Communication - Constant Feedback and prioritization from customer
• Visibility – Know your customer’s pipeline and demand so you can fine tune factory the appropriately
• Deliver Fast – Customer realizes value sooner
• Team empowerment – Team no longer needs to be “managed”, they can self organize
• Know your projects’ priority - measured business value and impact of your work
• Process still important – But, use the right process. Factory model won’t work everywhere
• Have multi-talented team - Team members move from role to roll as customers defined work needs
• Transparency – When I shared what the department was doing I was give the sales pipeline in return
• Use adaptive planning – A static workplan never worked well - now they rarely do

Photo Credits
Tony the Misfit
Under a Creative Commons Attribution License