Think like a man of action, act like a man of thought.


Agile Adoption – What is it?

So you’ve gone Agile – How is that working for you?
With increased exposure, many organizations are trying to become more “Agile”.

But what does that mean exactly? How the term “Agile” is interpreted can lead to different processes even within one organization. In many cases, “going Agile” can mean as little as “we will do what we want to do” to “we have no discipline or process whatsoever”. These are extreme cases, however with most organizations legitimately trying to change the way they think about or do software development. For our purposes, let’s assume that “going agile” means we are trying to find a way to develop software that is BETTER than what we are doing now, as we try to address organizational pain points.

The more common pain points normally center around speed of delivery, quality of delivery or team maturity. Addressing these issues seems simple enough, most organizations I work with tend to be places where things have gotten to a pain point so great, that they need outside help to assess and determine where things went wrong and what they can do to try to change them. Most of these organizations have had some exposure to the Agile movement, usually through a blog, a book or a person that tried it in their environment. Usually, the initial attempt to “go agile” is a silver bullet approach, with some tools picked and others passed over for what seem to be “logical” reasons. But inevitably, it seems that a large percentage of these attempts (80-90%) end in something OTHER than addressing the main issue that was being felt and help to surface OTHER issues within the organization!

It seems like for this type of change, an organization really needs to consider a helpful third party that has achieved results in a full Agile implementation. Because, as simple as Agile is, the basis for most of the tools is counterintuitive. And knowing when to change things and when NOT to change them is really the most important skill to bring to the table. But I go too far, let’s start at the beginning and move from there.

A lot of the “failures” encountered with an initial, in-house Agile transformation have to do with expectations and assumptions. It is a fine thing to become educated in the Agile concepts, to try to understand how they piece together to get you the best results. It is quite another to put these pieces in place to get the desired results. Most people who are considering these types of changes are actually extremely smart individuals, and the concepts of most agile processes seem a bit simplistic at first. One of the tendencies that we encounter is that people oversimplify or underestimate the effects of such simple processes, and inadvertently take away tools that are critical before the process even begins. In other cases a lack of understanding in terms of impact and time tends to cloud the water and results in undesired effects. The two most commonly seen types of this failure are the “silver bullet” effect (this simple process will fix EVERYTHING!) and the team loss effect (we are a great team, everyone will LOVE to work with this process!). In both of these scenarios, finding the undesired effects can sour an organization or a team badly enough to result in a re-build exercise, again, without addressing the root cause of the issue.

For us, the most important thing to do is to partner with you and help you understand the breadth and depth of undertaking a truly transformation change to the way you run your business. The changes that are seen in an in depth Agile implementation transcend software development, and reverberate across the organization. Knowing what to expect, how you will be impacted, assessing the risk involved, putting an action plan in place and showing HOW to succeed after we are done are all important parts of what we want to help you with. We want to partner with you, so that education, maturity and success are left with you, and we can be able to help you as you mature with the Agile process.


Digital Transformation is a Must

The world is getting more competitive, and it’s driving fundamental changes in how businesses operate. The entire enterprise is looking to become more data driven to better prioritize investments, target operational improvements, and identify key prospects. To stay ahead of the competition, products and services need winning customer experiences, operating processes need to be more automated and efficient, sales teams require greater mobility, and the entire organization is demanding more innovation, smarter data, and more automation from their technology.

You cannot succeed without great technology, smart technologists, efficient business practices, and culture change. You can’t win with legacy systems or systems that have Band-Aid data integrations. You can’t expect the same year-over-year revenue serving customers the same way you’ve done over the last decade because customers expect superb experiences.

Some of you will take matters into their own hands by procuring technologies without an integrated plan, but the world isn’t cookie cutter anymore, and you can’t sell differentiating product offerings without some innovative capabilities, technology to integrate business processes, or defensible intellectual property.

In short, your corporation needs you, a leader willing to take on the challenges of driving business and digital transformation. They need great technology leadership with a solutions-oriented team, outstanding platforms, and bulletproof practices. They need technologists to be maturing technology platforms, agile practices, and nimble services but assembled with more strategic purpose.

Great technology and outstanding technologists are just the beginning. Businesses need practices to grow their abilities to drive decisions and create winning products by leveraging their data assets. They need to be plugging into an ecosystem of third-party capabilities including new data sources, services enabled by APIs, crowd sourcing backed workflows, and app stores that can drive distribution. They need to better understand how emerging technologies like blockchain, IoT, and artificial intelligence will reshape their industry over the next five years and have confidence that they can incorporate new capabilities.

Businesses also need practices to learn customer needs, track new forms of competitive offerings, and evolve online and offline customer experiences. They need to develop practices to perform research to help target new markets and rank prospects. Most importantly, they need to enable the product management function to drive revenue from digitally enabled products and services. Finally, businesses need a new form of collaboration and partnership among technologists, marketers, product managers, data scientists, and key sales executives to align on strategy, partner on execution, and drive a smarter, faster digital culture.


Software deployment best practices

Software deployment best practices Best practices are tried and true methods that have a history of being successful. Deployment success and value realization are achieved when best practices are adhered to consistently throughout the Software Deployment Method. Through working with the many customers and seeing what works and what fails, we created the following list of software deployment best practices:

  • Identify an Enterprise Business Sponsor (EBS) and stakeholders
  • Centralize software fulfillment
  • Implement a license management tool and processes
  • Hire deployment services
  • Determine your deployment readiness
  • Commit to self-sufficiency
  • Define a time-to-value and return on investment (ROI) strategy
  • Communicate and market the vision

Overview of Scrum and Software Agility

On the surface, Scrum is a very simple process: a software management technique that has a relatively small set of interrelated practices and rules, is not overly prescriptive, can be learned quickly and is able to produce productivity gains almost immediately.

Scrum naturally focuses an entire organization on building successful products. It delivers useful features at regular intervals as requirements, architecture, and design emerge, even when using unstable technologies. You can implement Scrum at the beginning of a project or in the middle of a project, and Scrum has saved many development efforts that were in trouble.
Scrum works because it optimizes the development environment, reduces organizational overhead, and closely synchronizes market requirements with early feature delivery. Based in modern process control theory, Scrum produces the best possible software given the available resources, acceptable quality levels, and required release dates.
At its core, Scrum is an iterative, incremental process for developing any product or managing any work that produces a potentially shippable set of functionality at the end of each iteration. Scrum’s attributes are: Scrum is a tool that can be used to achieve agility.

Scrum is an agile process to manage and control development work. Scrum is a wrapper for existing engineering practices. Scrum is a team-based approach to developing systems when requirements are changing rapidly. Scrum controls the chaos of conflicting interests and needs. Scrum improves communication and maximizes cooperation. Scrum detects and removes anything that gets in the way of developing and delivering products. Scrum is a way to maximize productivity.

Scrum scales from single projects to entire organizations, and has managed development for multiple interrelated products and projects with over a thousand team members. Scrum is a way for everyone to feel good about their job, their contributions, and know they have done the very best they possibly could.

While describing Scrum practices in detail is outside the scope of this, the method is characterized by the production of a Product Backlog where requested features are organized by their .
A Product Owner is responsible for approving changes to the product backlog. Implementation occurs in roughly 30-day iterations called Sprints, which focus on the top priorities in the Product Backlog. The goal of each Sprint is to deliver a potentially shippable product increment. During the Sprint, checkpoints are observed in a daily “Scrum” meeting, which communicates the progress and activities within the team and shares issues that may be “blocking” progress for an individual or the team. This allows the Scrum Master to determine progress against the Sprint commitments and advise on midcourse corrections to assure successful completion of the Sprint.


Stealth Mode Development

The most common approach to product development involves taking the most promising ideas (often based on intuition) and developing them into products in a “stealth mode.”
In a stealth mode, companies typically cut themselves off from mainstream civilization and choose to complete a product built primarily on their assessment of what the problem is and what the solution should be instead of getting any early feedback or validation from the customers.

Companies hypothesize that they understand enough about the problem their customers are facing to know the right solution to build. Hence, they don’t consider slowing down the process by introducing any feedback loops in between steps.

Being an early mover is clearly one of the goals, and fear of competition makes companies wary of sharing their idea prematurely, even for the purpose of obtaining potentially life-saving feedback.
During the infamous dotcom meltdown, dozens of companies folded because they chose to build products without fully deliberating upon what the right product ideas worth pursuing were. They chose to build out every single conceivable product feature without determining if there was a market for it or not.
The result was that while they built a fully scaled, fancy-looking product or service, they unfortunately didn’t have a large enough customer base to make the product launch as interesting and successful as the product development journey had been. During the time that briefly preceded the NASDAQ crash in March 2000 and some two years after that, over 800 Internet companies collapsed.

Most of these companies had unrealistic valuations without any regard to a proven and repeatable business model. Despite the recent history of obvious pitfalls of such an approach, we still find takers for this grand way of building products. This method requires a long runway (meaning, a long supply of funding and patience), but more importantly, the belief that we the makers know better than the consumers. In a way, this is like Henry Ford saying, “Had we gone to the people, they would have told us faster horses.”—a sentiment doesn’t quite apply in today’s world. Clearly, the current thinking is not about making products in isolation or with an arrogance that we know better than our customers.