Don’t Be Afraid … Change!

Over the last several years, my teams have made significant changes to our project management, development, testing and implementation processes and paradigms. We’ve had some bumps along the way and in no way do I consider this evolution over. I will continue to challenge my team members to find a better way to build the mouse trap that drives our software development lifecycle.

Let’s look at some of the successes the teams have had introducing change into the organization:

1. Our project management process used to be split into separate and distinct teams: 1) project management for business and operational teams; 2) project management for technology teams. This has been consolidated into one project management team managing all project related activity across the organization. This has streamlined activity and improved communication across all teams involved in the process.
2. Our lifecycle was revamped as we consolidated the project management organization. During the revamp – we created RACI documentation that clearly outlined 1 owner for each key task/milestone within the overall project activity, along with those that would act in the roles of responsible, consultative and informed parties. This has provided clarity to who owns each activity and what the key tasks are that are included within every project.
3. Recently we made additional changes to the lifecycle – completely eliminating 1 phase and adjusting the tasks and milestones associated with both our scoping and design phases. This has allowed us to streamline the process and give clarity to when project activity actually starts within the organization.
4. We have challenged all of our team members to review the overall standard tasks/milestones within any given project, and challenge the project manager and sponsor to eliminate tasks and standard artifacts when it is justified and where there is minimal risk associated with utilizing an altered process.  This decision then is documented as part of the project and communicated to the team to ensure that down the road, people can review the effort and understand why certain documents or tasks might not have been done. This should allow us to be more nimble and find the best path for each project to take thru the organization.
5. A couple of years ago, it took up to 3 weeks to complete regression testing associated with key functionality within our application silos. This was a manual effort that typically was handled by multiple individuals. The teams have worked hard to automate the regression tests associated with these applications. Today, the execution of these tests can be done in less than 17 hrs. The labor savings moving forward will more than pay for this effort. This also allows us to provide quicker feedback to the development teams and ensures that our regression testing is more consistent across all projects.
6. Recently, the teams also completed the resurrection of standardized test data to be used across our test and development environments. This will be further enhanced as our automated tests are enhanced to create/modify/cleanse and reset data needed for a given test. This will reduce the time spent creating test data for each project and will ensure downstream processes/applications have the data that is needed to execute their regression tests.
7. Over the last several years, our implementation plans have seen significant improvement. Our business demands that our systems be available 24x7x365. When you want to buy a tank of gas at 3AM or 3PM, you want the transaction to go through so that you can continue on your way. You would not find it acceptable for us to deny the transaction because we are updating our systems.  Our implementation processes have been templated and include all implementation activity, across all application and infrastructure silos, commands, scripts, validation and fallback steps in the order they will be executed.  Recently, our external auditors informed me that our implementation plans are among the best that they have ever reviewed. This has hardened our implementation activity – reducing the overall time needed to implement changes into our production environment, standardizing the validation activity during and after implementation activity has occurred and most importantly having fallback steps at the ready when any validation activity shows that there may be an issue.
8. Our development teams have changed their processes to include code reviews of all changes prior to those changes being introduced into our production environment. This is hardening our code base and reducing the risk of making changes within our production environment.
9. Our development teams have changed their processes to ensure that unit tests are created for all code being touched within a project.  These unit tests are then kept in a repository and used in future projects. This, again, has hardened our applications and reduced the overall number of bugs slipping through the process into our quality assurance testing or into our production environment.
10. Our development teams are now doing nightly builds – with reports going back to each team on build failures, unit test execution failures, code coverage and other statistics. This is giving immediate feedback to our development team and ensures that issues are addressed within 24 hours.

These are just some of the changes that have been implemented by the teams over the last several years. And we’re not done! Moving forward, we will move the regression testing into our nightly build process. We will be evaluating further changes to our development lifecycle to reduce the amount of time between idea generation and product introduction into our production environment. We will continue to improve upon our implantation planning. We will introduce key metrics across the development lifecycle. And where it makes sense, we will introduce Agile techniques into the development process.

I talk to college and high school students on a regular basis to discuss what it means to be in the technology field (specifically software development). The one constant that I tell students is that being in this field means you will constantly have to learn. They will learn new languages, they will drive change into the organization, they will experience multiple different development paradigms. All of this is good – it means the organization is alive, is learning and is adapting to its competition. 

Don’t settle for how it works today or with someone telling you, “well, that’s the way we’ve done it for decades!” Your job, no matter what role you play in the organization, is to find a better way, review your suggestion with those that can help implement, trial those changes and then roll them out across the team and the organization. Change is good – don’t settle for the status quo! 

If you'd like more information on my background: LinkedIn Profile

Don’t Hide Behind the Process

Well, it’s been a while since I’ve discussed process issues.  Time to dig in and have some fun!

Most of you that have followed my previous posts know that I’m a process kind of guy!  I’ve introduced formal lifecycle management into several organizations.  The teams that I’ve led have successfully utilized process enhancements to drive improvements in productivity, overall capacity and quality within various organizations large and small.  Utilization of a known process allows you to begin to measure various pieces of the lifecycle – looking for inefficiencies and issues that impact your overall ability to deliver for the organization.

Now all that said, each organization needs to find the lifecycle process and development paradigm that will work with their culture.  I’m not going to try and tell you what development paradigm you need to follow because I don’t know your organization.  Within the organization I currently work for we largely follow a waterfall process with some agile techniques utilized within various teams.  This works for us and the style of applications that we create/support – mostly technical interfaces within the payments industry.  Our overall lifecycle has various checkpoints/gating that we use to validate we are ready to move to the next stage.  This works for us!  We’ve significantly increased our productivity and capacity over the last decade and have improved the overall quality of applications that we are delivering to our production environment.

While all this has been good, I occasionally notice when people are hiding behind the process versus just getting the work done!  Not every project needs every step of the lifecycle.  Some are small enough and straight forward enough that we can skip various parts of the process or make the decision not to create some of the standard artifacts/documentation.

Decisions need to be made up front when the project is defined.  Those in the know, need to direct the teams when a project needs the full pomp and circumstance of the lifecycle and when the teams have the option to skinny up the process and skip parts of the lifecycle.  That means at the very earliest stages of Discovery, the Project Sponsor should be giving direction to the team on what the risks are associated with the project which can then drive decisions on how much of the process can or should be used on the project.

Additionally, once a project has been initiated, I think individual team members need to be cognizant of what is happening and make recommendations to the Project Manager if they feel certain pieces of the lifecycle could be skipped or maybe some documentation might not need to be created.  I’m not saying that we’ll always make the choice to skip over pieces of the lifecycle or to not create various pieces of documentation, but as leaders, we need to listen to the recommendations of the people closest to the work and if it makes sense, say yes!  When we decide that we can skinny up the process used within an individual project or that we can eliminate some of the standard documentation, those decisions should be documented.  That way, there is a record of the decision and the reason is documented and shared with the Project Sponsor.

Overall, we still need to deliver for the organization!  Delivering the requested solutions with the necessary features/functionality; delivering a solution at or below the expected budget; delivering a solution with the highest levels of quality.  Our teams should be held accountable to ensure we are delivering successful solutions at the end of the project.

If you'd like more information on my background: LinkedIn Profile

Off-Shore Development - Plan it right or Fail!

Off-shore development continues to be a discussion point within many organizations.  I've managed teams across the US and had the occasion where I've used off-shore resources.  Let me share some of the experiences in the hopes that it helps others that struggle with the model or are questioning whether to proceed with the use of off-shore resources.  I won't claim this represents the model to run off-shore development, ultimately, you need to make the decisions that will work within your organization.  Hopefully, this will shine a different light on the topic and allow you to gain insight that may help you make the decision to use off-shore development resources or to keep the development on-shore.

First, it is not easy.  If you think this will solve issues within your current development lifecycle - don't bet on it.  If you're going to seriously begin to use off-shore resources, you better plan appropriately, or you'll pay the price with development timelines that get extended and budgets that creep beyond your expectations.  In the worst case scenario, you'll end up rolling product into production that has not been properly tested and vetted.

Some of the breakdowns that my teams encountered in using off-shore resources are as follows:

1. Communication - eliminating the natural lag in communications as teams work shifts that do not align.
2. Design Aberrations - ensuring the product developed fully conforms to the original design/requirements.
3. Coding Standards - putting processes in place to ensure that the off-shore development team followed the development coding standards of our internal teams.
4. Quality of Code - ensuring that the code had been properly tested all the way through integration testing with other application silos/subsystems.
5. Quality of the Team - ensuring the consistency of development resources applied to projects.
6. Product Knowledge - ensuring that knowledge of team was retained from project to project.

The above list covers the major challenges that we encountered.  Let me go in to some level of detail so that you can get the flavor of what was experienced and how we handled the longer term needs of the organizations use of off-shore resources.

Communication: Each and every day, without your knowledge dozens and dozens of project decisions are made as developers lean across the walls and talk to each other or see each other walking around the office.  My teams have been no different, requirements and designs could change based on a hurdle that needed to be solved and a quick conversation in the hall.  Suddenly you have a team separated by multiple time zones - in my case, they had left the office for the day by the time we arrived in the office.  If the remote team had a question, or hit a roadblock and needed direction, there was an automatic lag of at least 1 work day.  If it was a serious issue, the team might loose several days as communication threads worked their way through email.  In extreme instances, we might have some of the remote team stay late or some of the local team come in early to establish conference calls and work out the issues.

Design Aberrations: The standard methodology we used to develop project requirements within the organization wasn't sufficient to support the use of outside resources.  Didn't matter if those resources were on-shore or off-shore, our teams were comfortable dealing with each other and could abbreviate how the requirements were documented.  There were a lot of things assumed within the requirements that didn't need further explanation because the teams had years of experience working together.  This continued to feed through the process as design documents were generated by the team.  Suddenly we introduced a team of developers that did not have that tribal knowledge.  The results were obvious in hindsight, the off-shore resources built the product to match the documented requirements and designs.  The only problem - those requirements and design documents didn't contain the unspoken elements known by the internal teams.

Coding Standards: Some of the products that we chose to develop off-shore ended up needing to be supported by local teams.  We quickly found out that the coding standards we had in place were not documented thoroughly and left many items up for consideration.  Translation, the remote team was producing code that looked like none of the other code that was used internally.

Quality of Code: The internal teams had many years of experience working together, touching each others code and making the necessary revisions to the code base.  Suddenly we had bugs that had been solved being reintroduced into the code base later in the development cycle.  Worse yet, we would find chunks of code that were never being executed, yet were loading up the code base.

Quality of the Team: Just as we were getting used to working with one set of developers, suddenly they would be reassigned to a different project and we would end up having to reacquaint ourselves with a new team.  To say that this slowed down development and introduced inconsistencies into the code base would be an understatement.

Product Knowledge: As we completed development with one project and started up the next project, we were not assured that the team we had gotten used to would continue on and do development on the next project.

None of this is serious and can be resolved, but you need to think through the engagement up front and take the necessary measures to protect your organization.  Here are some of the tactics we began to utilize to minimize the risk in the use of off-shore development resources:

Communication: We required the off-shore company to place one of their resources on-site with our local teams.  They became the primary communication point between our teams and the off-shore resources.  They sat in on the meetings locally and could catch the small things that needed to be communicated to the off-shore team.  They could do the impromptu meetings in the hallway and get that information promptly to the remote teams.  Our project timelines included buffers to accommodate the communication lag between the teams.

Design Aberrations: We ended up beefing up our Business Analyst and Architecture teams to create more thorough documentation.  Our documentation became much more thorough and attempted to accommodate the things that people took for granted.  The architectural diagrams became much  more sophisticated outlining all servers touched, all databases touched and were color coded to identify new, changed or removed elements.  Design documentation began to reference not only the objects that would be touched, but could go down to the individual methods and parameters when needed.

Coding Standards: We ended up going through our coding standards and documenting much more thoroughly how code was to be structured, how variables names were to be created, what security precautions were to be taken when creating the code, etc. 

Quality of the Code: Code created by off-shore resources was required to go through the same code review process that we used for internal teams.  This ensured that our senior developers were reviewing the code - exactly as would be done for internally written code and that they could catch issues and feed them back to the remote team.

Quality of the Team: After some experience with team members shifting, we ended up negotiating with the off-shore company to ensure that we had a core set of developers that would not be reassigned off of the project.  This allowed us to maintain some level of consistency within the off-shore team and addressed quality of code, coding standards and communication issues.

Product Knowledge: Similar to the Quality of the Team issue - by keeping a core team of developers assigned to our projects, the off-shore teams knowledge base of our products began to increase and they could begin to anticipate some of the issues ahead of time.

I want to state again, these were experiences that my team had in working with off-shore resources.  Other organizations may have different experiences.  Hopefully, some of these issues and the ways in which we resolved them will assist you with determining whether you can support the use of off-shore development resources.

I typically do not use off-shore resources unless there is a need to temporarily augment our internal resources to accomplish specific development/project goals.  That's a choice that I feel comfortable with based on the particular business needs within the organization.  In previous roles, I've had the opportunity to work extensively with off-shore resources.  If you're going to use off-shore resources, I highly recommend you pick a couple of small projects and trial a couple of different vendors to establish which one will work better with your current development paradigm.  Don't be afraid to switch  vendors if you don't feel you're being taken care of - ultimately, it's you that will be held accountable for the delivered product.

If you'd like more information on my background: LinkedIn Profile