Your Proxy for Productive Process

The perils of process.

Architecting a program, project and team is much like architecting a building. If it isn't well planned, or if the architect or architects aren't well trained in the relevant nuances, there can be extensive damage to the infrastructure that may well lead to the end of program, team, and in some unfortunate cases, the entire company.

From my observation, I have seen many teams cannot possibly be certain that their implementations are delivering on the value context as set forth by the business and customers. It is my belief that Software Design and Development process should be so bulletproof that by the time the test cases and/or scenarios have passed, a team should be able to rest in the certainty that their instanced Verification has utterly proven the delivery of the value that is supposed to have been implemented.

It seems an obvious truth that even the greatest engineers, managers, directors and executives in existence can’t reach anywhere near their peak productivity (or morale) while wearing shackles of incomplete and malformed process. Malformed development process is almost invariably accompanied by a great uncertainty within the program’s ranks, with engineers and leadership personal alike spending a great deal of time and money spinning their wheels, without being able to properly direct their efforts in ways that would result in the sort of continuous improvement that every program should strive for.

Is there hope?

However, when I have been able to prescriptively analyze projects and teams, create clear role expectations, set into motion process machinery necessary to organically nudge leadership and engineering toward meaningful dialog, help implement automation framework architecture capable of both enforcing proper correlation to business value context, and deliver high quality automated reports that increase project transparency, I have been able to greatly impact the productivity of all members that are part of my program, such as management, feature/functional developers and QA/QE/SDETs. 

Some Questions and Pitfalls?

If your automation is not providing value to most people involved in your project, ‘what has gone wrong’?

If your Quality Engineers and/or SDETs are spending, as much, or even more time maintaining automation as they are building new automation, again, ask ‘what has gone wrong’?

If anyone involved in your project finds him or herself blocked, and does not know what to do for an extended period of time, once more, ‘what is going wrong’?

If managers are micromanaging in order to ensure that the any work at all is accomplished, somebody should really be asking, at least for the sake of morale, ‘what can we do about this’?

What can I do for you?

If anything you have read sounds familiar, then I have great feelings of empathy for you. I’ve observed the improper ways to motivate, some very improperly implemented development process, and I have also seen people religiously follow very poorly drafted guidelines that have little or no part in the overall plan. 

Truly, it does no good to merely mimic behaviors that were seen to have worked for other teams. Teams, and companies, must understand the underlying reasoning behind the processes, if there is any hope that they are to be implemented in a way that empowers a team to meet their goals successfully.

A software development and design process should also not be a few half understood paradigms that someone picked out of a book. It must be a set of well understood ideas that are then built into the everyday activities of everyone involved. It is without a doubt a full lifestyle change for the team.

It is much the same with the roles that people take on, and the tools that people use. It is not enough to begin using tools that sound better or look good. The tools must work within the context of the relevant design processes, test philosophies, and need to be able to track efforts from end to end. Team members must make use of the tools properly.

As an example, any team member in any role, in which it is expected, should relieve another contributor from blocked status. That can be accomplished by properly making use of the functionality that is already present in many project management tools. The blocked employee should only need to raise an issue with a requisite amount of information and then go about his or her day. On the other side, the team member responsible for the block should attach the issue to a task to be completed.

These sorts of changes may sound simple individually, however, coordinating them all on a significant scale, in tandem, and also in such a way as they happen organically within teams that are not used to such processes can prove to be somewhat of a challenge.

Why would I be able to help?

I have a great deal of experience in solving this particular style of friction. It is my part of my general technique to introduce enhancements in relevant quantized portions, allowing time for project leadership and contributors to keep up, while at the same time, allowing enough of a change in the just the right areas so as to maximize improve and minimize impact.

What is my track record?
https://www.linkedin.com/in/phillipplatt

I have had some impressive successes at Gogo Business Aviation (I implemented several new development processes with automation architectures to match, including work as part of a cross team, cross component integration team). The impacts that I had at Gogo BA have long out lived my particular tour at the company.

I had a great deal of fast success at RSA, an EMC security company. Within two short months, I had completely revamped the company’s way of thinking when it came to development process, and I was quickly flown out to the RSA headquarters near Boston MA in order to bring the rest of the core development teams in line with vastly improved methods for tracking value delivery, tracking, testing and maintenance. Keep in mind, this is before I was even fully on boarded. I became a major part of the leadership’s strategy across the company, and they made sure to include me in all of their discussions when it came to any changes or improvements to process/CI/automation.

In addition to the companies previously mentioned, I also have had a large impact on the software development and design processes as understood at Hewlett Packard Enterprise. I have architected, coded and created guidelines for a new automation framework with an unprecedented set of never before seen capabilities. Of the things I can talk about, it is capable of full version/component awareness, automatic code deprecation, no need for explicit class importation (as the framework will choose classes as required for what is being tested), as a result, test cases/scenarios need never be modified between versions unless there is an enhancement story that alters functionality, compatibility with CI for any project capable of working with Jenkins. Variable error handling based on whether the error is an automation error or an error with a component, functionality or behavior. It has full business value context based, test case/scenario driven automated reporting, results parsing for many popular test result aggregate tools. Reports are structured in such a way as to directly match the input test case/scenarios, and are meant to be digested by any stakeholder. Modular structure for simple code deprecation and maintenance with easy cross version regression capabilities. The entire framework itself is portable and can be moved to wherever an environment is that testing is desired, and it is fully extensible. In addition new API are easily added for the exposure of new capabilities, for hardware and software.

If the wheels on your team bus could use some greasing, get a hold of me.

I have worked with a fair number of talented teams, having been requested directly quite often when a project needs direct intervention. I found that I simply have a great knack for bringing painless efficiency, built to order process enhancement, greater tool utilization, morale improvements, automation innovations and greater velocity consistency to teams that I have worked with.

I haven't had a dissatisfied manager, teammate or client yet, and I guarantee that if you put me on the job for prescriptive analysis, I will tell you exactly what will need to be done, and if we go ahead with the manageable steps I set forth for your you and your company, you will have a program that will start flying, and a team that is far happier.

Thank you,
Phillip Platt
LinkedIn - Check my Recomendations