So you have read The Lean Startup. Suffered through following several agile blogs (such as this one). You think you are ready to join the cool kids and have product scrums and stand-up meetings and all that other stuff. Now you need an implementation plan.
Maybe it is time to read this post by Paul Adams on the Intercon blog. He describes some of the lessons he and his development team have learned from building software and scaling it up as the company grows. I asked a few of my contacts at startup software firms what they thought of the post and there was mostly general agreement with his methodology.
Here are some of Adams’ main points to ponder.
Everyone has a different process, and the process itself changes as the company matures and grows. But his description is for their current team size of four product managers, four software designers, and 25 engineers. Like he says: “it’s not how we worked when we had a much smaller team, and it may not work when we have doubled our team.”
Create a culture where you can make small and incremental steps with lots of checkpoints, goals, and evaluations. “We always optimize for shipping the fastest, smallest, simplest thing that will get us closer to our objective and help us learn what works.” They have a weekly Friday afternoon beer-fueled demo to show how far they have gotten in their development for the week. Anyone can attend and provide comments.
Facetime is important. While a lot of folks can work remotely, they find productivity and collaboration increases when everyone is in the same room in a “pod.” Having run many remote teams, certainly local pods can be better but if you have the right managers, you can pull off remote teams too. It appears IBM is moving in this “local is better” mode lately.
Have small teams and make them strictly accountable. Adams has a series of accountability rules for when something goes wrong. Create these rules and teams and stick by them. “We never take a step without knowing the success measurement,” said one friend of mine, who agrees with much of what Adams says in his post. My friend also mentions when using small teams, “not all resources have a one-to-one relationship in terms of productivity; we find that we that the resources we use for prototyping new features can generally float between teams.”
Have a roadmap but keep things flexible and keep it transparent. “Everything in our roadmap is broken down by team objective, which is broken down into multiple projects, which in turn are broken down into individual releases,” said Adams. They use the Trello collaboration tool for this purpose, something that can either be a terrific asset or a major liability, depending on the buy-in from the rest of the team and how faithful they are to keeping it updated.
However, caution is advised: “The comprehensive approach that Adams describes would be entirely too much overhead for most startups,” says my friend. This might mean that you evaluate what it will take to produce the kind of detail that you really need. And this brings up one final point:
Don’t have too many tools, though. “Using software to build software is often slower than using whiteboards and Post-it notes. We use the minimum number of software tools to get the job done. When managing a product includes all of Google Docs, Trello, Github, Basecamp, Asana, Slack, Dropbox, and Confluence, then something is very wrong.”
Several years ago I wrote, “everyone is in the software business. All of the interesting business operations are happening inside your company’s software.” Since then, this trend has intensified. Today I want to share with you three companies that should come under the software label. And while you may not think of these three as software vendors, all three run themselves like a typical software company.
The three are Tesla, Express Scripts, and the Washington Post. It is just mere happenstance that they also make cars, manage prescription benefits and publish a newspaper. Software lies at the heart of each company, as much as a Google or a Microsoft.
In my blog post from 2014, I talked about how the cloud, big data, creating online storefronts and improving the online customer experience is driving more companies to act like software vendors. That is still true today. But now there are several other things to look for that make Tesla et al. into software vendors:
- Continuous updates. One of the distinguishing features of the Tesla car line is that they update themselves while they are parked in your garage. Most car companies can’t update their fleet as easily, or even ever. You have to bring them in for servicing, to make any changes to how they operate. Tesla’s dashboard is mostly contained inside a beautiful and huge touch LED screen: the days of dedicated dials are so over. These continuous updates are also the case for The Washington Post website, so they can stay competitive and current. The Post posts more total articles than the NYTimes with double the reporting staff of the DC-based paper. That shows how seriously they take their digital mission too.
- These companies are driven by web analytics and traffic and engagement metrics. Just like Google or some other SaaS-based vendor, The Washington Post post-Bezos is obsessed with stats. Which articles are being read more? Can they get quicker load times, especially on mobile devices? Will readers pay more for this better performance? The Post will try out different news pegs for each piece to see how it performs, just like a SaaS vendor does A/B testing of its pages.
- Digital products are the drivers of innovation. “There are no sacred cows [here, we] push experimentation,” said one of the Post digital editors. “It is basically, how fast do you move? Innovation thrives in companies where design is respected.” The same is true for Express Scripts. “We have over 10 petabytes of useful data from which we can gain insights and for which we can develop solutions,” said their former CIO in an article from several years ago.
- Scaling up the operations is key. Tesla is making a very small number of cars at present. They are designing their factories to scale up, to where they can move into a bigger market. Like a typical SaaS vendor, they want to build in scale from the beginning. They built their own ERP system that shortens the feedback loop from customers to engineers and manages their entire operations, so they can make quick changes when something isn’t working. You don’t think of car companies being so nimble. The same is true for Express Scripts. They are in the business of managing your prescriptions, and understanding how people get their meds has become more of a big data problem. They can quickly figure out if a patient is following their prescription and predict the potential pill waste if they aren’t. The company has developed a collection of products that tie in an online customer portal to their call center and mobile apps.
I am sure you can come up with other companies that make normal stuff like cars and newspapers that you can apply some of these metrics to. The lessons learned from the software industry are slowly seeping into other businesses, particularly those businesses that want to fail fast and more quickly as their markets and customers change.
Today most of us go about implementing security from the outside in. The common practice to define and then defend a perimeter isn’t viable any longer. With the added complexities of more mobile endpoints, agile development and more sophisticated malware, better protective methods are needed.
In this whitepaper for Vasco (the link to my paper is on the right-hand menu), I describe a method that is gaining traction by defending the actual apps themselves using runtime self-protection. RASP, as it is called, comes from a Gartner 2012 report, but is catching on with several vendors, including Arxan Technologies, HPE App Defender, Immun.io, Lookout App Security/Bluebox, Prevoty, Vasco Digipass for Apps, Veracode and Waratek.
RASP can be a solid defense and a way to isolate and neutralize a potential threat, so you can operate your business safely in these uncertain environments.
Google Docs is a favorite way to build applications for lightweight data manipulation, reporting, and analytics as well as useful for building websites that can capture and display data. While it is a great tool to get started using an online all-purpose office suite, you should also know its limitations and when it is time to move on to something more industrial strength. In my post for Quickbase’ FastTrack blog, et’s look at what is missing and when you should move on.
Nearly 30 years ago, Lotus Software came out with a radical new tool called Notes that has since become a corporate staple. More than an email program, it was used by IT and non-IT alike to build collaborative apps. Think of it as the origin of the citizen developer movement.
But Notes has stalled and many corporations are looking to move on to something else. You can read my post on QuickBase’s FastTrack blog here about what can citizen developers do to get the decommissioning party for Notes started.
Many of us started out with database software with something like Microsoft Access. It came included as part of the Office suite, was fairly easy to get started and infinitely customizable for light database programming. But with all these advantages, it might be time to look elsewhere for alternatives, especially for citizen developers who want to build more sophisticated online database applications.
You can read my post here about ways to recognize when your Access is running out of steam.
With the number of coding for cash contests, popularly called hackathons, exploding, now might be the time that you should consider spending part of your weekend or an evening participating, even if you aren’t a total coder. Indeed, if you are one of the growing number of citizen developers, you might be more valuable to your team than someone who can spew out tons of Ruby or Perl scripts on demand. I spoke to several hackathon participants at the QuickBase EMPOWER user conference last month to get their perspective. You can read my post in QuickBase’s Fast Track blog today.
Last month’s Wired magazine featured a cover story entitled, “The End of Code.” Its thesis is that machine learning and neural networks will eventually obviate the need for programmers to write code. While it is an interesting thought, we are far from that situation actually happening anytime soon. Rather than seeing the end of coding, I think we are just at the beginning of a new era where coding and business-led app building is becoming more plentiful and exploding. This is the era of the citizen developer who has to carry the water for the rest of the world.
The issue isn’t whether any of us will or won’t code, but how we can do a better job with the coding tools and low-code platforms that we have at our disposal. My Fast Track blog post today talks more about these issues.
In the Quickbase blog The Fast Track, many others have written extensively about the rise of the citizen developer movement, whereby everyone can become a developer because of the widespread availability of rapid app development tools. IT professionals have been trained how to manage their app portfolios, and there is no secret to doing this. In this post, I suggest some ways to start thinking about how you can manage and build more capable apps on your own. Building the app is just the beginning of a lengthy process. More on this idea here.
Today we have a seeming ubiquity of the coding generation: rapid application development can be found everywhere, and it has infected every corporate department. But what is lost in this rush to coding everywhere is that you really don’t need to be a programmer anymore. Not because everyone seems to want to become one. But because the best kinds of collaboration happen when you don’t have to write any code whatsoever.