Lean Machine

Marius Grigoriu here… I’m the Product Manager for Risk Tracker and parts of the Connected Information Security Framework, some of the software we’re building for Microsoft Information Security and that we will frequently mention on this blog. The other day I got a link to the following article:

https://shapingsoftware.com/2009/06/15/introduction-to-lean-software-development/

Reading this article got me thinking about how my teams function in comparison. Microsoft Information Security is a group of smart, fast moving people and they are always coming up with new and better ways to manage the security program. When process changes, we need to ensure that our applications keep up. To succeed in this environment we had to adapt our practices. Here is how we stack up to the lean principles listed:

Eliminate Waste

Our old habits were to document everything, be as detailed as possible, and design everything up front. Then as we approached our first deadline we realized that we had to cut features. The upfront work that went into those features turned to waste, especially because when we do get around to start writing code we found that the business process changed and had to go back to the drawing board. Now we postpone figuring out the details until shortly before we need them. While we have a long list of requirements that will keep the teams busy for a long time, we only elaborate on them just in time for development. Finally, many of the other practices mentioned in post also apply to eliminating waste.

Create Knowledge

We found that unless knowledge is in the heads of our team members then it is not being used. We used to take a lot of time writing formal documents only to found out that the next group of people needed everything explained to them anyway. Creating that knowledge and putting it the minds of developers and testers still took a few weeks and the documents went largely unread. Then I took a second team and tried a different approach. Documentation was very light and only served as reminders for the discussion we needed to have anyway. I also had the entire team assembled and ready to go at the beginning of the project—no latecomers. Finally we only elaborated on the parts that we had to address in our first cycle. The result was that we got the second team ramped up enough to start writing code in only three days. I also am a strong supporter of minimizing changes to the team, especially when we’re mid-cycle. Adding a new developer to the team late in the project can actually cost us when we have to spend time creating knowledge rather than putting the final touches on our code.

Build Quality In

I think I might be gaining a reputation for being a bit of a pain because I always ask to have testers available with developers. With testers being available at the beginning, we don’t need to spend extra time building up knowledge and test activities are not all done in a rush at the end of a project. Also, acceptance tests are now defined with requirements – in fact they are sometimes what’s used to document requirement details.

Defer Commitment

My teams do this as a result of deferring decisions as long as possible while remaining responsible. It is a bit of a skill we need to practice as sometimes we make decisions without fully realizing it. However, by deferring decisions we improve the quality of our decision making. As time passes we gain knowledge about the project, requirements, technologies, etc. And with that additional knowledge we can make better decisions.

Deliver Fast

This was one of the driving factors for some of the changes in our practices. Business processes change quickly as new ideas dreamt up and the experimentation to find the best way at achieving results takes place. Software that powers such rapidly evolving businesses needs to keep up to remain useful. We also found out that the best way to help the business understand what they need is to deliver something tangible. We then use that release as a basis for discussion and future improvement. Fast delivery gives us the ability to have a short feedback loop and deliver more useful software. It also gives us more flexibility in maintaining a sustainable pace for the team. Postponing features proposed in the middle of a cycle is a lot less painful for the business if we can turn around quickly. Under a long development cycle pressure to accept changes during development was high and such changes always add more work to be squeezed in before the deadline.

Respect People

People are important. They build our software and they use our software. We respect people by working at a sustainable pace and maintaining work-life balance. We provide transparency in our process and progress to build trust with the other groups we work with.

Improve the System

Last and most important is to find ways to continue making improvements. My teams hold retrospective meetings at the end of each cycle. Now that our cycle is one month long for the application team and two weeks long for the BI team we get many opportunities to become more efficient, better at what we do, and happier with our work.