There is a longstanding joke in the Agile community that the real purpose of a Software Development Manager is to stay out of everyone’s way.

With self-governing teams interacting with competent Product Owners, an Agile Team can competently produce value in short increments, consistently moving the business further down the road to where it wants to be next. This team collaboration requires focus, discipline, communication, skill, competency, teamwork, and emotional intelligence by everyone involved.

Although humorous, this legitimately does raise the question—While the teams are busy generating value, what is the REAL purpose of the Development Manager?

The software development value stream has often been described as an assembly line of decisions, building a massive mathematical product. The better that humans can harmonize and organize, the better the product’s final utility value and fit will be for the organization’s customers.

Good Software Development is NOT Intuitive

All of this complexity must be managed correctly along the software value steam, and surprisingly it’s not intuitive. What you think you should do next is sometimes NOT what you should do next.  In other words, on-the-job training will produce pretty good managers, but not excellent ones.

The Standish Group’s CHAOS Surveys tell us what a typical organization look like.  Only 31% of projects are delivered successfully. 50% are late. And 19% are complete loses. (Standish 2020). With an combined industry budget of around 250 $Billion, this is a lot of unnecessary waste, dealt out by a lot of mediocre development leaders.  How do we fix this?

Ten Critical Software Development Bottlenecks:

There are ten critical bottlenecks (read: wastes of money) in the software development process and they are not intuitive. I propose the real job of a Software Development Manager is to attend to these things:

1. Employee Turnover – While this happens in our industry, every time a programmer leaves it takes about 6 months of work for the next one to come up to speed firing on all cylinders. Even highly skilled developers need time to acclimate to the products, the code base, the tools used in that environment, the customers, the customers attitudes, and how they use the product. Figuring a typical developer salary corporate burden today is around $150,000/annually, every time a programmer leaves a company, it costs them about $75,000 and six months of one person’s schedule.  Great Development Managers minimize turnover, saving the company lots of money and unnecessarily lost time.
   
   A good Development Manager keeps the teams productive and content.  Being near them, praising them for work well-done, and keeping the environment healthy and productive are important factors for healthy teams.  The best environments report high-trust, good communication, happy employees, and a good sense of satisfaction. Some people call this Psychology Safety.  
   
   It’s important to develop a culture of accomplishment and teamwork.  Team branding with a team identity, vision, mission, goals, and values which are supported by a feeling of appreciation and accomplishment is the magic formula here.
   
   

2. The Hidden Factory: I like to say “If it takes your team eight weeks to get six weeks’ worth of production completed, your team has 2 weeks of hidden factory.” This term describes everything that has to happen over again because it wasn’t done correctly or completely the first time around.  Meeting with customers again for the same reasons, re-structuring screens or reports, changing workflows, re-pushing builds, hot-fixes, testing churn, and many smaller and larger things including multi-million-dollar entire solution rejections which we see occasionally in large companies. These become multi-million-dollar mistakes.
   
   It’s not easy to address a Hidden Factory problem. Most groups naively think they just need more time to get some things done and if management would relax a bit they could catch up and stop making these consistent mistakes and omissions.  The truth is, they will never address the problem until they start doing work differently.  What they need is a quality system such as CMMI, ISO, or The Stable Framework to solve their reactivity issues.  This is an unintuitive reality of software development.
   
   Most groups I talk to report about a 33% effort loss to the Hidden Factory over time.  Just do some simple math on the total payroll burden of your Software Department x 33% and that’s only PART of what you are losing unnecessarily.  Add to that the opportunity cost for revenue delays on your products until 33% past the optimum endpoint and the wasted costs magnify.
   
   It is the Software Development Managers job to bring in a quality system to solve this problem. Quality pioneer W. Edwards Deming was extremely unpopular for putting the blame for low-quality work on management—not employees. Although he was uncomfortable and non-intuitive, he was right.
   
   

3. Not Using AI to Vibe Code: There is a tremendous advantage available now to software development teams who use AI to generate units of code and debug challenging problems. Many groups are reporting about a 30% increase in productivity using these tools. CoPilot, Clive, Grok.com, Gemeni, Claude.ai, and even local LLM’s using Ollama or LM-Studio will provide immediate lift.  To keep up with who’s currently leading the AI wars check out ARCPrize.org.
   
   
4. Using Awkward Tools: The first time I met Ken Schwaber, co-inventor of Scrum, he told me the best Scrum tools were a white board, sticky-notes, and a spreadsheet.  I met him again nine years later on the other side of the planet and he told me the same thing.
   
   Of course, today, many of us work remotely making those tools awkward. There are many digital tools to chose from. I can tell you from personal conversational experience with many professionals the most popular tools used tool today are Jira (80%), and SmartSheet (20%), with many companies using both.  Probably 10% of the remaining companies use Asana, Shrike, Monday.com, or ADO (Azure DevOps).
   Some companies are even reverting back to a virtual whiteboard and virtual sticky-notes using a group collaboration space such as Miro.com, LucidSpark, or just the new whiteboards inside of Zoom.  This works, and is a fun solution.
   
   Whatever tools your groups choose, make sure it helps keep you organized for speed, and doesn’t slow down your work. Incorrect tools, or misconfigured tools will slow the team down.
   
   
5. Bad Approaches to Coding: The first part of Robert C. Martin’s book Clean Architecture explains how important correct coding architectural techniques are to minimizing the cost of maintaining a developed system once deployed. Not all coders are the same, and if you hire sloppy coders you will soon have a production product that requires an exponential number of additional programmers just to maintain it.  Data with compelling examples are in his book. Basically, spaghetti code kills productivity.
   
   This costs a company millions of dollars of unnecessary payroll over time. As an owner, or investor, and because this is non-intuitive, you won’t know what you don’t know until it’s too late—and you will be paying a large team, instead of paying yourself.
   
   

6. Continuing to invest in Monoliths: Software development has evolved. In the past we all invested in Microsoft, Oracle, and other monoliths because they were the mainstream providers of proven technology. “Nobody ever got fired for buying IBM.” or so the expression went.
   
   While this once was an expensive but safe position, today Microsoft IIS webservers only make up about 4% of the internet.  Open-source solutions like PostgreSQL, Python, JavaScript, are proven, and all you need to construct a complete enterprise, or SAAS solution.  Forgive me for stating the obvious, but the days of these big players are waning.  Don’t spend unnecessarily big money on new investments here. There is no need anymore.
   
   
7. Hiring Wrong: An accountant and a seasoned software development manager would have two very different approaches to hiring for tech talent. While accountants want reasonable value for the best price, Steve Jobs said he witnessed a 25:1 difference in productivity between good and bad developers.
   
   You want your development staff to match the workload. Staffing for new development should look like an upside-down birthday cake.  You want it top heavy with senior coders, and just a few junior coders on the bottom to do the busy-work. This configuration will yield much more productivity over time of much and more stable products.
   
   It takes developers years to understand and permanently distill the larger compliment of common logical structures available within most programming languages.  Senior developers look at a challenge and select and organize which “tools” to use to construct the solution.  This is much like making a product from Legos.  Once you have a few years working with them, you’ll command a solid knowledge of all the common shapes.  Developers with this level of competency can be given an objective and can quietly create a solution correctly, the first time.  In contrast, junior developers must search and forage for solutions to what are all-new challenges for them.  This is the process that takes the x25 times longer Steve Jobs was talking about.
   
   
8. Not pulling weeds: Nobody likes a bad apple. Sometimes, despite all initial attempts for reaching across the aisle, you end up with a team member that causes problems for others on the team. This can quickly become a problem that never goes away without intervention. If someone presents with unwanted behavior over time, a good development manager should take the team member aside and find if the problem is temporary. If so, work with the team member privately to help them regain a successful gait. If not, they are likely in the wrong role. Work with them to get them where they would rather by. A good manager wants their team members to be successful not just on the job, but also in life. Good managers understand their team members are also their customers.
   
   
9. Outsourcing Incorrectly: Outsourcing is rarely effective. It’s never really been a good idea. Sure, you can find senior level management who defend outsourcing, but talk to any team and they will tell you it’s awkward, comparatively slow, and frustrating.  Most companies outsource because other companies outsource.  The argument used to be it was cheaper labor, but those days are past. Now the argument is the resources are instantly available.  This is a pretty weak argument. In my experience most senior executives support outsourcing so they can confirm to their senior board of directors, who are even more removed from the real software development value stream, that they are in-fact outsourcing, too.
   
   Companies who outsource successfully do it a certain way.  They budget for one member of their team to go stay with the outsourcing group for the duration of the project, or at least, go back and forth frequently.  Sometimes the model is reversed and the outsourcing agency has a team member stateside.  That team member spends 9 hours working with the American team, and then the other 9 hours working with the offshore team—each day.  It is brutal, and frankly unfairr
   
   Studies have shown outsourcing adds 20-40% on to a projects effort in cost and schedule—and that’s if you have a useful product.  Many a local team overcompensates for the outsourced contribution. However popular, it is difficult to outsource efficiently.
   
   
10. Not Investing in Training: Niccolo Machiavelli stated “…training--not budgets--wins wars!” That’s an important principle to digest.  More recently, Deming taught his customers, when evaluating vendors, to ask them how much money they had spent on training their people during the past 12 months.  This will give you some insight into the level of performance you’ll get out of them.
    
    

    Deming would draw the effect of training as a tight squiggly line representing effort, which abruptly straightens into a longer mildly jagged line at the point of training.  In this manner he demonstrated how training narrows the amplitude of ineffective effort, transforming the trainees’ efforts into work that move the company down the road towards their objectives faster.
    
    Training helps both new employees and seasoned employees get better at their jobs.  While new employees benefit from structured guidance on how to perform their tasks, seasoned employees benefit from having real-world experience they can conceptualize into immediate practical application.
    
                 
    
    Training also gives trainees a correct vocabulary use throughout the industry, and gives them confidence their efforts and skills are industry-standard.

In summary, statistics show software development is not performed efficently, and these ten factors are keys to leading your teams to perform much better than the Standish CHAOS Report data--or industry average of on 31% of project's being delivered on-time.

PMI (the Project Management Institute) has recently introduced new content into it's curriculum....the Process Owner and Process Manager.  The distinction between these two roles seems to originate from ServiceNow's influence.

In small organizations the same person wears both hats, but in larger organizations these two roles may be split between two people.  Basically the Process Owner is a senior person responsible for "working on" the process, to improve it, while the Process Manager "works in" the process to execute it with efficiency.  A description of each role follows:

Job Description for Process Owner:

Process Owner's are responsible for the end-to-end oversight of a particular business process within an organization. Their main responsibilities include designing, implementing, monitoring, and continuously improving the process to ensure it meets the organization's goals and objectives. Process owners also ensure that the process is compliant with regulatory requirements and industry standards. They work closely with cross-functional teams to identify areas for improvement and implement changes that increase efficiency, reduce costs, and enhance quality. Other key responsibilities of a process owner include:

• Developing and maintaining process documentation, including standard operating procedures (SOPs), process flowcharts, and process metrics.
• Monitoring process performance using key performance indicators (KPIs) and other metrics, and identifying areas for improvement. (Note, both roles include this bullet point as it is an ongoing common point of review and discussion.)
• Leading process improvement initiatives, including process re-engineering and process automation.
• Collaborating with other process owners to ensure that processes are integrated and aligned across the organization.
• Communicating process changes to stakeholders, including senior management, process users, and customers.
• Providing training and support to process users to ensure that they understand and follow the process.

Job Description for Process Manager:

Process managers are responsible for the day-to-day management of a particular business process within an organization. They ensure that the process is executed efficiently and effectively, and that process users comply with the process requirements. Process managers work closely with process owners and cross-functional teams to identify areas for improvement and implement changes that increase efficiency, reduce costs, and enhance quality. Other key responsibilities of a process manager include:

• Ensuring that the process is executed in compliance with regulatory requirements and industry standards.
• Monitoring process performance using KPIs and other metrics, and identifying areas for improvement. (Note, both roles include this bullet point as it is an ongoing common point of review and discussion.)
• Providing training and support to process users to ensure that they understand and follow the process.
• Identifying and addressing process issues and bottlenecks that impact process performance.
• Collaborating with other process managers and process owners to ensure that processes are integrated and aligned across the organization.
• Communicating process changes to stakeholders, including senior management, process users, and customers.
• Developing and maintaining process documentation, including SOPs, process flowcharts, and process metrics.

Overall, while both roles are involved in managing and improving business processes, the process owner has a more strategic and high-level focus, while the process manager has a more operational and hands-on focus. The process owner is responsible for setting the direction of the process, while the process manager is responsible for executing the process according to the owner's direction. The process owner is more involved in initiating and leading process improvement initiatives, while the process manager is more involved in implementing and monitoring process changes on a day-to-day basis.

The Hidden Factory is everything your group does over again because it didn't go right the first time around.

This ranges from re-doing a failed multi-year project, to re-pushing a production release which had some minor issues the first time around. Sometimes these activities are called "Fire Fighting."

Most groups I talk to tell me that about 35% of their teams efforts are lost to this problem.

Someone must pay for this, and it's very expensive.  Higher prices, lower wages, and lower shareholder dividends are one way to quantify the hidden factory.  In addition, the opportunity cost of not being able to reach your project monetization goals 33% faster means you left money and customers on the table.

The Stable Framework™ is a performance management framework for IT designed to give IT departments the tools needed to tame this wild Hidden Factory beast and bring the fire-fighting down to nearly zero, where it should be.

Read more about it here

Mike Berry

The software development life-cycle (SDLC) is the process of planning, designing, building, testing, and deploying software. There are various models for the SDLC, each with their own advantages and disadvantages. Here are some of the most common models:

1. Waterfall model: The waterfall model is a linear, sequential approach to software development, where each stage is completed before the next one begins. The stages include requirements gathering, design, implementation, testing, and maintenance. This model works well for projects with well-defined and stable requirements, but can be inflexible and slow to respond to changing requirements.

2. Agile model: The agile model is an iterative and incremental approach to software development, where software is developed in short cycles called sprints. The stages include planning, requirements gathering, design, implementation, testing, and deployment, and the process is repeated in each sprint. This model works well for projects with evolving requirements and a need for flexibility, but can be challenging for teams that are new to agile methodologies.

3. Spiral model: The spiral model is a risk-driven approach to software development, where risks are identified and addressed in each stage of the SDLC. The stages include planning, risk analysis, design, implementation, testing, and deployment, and the process is repeated in a spiral fashion as risks are identified and addressed. This model works well for projects with high levels of complexity and uncertainty, but can be time-consuming and expensive.

4. V model: The V model is a variant of the waterfall model that emphasizes testing and verification throughout the SDLC. The stages include requirements gathering, design, implementation, testing, and maintenance, and the testing process runs in parallel with the development process. This model works well for projects with a strong emphasis on testing and verification, but can be inflexible and slow to respond to changing requirements.

5. DevOps model: The DevOps model is a collaborative approach to software development that emphasizes the integration of development and operations teams. The stages include planning, development, testing, deployment, and monitoring, and the process is highly automated to enable rapid and frequent releases. This model works well for projects with a need for rapid release cycles and a high degree of automation, but can be challenging for teams that are new to DevOps methodologies.

Each of these models has its own strengths and weaknesses, and the choice of model will depend on the specific requirements of the project, the experience and preferences of the team, and the organizational culture. Successful software development requires careful planning, effective communication, and a willingness to adapt to changing requirements and circumstances.

Need a good software requirements specification (SRS) template?  Use an industry-standard SRS.  Can't find one?  Well now you have-get it here for free.  Enjoy!

Mike J. Berry www.RedRockResearch.com

Want to visit ground-zero for data security?  Experts from SANS, MITRE, SAFECode, EMC, Juniper, Microsoft, Nokia, SAP, Symantec, and the U.S. Department of Homeland Security's National Cyber Security Division last week presented a listing of The Top 25 Most Dangerous (Information Security) Programming Errors.  Expect to see future government and big-money RFP's mandate these items be addressed.

Mike J. Berry www.RedRockResearch.com

Have you been challenged with performing a high-risk task like upgrading a prominent server, for example?

Here's an execution plan template that you can use to guide you.

I. Executive Summary
Brief overview of intended event.

II. Review of Discovery
Details of what efforts were made to research what is listed in the following sections.  Meetings, Vendor consultations,  Online Resources, and Conventional Wisdom can be included.

III. Pre-Upgrade Procedures
Steps identified to be taken before the event.

IV. Upgrade Procedures
Steps identified to be taken during the event.

V. Post-Upgrade Procedures
Steps identified to be taken after the event.

VI. Test Plan
Verification procedures to confirm the event was a success.  This section should define the success criteria.

VII. Rollback Plan
In case the worst happens, what to do.

IIX. Situational Awareness Plan
After-the-event steps to validate the success of the event with the system's business users.  This would include a two-way communication between your group and the business users, announcing the success, and providing contact information for them to contact you in case there is still a problem.

IX. Risk-Management plan
A plan listing risks associated with the steps above and recommendations as to how to lower those risks.

X. Schedule
If the event spans many hours or days, you may want to draft a schedule for the benefit of all involved.  Include on the schedule the 'rollback point,' which would be the latest time a rollback could be successfully performed.  Your success criteria whould have to be met by this point to avoid a rollback.

Be sure the Execution Plan is in a checklist format, not a bullet-list format.  Require participants in the event to 'check' completed checklist items and sign-off sections they are responsible for.

For critical areas of high-risk, (ie: setting up replication), for example, you may want to require two individuals to perform the checklist steps and sign their names when that section is complete.

If you like, add a 'lessons learned' section to be completed later, and ke copy of the execution plan for historical purposes.

Mike J. Berry
www.RedRockResearch.com

In a conversation with a friend once, they jokingly described their inability to play racquetball against other seasoned players as "They are playing racquetball, while I am just hitting a ball around the room."

I'll borrow that reference and apply it to Software Production Support.

Is your Software Production Support group "playing racquetball," or are they "just hitting a ball around the room?"

From a distance they can appear like the same activities.  On closer inspection however, one is much more organized, elegant, patterned, and proactive--while the other is only reactive.

Finding the order from all the choas separates the effective from the ineffective.

There are three particular areas your Software Production Support team should be focus on.  These three areas are:

1. Maintaining Systems
2. Managing Customer Expectations
3. Become a Quick-Reaction Force

1. Maintaining Systems:

Think of your production servers like a fleet of cars.  In a fleet plan, the company sends every car to get an oil change after x number of miles, a tire rotation after y number of miles, and a general tune-up, fluid change, etc. after z number of miles.  This pattern repeats itself for the life of the car that is serviced by the fleet manager.

How often are your server hard drives defragmented?  How often are the transaction-logs backed up?  How often are the indexes reindexed, and the statistics updated?

How often are memory settings adjusted for performance? Latest patches applied? How often are your servers checked to see if there any impending disk space issues?

To maximize system performance, create a "fleet plan" for your servers which checks all of these items at regular intervals.

2. Managing Customer Expectations:

If a server fails, do you know which systems depend on it? If a database goes corrupt, do you know which applications need it, and which corresponding business units will be impacted when that happens?

Do you have a way to communicate to those groups immediately?

Create a dependency map for your products.  A dependency map illustrates which servers host which databases, and then which databases are used by which applications, and finally the names, numbers, and email groups of the business users that are affected by that server/database failure.  This will enable your team to proactively manage your customers expectations.  You can notify them before they have to notify you.

3. Become a Quick-Reaction Force:

The SWAT team, the FireStation, and the Ambulance services all have something in common: they are ready to take action at a moment's notice.

They have the information they need available to them, and additional services available with a simple call.

Do your products have support information organized and readily available?  Do you have the names and numbers of your account representative for each third-party product or tool you support?  Do you have the product-support phone numbers and your support plan credentials readily available?

Do you know who knows what about each application in your enterprise?  Who programmed it originally?  Who has supported it lately?  Which business units use it?  Where is the source code located?

Keeping information about each system updated in a central location should also be part of your "fleet plan."

Another effective tool for a Quick-Response group is a monitoring system.  Something that indicates the overall attitude of each of your production servers?  Disk Space available? Will the system reply to a ping?  Is SQL Agent running? Is that required Windows Service up and running?  Monitoring tools like Nagios can do this for you.

Another great idea is to keep a lessons-learned log for each component you support.  Track problems, fixes to problems, assumptions to be confirmed, and ways to test if the component is functioning properly.

All of these pieces in place will make your production support much more effective.

So, think about it...is your Software Production Support team playing racquetball, or are they just hitting a ball d a room?

Mike J. Berry
www.RedRockResearch.com