Archive for the ‘Entrepreneurship’ Category
New Year’s One Wish – and One Resolution
It is that time of year again …. New Year’s resolutions. Well, I won’t talk – in this blog – about staying fit or a better work-life balance, but rather I’ll keep it focused on software engineering. I will also keep it simple and limit to one wish: specs on time — and one resolution: fostering more innovation.
New Year’s One Wish: Specs on Time
If I could wave a magic wand, and change just one thing in my professional life, it would be: Engineering receives specs 8 weeks prior to the official start of the release
Why?
As obvious as the answer is, in general, the Business team (product management and execs who are involved in the product roadmap) don’t seem to grasp that if Engineering gets incomplete specs when we are supposed to start coding, well … we can’t start coding – which means we will not be able to deliver as many features as we could have.
For example, let’s say that one release finishes July 31, and that –as is typically the case – we only start discussing the December release on August 1. The result is that the specs do not get finalized until the end of August. Thus rather than having the expected 5 months to implement the new release, we have four. Actually, we have much less. …
Why “8 weeks prior”?
A lot of work must take place between the time Engineering receives the spec, and the time all developers can start coding in earnest:
- Scope the deliverables: to figure out what subset of the proposed list of features submitted by PM can actually be delivered in the imposed timeframe
- Finalize the exact deliverables: Based on the “cost” (scope) provided by Engineering, the PM team determines the final list of deliverables for the release
- Architecture and design: some features require thinking before coding J
- Technology analysis: evaluate and validate any new third-party tools, libraries, or packages
- Task breakdown and allocation to individual developers
Only when all these tasks have been completed – at least on the most important features – can development start in earnest.
8 weeks seems like a long time, and there is obviously flexibility in the number. The newer the functionality, the more uncertainty on the scope, and the more research required, the more lead time is needed by Engineering to plan out the release.
A good rule of thumb is: when the previous release is feature-complete is the time when PM and Engineering need to start planning the next release, specs in hand.
What Spec?
… Enough to be able to scope, and plan
In order for Engineering to commit to deliver certain features by a certain date, Engineering needs enough information about these features to be able to scope them – in other words, something more substantial than a handful of bullets on a PowerPoint slide, or a wiki.
There are many ways to write up requirements, and in the spirit of Agile Development, we don’t really want, nor need, everything written down upfront. On the other hand, Engineering needs a modicum of clarity and specificity about what needs to be built. This can be delivered via use cases, UI mock-ups, flow-charts, feature list as long as the Engineering team can appreciate the scope of work: e.g. feature enhancement vs brand new functionality? Is new technology required? Are there performance challenges? Are there new partners or systems with whom we need to interface? Etc.
New Year’s One Resolution: Fostering More Innovation
The day-to-day, week-to-week, month-to-month pressure on the Engineering team is “to deliver on-time, on quality and on budget” The vast majority, not to say all, demands are short-term and reactionary: requests from customers, or responses to competitive pressures.
However, the Engineering team also has the responsibility to innovate: to add to our products something that nobody else has thought of. If we don’t, then within a couple of years, a competitor, or a new startup, will, forcing us to react and catch up.
So, how does one drive innovation in an Engineering team, when there is never enough time to do the things that the business team requires? The answer is that we have to make, sometimes steal, the time, and we have to be efficient – both are admittedly easier blogged about than done. Please send me your suggestions!
Making the Time to Innovate
Few companies are as profitable as Google, and can afford to grant a blanket 20% of their time to employees to do self-directed research. On the other hand, in a world where technologies become obsolete within a couple of years, it is suicidal not to heed Steve Covey’s 7th Habit: “Sharpen the Saw”. This applies to each of us as individuals, but also as a team.
In practice, this means each engineer must, on his/her own, make time to research new technologies and approaches. It also means that as a team, we need to organize time to discuss promising technologies.
The best approach that I have found is “Tech Talks” where members of the Engineering team present their recent work; articles, books or blogs they have read; or simply a new technique that they have invented.
Directed Innovation
“Directed innovation” is admittedly a contradiction in terms. Yet, a small company cannot afford to disperse its resources. It is thus incumbent on the leadership to present the right context for the Engineering team in which to explore, why our customers buy our product and what will make a true difference for our business: performance, scalability, usability, reliability, etc?
With this context, we can direct our investigations and leverage our efforts. Again, team work, and group discussions usually accelerate the growth of ideas.
Getting a startup to articulate its vision and strategy, particularly how these translates to technology needs, has traditionally been a challenge in most of the startups where I have worked. The mode of operation has typically been more reactive – following the orders that will make the quarter …
This is exactly why fostering more innovation is my one and only New Year’s resolution.
Planning – and Executing the Plan – are Part of the Job
Filed under: Agile Software Development, Entrepreneurship, software development, software engineering |
Leave a Comment Being an engineer entails more than writing good code. It also requires being a good corporate citizen. We write and test software so that it can be used by our customers. The Engineering team is one of the teams that constitute the business. As such, we need to coordinate our activities with those of the other teams in the business: Marketing, Sales, Operations, and Support. We are dependent on these other teams for our software to find its way into the hands of our customers. We also depend on them for the business to survive. Let’s not forget that Engineering is an expense center, and that without the Sales team, there would not be any paycheck.
Our obligation to the other teams in the company can be summarized fairly simply: we need to deliver what we promised, on time. We thus need to be able to forecast within a reasonable horizon what we will be able to create, and then deliver against our forecast.
Planning is Difficult but Necessary
Some argue that writing software is a creative and innovative endeavor, which, as such cannot be predicted. The comparison is made with Civil Engineering where designing a new building is akin to applying well documented formulas and following well defined processes lending themselves to formulaic forecasting. While there is truth to the argument, it cannot be taken to the limit. It does not means that forecasting a software project is impossible, but rather that it is hard.
This being said, we don’t have a choice. As I often point out to my colleagues, sales people have to forecast every quarter, and one can argue that forecasting sales is eminently more challenging, since it relies on the behavior of people over whom we have very little control: our customers. Yet, no company can operate without a sales forecast, and forecasting is one of the skills that salespeople need to develop, along with their sales acumen. Engineers are in the same situation.
More specifically, the reasons we make plans are:
- To forecast when a given release will be complete. This in turn will drive forecasts for sales projections, staffing assignment in services – which in turn drive financial projections, and how the company manages its expenditures – such as our salaries
- To make strategic decisions: for example, if certain set of features take too long, or too many resources, we may decide to postpone their implementation, and allocate resources to another product or set of features.
- To make our own decisions: by knowing how much work each task will take allows us to staff projects appropriately, and thus be as efficient as possible. Over-staffing and under-staffing both have negative consequences that are easy to understand
- To align internal resources: the most obvious example is that the QA team needs to know when a certain feature will be ready to be tested.
The above illustrates how important it is to meet our commitments, once we have announced our plans. If we don’t meet our plans, we let other people down, and force them to scramble to make alternate plans. Yet, meeting one’s commitments is not only about working hard. It starts with making good plans.
Making Good Plans
How does one make good plans?
- First and foremost: include everything (easier said than done but none the less critical)
- Think through ALL the tasks that are required to complete the job: create a new Maven project, become familiar with the idiosyncrasies of a new software package, upgrade libraries to a new version, organize design reviews, code, unit tests, integration tests, performance tests, error recovery tests, security intrusion tests, documentation, training, etc.
- Account for everything that happens in a typical day/week: e.g. Meetings, interrupts from Ops, support, or other
- Be realistic: Engineers tend to be optimistic – make sure that you take into account that something at some point is going to go wrong
- The best technique that I know is to use history as a reference. Have you typically been late/early on your past projects. Are there activities that you typically fail to account for?
- Build some buffer – because it is important to meet the commitment (and if you don’t need the buffer, you’ll use the time to implement an extra feature, or start the next release early)
Tracking Progress
A tool like Atlassian’s Jira allows each developer to enter their tasks and the time for each task. It is critical that each developer enter their own time estimate. No task should be longer than 2-3 days. If it is, it is best to break it up. I have found it to be the right balance between having enough detail in the task to grasp its whole scope, while keeping the total number of tasks manageable.
It is important to think of a task as a complete project: including reviewing requirements, design, code, integration, testing, documentation, hand-off to QA. Of course, each of these tasks can be spelled out when their scope warrants it. Again, include the typical daily overhead in the estimates .
Once we have entered the tasks in Jira, it is critical to track them accurately. Don’t be shy about entering time beyond your original estimates if you are running late: your teammates, and your team lead, need to know — so that they can make alternate plans if necessary. Progress tracking tools are not meant to find faults, but for project management and communication: it is a much worse offense to your team to keep quiet about your being late, or struggling, on a task, than the fact of being late. Being late is a problem that can be dealt with – keeping quiet is a professional fault that hurts the project even more than bad code.
One important note: a task is DONE when you won’t need to put any more work into it. In particular, this means a piece of code is not done until it has been fully tested and validated.
Cloud Computing – The Miracle Tool for Testing
Filed under: Agile Software Development, Cloud Computing, Entrepreneurship, Extreme Programming, Quality, software development, software engineering |
Leave a Comment Does this story rings familiar? You are in a planning meeting for the next release, and learn that in addition to supporting Oracle 11g, the product will also need to support Microsoft SQL Server 2008 (or DB2, or mySQL, or PostgreSQL). Once the typical brouhaha dies down about how complicated this will be, how the whole code will need to be ripped apart, and how much time this will take, the Director of QA turns to you and asks for a couple of additional servers for the QA lab, so that the software can be tested on the two databases in parallel; minimum of three servers: 1 for the database, 1 for our software, and 1 for the test fixtures. The following day, it’s the developer lead’s turn to ask for more servers: need at least 1 “populated” database against which the developers can test, plus another set up for the daily build, etc. Makes perfect sense … Except that no budget has been allocated for these servers! Soon you find yourself with your beggar’s cup in the CEO’s office, explaining to him, and the CFO, why your team needs these extra servers when “you already have so many!!”
Rejoice! Here comes Cloud Computing to the rescue ..
Cloud Computing could not only eliminate the need to purchase servers for testing, but also actually radically improves your ability to test, and thus improve product quality.
Cloud Computing, such as Amazon EC2, offers the ability to deploy (and un-deploy) software on demand. One pays “by the hour” of computing used, and storage and bandwidth consumed. This is perfect for testing (by developers and by QA): compute load varies greatly over the cycle of the day, as well as the cycles of the release.
First of all, every developer can now have his/her own test setup against which to test. There is no limitation of hardware, no begging, borrowing or stealing from your colleagues for unutilized servers. One can just deploy at will. Furthermore, there is no restriction on the number of servers. So if you need to test a four-server cluster, you don’t have to hunt around for free servers, you just do it.
Similarly the daily build can deploy to multiple test environments concurrently and thus accelerate the validation of the build.
Finally, the QA team can also test in multiple environments simultaneously, e.g. Oracle and SQL Server at the same time! This offers the potential benefit of being able to test a much larger number of deployment scenarios, than would be possible using one’s own hardware.
Naturally, leveraging a Cloud Computing infrastructure, requires new tools.
First and foremost, all the tests must be automated. While technology has created virtual servers, it has not yet inventing virtual test engineers J. Secondly, one will have to build tools to automatically deploy, e.g. from the build environment, the new version of the software, and the test fixtures, as well as collect the results of the test runs.
One can be quite creative with the test management tools. For example, if a test setup encounters a high-severity bug, you could configure your test software to pause the test, deploy to a second environment and continue testing in the second environment. This allows you to go back to the first test setup to troubleshoot, and find the cause of the crash.
Another fascinating advantage is that you can deploy demo or beta systems at will (assuming your deployment model allows it.), and let your sales team or prospective customers to “play with” the early release. By making it easier to expose early releases of the product to the outside world, Cloud Computing further improves the quality of your product.
Will you save money by testing in a Cloud Computing infrastructure?
Obviously the answer depends … on your usage, but also on factors like how much data you need to keep permanently in the cloud. For example you may need to permanently store a synthetic database of a million users (it would be too slow to upload it each time). You will also incur higher networking traffic.
In addition, you may not want to move all your tests to the cloud. For example, you may want to keep your stress-tests, or longevity tests in-house, since these will be running 24×7, and you may want the option of running them on bare-metal.
At the end of the day, to me the attraction of Cloud Computing for testing is that it will increase quality (in addition to reducing costs). It will allow each developer to have access to a test environment at will. It will create an additional impetus for test automation. Cloud Computing will also allow the concurrent deployment of tests to an arbitrary number of computing environments, and make it easier to give early access to your customers. Net-net, this translates to more tests in the same amount of time with less effort. It’s all goodness.
MVP – Minimum Viable Product
Filed under: Agile Software Development, Customer Discovery, Entrepreneurship | Tags: Customer Discovery Process
Comments (1) I have recently discovered, with great delight, Eric Ries’ “Startup Lessons Learned” blog , and in particular, his post about Minimum Viable Product (MVP). This is not surprising, since we are both fans of Steve Blank‘s Customer Discovery Process.
Eric’s post reminded me, how critical, yet how difficult in practice, the concept of Minimum Viable Product is.
Defining the minimum viable product correctly allows you to release products that are valuable to your customers with the minimal amount of energy and time invested – because as the name says, you have done the minimum, and yet you provide value. Said differently, if you only need to have 2 features in your product in order to sell it for $100, then you’d be crazy to spend the extra effort to add a 3rd or a 4th feature. Plus, by only delivering the minimum, you get to market fast – and hopefully beat the competition.
So why is this so difficult in practice … at least in my experience 
?
My first answer is that it is a lot easier to define the Maximum Product than it is to define the Minimum Viable Product.
Defining the Maximum Product entails compiling a list of all the possible features that your product could possibly have: you only need to talk to a handful of customers and take good notes. Critical thinking is not required. It is easy to get consensus on the Maximum Product: More is always better. The only problem is that no company can afford the time it takes to deliver this “ideal” product. Hence this need for the MVP.
The first step in defining the MVP is the one that is most often overlooked: you first need to define the segment of your customers that you target with the new product. The segment has to be small enough to group customer with similar requirements, but large enough that your new product will generate enough revenue.
The second step is to define the theme of the product in terms of benefits (not features). One of the best tools to help define this theme is by imagining that you are putting up a huge billboard on 101 (one the main arteries of Silicon Valley) that will advertise the new product: what does the billboard say?
The third and final step is to define the critical mass of features in the release. In this step, ruthless time vs feature vs price trade-offs need to be made – because the question is not just “what features do our target customers absolutely need?” (this list will always be too long), but rather: “Will our customers be willing to buy the product with these features - available at this date - at this price? Economically, this question may have multiple correct answers. However, in practice, presented with this question, customers will often select a date in the near term, which in turn defines the minimum viable product.
Nice presentation on “The Lean Startup”
Check out this nice presentation on the Lean Startup.
http://tinyurl.com/n5rt9a
While not all businesses, and products can accommodate IMVU’s rapid rate of release, the points about (a) rapid experimentation and (b) Agile Software development are right on the money
