Is Your Product Secure Enough? (Part 2 of 2)

For the past 30 years it has become a widely expected, common practice for the Enterprise Software vendors to commit to always shipping zero-defect software. Where any issues were to be found, vendors committed upfront to correct them within predetermined timeline depending on the issue severity. For example, customers would expect all Critical issues to be resolved within 30 days, and all High severity issues  to be resolved within 60 or 90 days.

These days however, it's becoming increasingly evident that this fixed timeline approach, while well intentioned, is impractical and in some ways delusional.

Software vendors can no longer commit in good faith to a fixed number of days it will take to address discovered/reported issues because

• The number of product security/quality issues we will face in the future is unknown. At any point in time, a new issue may be reported to or discovered by vendors internally (e.g. using code scanning tools).
• The amount of time to resolve or mitigate any security/quality issue is also unknown in advance.

Software businesses should classify all known security and quality issues into two groups, based on how they impact their operations. 

• Group 1: This category mandates we drop all our planned activities and throw at it as many of our resources as we have to address the issues as fast as possible (and yes, however improbable it may sound, we may run out of resources, much like some hospitals ran out of beds at the peak of COVID). You may designate these as all Sev 1 (and potentially Sev 2) quality and CVSS 9.0 and higher security issues. I want to stress this category of work trumps everything else. This applies to issues reported to us as well as to issues we discover ourselves.

• Group 2: This category of issues is managed in a planned manner using managed resource allocation (reviewed/adjusted periodically, e.g. quarterly) and disciplined prioritization. This may include Sev 3/4 quality and CVSS 8.9 and below security issues. For this to work, we must diligently rank all the issues on the list from 1 to N. At any given point, a developer or team assigned to work on this should grab from the list what’s at the top, not what has been sitting the longest on the list. Prioritizing High, Medium, or Low will not work as it leaves discretion to developers to pick from the pool of many issues using their discretion. If we don’t rank, we will not necessarily be addressing the most critical issues at the time. For security issues, we need to have the CVSS score calculated before making the change to the product to reliably justify the complete cost of making the change (not just editing the code). That cost for vendor and customers includes testing by us, packaging and distribution, communication internally and to customers, training our support, customers downloading and deploying a modified version of our product, and then in some cases testing their implementations before ultimately pushing them to their users.

The approach described here will scale better in the face of growing velocity of incoming security challenges and increased uncertainty in a complex world of enterprise software.

What is your experience with this?

Is Your Product Secure Enough? (Part 1 of 2)

There are different types of security vulnerabilities in every product, and I stress, every product.

• Those that no one discovered yet

• Those that have been discovered quietly, the world does not know about and
1. no one has exploited yet, or 
2. someone is quietly exploiting them as we speak 

• Those that the vendor knows about and has not yet made the patch available (for any number of reasons)

• Those for which the patch exists, but the users have not applied it (for any number of reasons)

My point is there is no such thing as defect/bug/vulnerability free software.

It’s a vendor's responsibility to find the best possible balance between the cost of the solution and the value it provides to the customers, minus the risk of harm it can cause.

A lot has been written about Zero-Defect Software, and while the intent is certainly nobel, organizations that solely focus on this, are missing the point. 

• This blog about Zero-Defect Software concept written through the eyes of QA lead (Nyall Lynch), applies equally well to dealing with security defects, commonly referred to as vulnerabilities.

The key question Product Managers need to answer: "What level of risk, given the nature of our product and its application, is acceptable" for us as a vendor. In other words: "Is our build secure enough to ship?" 

As well, responsible vendor will ensure the product releases already in customer hands remain secure enough for continued use until these releases reach the end of communicated maintenance window.

In Part 2 I will share some practices that can help large scale enterprise software vendors to continue delivering value in the face of growing uncertainty about product security risks.

Third-Party Products - Who Owns Them?

A lot goes into production of complex products, and not just cars. Complex software products commonly incorporate and interact with hundreds of other, third-party software and non-software products.

So what does this mean for Product Managers?

Usually, there is no need for Product Managers to get involved with the third-party products used to build their products. Except for special circumstances, this is left to Architects (technology strategy), Engineering (quality and security), and Legal (the IP rights).

PM does however need to direct and provide recommendations and guidance on the third-party products that interact with and enable the operation of their products.

Allow me to use the automobile industry to illustrate this concept.

Let’s look at the role of the third-party components through the eyes of car manufacturers and car users.

When Toyota is producing its cars, it inevitably embeds the output of other companies in its products. For example, the door panels are formed from metal coming from companies specializing in smelting ore into sheet metal. Toyota evaluates what’s available on the market and elects to use the product it believes is best for its cars. In this example, sheet metal is a third-party product that once chosen by the product vendor is permanently embedded into the product and can’t be swapped out. Let’s call this a Class C third-party product.

Next, the Jeep designers equip their cars with Bosch spark plugs. While these spark plugs can be replaced by the product user (e.g. once they are worn out) the car cannot operate without them. Let’s call this a Class B third-party product.

Finally, the car manufacturer recommends certain conditions, care and the use of some third-party products for its car's optimal performance, safety, and longevity. For example, it may recommend the use of high-octane gasoline/petrol, oil change interval or certain load limits. All these criteria are outside of the car manufacturer’s direct control (they are the responsibility of the user), and yet they are expected to impact the product. Let’s call the third-party product in this category a Class A.

Now, to draw a parallel with Software Products, 

• Class A is the expected environment, such as hardware configuration, network connectivity, Operating System, web browsers, Java, and .NET that are expected to be provided and maintained by the product user.
• Class B is the stuff that may be included with the product. The end-user has control over it. The vendor should explain the recommended steps to maintain this stuff in optimal and safe working order, compatible with continued eligibility for the overall product support and maintenance services.
• Class C is the stuff that gets embedded or compiled into the product. The end-user has no control over it.

Product Management owns support and compatibility strategy, and communication about Class A and Class B third-party products as explained above.

Please let me know your thoughts or experience with this.

Team Calls during COVID-19

These days especially, with most of us working remotely, I often find myself on calls with a large number of participants who don't actively participate in the discussion. Their cameras are turned off and their microphones are muted.

Am I alone in this observation?

I am not referring to presentations or town hall type of meetings where information is shared with large groups. These are team calls where active collaboration and decision making are meant to take place.

In the past, when we could meet in person, I could see every participant's body language. I could see when people who did not say a word during the meeting were actually actively listening, leaning forward, or showed signs of disengagement, slumped in their chairs, crossed their hands, checked their phones or computers... I have no such feedback with everyone joining remotely these days. Furthermore, I have a sense our calls on average include more people these days, and I wonder if there is data to confirm or deny this hypothesis.

So, why do I care?

For once, these calls cost companies a lot of money. Usually they include attendees who are smart and well paid, and their time is valuable for the company.

Equally important, but less obvious, I think this practice is obscuring another important set of issues.

While attending these large calls creates a sense of collaboration, signals cultural conformance and seems to foster improved information exchange, in reality most attendees are simply multi-tasking. On the outside this looks like our productivity goes up. We attend more calls, while answering more emails and developing more documents, presentations, reports, quotes, code, etc. In practice, we get overworked, stressed and the quality of our work suffers.

I want to go back in time and only attend calls where everyone pays 100% attention and decisions are made. Everything else I would rather read subject to my time availability, and if I don't have capacity to process more information, I will not pretend I can handle this by attending the call with muted mic and webcam off.

What do you think?

Engaging your online audience

I was wondering recently why no one responded to one of our Architect's community posts seeking for customers' feedback on our product improvement idea, and so I took a closer look: The title is catchy and stands out in the list of posts, so that’s good. 

As is often the case with technical writing, I found the writing style to be the main detractor. Below I am sharing some pointers that would help.

1. The post is overly verbose. Half (or more) of the content could be chopped without hurting the post objective. By shortening this post more busy people would take a plunge and read it.

2. Formatting techniques can be employed to improve the readability.

• Paragraphs would help. Without them everything looks like one big blob of black on white characters. It’s hard to "park" the look on any particular part of the post. Nothing jumps out.

• Questions could be grouped into concise bullet lists.

• Headers can be used to break down the post into 2-3 sections, e.g. Background; Challenge; Our  Questions.

• Bold or underline font could be used to highlight key concepts (just don’t overdo this so it does not look like a glittery Christmas tree).

3. A picture could help to spice up a post and attract attention.

All of the above pointers are also applicable to writing emails and blogging.

Listening to Customers

What’s important in interactions with customers is how we interpret what we hear. As Product Managers//Owners (PO/PM) our challenge is to listen actively and always seek for the underlying pain points.

Customers may be telling us how they want to change our product, but we always need to dig deeper to understand why. Never be afraid to follow one “Why?” with another, with another, and yet with another. Sometimes it takes several attempts to get to the bottom of why the customer really wants us to change the product. If we understand the real need, the real pain point, then we can present the challenge to our engineers and architects in a way that leaves room for them to address the root of the issue in a most creative and effective manner, potentially much better than what the customer had in mind.

Other times, the customer may not even mention the pain point, not realizing they have it. Here again a PO/PM using effective interviewing skills can pick up on potential opportunity to create value for the customer, to alleviate a pain point, to offer them something they would be willing to pay for.

Last, but not least, PO/PMs are managing products, not tailored solutions. We therefore need to look for common needs, ways to improve our products for all (or many) customers not just one. This requires ability co connect the dots, draw parallels, and recognize patterns when interviewing customers. Often times customers describe their needs, issues, challenges using different words and propose different solutions. No one is in a better position than a PO/PM to help translate this stream of data into actionable product roadmap and backlog.

Stretch Objectives

What do I think about them?

ox·y·mo·ron

Dictionary result for oxymoron

/ˌäksəˈmôrˌän/

noun

a figure of speech in which apparently contradictory terms appear in conjunction (e.g. faith unfaithful kept him falsely true ).

Way too often Stretch Objectives are understood and used by teams in a way that make them a classic case of oxymoron. And no wonder. After all “Stretch” implies uncertainty and hope. “Objectives” on the other hand imply exactly the opposite - certainty and commitment.

Teams may find it more self-fulfilling to present longer lists of objectives at the end of Program Increment (PI) planning by including along with PI Objectives also Stretch Objectives.

The reality however is that the product organization can only count on committed PI Objectives, not on hopeful Stretch Objectives. Stretch Objectives are merely work items that the organization wanted teams to take on but in the end admitted/realized they cannot be committed to in a given timeframe, due to some constraints.

Furthermore, the understanding of relative importance (priority/ranking) to deliver on Stretch Objectives is a snapshot in time, valid only at the time of PI Planning. As teams move through the Program Increment and receive new inputs, the product needs and priorities may change, potentially invalidating or changing priority of the original Stretch Objectives. For this very reason as a good practice teams should re-confirm with Product Management later during PI before work on any Stretch Objective starts.

Here is how SAFE defines Stretch Objectives:

Stretch objectives help improve the predictability of delivering business value since they are not included in the team’s commitment or counted against teams in the program predictable measure.

Unfortunately, way to often teams forget the difference and keep Stretch Objectives on the list just like PI Objectives. Over time I found it best to simply move out all PI Planning candidates back to the parking lot for consideration in future Program Increments.

What's your experience with Stretch Objectives?

Agile Transformation (Part 1) - Understanding Your Investors

In this miniseries I want to share my observations about the organizational challenges with Agile Transformation. The information I use originates from my personal experience as well as from anecdotes and stories I collect from my friends and colleagues working in the software industry.

Any Agile Transformation is soner or later bound by the organizational capacity to accept change, and this includes executive leadership. At the end of the day, no matter how far the product development team is capable of going in becoming lean and Agile, they need full support and understanding of their investors, including customers and executives.

To illustrate, I want to use the unrelated at first glance story about the Japanese/American cultural differences. I drafted and never published this post more than a year ago, finding it interesting from the cultural perspective point of view. As I re-read it now I was somewhat surprised at how natural the story read if I were to replace the "American Vendor" below with a software development organisation striving to adopt Agile and similarly the "Japanese Customer" with their corresponding corporate level executives.

Situation: An American Vendor working on addressing a Japanese Customer’s request. Part of the disconnect is due to some cultural peculiarities that need to be understood by the Vendor.

First, the Customer fully expects to be able to provide input into the Plan. Not only the bottom-line value to the Customer has to be clearly articulated, the Vendor needs to sell the Customer on each item in the Plan so they understand how it maps to their concerns.  

Second, from the Customer’s perspective, the target completion dates should be thoroughly vetted and accounted for all possible delays. While an American might think this is unrealistic or overly conservative, from a Japanese perspective this is normal. From that perspective, it can be seen why multiple revisions to the Plan dates become problematic – the Vendor loses credibility with regards to its forecasting ability. This also helps understand why the Japanese Customer sometimes finds it hard to believe Vendor's explanation of the reason for a delay. The Customer believes the Vendor should have predicted the outcome and mitigated the risk before the Plan was committed (unless the Vendor is hiding the real reason for the delay). Again, from an American perspective this is unfathomable, but it helps to see things from the Japanese Customer’s perspective. 

Third, Japanese companies need frequent updates and hand-holding. Even if no progress is made, they need to be updated by the Vendor, with explanations why what is being done matters to them. The level of updates that Japanese companies see as normal may be considered an overkill to an American. Depending on the situation it is advisable to provide a weekly or even daily status update that simply states what has been accomplished and what is planned for the coming period. This can go a long way towards maintaining good relations. 

Fourth, the phrase “TBD” is not acceptable to the Customer. Culturally, Japanese are not nearly as comfortable with uncertainty as Americans. We see TBD as a necessary component of planning, but the Customer sees it as a lack of focus, investigation, and drive. For this reason, it is best to use TBD sparingly, and only if accompanied with an explanation of why it is undetermined, and when/how it will be determined. 

Bottom line, when helping Japanese Customers we need to make sure it is crystal clear what problem we’re trying to solve and exactly why that particular action item has value to them. Also, if there is some uncertainty, or if something will take more than a week to complete, or if there were multiple revisions to the target date, we need to thoroughly explain why.

What's my point? To be successful every Agile Team needs to understand the psychology of their investors, or their executive management.

Do you respect the backlog?

We always strive to be more effective in how we build software for our customers, and today I was compelled to reach out with the following to my scrum teams:

The backlog ranking order is in place for a reason. Traditional waterfall software development projects have for years struggled to meet planned quality, schedule and content targets. The Agile software development recognizes the unique nature of uncertainty associated with software development, and gives us an approach to improve the governance and predictability for shipping quality software while building the content that target customers want. We do this by 

• QA: building quality targets into our definition of done criteria and acceptance criteria. This way any work that fails to meet DOD or acceptance criteria is not accepted and is not shipped. 

• Schedule: fixing the timeline. Sprint duration is fixed. Anything that is not accepted is not part of a sprint delivery and is not included in the shippable product (we can choose when we ship the release, but only after one of the sprints). 

• Content: we use backlog ranking to control what gets built as part of the release. When we run out of time, ranking ensures that we had enough time to build what we wanted to include in the shippable product and that we didn’t instead use that time to do something less desirable.

Generally speaking you should not begin work on any defect or a user story if you are also the owner of another open defect or an unfinished user story that is/are ranked higher. If you want to work on this because you disagree with the backlog ranking order, this is material and it is important that other people working on the release know; so just bring it up in our daily standup meeting, or reach out to me or your scrum master (in person, Flowdock, Skype, email, call, SMS). We can quickly discuss this and come to a shared agreement which can then be communicated and logged (e.g. in the Rally Discussion tab of the affected work item).

This also applies to any new work items popping up in our backlogs in the middle of sprints, i.e. items that we have not explicitly planned for during Sprint Planning sessions. If you open a new defect during the sprint or move a story or a defect from future sprints, please communicate/log this (e.g. by adding the explanation in the corresponding work item’s Discussion tab in Rally). Again, in general, the work on these work items should only begin when all the items planned for the current sprint are either completed or the work on them is blocked. If the unplanned item is critical for the sprint progress, we should discuss and if deemed necessary rank it higher on the backlog and (again) communicate/log our decision.

Although we are dealing with high uncertainty associated with complex software development, our business needs us to be more predictable in our ability to ship the working product. This is really important for our company's ability to operate as a well-run successful enterprise. Improving the following will help us get better 

• Transparency and communication

• The discipline and consistency in how we allocate our time during the sprints 

What makes top performing teams click

I came across this great New York Times article called "What Google Learned From Its Quest to Build the Perfect Team", and since the topic is near and dear to me I am taking time to share my short interpretation of this knowledge.

This research points out that best performing teams typically excel in what psychology researchers refer to "conversational turn-taking" and "average social sensitivity" behavioral norms - both relating to psychological safety defined by the Harvard Business School professor Amy Edmondson as 

"a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,.. It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves."

Reducing the number of supported platform variations

Does your product support multiple platform variations (operating systems, databases, etc.)? Have you noticed how it slows your development cycle and adds to the cost of maintenance and new development? If you've contemplated how to get out of this situation, you are not alone. This is a common challenge for many established software vendors.

Consider this hypothetical example:

Two companies compete, both have the same budget. Company A only ships on Linux and only on MySQL database. Company B ships on Linux, Solaris and Windows, and supports Oracle, MySQL and PostgreSQL databases. Question, which company can offer more features, better quality and/or more frequent releases?

Of course one can argue that for Company A part of the market is simply shut off because of the strong platform preferences many customers exhibit, but is it truly always so? What if Company A offers far superior overall solution, could it in some cases swing the balance of platform preferences in its favor? Surprisingly, in many cases, yes!

New products these days are almost always pick one of the following go to market strategies to make it easier to accomplish what Company A is trying to do:

1. Appliance, where the customer gets a box, and simply does not know what OS or DB are inside;
2. SaaS, where the customer uses browser and mobile apps, and again does not know what’s in the data center behind flickering server lights.

In both cases, this helps software vendor to focus on capabilities, quality and time to market (instead of retesting the same feature set on yet another platform variation), helping better optimize available funding.

Granted, it’s a lot harder to shrink to fewer platforms vs. not letting them expand in the first place, just like losing weight. Trying to do this for an existing mature product is guaranteed to upset some of your customers, yet it is still possible to make this decision and announce that going forward you are dropping one of the operating systems and one of the databases for argument sake. In the long run this will help you better serve your customers. If you calculate this well, on a balance you will actually gain more customers, even if you initially lose some.

It's okay to be introvert

I grew up in Eastern Europe, and after immigrating to Australia and living there for 10 years I relocated with my employer to the USA. Ever since that move I started noticing one particular set of cultural differences. I felt like to be successful at work I need to fit in better, to find a way to behave in a way that is unnatural for me - to be more of an extrovert than I really am.

I found it necessary to speak louder and more frequently than I would normally do.

I observed how uneasy people feel about a pause in a conversation. Someone would often start talking without any particular substance just to fill the "awkward silence".

Somehow in this culture high performers are expected to be assertive and outgoing. The enthusiasm is expected not just at work but also during informal social events. Class Participation and Team Projects are important part of the grading process at business schools, while networking skills and etiquette at business dinners and cocktail receptions are often deemed important enough to be explicitly taught.

Over the years I watched how more and more organizations opted for open space office configuration for their employees. As much as I am a big fan of Agile and Scrum Team collaboration dynamics, I just don't find that à la "Wall Street trading floor" workplace setup conducive to any type of work requiring concentration and attention to detail.

Earlier this week I read the Forbes article titled "Research Shows There May Be A Hidden Dark Side To Working With Introverts". It mentioned Susan Cain's book "Quiet" and so I looked her up online. Susan's spirited presentation on this topic is amazing in terms of addressing this very close topic to me. 

To share or not?

Should the product teams submit their internal ideas for voting by their user communities or not?

This reminds me of the internal dilemma some A/A+ students face: to share or not, i.e. to always do their work in solitary mode or to join a study group. Personally, I've always believed I can only get better by sharing what I know. Sharing allows improving my knowledge and skills either through teaching what I know, responding to broader range of clarifying questions, or through a realization that my perceived understanding is not quite accurate.

Hence, I fully support the concept of posting internal ideas for voting and commenting by the user community.

If a potential product idea is misunderstood by the audience or not really seen as valuable it will receive few votes and will be buried by other more critical in the eyes of the user community enhancement requests. It's far better to find out early that what we think is valuable is actually not.

In addition to straight voting score, this approach also gives us the opportunity to hear back from the user community members in the form of comments, including clarifying questions, fine tuning points and additional use cases and scenarios.

As an added bonus, sharing internal ideas with our user community promotes a true two-way collaboration and trust between the product team and the customers and field.

Running our calls on time

In his article Class bells Lynn Grant reminds us of the old good times when our classes in school ended with a bell, making sure we stop and move on to our next class in a timely fashion. Would not the bells be nice in many cases in our modern life when we are scheduled to attend multiple back to back meetings and calls throughout the day? Thanks for the fond memories and releavant association Lynn!

In the absence of bells a few more tricks/ideas may help run your calls/meetings in a more efficient manner:

• We tend to always block off the entire hour, even if a 15 minutes discussion should be sufficient. Go ahead, pick a suitable next meeting and schedule a shorter time slot for it.

• Yes, we are often more accustomed to start our meetings/calls 5 minutes past the official start time, allowing participants to switch from their previous call or walk from another meeting room. If you are the organizer, try allowing your meetings to end 5 minutes before the scheduled time.

• Time boxing a particular agenda item often helps.

• When using a WebEx, a GoToMeeting or other similar online meeting technology, making sure the online roster is correctly used/initialized by everyone dialing in helps save time at the start of the call going over the participants on the call, keeps people more engaged in the conversation because at any given time everyone can see who is talking and who is listening, and reduces time waste due to inevitable noise on the line (barking dogs, crying babies, music on hold) from an anonymous caller line.

• The rule of SEVEN, i.e. if you want your meeting to be a productive one where a decision can be made quickly, don't exceed 7 participants. Recent research by Bain & Company, published in the book "Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization" indicates that once you’ve got 7 people in a decision-making group, adding an additional member reduces decision effectiveness by 10%.  As a result, large groups rarely make any important decisions, at least not in a time efficient manner.

• Don't join every meeting or call, understand why your presence is needed and decline the invitation if you don't anticipate contributing to discussion.

• Excuse yourself from the meeting if you find yourself immersed in something else, reading or answering emails for example. Your departure will reduce participants count and may help run the meeting on time, and it will certainly help you focus better on what seemed to be your primary task.

• If nothing seems to help run your meetings on time, 2-3 minutes before the end time, announce you are leaving and hang up when the meeting time is over. The more people will do this the more we will run our meetings on time.

Do you Ba?

Have you ever attended a backlog grooming session where participants appear detached, yawning around the table, the scrum master is sizing the stories and handing out the tasks, and hardly any questions are raised about the new user stories? How does this compare to the loud, agitated white board discussion, team members eagerly leaning in, volunteering their help, clarifying the objectives and acceptance criteria of the user stories presented? What's the word to describe the different feeling in these two rooms?

For a while now I've been looking for a way to describe this special spirit emanating from a high performing Agile scrum team and, thanks to Dean Leffingwell tip, I think I've finally found it.

Meet the "Ba"

In their research of organizational knowledge creation Ikujiro Nonaka and Ryoko Toyama define "Ba" as a shared context in motion, in which the context is constantly moving and the knowledge is shared, created and utilized. Through interactions with others and the environment, both the contexts of Ba and the participants grow. To participate in Ba means to get involved and transcend one’s own limited perspective.

In his blog (On “Ba” at a Scrum of Scrums) Dean Leffingwell builds on the original teachings and shows how Ba is essential to Agile software product development, as the energy that drives self-organizing teams. 

• Dynamic interaction of individuals and organization creates synthesis in the form of a self-organizing team.
• The fuel of Ba is its self-organizing nature - a shared context in which individuals can interact.
• Team members create new points of view and resolve contradictions through dialogue.
• New knowledge as a stream of meaning emerges.
• This emergent knowledge codifies into working software.
• Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively.
• Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment.
• Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development.
• Time pressures will drive extreme use of simultaneous engineering.
• Equal access to information at all levels is critical.

Now that we are more aware of it, what are the different options available to employees at all levels in their organization to help build and nurture Ba?

Concealing your weaknesses alone will not make you a winner

My young daughter is quite competitive by nature and when we first started playing chess she immediately focused all her attention on not losing, whether that was about individual pieces or the whole game. She quickly improved at that aspect of the game, but she was still miles away from actually winning her first game...

I am a big believer in open Ideation with my current and prospective customers so that

1. I can build a vibrant Ideation community, with more eyes, views and opinions shared (in the end I will still translate what I see and prioritize my release backlogs, but the value of any Ideation system is only truly unlocked when it is open and embracing vs.when it is tightly controlled)
2. I incur zero admin overhead for membership management (I am busy, and I don't want to stand in the way of my end users who are willing to donate their time to help me build a better solution for them)

I support responsible Ideation - anyone making changes to Ideas (voting, commenting, submitting new ideas) should be authenticated. This allows moderation of online community behavior and generally understanding the participants better, e.g. if we want to interview someone to clarify or better understand where they are coming from.

We are often naïve worrying too much about our "evil" competitors. Truth is they are too busy fighting their own demons.. and if we lose to them it's not because we are open and transparent but because they move faster and develop better solutions for our customers.

We should be worrying more about our ability to execute better and about improving our company's brand appeal. This will make more for growing our business than trying to conceal our deficiencies. Open user communities, Ideation and even the user documentation shared publicly can help turn around sometimes dated and unfavorable perceptions about the vendor. Trust is a critical foundation for turning around stale brand perception (i.e. what our customers think of us), and being more transparent and embracing with our customers, partners and our own employees will go a long way in this endeavor.

The fallacy of "low hanging fruits"

Why does it take so much time to make small improvements in our software products?

I am noticing how the pace of product improvement slows down as the product becomes larger and more complex over time. What seem to anyone as a small change, perhaps a matter of modifying a few lines of codes, for some inexplicable reason drags on and on and often not gets done at all. I set out to understand why this is happening, particularly when Agile culture seems to be so firmly embraced by the product team.

I found several contributing factors, and perhaps there are more.

First, the complexity and sheer size of the software product plays a role. Put simply, making the same change in the product that is 10,000 lines of code is not the same as touching the product that is comprised of over 1 Million lines of code. While a lot depends on what exactly is touched, in general the number of dependencies is higher in larger products, and hence the likelihood of unforeseen impact is also higher.

Second, the number of people who may touch the same area of code plays a role. The more developers involved in the same or adjacent parts of the source code that need to be modified, the harder it is to avoid misunderstanding about the intentions of individual software developers. This in turn makes it harder to foresee the impact of even a seemingly straightforward change. Those of us who have ever coded can surely recall encountering some questionable coding styles, cryptic naming conventions, commented out blocks of code and lack of comments explaining the intent.

Third, and somewhat related to the previous factor, is the age of the code. Over time layers of code changes are made by different people. Each change is tackling a particular need, often a special case favoring unrelated requirements or a subset of customers. Again, a developer supposedly making a minor improvement may not necessarily know everything about the code he is touching.

Fourth factor is the number and variety of customers using the product. With just one customer, usage of the software product is specific and generally more predictable. On the other hand, with more customers the number of different scenarios, integrations and workflows raises, increasing in turn the cost of adequately designing and testing even the minor change and considering the full impact on all customers. After all what might improve the product for one set of customers may break something for other customers.

Perhaps after all not all of those "low hanging fruits" are hanging low enough or maybe they are not even fruits at all.

Cloud security - who is in control?

I was looking for some numbers in support of my belief that we should focus more on enabling organizations to benefit from cloud applications, rather than sticking with the “on premise security” mantra of control and prevention. Any applications or services consumed from the cloud just can't be as tightly controlled by the enterprise IT as anything operated within their own environment.

I found these articles:

IT's Losing Battle Against Cloud Adoption

I share the view expressed by the author in the conclusion of this article:

"If anything, it seems like IT needs to shift away from its role as gatekeeper to instead being an enabler, one that finds different ways to deliver security. For example, Apigee enables enterprises to secure sensitive data rather than the devices or apps running beyond IT's control. These and similar measures may be ways for IT to remain relevant in a cloud-dominated enterprise, one that doesn't need or seek IT's permission to spin up another EC2 instance or start a Dropbox shared storage space.

One thing is clear: IT has no control over the cloud, and likely never will be. Time to get over it and figure out ways to live by its rules."

Most CIOs grossly underestimate how many cloud apps their employees use

Measuring scrum teams' velocity acceleration

No matter how exactly the scrum teams decide to measure their velocity, how the people are incentivized or motivated to drive productivity improvements, at the end of the day what really matters is the elimination of waste due to unproductive activities and increased output of value for our customers.

I found this blog post by Jeff Sutherland (Six Signs your Team’s Acceleration is Too Good to to be True) offering a great insight into the challenges with measuring velocity improvements of Agile scrum teams.

Why should we aim for shorter sprint duration

I was asked the other day why do I prefer shorter sprint duration, say 2 weeks instead of one month. I’d like to have shorter sprints for a number of reasons:

• Assuming we are motivated to demonstrate something tangible at the end of every sprint, with shorter sprints we end up looking for ways to produce something tangible sooner. The resulting sense of urgency in itself is good, although this is not about making our engineers work harder, that’s not the point at all.


• Shorter sprints encourage teams to master ways to break down large chunks of work into smaller independent user stories and as a result to better manage technical risks, helping increasing the odds of delivering more value at the end of each iteration.


• Shorter sprints motivate us to scope and size just enough level of detail and just enough user stories ahead (Just in Time) to help us deliver value and move at brisk pace. We gradually find ways to reduce and eliminate waste from our processes. For example, we learn that a user story that is thoroughly researched too far in advance often ends up collecting dust on our backlog as we may switch our priorities before we ever start working on it.


• With shorter iterations there is less time to procrastinate. Every day the team goes through daily stand up and it does not take long before we all know who makes good progress and who needs help.


• Shorter sprints help better manage risk across multiple scrum teams within a release. The longest a product team will go without knowing something is wrong is two weeks instead of one month or longer.


• With shorter sprints we become more nimble, more Agile as a vendor and competitor. In only two weeks we can pivot, change our priorities based on newly acquired knowledge, instead of sticking to the plan for one month or more.