Cloud Computing has ushered in new ways of developing and delivering products. The emergence of Agile Development Practices has sped Cloud Computing adoption. Interestingly, executives struggle with leading organizations that must master both. Here, I explore lessons learned from helping companies deal with these two dynamics.
Showing posts with label lean. Show all posts
Showing posts with label lean. Show all posts
Tuesday, November 3, 2009
Beyond Development's Purview
Toyota has been dominant in applying lean (or agile) manufacturing techniques to improve product quality, lower costs, and increase responsiveness to customer needs. Other manufacturers have applied the same principles and gotten similar results. Recently, lean software techniques (Scrum, Kanban, XP) have been applied by development groups to create high quality, fast-time-to-market products focused on their customers' needs.
Now, VCs and management teams are starting to use lean techniques. I was fortunate to be invited to "Overturning Conventional Wisdom To Disrupt Industries and Markets – A Discussion On Disruptive Business Models and Innovative Approaches In Professional Sports, Software and Venture Capital" held on Thursday, October 29, 2009. Ben Nye, Managing Director of Bain Capital and Scott Maxwell, Founder and Senior Managing Director of OpenView Venture Partners shared their experiences with using Scrum to run their respective VC firm, and its use at their partner firms.
Scott met with Jeff Sutherland who started the first Scrum at Easel Corporation in 1993. Scott told Jeff that one of their partner companies was getting a 30% productivity improvement using Scrum. Jeff's response was that they must be doing something wrong if they're only getting 30%. This caught Scott's attention and Jeff is now an advisor to Scott's firm. Scott likes Scrum because it creates focus. Scott's VC firm uses a basic form of Scrum where his staff members are product owners for various Scrum teams, for example, Sales, Marketing, Finance, Investments. Each team holds daily SCRUM meetings and does weekly sprints. Scott starts with yearly company goals. The product owners break them down into quarterly goals similar to product release planning. Each Scrum team does weekly sprints to plan and do work towards the quarterly goals. Ben added that he sees benefits with agile practices: improvements to time-to-market, more at-bats, and organizational learning. Both said that software companies often bring complex products to market, use expensive direct sales and services to channel their products, and do not focus on customers' pain-points. Their guidance is to keep focused on customers' pain-points and straight-forward products by using Scrum and other lean software development techniques.
Other VC advice from Ben and Scott:
Analysis at CalPHERS showed that private equity investments made following a clear strategy provides the best ROI. Scott's strategy is to target a specific type of company, identify candidates, select companies with good, highly qualified people, provide them access to experts, and repeat the process again. His firm has marketing, sales, process, and finance experts on staff to fill partner companies' gaps.
On customers, based on the customer continuum, Consumer, SOHO, SMBs, ..., Enterprises, start with a selected customer type and work backwards to determine the go-to-market plans. Don't be slow to identify the customers. Size the market opportunity with top-down, bottoms-up, and growth drivers analysis. Get to know the customers. Things like Google Adware gets customers but without allowing the company to know them. Keep a sharp focus on customers' pain-points and products designed for the target customer. Focus go-to-market strategy on the buyer. Use web analytics to know what your customer is doing. Being early to market is the same as being wrong.
On people, debunk the 'status quo'. Risk taking means mistakes will be made. Get minds around innovation. Have great relationships with people. The 'power of question' and 'power of suggestion' are useful when advising companies. As an investor, if you fire someone, you take on their role, so act carefully.
On taking investment, choose partners well. Partnering with VCs is like a marriage, you live with them for a long time. Spend time together. Chemistry is important. Check references as much as possible. Take as little capital as possible. Capital constrained companies quickly figure out who the customer is, and channel to the customer. A high investment offer is likely from a poor VC. Customer revenue is the 'best' kind of capital investment.
Friday, October 30, 2009
Agility
I have spent the past month digging deeper into lean (or agile) software development principles and practices. I have led many successful software projects and programs that have yielded high-quality, well-received software. For various reasons during the past four years, I have led software projects using agile development. Originally, I was trained in the classic waterfall model for software development engineering and management. I have also worked with many successful senior architects who are deeply entrenched by their successes in waterfall practices.
Distinctions help me learn by having opposing views in front of me and asking why people favor one idea over the other. For this investigation, I mentally placed a miniature version of a waterfall architect on one of my shoulders and a miniature version of a lean software development proponent on the other in a similar fashion as one might imagine conscience as an angel and a devil on each shoulder. I won't assign good or evil to either because such assignments make no sense and because I have been a witness to techno-religious wars that are never resolved, for example, the still on-going emacs versus vi war. I would rather master both methods and apply the best for the job at hand.
In my mind, the waterfall architect tells me that long, deep research cycles, in-depth, insightful discussions with multiple customers, careful, precise crafting of specifications, thorough hiring of skilled and capable engineers, well-engineered components, well-planned integration cycles, construction of comprehensive testing and release engineering functions, beta testing for customer feedback and verification, and production release of the final product are needed for successful projects. I appreciate his reasoning behind this statement because of our many successes with waterfall. His challenge is: fundamentally, why does a lean, iterative, agile development process produce as good or better results compared to what we know works?
Metaphorically, I turn to the lean software proponent and raise my eye brows looking for the response. She responds to my silent inquiry with we don't know what we don't know. The architect smiles. I know that he's thinking that's why we spend time carefully thinking through every step before proceeding to the next one. She continues, therefore we need to factor that reality into a different approach by eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the decision makers, and building in integrity. That sounds intriguing to me. I respond, please continue.
Waste in software development takes many forms such as waiting for approvals and resources to become available, working on features that will never be used by customers, and developer context switching. Learning can be amplified by multiple iterations (think practice makes perfect), feedback, and transparency (anyone can inspect project status at anytime). Deciding as late as possible sounds counter to making decisions but it isn't. Decide on those items that must be decided on first. For those items that you don't need to initially decide upon, allow those decisions to go unmade until you have learned more. Work on items in a depth-first approach to create more information to make better decisions as you go. Delivering as fast as possible to create working versions that customers and sponsors can verify is (or isn't) meeting the need. Empower the rank and file decision makers to make the hundreds of decisions daily to be consistent with the current plan and customer feedback. Allow them to organize the work to deliver potentially shippable units of work with each iteration. Finally, build both conceptual and perceived integrity into the project such that the incremental changes and re-factoring can be done while maintaining a consistent customer experience. This can be achieved by frequent inspections and test driven design with automated test development done either prior to or concurrent with implementation. While these techniques are promising, they are relatively new, not yet applied in a consistent, repeatable fashion, and are usually engineering centric instead of being embraced by the whole organization.
I turn to the architect and ask if these seem incongruent with his perspective. His response is that in theory, there are big differences, however, in practice, many of these techniques are used in pragmatic, successful applications of waterfall. For example, waterfall development projects are often slowed down by waiting for permission and approval, so he often takes risks by proceeding on work before approval or permission is granted. His motto is, "It's better to ask for forgiveness than to ask for permission". He is often frustrated by the lack of clarity of early customer requirements, even those formally specified in contracts. He's equally frustrated by changes in requirements as the project is under development and initiates a formal change request approval process. He keeps track of all of the changes to justify the additional time needed to redesign or re-implement previously completed work. He plans on multiple implementation and integration cycles to resolve dependencies among components and enable testers' early access to functionality. He finds ways to unlink dependencies so groups can work independently. He is frustrated by the constant requests for project status and lack of insight into what's being done by the various groups. He is particularly frustrated by the 'schedule chicken' that occurs between groups. Critical bugs found during testing are problematic, especially, those that uncover issues with the specifications. In response, he asks for design and code reviews to inspect work before it is integrated. He meets with testing organizations to develop test plans in advance so he knows what they will be doing and ensures the implementations can holdup during testing. He encourages testing to make automated test environments available early so engineers can run them locally prior to putting back changes.
I, too, have used these techniques to deliver waterfall projects on time. On the other hand (or, er, shoulder) these techniques are inherent in lean software development. My next question to the architect is so why don't we just use lean software development techniques directly instead of remaining entrenched with waterfall and applying techniques to address its short comings?
He nods and smiles.
At least, he didn't glare at me like he does when someone tells him that emacs is better than his beloved vi.
Distinctions help me learn by having opposing views in front of me and asking why people favor one idea over the other. For this investigation, I mentally placed a miniature version of a waterfall architect on one of my shoulders and a miniature version of a lean software development proponent on the other in a similar fashion as one might imagine conscience as an angel and a devil on each shoulder. I won't assign good or evil to either because such assignments make no sense and because I have been a witness to techno-religious wars that are never resolved, for example, the still on-going emacs versus vi war. I would rather master both methods and apply the best for the job at hand.
In my mind, the waterfall architect tells me that long, deep research cycles, in-depth, insightful discussions with multiple customers, careful, precise crafting of specifications, thorough hiring of skilled and capable engineers, well-engineered components, well-planned integration cycles, construction of comprehensive testing and release engineering functions, beta testing for customer feedback and verification, and production release of the final product are needed for successful projects. I appreciate his reasoning behind this statement because of our many successes with waterfall. His challenge is: fundamentally, why does a lean, iterative, agile development process produce as good or better results compared to what we know works?
Metaphorically, I turn to the lean software proponent and raise my eye brows looking for the response. She responds to my silent inquiry with we don't know what we don't know. The architect smiles. I know that he's thinking that's why we spend time carefully thinking through every step before proceeding to the next one. She continues, therefore we need to factor that reality into a different approach by eliminating waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the decision makers, and building in integrity. That sounds intriguing to me. I respond, please continue.
Waste in software development takes many forms such as waiting for approvals and resources to become available, working on features that will never be used by customers, and developer context switching. Learning can be amplified by multiple iterations (think practice makes perfect), feedback, and transparency (anyone can inspect project status at anytime). Deciding as late as possible sounds counter to making decisions but it isn't. Decide on those items that must be decided on first. For those items that you don't need to initially decide upon, allow those decisions to go unmade until you have learned more. Work on items in a depth-first approach to create more information to make better decisions as you go. Delivering as fast as possible to create working versions that customers and sponsors can verify is (or isn't) meeting the need. Empower the rank and file decision makers to make the hundreds of decisions daily to be consistent with the current plan and customer feedback. Allow them to organize the work to deliver potentially shippable units of work with each iteration. Finally, build both conceptual and perceived integrity into the project such that the incremental changes and re-factoring can be done while maintaining a consistent customer experience. This can be achieved by frequent inspections and test driven design with automated test development done either prior to or concurrent with implementation. While these techniques are promising, they are relatively new, not yet applied in a consistent, repeatable fashion, and are usually engineering centric instead of being embraced by the whole organization.
I turn to the architect and ask if these seem incongruent with his perspective. His response is that in theory, there are big differences, however, in practice, many of these techniques are used in pragmatic, successful applications of waterfall. For example, waterfall development projects are often slowed down by waiting for permission and approval, so he often takes risks by proceeding on work before approval or permission is granted. His motto is, "It's better to ask for forgiveness than to ask for permission". He is often frustrated by the lack of clarity of early customer requirements, even those formally specified in contracts. He's equally frustrated by changes in requirements as the project is under development and initiates a formal change request approval process. He keeps track of all of the changes to justify the additional time needed to redesign or re-implement previously completed work. He plans on multiple implementation and integration cycles to resolve dependencies among components and enable testers' early access to functionality. He finds ways to unlink dependencies so groups can work independently. He is frustrated by the constant requests for project status and lack of insight into what's being done by the various groups. He is particularly frustrated by the 'schedule chicken' that occurs between groups. Critical bugs found during testing are problematic, especially, those that uncover issues with the specifications. In response, he asks for design and code reviews to inspect work before it is integrated. He meets with testing organizations to develop test plans in advance so he knows what they will be doing and ensures the implementations can holdup during testing. He encourages testing to make automated test environments available early so engineers can run them locally prior to putting back changes.
I, too, have used these techniques to deliver waterfall projects on time. On the other hand (or, er, shoulder) these techniques are inherent in lean software development. My next question to the architect is so why don't we just use lean software development techniques directly instead of remaining entrenched with waterfall and applying techniques to address its short comings?
He nods and smiles.
At least, he didn't glare at me like he does when someone tells him that emacs is better than his beloved vi.
Subscribe to:
Comments (Atom)