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.
Saturday, September 6, 2014
Smartphones, Tablets, Laptops and Incremental Improvements…
Tablets were hot items 4 years ago. They burst onto the market as iPads, then Androids and Windows 8s. They offered a compelling value proposition, lighter weight than a laptop and larger screens than a smartphone. Everyone had to have one. The market exploded. The pundits wondered if the eras of the smartphone and laptop might be eclipsed. Recent reports have shown that smart phone numbers are still growing. Laptop sales continue to be under pressure and look weak. The shocker is that tablet sales aren’t growing and they appear to be possibly shrinking.
Why? Could it simply be smudges, muscles and incremental improvements?
I went shopping for a new tablet to use during a trip to see my parents. I wanted to spend time writing my blog entries (like this one) while sitting on various airplanes and in various airports (like I am now). I have never owned a tablet and wanted to give a tablet a whirl.
I’ve owned various smartphones and know that I can send long text messages with iPhone or Android text input, autocorrect and autocomplete. Somehow, writing a blog post using a smartphone did not appeal to me. Even so, I’ve grown accustomed to a greasy smartphone screen from my ears, cheeks and fingers being pressed upon against the glass. Smudges were something that I have never been able to stand on my computer screen.
I’ve owned a laptop ever since those old clamshells computers that weighed 5 pounds back in the 1990s were in vogue. In those days, the airlines were still trying to figure out how to deal with those boxy electronic devices. Laptops have come a long way and made major improvements in keyboards, screens, storage, battery life, weight and wireless networking. I needed a break from my old friend, the laptop.
My calculus was that after four years, the tablets would be mature and ready for primetime. Their screens are sharp. They’d have greater storage capacity and longer battery life. Even the airlines allow tablets to be kept out and on during takeoffs and landings. Those poor laptops still have to be stowed away. I went to the universal, hands-on, low-priced electronics store of our age, Costco. I tried the iPads, the Androids and the Windows 8s.
I decided after trial and error, that grease and muscles are the unavoidable problems for tablets. I could not get past the constantly wiping of the screen to keep it clean. What is tolerable for the smartphone isn’t acceptable for the tablet. However the bigger issue was with my finger and wrist muscles. I am a poorly postured typist. I let my fingers rest ever so slightly on the keyboard. For computers or laptops, this slight sin of posture goes unnoticed. For cell phones, I only use one finger to type. With a tablet, my poor posture caused autocomplete and autocorrect to go crazy. I spent 80% of my time trying to figure out if autocomplete was smarter than I was. I finally accepted that I am incapable of typing on a tablet.
I ventured over to my trusted friends, the laptops. I cruised past the clamshells and went to the new Windows 8 Dell Inspiron 11 2-in-1. While the price was in the tablet pricing range, it had the keyboard, USB ports and reasonable battery life. I could flip it over like a tablet (and not stow it during take-off and landing) and then easily shift it into laptop mode. Another benefit was that the hinges allows various standalone modes for the display that lets my hands free from holding up the screen. Best of all, the smudges can be avoided and the muscles can rest in their poor posture when typing. I was sold.
The Dell Inspiron 11 is a nice blend of laptops and tablets. The incremental improvements of both has produced a product that can be use like a tablet and a laptop to get serious work done. The beauty of high-tech’s incremental improvements. Now, getting the smartphone integrated with a wireless Bluetooth headset might make for a nice 3-in-1 product. I can’t wait for the next round of incremental improvements.
Tuesday, August 26, 2014
Innovations in Change Leadership
We enter into the high tech industry wanting to be that person with an idea that changes the industry. Few have had such ideas. The industry has been changed by such ideas. Somehow, even for those who have changed the industry, we create organizations, products, processes and roles that become resistant to change.
During my career, I've held various positions where I have been responsible for leading change. A few times, my team has been on the leading edge and we were operating in a future, potential state. Change was easy because we had no past. Getting others to see our potential was the difficult part. At other times, the business was forced to change. A near death experience is a good motivator. We reacted to correct for not changing sooner. Even then, change was difficult.
The drive for change was and is something that comes naturally to me. Early in my career, I felt that logical arguments wrapped with a little passion were sufficient to lead change. But, when asked how I led change, I could not describe it well. Unconscious-competent some would say. Reading studies on how leaders affect change, helped to explain methods and effects but they failed to create a workable model to shift an entire organization from one operating model to another. I read and practiced lean software and agile development methods. I read up on situational leadership by Hersey and Blanchard. I kept seeking better constructs to plan and affect change across a large engineering organization.
I came to a company to lead change. The executives wanted to pivot the organization from years of long-cycle development processes towards faster time-to-market processes for new enterprise products. This was important as we needed new, constantly improving products for emerging markets to return us to profitable growth. Previous product efforts missed their market windows. There were other issues facing engineering: focus on product features and not on customers, focus on waterfall checkpoints with lengthy periods for architecture and design, separated implementation from testing, multiple software control/build processes, and weak engineering skills in modern development, testing and tooling practices. The engineering organization was highly resistant to change after various predecessors and projects failed. Fortunately, a new management team was already in position was demanding change.
Building the case for change was easy as one of my product projects had already been established, the market conditions were right, and the company need was clear. The difficulty was, as a new leader, I had to use the people that I had while avoiding their passive-aggressive behavior. I needed to push change along multiple dimensions in parallel for a large, geographically dispersed organization. My dilemma was how to do this?
I was concerned with potential passive-aggressive behavior along two dimensions. The first being passive-aggressive behaviors vertically within the organization and, secondly, horizontally across multiple components of the product. I decided to orient the organization along four concepts: product, architecture, process and people. I would use Hersey-Blanchard situational leadership within of these areas to cultivate new leaders and methods. I selected Scrum for a development method due to my previous experience and readily available training. I made an appeal for change due to that fundamental reason why we joined high tech, to change the industry. I made the cause for change personal to each individual.
My innovation was to create three virtual organizations where the leader of each reported directly to me for product, architecture and process. A virtual organization leader had dotted line relationships to their organization but not direct management control. I created a fourth organization with people managers who had everyone else reporting to them. A leader was responsible for their area. This prevented any one of them overpowering another without me being notified. I selected a leader for each organization who had been open to change and had a strong understanding of their respective area. This organizational model gave me visibility into issues as those issues crossed between these virtual organizational boundaries. The issues escalated to me created teaching moments. This structure also mirrored Scrum roles.
The second step was to refactor the existing organization into the new structure while leaving the development process untouched. This allowed the organization to adjust while doing work as they had previously done it. Meanwhile, I started coaching of each leader on their roles and new expectations. I described to the engineers how the new organization would function in the future. Meanwhile, we kept current projects on track.
The third step was training. On product, training was focused at the use of customer stories with goals and definitions of done, as well as, release planning with shorter horizons and smaller increments. On architecture with the lead architect, we worked on a redesigned, flexible architecture. On process, I cultivated the notions of continuous integration, use of modern build and automated testing tools, test driven design, and early devops concepts. The goal was creation of a single repository, build, test and deployment model for the product. Lastly, I worked with the people managers on training (Scrum, virtualization, automation) and self-managing-team skill development.
The next step was practice. The product owners began to state requirements and SLAs as user-stories. The architects started to redesign the current architecture to allow refactoring and better incremental, independent changes. The process team began to pull together a single tool set using open source tools and modern methods. The next release that was heading into planning signed up for the first attempt at Scrum. The approach taken by the team was actually closer to spiral development while using Scrum terms. User-stories were closer to tasks than they were user-oriented. The back end was heavily focused on final integration and testing. Meanwhile, I continued to push product owners closer to user-stories, architects closer to enabling refactoring and independent development by component, and teams towards Scrum and self-management. The process team needed the least encouragement because they were building tools for future use and had already moved into the agile development mindset. Releases continued to flow out every 4 to 5 months.
I had the teams working on new releases incrementally move components on to the new tools and to automate aspects of builds and tests. This required shifting repositories and changing tools. It required finding ways to build things that were never automated. Meanwhile, we kept raising the quality of the definition of 'done' with each release.
The last step was to do a hard shift to only user-stories with a clear goal and definition of done, to being 'done within a sprint' and 'done-done' (or customer shippable quality). This created tremendous tension with the product owners and engineers as the whole organization had to shift from fast cycle, mini waterfall development to true Scrum development. The teams and product owners pushed back. They claimed it wasn't possible. I had the visibility to influence and coach the low-level product owners. I worked with the people managers and teams directly when needed. The architecture and the process were in place to enable this critical transition. The teams did make the switch. We moved into true agile development with user stories being started and done to customer shippable quality within a sprint. Releases continued to flow out under the new process
The quality of the product from our customers’ perspective improved with each release. The teams were able to deliver both incremental features and velocity improvements with each sprint. The product owners were able to remain focused on customers’ needs and stakeholder demands. Teams were able to show stakeholders feature demonstrations earlier. Sets of teams could work independently on different work streams than were integrated and released when done. Back-end testing moved from 3 sprints to 1 clean-up sprint with the number of serious bugs found during testing dramatically lowered. For a modest investment, the team created differentiated product features ahead of the industry leaders. From a change management perspective, the organization became fully bought into Scrum, its methods and its value. They pushed themselves to improve with each sprint cycle.
Looking back, there are things that I would change on my approach. For example, I should have been more demanding of the product owners to move to user-stories earlier. This would have provided a stronger motivation to break from the mini-waterfall development within a sprint to ‘potentially shippable’ user value being done for each story multiple times within a sprint.
During my career, I've held various positions where I have been responsible for leading change. A few times, my team has been on the leading edge and we were operating in a future, potential state. Change was easy because we had no past. Getting others to see our potential was the difficult part. At other times, the business was forced to change. A near death experience is a good motivator. We reacted to correct for not changing sooner. Even then, change was difficult.
The drive for change was and is something that comes naturally to me. Early in my career, I felt that logical arguments wrapped with a little passion were sufficient to lead change. But, when asked how I led change, I could not describe it well. Unconscious-competent some would say. Reading studies on how leaders affect change, helped to explain methods and effects but they failed to create a workable model to shift an entire organization from one operating model to another. I read and practiced lean software and agile development methods. I read up on situational leadership by Hersey and Blanchard. I kept seeking better constructs to plan and affect change across a large engineering organization.
I came to a company to lead change. The executives wanted to pivot the organization from years of long-cycle development processes towards faster time-to-market processes for new enterprise products. This was important as we needed new, constantly improving products for emerging markets to return us to profitable growth. Previous product efforts missed their market windows. There were other issues facing engineering: focus on product features and not on customers, focus on waterfall checkpoints with lengthy periods for architecture and design, separated implementation from testing, multiple software control/build processes, and weak engineering skills in modern development, testing and tooling practices. The engineering organization was highly resistant to change after various predecessors and projects failed. Fortunately, a new management team was already in position was demanding change.
Building the case for change was easy as one of my product projects had already been established, the market conditions were right, and the company need was clear. The difficulty was, as a new leader, I had to use the people that I had while avoiding their passive-aggressive behavior. I needed to push change along multiple dimensions in parallel for a large, geographically dispersed organization. My dilemma was how to do this?
I was concerned with potential passive-aggressive behavior along two dimensions. The first being passive-aggressive behaviors vertically within the organization and, secondly, horizontally across multiple components of the product. I decided to orient the organization along four concepts: product, architecture, process and people. I would use Hersey-Blanchard situational leadership within of these areas to cultivate new leaders and methods. I selected Scrum for a development method due to my previous experience and readily available training. I made an appeal for change due to that fundamental reason why we joined high tech, to change the industry. I made the cause for change personal to each individual.
My innovation was to create three virtual organizations where the leader of each reported directly to me for product, architecture and process. A virtual organization leader had dotted line relationships to their organization but not direct management control. I created a fourth organization with people managers who had everyone else reporting to them. A leader was responsible for their area. This prevented any one of them overpowering another without me being notified. I selected a leader for each organization who had been open to change and had a strong understanding of their respective area. This organizational model gave me visibility into issues as those issues crossed between these virtual organizational boundaries. The issues escalated to me created teaching moments. This structure also mirrored Scrum roles.
The second step was to refactor the existing organization into the new structure while leaving the development process untouched. This allowed the organization to adjust while doing work as they had previously done it. Meanwhile, I started coaching of each leader on their roles and new expectations. I described to the engineers how the new organization would function in the future. Meanwhile, we kept current projects on track.
The third step was training. On product, training was focused at the use of customer stories with goals and definitions of done, as well as, release planning with shorter horizons and smaller increments. On architecture with the lead architect, we worked on a redesigned, flexible architecture. On process, I cultivated the notions of continuous integration, use of modern build and automated testing tools, test driven design, and early devops concepts. The goal was creation of a single repository, build, test and deployment model for the product. Lastly, I worked with the people managers on training (Scrum, virtualization, automation) and self-managing-team skill development.
The next step was practice. The product owners began to state requirements and SLAs as user-stories. The architects started to redesign the current architecture to allow refactoring and better incremental, independent changes. The process team began to pull together a single tool set using open source tools and modern methods. The next release that was heading into planning signed up for the first attempt at Scrum. The approach taken by the team was actually closer to spiral development while using Scrum terms. User-stories were closer to tasks than they were user-oriented. The back end was heavily focused on final integration and testing. Meanwhile, I continued to push product owners closer to user-stories, architects closer to enabling refactoring and independent development by component, and teams towards Scrum and self-management. The process team needed the least encouragement because they were building tools for future use and had already moved into the agile development mindset. Releases continued to flow out every 4 to 5 months.
I had the teams working on new releases incrementally move components on to the new tools and to automate aspects of builds and tests. This required shifting repositories and changing tools. It required finding ways to build things that were never automated. Meanwhile, we kept raising the quality of the definition of 'done' with each release.
The last step was to do a hard shift to only user-stories with a clear goal and definition of done, to being 'done within a sprint' and 'done-done' (or customer shippable quality). This created tremendous tension with the product owners and engineers as the whole organization had to shift from fast cycle, mini waterfall development to true Scrum development. The teams and product owners pushed back. They claimed it wasn't possible. I had the visibility to influence and coach the low-level product owners. I worked with the people managers and teams directly when needed. The architecture and the process were in place to enable this critical transition. The teams did make the switch. We moved into true agile development with user stories being started and done to customer shippable quality within a sprint. Releases continued to flow out under the new process
The quality of the product from our customers’ perspective improved with each release. The teams were able to deliver both incremental features and velocity improvements with each sprint. The product owners were able to remain focused on customers’ needs and stakeholder demands. Teams were able to show stakeholders feature demonstrations earlier. Sets of teams could work independently on different work streams than were integrated and released when done. Back-end testing moved from 3 sprints to 1 clean-up sprint with the number of serious bugs found during testing dramatically lowered. For a modest investment, the team created differentiated product features ahead of the industry leaders. From a change management perspective, the organization became fully bought into Scrum, its methods and its value. They pushed themselves to improve with each sprint cycle.
Looking back, there are things that I would change on my approach. For example, I should have been more demanding of the product owners to move to user-stories earlier. This would have provided a stronger motivation to break from the mini-waterfall development within a sprint to ‘potentially shippable’ user value being done for each story multiple times within a sprint.
Running...
Lynn Cowan, an Unisys Scrum Master, wrote an IEEE paper and gave a presentation in 2011 about the work that we were doing together back at Unisys. I wanted to post it here for reference and as a framing paper of my various posts. Enjoy.
Returning to the fray....
I'm back in the consulting saddle again for a short two weeks before I start my next gig. I hope to post a few more blogs.
Sunday, January 10, 2010
Elder Mail
I recall using email for the first time when I joined Hewlett-Packard as a new engineer. I liked the ability to share designs, bugs and information with my fellow engineers. From that day forward, I had to find ways of organizing, deleting, and archiving my email. When AOL burst on to the scene with their dial-up accounts and email service, I helped my parents understand email and how it could increase communications with their children. Needless to say, it took them a long time to get into the email craze. A few years later, with my email filling up with 'if you care, you will forward this message to 10 friends and family members', I wondered why I ever helped them. I spent more time managing email. When Spam arose, I spent even more time managing email. Sometimes, I was thankful when I had to do a fresh system reinstall. Since I never backed-up my email, I started with a new, clean mailbox at the cost of losing information.
I tried Gmail Beta as soon as I could get a friend to invite me into the trial. Google changed email by introducing conversations and an ever-increasing storage limit (now at 7.4 Gigabytes). Just as in having a conversation with a friend, you don't delete a conversation from your memory or Gmail. They used Spam filters to keep junk out of my Gmail. I spent less time managing Gmail. Nothing seems to stop my parents from forwarding the 'if you care' messages. I don't care since I don't worry about storage space. So far, I have not lost a single conversation due to a system crash. I use the 'search' feature to provide 'on-demand' organization for the conversations.
Recently, I have been using Twitter, blogspot, facebook, and other social networking services. These Cloud software services have millions of users and tons of storage. Just like Gmail, they are about hosting discussions. The discussions are an ongoing stream. They don't get organized, filed, or filtered. We choose who sees and receives our discussions. Nothing gets deleted. I don't have to organize the streams of discussions. Searching is done by who we connect to and what they publish.
I had an epiphany during a face-to-face (hard to believe isn't it) discussion with a friend who had brought her teenaged daughter into work. Her teenaged daughter is a 'power' facebook user. Her daughter sat down at her desk, looked at her email screen with a bunch of file folders to the left, and asked about those. My friend explained that she had to file her email messages into folders because she wanted to keep them organized so she could find a message when needed, and her company wanted to keep the email server space available. Her daughter looked up, scrunched her face and whined, 'that's sounds too hard'. Email has become 'elder' mail. The notions of discussions, publish once, store forever, search everything, and social organization are driving us to a completely different way of communicating.
Maybe the 'if you care' emails will be replaced by the 'if you care, you'll subscribe to my Twitter feed' requests.
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:
Posts (Atom)