17 March 2015 Comments Off on Five Issues Faced By Large IT Organizations News, PMO, QA
It is common to read articles and posts which say that the issues that organizations face when developing software are bigger than ever before. However, in many ways we face many of the same issues now as those that were common in 1975 when Fred Brooks wrote his famous essay on issues facing software development companies, “The Mythical Man Month”.
The issues discussed in “The Mythical Man Month” have not so much changed as the options for fixing those issues have grown and morphed into better solutions. Every business is different and they all have their own sets of challenges. We can categorize issues that businesses face by the size of the organization. Large businesses have more employees, harder to handle communications, and more strenuous processes that must be followed. With that in mind let’s explore five issues, and their solutions, that large organizations face as they try to find success with IT.
Big Design Up Front
Large organizations have a number of challenges which often seem as though they can be solved by the concept of big design up front. Executives want to know when they will be able to see a return on their investment. Marketing and sales teams want clear deadlines so that they can begin to share information with customers about new features. Engineering management want to be able to plan what will be developed with project management groups. Operations teams need to be able to plan and purchase needed hardware to support these new products.
It is exactly these pressures which cause companies to attempt to design every facet of their software as early in the process as possible. Big design up front is the process of trying to architect and plan everything in a project before ever writing a line of code. Often big design up front will lead to long schedules filled with development tasks which take a product down the wrong path and do not leave room for an organization to learn from their customers as development proceeds. Big design up front may alleviate the initial pressures of development by creating schedules, but it will also often lead to product failure.
Obviously companies can not just ignore these initial project pressures. The solution to these pressures is to adopt a goal to deploy to real users early in the development process and often after an initial release. At Hewlett Packard, on a consumer facing project, we made a goal to release to a small set of customers in the first week, and weekly after that. By doing so, everyone in the organization could plan and prepare for constant customer interaction. Additionally, the company was able to receive customer feedback early and pivot quickly as it saw areas of innovation. This sort of goal, as opposed to big design up front, leads to quick and consistent success.
Not Quite Agile
Many organizations I work with call themselves agile. However when pressed to discuss what agile methods they follow companies will stammer out an explanation that we in the Agile community call “Scrum But”. “We are scrum but we don’t have stand ups,” “… but we don’t write user stories,” “… but we don’t demo to stakeholders”. This list can get quite long and before long the organization is not so agile at all.
Large organizations need to understand the agile mindset now more than ever before. Agile states that an organization should value:
● individuals and interactions over process and tools
● working software over comprehensive documentation
● customer collaboration over contract negotiation
● responding to change over following a plan
Large businesses know that agile is important but they fall into the pit of “Scrum But” when they forget the real tenets of agile. Companies need to remember that agile is not scrum. But the rules of scrum, as well as extreme programming, lean, kanban, and many other so called “Agile Methodologies,” if adhered to, will help an organization to follow the four truly agile principles.
Too Many Meetings Not Enough Action
Large organizations often complain of communications issues. With dozens of levels of employee and management between the software producers and the executive teams it is easy to see how communications can become problematic. Most people within organizations have an honest desire to communicate status, changes, and issues to both their supervisors and their subordinates. However this honest desire to communicate generally leads to a crippling number of meetings. These meetings often hamper the amount of work a team can complete.
Organizations in recent years have turned to agile practices in an attempt to alleviate these meeting needs while still keeping communication channels open. This is a good tactic as long as it is kept in check. All too often companies allow agile to become a reason for more meetings. Daily stand ups turn into multiple hour status sessions. Sprint planning can turn into multiple day marathons. When agile methods are not kept in check they are not agile at all.
When agile is used correctly it can reduce the meetings and increase communication. An organization must work to have an effective backlog and to make sure all of the stakeholders in an organization have access to the list. A prioritized backlog can tell stakeholders, even at the executive levels, more in a few minutes about development efforts than weeks worth of meetings. Additionally companies must be diligent in keeping their agile meetings agile. Stand ups must be kept to 15 minutes of less. Sprint planning should be under an hour. Other meetings should be kept to a minimum or eliminated. By keeping a prioritized backlog and keeping agile meetings agile, organizations will see engineers complete more software development and meet less.
A Lack of DevOps and Automation
Whenever I start a new engagement I always ask how the company deploys its software. Often the company will complain of the long and arduous process of moving their code from environment to environment. The process usually involves a myriad of manual steps and is quite error prone. The longer and more error prone the process is, the longer the organization will wait between releases. This is not good for the development process nor for an organizations bottom line.
This is why DevOps and automation is so important. DevOps is the intersection between development and operations teams. Before the DevOps movement engineers working on products would complete features and then “toss” the code over to operations for deployment. Operations would then try to replicate a development like environment on production hardware, deploy the code, and debug any production issues. This method of deployment is ineffective and expensive.
By implementing a DevOps strategy which includes the automation of both the server configuration as well as software deployment organizations can speed up the deployment of their software. Product engineers must help in the process of automating these steps. Companies can no longer tolerate an internal atmosphere where product engineers create software in a vacuum and then toss the results over the fence to operations. As product engineers plan their development activities they must add tasks to automate and test deployment strategies.
Rebuild Or Hand On Too Hard
Large organizations can on occasion fall prey to their own success. Unlike bootstrapped or venture backed start ups, large organizations often have the capital needed to invest in very large software projects. These projects do occasionally go awry. When that happens companies will either decide to rebuild or hang on and keep trudging forward with their software development. Depending on the circumstances these scenarios can be detrimental to the company and the development teams.
When a large software project starts to have huge problems is may seem like the best plan is to rebuild the project from scratch. This stems from the nearly universal good feelings that come at the beginning of a project. Tasks complete quickly and progress often is fast in the early project stages. But if there is a problem in an initial project it will be exacerbated in a rebuild project.
Similarly, companies in distress will sometimes try to hang on to a failing project. They do not want to lose the perceived value, and cash, they have already put into a project so they trudge forward hoping things will get better. Again when a project has issues this desire to trudge forward, throwing good money after bad, will exacerbate the issues.
The answer to these issues is not to rebuild from scratch or trudge forward blindly but to find the underlying issue in the project and eliminate it. Often the project is having issues because of ill defined requirements. At other times simple processes are being made overly complex. It is also not uncommon for a project to no longer be of value to the organization. It is better to understand the underlying needs and address them than to blindly rebuild or hang on.
Where Do We Go From Here?
Large organizations are obviously not immune to issues when it comes to IT. Unlike smaller businesses, large organizations have a huge number of employees, levels of management, high budgets and budget constraints, and rules and regulations to follow. When we look over these issues that have been presented, it can be seen that they creep in because of the unique environment that are within these large organizations. However, by following good principles such as true agile methodologies, keeping communications in check, automating, and making solid businesses decisions when issues arise, we can overcome problems within our large organization IT departments.
Tags:
