To learn more about what works and what doesn’t in large-scale DevOps and agile deployments, we need data. The problem is, that data is notoriously difficult to get ahold of because much of it lies hidden across numerous private repositories.
Efforts such as The State of DevOps reports have helped us gain some understanding by using survey data to answer questions about practices such as the frequency of deployments in a team or organization. However, survey data has its limitations, as Nicole Forsgren and I described in "DevOps Metrics," which we wrote to clarify the trade-offs of system and survey data collection. 1 Today, our understanding of DevOps practices is based largely on this survey data and on anecdotal evidence. Is there a way to expand our view of DevOps to include studies of system data of DevOps at work?
Most enterprises do not yet think of their delivery pipeline as a product. When I mentioned this concept to a few folks, they literally slapped themselves on the head and said something like "that makes so much sense and it so simple, why didn’t we think of that!" – Carmen DeArdo, Tasktop
It’s been a week since the lively and deeply enriching DevOps Enterprise Summit 2018 in Las Vegas came to a thundering close, giving us some time to digest and reflect on yet another successful event by the IT Revolution team.
I caught up with Carmen DeArdo, Tasktop’s Senior Value Stream Strategist, about his experience at the event, including his favorite speaker sessions, the event’s major themes, noteworthy conversations he had with the DevOps community, and the launch of our CEO Mik Kersten’s eagerly-awaited book, Project To Product and the pioneering the Flow Framework™.
Websites, web applications, and desktop applications are systems, known as the concept of human-computer interaction (HCI). Human interaction with systems is what we called the user experience (UX). UX is important because it aims to provide positive experiences that keep users loyal to the product or brand. With the rapid development of industry technology and methodology, websites and web applications are now more complex than before. The modern structure of static web pages have become so complicated, and some do greatly enhance the interactive design and experience.
According to the definition of UX, an excellent UX designer focuses more on the interactive level of products, asking questions like which way is the product displayed to the users in? In particular, how does the panel pop up? How does the user respond to the panel? UX designers study and evaluate a system’s user experience concerned with the system’s ease of use, value, practicality, efficiency, etc.
A lot of articles address the role of tech leads and engineering managers. One common theme we often come across is how to increase a team’s productivity. But before you focus your energy trying to increase their productivity, you might first want to consider what’s destroying it, to have a sound base on which you can build. Unfortunately, even though Peopleware was published almost 30 years ago, we see lots of teams suffering from huge productivity loss in some (negatively) remarkable ways!
No one expects a programmer to get work done without access to a computer, but there are many companies that expect programmers to get work done without access to their mind. This is equally unrealistic.
We hear a lot these days about project-based organizations vs. product-based organizations. Much of what we do in software is in service of products. Products tend to evolve over time.
When we work on projects, we learn from the experience. However, once we finish this release, the "product" (the output of the project) doesn’t change and incorporate our learning for the future. Here are some examples of projects where we learn, but the product doesn’t change:
This is Part 2 — make sure you read Part 1 before you continue.
I have talked to countless organizations where operations is in the infrastructure group, and they’re part of the run, plan, build, etc. They run everything. They run the platform, they run the infrastructure, they run the middleware, they run the applications.
What we could be talking about here is really DevOps. Let’s put operations, let’s make operations part of the product teams. Again, it doesn’t have to be the same exact individual. It has to be the team though. Instead of having one operations group, let’s put operations capabilities into each of the product teams so that the people who are experts in operating the platform product can operate the platform product, and we empower the teams and the application team. We give them the right abstractions so that they can do their own operations.
That doesn’t mean that they have to learn the entire stack down to the infrastructure. For goodness sake, no!
We don’t all become experts at everything, but we give them the tools and the empowerment to do their own operations. We take a function that was one function, and we split it out over the different product teams.
I was working with a very large automotive manufacturer in the United States, and I was talking with somebody from their ops team. I was poking at these roles, trying to understand exactly what theirs looked like, and I said, “Who’s responsible for capacity planning?” And, I kid you not, the individual from this organization pulled up the IT manual and said, “See, it says right here, we’re responsible for capacity planning.” It was that rigid. There was one group that was responsible for capacity planning across this entire spectrum.
That’s pretty normal. So what happens?
Well, the capacity planning process goes something like this. Really early on, well before production, we have to come up with some estimate of how much capacity you’re going to need, and you know what? We’re lousy at that. It’s impossible to come up with a really good prediction of what the capacity is that we’re going to need.
Since, we know that we’re lousy at it, the worst thing that would happen is if we underestimate. So we overestimate. We end up over provisioning, and we have resources that are under-utilized.
The answer here is to put capacity planning in both of the places. Now, it’s not as easy as that. It comes back to the contract that’s sitting between the platform team and the application team. You cannot, for example, have the App team doing their capacity planning and doing the scaling. Capacity planning is not just an estimation function now. Capacity is really capacity management. If I need more, I get more.
But how do I keep the application teams from exhausting the resources that are in the platform? Well, we do that with contracts. Simple things like quotas.
Even if you’re using GCP, or Azure, or EC2, or any of the AWS capabilities, you have quotas. Yes, it’s very simple to get more, but you have that contract with AWS that says here’s the amount of capacity that I need. AWS or whoever your platform team, is going to use those quotas to estimate the actual capacity that they need to provide from the platform. So it’s important to come up with that contract and then each of the teams comes up with the processes that they’re going to use to both provide enough capacity to their consumers and to estimate their capacity needs going down.
The next ones, you’ll notice I pulled from the data team. Now I will confess to you right now that, again, I’ve been working on Cloud Foundry for the last just about five years, that we as an industry have made a lot of progress on breaking things up and figuring out how to reorganize groups when it comes to application capacity, when it comes to compute, but we haven’t done as well on the data side.
For example, in most cases, we’re seeing, organizations creating microservices based architectures that if you peek behind the covers just a little bit, you notice they’re all tied to the same very large monolithic database. From an organizational perspective, we’ve seen very little movement on the way that the data team is reorganized and they’re the ones that are responsible for providing any kind of database capacity into the organization.
I sometimes like to say this is the group that you go to and they say, “Hi, Oracle is the answer. What’s the question?” We want to break that apart as well. Whether these terms are the exact right terms or not, you can notice that I moved the DBA, and I’m considering the DBA, the individual who’s responsible for providing the database servers, the database clusters, for providing that capacity. They belong as a part of the platform team.
Now the platform team, can, in fact, be subdivided into smaller two-pizza teams, so you might still have a team that specializes in providing relational database capacity, another team that specializes in providing compute capacity, another one that specializes in providing graph database capacity and so on. But we have that team that’s responsible for providing those services as a part of the platform substrate.
Then what we want to do is give them control of their databases and their Schemas. Let them evolve their Schemas, let them version those Schemas, let them figure out how they can have multiple Schemas running in parallel, all of those types of patterns. We want to break up data into the right groups as well.
I’m going to bring another organization into the picture here, and that’s the business. What we’ve had in the past, you’ll notice there, under enterprise architecture, are business analysts. Business analysts have generally been in the business of taking the requirements from the business and translating them into something that they can start to launch the rest of the IT process.
What I want to do here is I want to take your business analyst and not make them THE product manager. I want to pair them with somebody from the business, because if you don’t pair them with somebody from the business, then you’re still throwing things over the wall. Remember the picture at the very beginning, I’m still starting with the business who’s throwing things over the wall, and so you’re still going to have that conflict, that tension, that finger pointing that happens when we do scope creep, etc. Make them part of the product management team, though, they’re now responsible for the scope themselves. There are no longer change orders.
Now, of course, it’s not just the application, the consumer-facing application team that needs product managers. The platform team needs product managers as well, and what we found that is really, helpful is that the folks from your enterprise architecture group are really good candidates for becoming the product managers, or maybe pairing with somebody from the infrastructure teams to be the product managers for the platform team.
You’ll also notice that I’ve put enterprise architecture as a part of the platform team, but I’ve left them over there in their bubble as well.
Now, I’ve got two things left.
I’ve got some enterprise architecture roles, and I’ve got enterprise application roles.
The third house that I’m going to add is your enterprise applications house.
So DCTM, you’re probably wondering what that is.
Documentum Enterprise Application was built 30 years ago. It’s one of those monolithic applications. Built on top of kind of a three-tier architecture. It’s got that big old Oracle database, or a sequel server database at the bottom. Very resilient, resilient storage systems. It’s got a big, thick tier in the middle, and it started out with the desktop client application, and this was pre-web, of course.
You all have these types of enterprise applications in your organization, and we have to continually deal with them. The first thing that I’ll tell you is that I want you to start thinking about your Documentum team, or your enterprise application team, as the product teams.
Now, they are not going to be able to move as agile as some of those other organizations. However, there are like Rosalind Radcliffe who is applying DevOps principles to the mainframe. The lessons that you may learn from her are the lessons that you should be applying here. You can do product management, you can do DevOps in these settings as well.
These systems, however, will tend to move, particularly while you’re still making the DevOps transformation at a pace that is not quite the same cadence as the daily or multi-daily releases that are happening by the App teams.
What we want to do now is create multiple product teams, multiple application teams across the top that are leveraging both the new platform as well as connecting into the enterprise systems. I call that the legacy service team here.
This is the team that is generating the interface that’s going to mediate between the application teams on the left-hand side, and the enterprise system on the right. Notice that it’s a product team just like any of the other product teams with a product manager, capacity planning, all of those types of things.
Let’s talk a little bit more about enterprise architecture. I was at a conference a couple of years ago, and I was having breakfast with a number of individuals that I didn’t know. There was somebody from QVC. There were two individuals from that organization there. One of the individuals was telling a story where he said, “Last year when I was at the conference, I was part of one of these teams over here. This year I’m in enterprise architecture. Last year I was policed, this year I am the police.” I thought, “Remind me not to go work there.”
What we want to move away from is this notion of enterprise architecture being the ivory tower. This has been one of the most successful things that I’ve seen with the organizations that I’ve been working with. By and large, the enterprise architects love this transformation.
Here’s what we’re doing, I’m going to introduce a new house. This last house I’m adding is what I’m calling the “Enablement house.” It says: take some of those functions that are in enterprise architecture and instead of making them an ivory tower, follow the practices, have them in the role of enabling teams. One of the best ways that you can have them in a role of enabling teams is actually to make them part of the team.
You’ll notice here that I didn’t remove them from the enablement organization. These are individuals that can stay as a part of a matrixed organization like enterprise architecture, but they actually spend part of their time pairing in the teams. They become parts of the team members. They’re measured on that team success. It’s important, though, that they still have this broad view across the different projects because that’s where you start to see about the reuse.
One final thing that I want to add into this picture is that enterprise architecture is not the only organization that I’m suggesting that stays together as an organization and is then paired into the product teams. Other organizations like that would be things like information security.
That is the final sorting that I want to do, now, let the wizarding begin.
Attend the DevOps Enterprise Summit in Las Vegas: October 22-24, 2018
There is a strong tendency among Java and C# programmers to prefix or suffix their extended types, such as naming a “smart”
SmartView or a
Work that is “delegated” as
DelegatingWork. In this post, I will focus on decorators and how this widespread naming scheme reduces readability and adds no value to the code’s context. I think it’s time that we retire this needless naming redundancy.
Milton, from Office Space
Composable decorators are small, highly cohesive objects that work off of another instance of their same type and, thus, are unable to function on their own. You can think of decorators as adjectives.
final Collection<Product> products = new FilteredCollection<>( Product::active, new MappedCollection<>( Subscription::product, new JoinedCollection<>( subscriptions1, subscriptions2, ... ) ) );
The problem with the traditional naming scheme is the needless repetition — we know from the outset that
products is a
Collection, but the code keeps hammering this point over and over again as we read on. This code is tedious to write, but, more importantly, it is tedious to read because of how the words are composed:
‘Product’ is a filtered collection, a mapped collection, and a joined collection
Normal, everyday speech is not encumbered like this; nouns are routinely omitted when sufficient meaning can be extracted from the context. You don’t normally say
The rich people and the poor people.You just say
the rich and the poor. Nouns are omitted and adjectives are nominalized.
Following this same principle, let’s make the code below read like this:
‘Product’ is a filtered, mapped, joined collection
It would have to look like this:
final Collection<Product> products = new Filtered<>( Product::active, new Mapped<>( Subscription::product, new Joined<>( subscriptions1, subscriptions2, ... ) ) );
I recommend that we make our code more terse by removing redundancy and allowing the code’s context to work in our favor for readability’s sake. For example, let’s use nominalized adjectives as names for our decorators.
“We need a product that does X because our competitors have a product that does X”
“Our product needs feature Y because our competitors product has feature Y.”
It makes me want to cry.
Let me clear: building something because your competitors have it IS NOT A STRATEGY.
Neither is it a particularly good tactic.
Stop obsessing about your competitors and think about your customers.
I don’t doubt that your people are being told that customers are buying the competitor product because it has X or Y and I don’t doubt that some of your people feel that if you only matched the competitors feature-for-feature you would win, but I just can’t see it myself.
For a start, is feature Y really the only thing losing the sale? Are the products so well-balanced that this one small thing is it? And is there really nothing that your product does better?
Try this simple experiment: tell the customer that feature Y will be delivered next month and see if they decide to buy yours there and then, or find something else that makes the competition better.
Now let’s suppose you decide to build Y. Before you make any plans ask yourself:
While you are building feature Y what are your competitors going to be doing?
Will they stand still or will they be adding feature Z?
And once they have feature Z will you need to play catch up?
Chances are that tomorrow you get to where you want to be (where your competitors are today) only to find your competitors have something else you don’t have either.
I’ll agree this is a good strategy if you have deliberately chosen to be a Fast Follower — you can play Android to your competitor’s iOS. Just make sure you know why your customers will choose your Android over the competitor iOS. Will you be cheaper? Or better? Or will you bundle some other goodies with it?
Before you run to where your competitors are today, ask yourself: where will your competitors be tomorrow?
If you still insist on building this feature you need to:
A better approach is to find out what your customers actually need. Stop looking at the features, go back to first principles: what is the problem your customers face? what is the job they are attempting to make progress with?
How can you help your customers with this job?
How can you make them faster?
How can you help them achieve their work more cheaply? Or at better quality? In fact, what do “better” and “quality” look like to them?
Someone — I honestly forget who — told me earlier this year that they wanted to catch-up with their competitor and overtake them.
One small flaw there: if you build features to match your competitors you can never overtake them because you won’t know what to build once you reach parity.
Put it another way, you add all the features they have today, and all the features they add while you are catching up. What do you build next? Until they build their next version (and recapture the lead) you don’t know what to build. And if you build something different you just lost feature parity.
So, go back and examine what your customers are using your tool for. Look at the job to be done, look at how your customers are doing their job and using your tool and work out for yourself how you can help customers do a better job.
Celebrate the difference, explain why you are better.
And please forget about matching the competition.
I’m old enough to remember the days when WordStar was fighting WordPerfect, AmiPro was fighting them both, and all were better than Microsoft Word. Adverts and magazine reviews would compare them feature to feature. Someone somewhere thought people bought word processors based on the number of features.
Then Microsoft launched Windows and everybody went over to Microsoft Word for Windows almost overnight.
Don’t focus on your competitors. Focus on your customers. Unfortunately, that requires more work and some original thinking.
The QA strategy (or lack thereof) that works well when your team is first starting out probably wasn’t necessarily sophisticated. But teams that go through periods of growth often discover the hard way that QA that is “good enough” for a tiny start doesn’t hold steady in the long run.
Spotify is a great example of how to scale development and QA practices successfully. Since their launch in 2008, Spotify has grown from 150 employees to over 2000. How do they keep product quality high for over 157 million users? Here are a few QA lessons shared by Spotify that growing development teams can model their own testing process after.
One of the biggest hurdles faced by growing teams like Spotify is maintaining quality and coverage over time. As organizations gain momentum, opting for quick fixes and low-hanging fruit can easily become the norm. But to scale effectively, teams must prioritize development and testing choices that will provide the best long-term gains. At Spotify, developers work with the product team to prioritize testability and stability in the product over time.
“If you have a solid system to test, you need to add a lot of testability; I talk to the product owners saying that we need to add this to give you what you want. I know you didn’t order this, and this will take us ten days extra, but this is what we have to do to have a product which we can have high reliability in the future.” – Kristian Karl, Test and Development Manager
Fast-moving organizations know that siloed QA teams don’t scale. Spotify’s development organization is composed of squads and tribes arranged around focus areas. This structure helps individuals collaborate across different functional areas more effectively, and ensures that the goals of the QA, product and development teams stay aligned.
In addition to this more tribe-squad team structure, Spotify stresses that the role of QA isn’t to block releases or act as a gatekeeper, but to collaborate with developers and product teams to continually improve the product.
Leaving that role behind can be harder to do than it might sound like. It takes some effort as a QA to not have full control of what goes out to the end-user, but to try to have that would be detrimental to true engagement from the others in the dev-team, and also slow all of you down immensely. – Olof Svedström, QA Chapter Lead
Testing automation is a key component of Spotify’s ability to scale development. However, it isn’t used as a panacea for every quality woe. Instead, Spotify’s QA team uses testing automation as a tool to help their QA engineers be more effective, and focus more of their energy on their overall product quality goals.
“I would rather say that you can never replace humans with machines for testing. We can lose 20% of the testers that don’t apply. The number of tests that you can do on this system is infinite. If I can get help with automation, I can focus on further, deeper and broader tests. That’s what I want to achieve and get from automation.” – Kristian Karl, Test and Development Manager
We recently took a look under the hood at a few big-name enterprise organizations with famously lean QA processes. In our guide, Agile QA at Scale, we dig into how companies like Spotify, Facebook and Atlassian have built QA strategies that scale, and the lessons that growing teams can learn from how they approach quality assurance.
Download the guide now for more insight into what it takes to build a software testing strategy that will scale with your organization.
DataStax Enterprise (DSE) 6 represents a major win for our customers who require an always-on, distributed database to support their modern real-time (what we call ‘Right-Now’) applications, particularly in a hybrid cloud environment. Not only does it contain the best distribution of Apache Cassandra, but it represents the only hybrid cloud database capable of maintaining and distributing your data in any format, anywhere—on-premise, in the cloud, multi-cloud, and hybrid-cloud—in truly data autonomous fashion.
To start, new functionality designed to make Cassandra more efficient with high-compute instances has resulted in a 2x or more out-of-the-box gain in throughput for both reads and writes. Note that these speed and throughput increases apply to all areas of DSE, including analytics, search, and graph. A new diagnostic testing framework developed by DataStax helped pinpoint performance optimization opportunities in Cassandra, with more enhancements coming in future releases.
Next, DSE 6 includes our first ever advanced Apache Spark integration (over the open source work we’ve done for Spark in the past) that delivers a number of improvements, as well as a 3x query performance increase.
All of these performance improvements have been designed with our customers in mind so that their Right-Now applications deliver a better-than-expected customer experience by processing more orders, fielding more queries, performing faster searches, and moving more data faster than ever before. If an app’s response time exceeds three seconds, it won’t be because of DSE.
In designing DSE 6, we listened to both DataStax customers and the Cassandra community. While the interests of these groups sometimes diverge, they do have a few things in common.
It turns out that helping with Cassandra repair operations is a top priority for both. For some, Cassandra repairs aren’t a big deal, but for others they are a PITA (pain in the AHEM). Don’t get repair right in a busy and dynamic cluster, and it’s just a matter of time until you have production-threatening issues.
If you like your current repair setup, keep it. But if you want to eliminate scripting, manual intervention, and piloting repair operations, you can turn on NodeSync and be done. It works at the table level so you have strong flexibility and granularity with NodeSync, plus it can be enabled either with CQL or visually in OpsCenter.
Another area for improvement on which open source users and DataStax customers agree is upgrades. No technical pro that I know looks forward to upgrading their database software, regardless of the vendor used.
These management improvements and others are directly aimed at increasing your team’s productivity and letting you focus on business needs vs. operational overhead. The operational simplicity allows even novice DBAs and DevOps professionals to run DSE 6 like seasoned professionals. Ultimately that means much easier enterprise-wide adoption of data management at scale.
For the first time, we’re introducing our advanced Spark SQL connectivity layer that provides a new AlwaysOn SQL Engine that automates uptime for applications connecting to DSE Analytics. This makes DSE Analytics even more capable of handling around-the-clock analytics requests, and better support interactive end-user analytics, while leveraging your existing SQL investment in tools (e.g. BI, ETL) and expertise.
We also have great news for analytics developers and others who want to directly query and interact with data stored in DSE Analytics. DataStax Studio 6 provides notebook support for Spark SQL, which means you now have a visual and intelligent interface and query builder that helps you write Spark SQL queries and review the results – a huge time saver! Plus you can now export/import any notebook (graph, CQL, Spark SQL) for easy developer collaboration as well as undo notebook changes with a new versioning feature.
Over 60% of DataStax customers currently deploy DSE in the cloud, which isn’t surprising given that our technology has been built from the ground up with limitless data distribution and the cloud in mind. Customers run DSE today on AWS, Azure, GCP, Oracle Cloud, and others, as well as private clouds of course.
DataStax Managed Cloud , which currently supports both AWS and Azure, will be updated to support DSE 6, so all the new functionality in our latest release is available in managed form. Whether fully managed or self-managed, our goal is to provide you with multi and hybrid cloud flexibility that supplies all the benefits of a distributed cloud database without public cloud lock-in.
With DSE 6, we want you to enjoy all the heavy-lifting advantages of Cassandra with none of the complexities and also get double the power. , are now available, so give DSE 6 a try (also now available for non-production development environments via free online training , and other Docker Hub) and let us know what you think.
2018 has come, and it is virtually impossible to talk about agile product management methodologies without referring to story mapping techniques. And rightfully so – user story mapping has become one of the cornerstones of agile product development and it is hard to imagine modern product management without it.
Story maps are essentially a method of laying out your initial specs for the product, by way of a story. While verbalizing and thinking your product’s story out loud, you give it form and substance, challenge its validity over and over, identify problems, scrutinize the process and fill in the missing pieces.
Much of the story map’s success depends on the owner’s creativity and ability to run with her/his associative logic. This is a fragile process that leans heavily on one’s concentration, so it warrants delicate handling. We’ll get to that later.
The traditional way to story map is with stick-its, but I find it too confusing and after the second time, I realized I lost my hands and feet in an office covered wall to wall with stick-its and I started looking for free story mapping software. It became easier once we launched Craft and we’re now able to streamline the discovery process, prioritization, workbench, and backlog all on the same platform.
The story mapping technique is considered a “softer” way of product specing (as opposed to user interviews and data-based research) when in fact, it is much more comprehensive in terms of identifying user behavior patterns and spotting challenges. In other words, it is a more holistic approach to product development.
Another point in favor of agile story mapping is that it is easy to manage in the fast-paced, rhythmic agile environment. When you work in two-week sprints, it is practically impossible to aggregate data at the proper pace.
I put together a short list of takeaway benefits I like to call “Story Mapping Saves Lives,” but it comes with reading instructions: scan it now, and return to read it in-depth after you learn how to create a story map:
Each agile user story map is composed of 5 stages, carefully yet intuitively structured. None of it is particularly complicated, but attention to details is of the utmost importance. A winning tip for successful agile story mapping: try to pace your progress and see every stage through to its very end, because every stage is constructed largely on the previous one and we need a stable base to build our product upon.
To put it simply: tell your story. Sketch a high-level overview of your story. Before you go into details, you need an outline of the thing you want to build. This is an excellent exercise for agile product managers in planning with the big picture in mind.
Start building the story step by step. Simulate the user’s journey through the product, corresponding to their needs and pains. These are the stepping stones of your product, so to speak. It is important to break down the user journey to as many steps as possible – the deeper you drill down, the richer your picture becomes, making sure you don’t skip any critical stages or give yourself a pass on any challenging elements.
Start pouring life into the steps. Broaden your vision to include details and put flesh on the bones. You will notice this is where you start scrutinizing your product on an insane detail level. I can’t stress this enough – more details are better. This is where the plot thickens: you may start to find different use cases for different details and elements.
Remember back in #3, when you piled heaps of details, use cases, and usage elements? Prioritization is when you get to decide what matters, what matters less and what should be scrapped. Prioritize elements according to relevance and user needs. Note that this isn’t product prioritization yet, but a more intuitive “taking stock” measure.
Create personas and apply them to the stories. This can create derivatives and help further find holes. Notice that in some cases, the steps vary so much for the new persona, that it spins off a whole new story. I know some product managers who create a whole new story map, to correlate with the new persona’s journey. Personally, I find this is a good point to stop, take a step back and decide whether or not this new persona’s needs are within the scope of my target audience.
Screenshot from Craft’s Story Mapping module
Remember we talked about how fragile the process of mapping out the story is? Our product owner and storyteller’s process of thought depends fiercely on her/his ability to complete a line of thought and glide into the next one, uninterrupted. This is how we make sure that happens:
When all’s said and done, it’s quite difficult to stay focused on the big picture with so many details clogging the view. Difficult, but crucial. Over time, I devised a series of questions, which I make sure to stop every now and again during the story mapping process and ask myself, just to make sure I’m still on track. I call them “The W’s”:
Agile story mapping techniques and tools are a rising field. My instinct tells me we are going to get so much more out of them in the coming years and story maps will develop into an even more central tool in agile product discovery.
Above all, it brings out the human aspects of product usage and user needs. A good story map demands that the product manager be a storyteller, telling a structured but evolving story of a user’s journey down the product path. It’s demanding, stimulating and fun as hell if you dive in and immerse yourself in the product story.
Sprint Zero is a way to get everything ready to start work, to buy the tools you need, set up your databases, perhaps do some architecture review, tell the rest of the organization about what you are doing, maybe write some requirements, get some additional training, etc., etc.
Sprint Zero doesn’t need to happen in a time box; you can take all the time you need. After all, you haven’t become “Agile” yet, and Sprint Zero will make you Agile.
Good idea? Please don’t.
Sprint Zero is a get-out-of-jail-free card that pushes really change down the road a little bit further. The truth is: there is work to do. Just start sprinting. Schedule an iteration to start tomorrow and get going. Do what you plan for the next week, then review and plan again.
Doing anything else delays the change and potentially reduces motivation.
If you want to call your first iteration Zero, then fine; you can call it Zero, or One, or Two, or 57 or even -1 if you want, I don’t care. Give it a number and make sure the next iteration adds one to that number.
All those things I just listed—and more—that you need to do to “get started” are themselves work that needs doing. Why not write them on a card and schedule them like you would any other piece of work in an iteration?
If you haven’t worked out what those things are, then no problem; try and schedule some real work. When you find you don’t have something (a database instance, for example), simply write out a card, schedule it, and do it. The things you need to do to “get ready” are actually things you need to do to build something you do want.
My big worry with Sprint Zero (apart from it injecting unnecessary delay and loss of change momentum) is that it makes work. You may think you need to do something in advance and you might be right. But, then again, you might be wrong. You might do something—like install a database—when you could quite easily postpone that work for a few weeks or even skip it entirely.
Similarly, some say, “How can we start work until we know what we need to do? We need to gather requirements, write some stories….”
But again: determining what needs doing, requirements gathering, is itself work to be done.
If it is not clear what needs to be done on day 1, then the first thing to do is to do some work to find out what needs to be done. The initial work may well be requirements discover and story writing with only a little bit of product building.
Speculative, early, requirements gathering, may actually increase the amount of work to do because you capture all the things people think you need to do. Once you start to put the product together you may not need those things, but once they are listed as part of the work to-do—and especially if they have been promised to someone—then not doing them can be problematic.
Anyway, having written this blog I now wonder if I should have bothered. Now I look about, a lot of other people have made similar points already. As I have been writing this post I thought I should find a definition of Sprint Zero, so I did a search. Interestingly, most of the articles that came up on page 1 of Google are also critical of Sprint Zero for similar reasons to myself. So maybe Sprint Zero is an idea whose time has already come and gone.
Software development and coding are two different things. Usually, the former includes the latter, but not always. Coding produces lines of code, while software development creates products. Unfortunately, the majority of programmers joining Zerocracy now are coders. Even though they claim to be developers, in reality, they are lacking the very important sociotechnical skills that differentiate product creators from lines-of-code writers.
Hard Men (1996) by J.K. Amalou
Let me show you the symptoms first.
Let’s call him Mario. He is a very skilled Java developer, as his resume says. He’s been in the industry for ten years or so, done a few enterprise projects; he seems to be very seasoned. We give him access to the project and assign a few GitHub tickets.
In a few hours, I get a Facebook message a page long. It says that he is very glad to be on the project, but doesn’t understand a thing yet and needs help. Here is a list of questions he prepared and he’s ready for a phone call to get them answered.
I reply: “Dude, I love you like a brother, but I don’t have time to answer your questions. Not because I’m lazy or don’t appreciate your work… Actually, yes, exactly because of that. I am lazy and don’t want to answer any questions over Messenger. My answers will be totally wasted, if you, for example, quit the project tomorrow. Or if someone else joins us in a week and has exactly the same set of questions. Do I have to explain all over again? I’m too
old lazy for that.”
In half an hour Mario submits a ticket to another (!) repository. The title is “The problem” and the description says “Help me understand the project.”
What do I do, as an architect of the project? I close the ticket with a quick message: “Please, make your tickets more specific.” My response is just one step away from “Get lost,” but what else can I say? Mario doesn’t know how to use the ticketing system. He’s most probably been working all his life in a cozy office, where everybody around was his friend. Not even using chat, just asking questions across the table. I’m asking him to do something he has never done before. Of course, he doesn’t know how. He feels ashamed, I suspect.
What happens next? He comes right back at me in Messenger, with the same set of questions. Actually, his reaction will depend on his personality. It may either be anger, confusion, or something else. But the bottom line is that Mario is not a software developer, he’s a coder. He doesn’t understand the dynamics of a modern software project, he doesn’t know how to use its communication instruments, and he has no sociotechnical skills:
The same happens to almost everybody who joins us, unfortunately.
A modern software project is much more a social activity than code writing. Knowing how to interact with the team and deal with information is much more important than knowing how to use design patterns. The only way to learn these skills is practice. I’ve said it many times, let me repeat it again: If you are not an open source and StackOverflow activist, you most likely won’t have these skills.
As part of the recruiting effort for a position I accepted a few years ago, the initial phone screen I participated in was with the Chief Information Officer (CIO) at the perspective employer. One might have thought that I was interviewing for a Chief Technology Officer (CTO) or some other high-level position. This was not the case, however, but was a decision the CIO held to as he screened close to 1,000 candidates focused on filling ~100 technology-based positions that made up the core group of his brand-new division.
While an article could be written solely around the CIO’s mindset and rationale for performing the interviews, I wanted to focus on a key aspect that the CIO taught me during the time we worked together. That key aspect is the importance of the technologist’s brand, regardless of the path their career will take.
The ABC network has maintained the popular reality television program the Shark Tank since 2009. According to Wikipedia, Shark Tank shows aspiring entrepreneur-contestants as they make business presentations to a panel of “shark” investors, who then choose whether to invest.
In the times I have viewed various episodes, one big distinction that the sharks often focus on during the sales pitch by the presenters is the differentiation between a product and a brand. More times than not, it appears that the contestant has created a product that meets a need where a competing product does not exist. Without knowing the official statistics, those purely product-focused presentations tend to gain an investor equally as often as they walk away without a deal. The one aspect that adds favor to the product-based pitch, is if there is a potential to license their idea for use by larger corporations that already cover that particular market space.
Where the sharks tend to get excited and even bid against each other, is when the sales pitch includes something that is more of a brand than a singular product. If they see the potential for a brand to emerge out of the sales pitch, they are much eager to partner with the contestants – with both their money and their time investments.
This same brand-based approach should be something every technology professional should be keeping in mind.
If someone were to ask you to describe yourself, as a career professional with a limited amount of space, how would you approach the question?
When I have asked this question to fellow attendees at a trade show, conference or user group, I am surprised by the number of times I hear an answer that includes skills and technologies over experiences. Here are some examples:
“I am a Java developer building applications using Spring Boot.”
“I am a Salesforce Administrator using SalesCloud and MarketingCloud.”
“I am a full-stack developer using .NET and ReactJS to build responsive web applications.”
My experience within Information Technology allowed me to understand the current skills being utilized by the individual, but I felt like I was getting the sales pitch for a particular product and not an established brand.
I wrote about the idea of an elevator-style sales pitch in my “Innovation Days (v2): Creating an Elevator Pitch Before the Product” in February 2016. When reflecting back to my original question, how does your answer change when I tell you that you have a limited amount of time and the goal is to sell yourself on the listener in the elevator — with no distractions to get in your way?
This time, you cannot be certain that your target audience has any knowledge on technologies. To the other person, Spring Boot could be something that is worn after the wintery temperatures have subsided, but the warmth of summer has not yet arrived. That SalesCloud and MarketingCloud terms may appear to be levels of clouds above the common cumulus and stratus clouds which can be viewed on a beautiful day. The idea of a full-stack may better represent the type of sandwich that they typically enjoy during their lunch hour.
Since your brand is something that is 100% up to you to maintain, below are some items to keep in mind:
Focus on your experience, especially differentiators that set you apart from others with similar technical skills. Instead of focusing on what technologies you have utilized, talk more about the need that was being addressed — at a level that most will understand and see the benefit from your efforts.
Gain an understanding of how others can relate to you. You may be a brilliant person, but if people don’t comprehend what drives you, your brand will become lost.
Examine your credibility. It is important that your views are credible and reliable, which is often supplemented with experience.
The ability to motivate and lead provides a solid window into your brand. This builds upon your credibility, taking your brand to a higher level.
The philanthropical angle is important as well. This ties to how often and the manner in which you take time to help others.
I have often heard, if there is no differentiation to your brand, you have no brand.
With the Information Technology (IT) industry constantly in a state of change, it is important that your brand always be tuned and focused on meeting the needs of the industry. If you maintain a solid brand, it becomes much easier for you to represent and sell yourself for whatever challenges you seek to embrace.
Technologies will come and go, but your experience will open future doors for you. The key is to understand how to build and refine your brand — with an awareness to constantly re-evaluate and re-build as necessary.
Have a really great day!
Every great startup begins with a great idea. But ideas are just ideas. Startups need to turn them into products that users will love for the first step to success. That’s why the product development cycle is the most exciting stage of your startup’s life. When it’s done right.
Here’s a quick A-Z on starting up your product development cycle properly:
Every captain needs a crew. Even if you have the best idea, you’ll still need a kickass team to help turn that into reality. How do you find the right people, though?
Start with a question: what and who do you really need? From this one question, you can determine the people you want to have on your team. Building your dream team isn’t like an open call for volunteers. You’ll need a stringent screening process to ensure aligned goals and visions. Look out for the qualities you need – skillsets, experience, passion and attitude.
In addition, the structure of the team is important to your product development success. For starters, here’s a good guide on how you can structure a consumer-driven product team.
Not every product is created the same. A food delivery startup is wholly different from an SaaS provider. Each startup’s KPIs vary from one another. Like building your dream team, creating the perfect set of KPIs for your startup starts with asking the right question: how do you want your product to succeed?
At the earlier stages of your product development, creating the best metrics is crucial. Attaching the wrong metrics to your young product may influence how it grows, for better or for worse.
Luckily, thought leaders in the startup scene have developed trustworthy frameworks that help teams assess their product. Notable examples of these are the HEART framework and PULSE metrics.
With startups coming out left and right, you might be tempted to push your product out as fast as possible. Besides the obvious quality issues, rushing your product can have consequences deeper into its heart—its code. Keeping code clean is a tougher challenge that all developers face. It takes time, effort, and a whole lot of coffee.
But it’s not just about poring over lines and lines of code to check for errors. Keeping code clean means keeping it easily readable and accessible for both the original developer and any succeeding developers who will handle the code in the future. In this state, software can be easily patched should any bugs pop up in the future. Having a clean code will ensure that your product is always up-to-speed and up-to-par for your customers.
Crafting an enjoyable user experience is one thing; creating a safe one is another. With controversies on user privacy rising to the fore across the software industry, the race to secure software is on. More and more users are realizing the value of security. Creating secure software no longer plays second fiddle to the actual product experience itself – and integrating information security is best done during the development process.
These are just the tip of the iceberg – there’s so much more to learn about the various facets of product development.
If you’re a product manager or developer wanting to learn more about the topic and how to create a product users will love, head on over to Tech in Asia Jakarta 2017’s Developer & Product Stage where speakers from Grab, Go-Jek, UrbanIndo, KODEFOX, Ematic Solutions, and Blackstorm will share their expertise and insights.
Also, don’t miss out on your final chance to save 10 percent off your tickets! The code is tiajkt10 and will only be valid for one more day until October 13, 11:59PM (GMT +7). Or if you’re not yet ready to commit, drop your details below to get our latest conference updates via email.