Tag Archives: Best Practices

Reboots and Turnarounds: Changing your software development?

What is a turn-around? Having a conversation with a colleague yesterday around a “turn-around” project we are doing for a client. Going a new direction can be considered a negative thing, but it shouldn’t be assumed so. New directions for a business are commonplace. Sometimes technical debt overwhelms business value. Sometimes the customer base needs shift radically. Whatever the case, a significant change is needed. Sometimes it helps have a new leader or team to change the game. This is where people like me come into place.

Helping Navigate Change

So if a turn around is needed, change is required. We need to talk people, process, and tools. I always prioritize them in that order. People are the hardest to find. It can take years to develop the expertise in house. People change easier than process and tools. You never want to change the people, rarely does it make business sense. The process is usually the biggest problem. The waterfall to agile process change was painful, but thankfully mostly in the past. Most organizations understand the value of process, but make too many exceptions. Exceptions impact the process’s business value. Reviewing the process with the team and re-enforcing/incentivizing adherence is the best approach. The tools are the easiest part. If there is a tool in place that is performing well, leave it be. If there is a gap, analyze the need and offering and fill it. Having the team evaluate and select is important. Buy-in is required whether it be people, process, or tools. Having the team work in concert is always good hygiene.

Creating a Positive Foundation

So now the basics are done, let’s talk about the business. What and who are the customer base? What is our moat? Who are our competitors? How do we reach our customers? Do you have a customer advisor board? These are are vital inputs to a what I call a “north star”. If you are wanting to go a different direction, never run away from something – run toward something. The north star allows you to have direction in your turnaround.

After evaluating the team, processes, tools, customers, and market its time to make decisions. Creating a plan is always tricky. You want to set appropriate and achievable short, medium, and long-term goals. I like to start with the long-term goals first. Perhaps its a new product release? What is that timeframe and business metrics required? With the tentpole agreed upon, you can leverage best practices to define medium and long-term goals. The metrics make the goal. You cannot have goal unless you have metrics to can check to ensure you have achieved it. This is the most common mistake made in software development. Creating nebulous goals alienates business leadership in software development. So with the plans in place and agreed upon metrics, you can spin up your tools to track those metrics. Once you have the dashboards in place with people following the process, you can start sprinting.

Process That Re-enforces Change

Sprinting is the agile process of development. How do you eat an elephant? One bite at a time. That is how software development lifecycle (SDLC) works. You have a planning session to define what are the immediate and stretch goals for the next 2 weeks. You load up the work with the developers and they start eating that elephant. As the team works, they track their individual outcomes in software tools. Those tools allow management to understand how quickly that elephant should get eaten. At the end of the sprint, you do a retrospective on the results. Those results get added as input to the planning session for the next sprint. This cycle repeats until the product is end of life. Software development is about retrospectives and planning sessions. Here is where the business can help or direct the team to ensure value is created on time and under budget.

Outside of the SDLC, you need to manage the team members. You may need to add or reduce staff on the project team. Their individual contributions tracked in the process and tool helps you understand who are you experts and who needs help. Training and cross-training are vital activities to help teammates grow and excel in their roles. Understanding the needs of the people are as important as the needs of the outcome. You will not have a good outcome without good people. Setting and tracking individual achievable goals is important to the long-term success of any software development team.

Ensure You Are Creating Quality Outcomes

Quality assurance is where releases become a reality. As I have stated before, set a bar of quality and maintain it. Releases are your market credibility, treat it as such. Be transparent with your testing. Everyone in the company needs to know you clean up your own mess. If you are not transparent, your support and sales team will assume you are not doing anything. Regular company briefings of your triumphs and tragedies shows accountability and build trust. Trust is the currency of good stewards.

Most “turnarounds” are a positive thing. The business wants to make a shift and a reboot is necessary. Create your new north star and follow it. Leverage best practices. Make sound, informed decisions using data. Be transparent to your customer, the business. Starting new is opportunity. Let me know how your reboot journey is going.

Managing the Software Chaos: Achieving Quality Product Development Outcomes

Have you heard this before? The product development started great and we made our first milestone. BUT, ever since then things have gone off the rails.

Or how about this one? Our technical debt is unsurmountable, our only option is to depreciate. We are seeing horrible retention rates. How did things go so wrong?

Customer experience (CX) is about delight. Making the consumer of the application happy to use it and be in awe of its value to them. Novelty will only get you so far. Reality will hit your user community. Bugs will disappoint. Depreciation of keys features will enrage them. Upgrade paths that are no different then rip & replace will lose you customers. CX is about delivery of quality software. The better the software, the better the experience.

We all know what great software is. We all understanding the benchmarks. The problem is achieving those benchmarks. How do you avoid the primrose path of product development? By understanding, embracing, and enforcing sound engineering best practices.

What is Your Dream?

Let’s start at the beginning: ideation. This is where you define your vision. Who is the consumer? What is their journey? What is the market: from a price, value, and definitive profit opportunity. We live in reality, what are your acceptable trade-offs? How are you going to sell this product? What are the marketing materials required? What is the go-to-market strategy like market segment and demographics? What timelines do we have?

This will allow software creation within the constraints of the business. This means budgets, roles, responsibilities, and investment requirements. Hopefully you have heard “no bucks, no Buck Rodgers” — its as apt now as 50 years ago. This vision will allow your team to make good decisions. The vision is what creates and enables business alignment. When aligned, we can begin creating value.

Realization is Better than Building

Developing a software product is sometimes called sprinting. I see it an appropriate term. To generate business value, you will want to set a short-term goal, work on it, and measure if you made that goal. What is the release strategy? What timelines do you have, that defines the goal setting. Remember the marathon is the release. Segmented sprinting will get you there with the least amount of technical debt possible.

What is technical debt? Product Manager’s boogeyman. That is wasted productivity. When you ask to build something that provides no business value, it is a waste. If you have to re-write something in the future, it’s waste. Eliminating or minimizing technical debt is a key feature of quality software development. That is why agile development principles exists. It aligns development to the business regularly minimizing waste.

As part of agile you have planning sessions to talk about your goals and set them up. You have retrospectives to learn, grow, and adapt to challenges. You have tools that track tasks, resources, and hours. These are vital best practices that make quality software. But even bad software team have defined processes and great tools. The real difference is in the culture or in the people. Using the process to grow talent. Being accountable so you make goals. This is only possible with sound leadership and quality resources. Doing the work is about harness a team’s excellence. Maintaining that begins with quality assurance.

Software is a Business, Run it Like One

Great software is not defined by delight. Great software is a measured outcome like any other business unit should be; with SLAs and KPIs. Your vision should include your tolerances. Enterprise-grade, Commerical-grade, and Carrier-grade: there are many standards out there. What is your standard? What contract do you have with your consumer (written or otherwise)? Once you have your standards, we need to understand the different layers of missing them. What is a P1 vs P2? These thresholds will set the bar of quality of your software. They will allow you to compare individual output to team outcomes. Understanding your standards and your consumer base will enable you to create a test strategy. This is your bar. This how to define quality software.

Many organizations get held up on test automation. Automation is about helping resource management and being more efficient. This is an excellent goal for mature development. But if you first cannot test manually, then you are not ready for automation. Automation distracts many organizations from the purpose of testing – reporting. You need to know if you are making your standards so you can release. That is the most important party. Releasing software is the goal. Businesses expect releases. Testing reports, will tell the team they are ready to release. But they also provide more value. Testing results will also let you if you are resourcing correctly or “achieving velocity”. Do you have enough developers? Do your developers need more training? Who are your leaders? Do you need automation? Great software is made in the QA phase. Applying standards and data, allows software to be released on time, under budget, and with minimal defects.

Best Practices are About Managing People

Excellence in development all about applying best practices. Starting in product visioning. Applying agile development processes. Releasing with quality assurance. The trick to managing the software chaos is following best practices. This is not about the latest development tool. This is not the latest development language. This is not the latest process framework.

Software development best practices are about the people. Its about leadership having the proper data to make good decisions. Engineers focusing on excellence in delivery. You get this working, then ideas become experiences. And experiences change the world. Reach out to me if you ever need to change world, I have a team ready to help.

Operations Digital Transformation Playbook

Digital Transformation is the buzz word of the day.  Whether TMF is saying it or Lightreading is reporting it, CIOs are doing it.    Here is an example roadmap for transforming operations for the business’s digital transformation.    This 4-step process leverages much of what the industry has already said. I have interweaved some color and advice .   I hope you find it useful and comment below.

Acceptance for Digital Transformation

Step 1: Acceptance

First, your organization needs to buy into the fact that something has to change.     Buy-in for digital transformation is the key to success.  While 100% agreement is not possible, getting an overwhelming majority will reduce timelines.   Forming a committee with regular cadence calls can assist on collection of use cases. As a sound board, they can be the voice of the organization. They will also provide you cover during the transformation process.
Here is some advice to help people get in the boat. Some will doubt the need for change. To those doubters, I would pose the following questions:
  • What % of the time does operations spend on firefighting?
  • What does your customers say about the quality of the services you provide?
  • How many compromises does your team make to “get the job done”?
  • Does 25% YOY staff turnover frighten you?

These questions are the canaries in the coal mine for impacting digital transformation.    If you cannot focus on improvement, growth, and resiliency – the organization is in danger   When the business is changing to a more agile footprint, operations gets left behind — or even worse, becomes the roadblock.


Selection for Digital Transformation

Step 2: Selection

Change scares people and organizations and digital transformation can get scary.   When it comes to selection, it must be a sober, deliberate decision.   RFIs are a common method for initiating change.    The trouble is the net you cast.    If you only send the RFI to your pre-existing vendors, you will get lots of the same.
I recommend that you start with a google search on “Operations transformation”, then “IT transformation”    The results should net you some NEPs/DEPs (EMC, Huawei) and Global SI players (Accenture, Deloitte).   If you are a fortune 500, they will be very kind to you and expect big money.    If you have a relationship with these guys, I recommend calling upon them and seeing the “big pitch”.    Its great for context and helps to understand the commitment involved in transformation.
The next step would be to call some analysts.   I have had great experiences with Analysys Mason, Appledore Research, and Gartner.    They can tell you what other customers have done.    Attend some webinars and trade events can help get you connected to the trend setters.    This will help you round out the group you want to invite into the RFI process.
With the RFI executed, you will want to review the material and cut down to 5 or less parties.    Make sure you have a global SI, a NEP/DEP, and some trend setters in the bunch.    Ask for presentations and documentation of best practices.   Get as much information as possible, creating quality requirements is key.
Within the transformation workgroup, create a top 10/25 list from each member of key issues.   Apply your use cases and develop a list of requirements (<100 items). Add to it a ratings system to keep it fair, to the point.   If you value verification of technical compliance (ie. support for Cisco IOS Y/N, etc), add another sheet.   Another tip; you can always demand entries to combine their offerings. This firms up and consolidates your options.   Use this list with your procurement team to create the RFP. Give at least 2 weeks to respond, and no more than 4 weeks.    Stick to your schedule and grade the entries responses.
Work within the workgroup to kill and combine entries until you get to at least 2 — the fewer the better. Based upon grading, provide a list to the down-selected parties of how they can improve their response. Giving parties the opportunity to focus and improve, will allow for better options. Schedule meetings with no more than 7 day’s notice for their presentation and response.    After all meetings are complete, revise the grading and make a selection with procurement.    Notify all parties and negotiate a contract.   I recommend all contracts as part of transformation be longer term, you will want a partner for at least 3 years.    I also recommend agreement of SLAs and penalties of failed/delayed delivery.


Execution for Digital Transformation

Step 3: Execution

After making the selection, now the hard work starts – addressing digital transformation.    Implementation should be a core concern during the selection process.   Some transformation projects are short-term (less than 6 months), longer term leverages milestones.    Phasing allows transformation projects to achieve quick wins and setup long-term success.   When building the business case, phasing allows prioritization of key objectives.   I always recommend to show significant value within a quarter, and every quarter after.   Regular improvement needs to be visible, or you will need significant executive sponsorship.    Phasing will help drive the value and keep on task.
Selection of a project mantra defines how that project will run.   Agile is very popular in IT projects.   A DevOps approach allows your transformation project to become evergreen.   For long-term projects where you need extreme flexibility, there is no better technique.    For short-term, fixed scope projects waterfall is more than satisfactory.
When executing the vision, setting phased milestones provides the director. Quarterly scheduled demonstrations keeps the faith. With consistent, planned deliveries will confirm healthy project management.   When it comes to execution focus, communication and delivery success should be the first priority.    Its always best to remember, if you have an unhealthy project — you will have poor deliverables.


RIO Renewal for Digital Transformation

Step 4: ROI & Renewal

Once the project has achieved it main objectives the question becomes “Now What?”.    In every sense of the word, there is an “end-state” with regards to transformation.   Once you get there, you will experience the fact that the goal posts moved on you.   This is another reason Agile methodologies are popular.

Meet with your workgroup and steering committee, does it make sense to continue.   One key issue my customers have seen, is that transformation can lead to change for only change’s sake.   There must be clear needs to continue.   You can always reduce team cadence and let the needs of the business denote the tempo.
In summation, executing a digital transformation is a heavy commitment.   The facts are that the change required is necessary to address industry climate.    Nobody wants to buy a T1 anymore and that is a good thing!    The good news is that meeting the needs of business is possible and profitable. Good luck transforming!

Key lessons learned for Digital Transformation:

  • Collaboration = Commitment = Success – if you communicate effectively
  • Select the best process and tools for your team.     Do not fall into the conformity for its sake.
  • Set achievable regularly delivered goals.   Show consistently increasing value to the business.
  • Focus on the present, but regularly plan for the future – and always communicate


Shawn Ennis

About the Author

Serial entrepreneur and operations subject matter expert who likes to help customers and partners achieve solutions that solve critical problems.   Experience in traditional telecom, ITIL enterprise, global manage service providers, and datacenter hosting providers.   Expertise in optical DWDM, MPLS networks, MEF Ethernet, COTS applications, custom applications, SDDC virtualized, and SDN/NFV virtualized infrastructure.  Based out of Dallas, Texas US area and currently working for one of his founded companies – Monolith Software.

Best Practices Guide for Application Monitoring

Don’t Fear the App

Digital service providers are being driven by customers into the world of applications. Gone are the days that simple internet access is all you have to provide. The more complex the service, the more value it is to the customer. As SMB customers are embracing managed services, service providers are managing applications. While traditional network services are well defined, most applications are disparate and obtuse. Many of the customers I talk to see a real challenge in application monitoring.
Applications requires the same, if not more, care and feeding that any other tech.  Defining services is easier, but components are vast and complex.  Application discovery is still a new concept and is not yet 100%.  Knowing the availability, performance, and capacity of an application is vital information. Having the heuristics, audit, and log information to troubleshoot allows for quicker resolutions.  Performing end-to-end distributed active testing allows for basic verification. Passive activity scanning can ensure you know problems as soon as end-customers do.  Mission critical apps need comprehensive monitoring and management. To the tune of the same cost and value of that application deployed.
Applications can be very difficult to manage due to their inherent uniqueness. These custom digital services come in all forms and fashions. From printing queue services to real-time stock trading platforms. This series of blog articles to provide insight on how to plan for monitoring custom applications. Interested providers will be able to leverage these concepts for their own environment.

Discover the Application

First part of any new application monitoring is to determine what consists of the application.   Application discovery has two common flaws. First is over-discovery, or creating so much detail association is complex and useless. Or the problem is under-discovery, in which you are missing key associations and thus useless.   Discovery is like all other technology, it requires human guidance and oversight — do not blindly depend upon it.

Website Monitoring

For our working example, I will use a custom application using a traditional 3-tier architecture stack. We first start with the presentation layer. Its best to start by listing out what can go wrong. Network access might be down. Server failure is a possibility. The web server process (httpd) might no longer be running. Are the network storage directories mounted? Once you have your list, create your dashboard. Once you have your dashboard, link the necessary data to it (syslogs, traps, ping alarms). With a finished dashboard, you can automate it with policy. Create an alert that indicates an application error exists and points to the cause. If your assurance tool cannot perform these features, find one that does the job.

Database Monitoring

Now repeat the same for data layer. Which database do you have? MySQL provides rich monitoring plugins. What are the standard database KPIs? Google provides plenty of opportunity to leverage 3rd party lessons learned. What else is important with a database? Backup and redundancy are key. Are those working? Repeat the dashboard driven monitoring techniques from above. The result is 2/3rds of your custom application monitored.

The hard part…

The most difficult layer to deal with is the application layer. Here there are no rules. The best case is talking to the developers. Get them to explain and define the known KPIs and failure points. Worse case, you can break down the logs, processes, and ports in use to check for basic things. Do not discount basic monitoring such as this, the more your know the easier to troubleshoot. Run the dashboards you have as reports, get them into the inbox of the application team daily. This will assure the feedback you need to refine your monitoring policies.

Last advice…

– Be bold – Don’t be afraid of monitoring
– Communicate – Let the team see the results, if the data is wrong fix it
– If nobody cares about the data, you don’t have to keep it and don’t alert on it
– Alerts and notifications are only useful if they are rare and desired
My last point would be if you are a SMB, your managed service provider should be able to perform custom application monitoring. If the can’t, have them call me…