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

Picking your own Path!

I’ve been around the block for a while now.  Later this month I’ll turn 51 – which means I’ve seen all sorts of things during my career.  I’m lucky – I love what I do and I knew I wanted to be in software development very early in my life.  I touched my first keyboard when I was 12 and began programming in Basic on a DEC PDP 11/70.  And if that alone doesn’t date me, my first programs were created on punch cards and teletype terminals – yep a keyboard with green bar paper running through it that would physically type out the commands entered and responses would come back and print on the green bar paper.  The smartphone I have in my pocket has significantly more power than that first computer I used.  My Nana always used to joke that I was going to fry my brain working on those ‘computers’!

I also knew at a young age that I eventually wanted to be in management.  I had grown up watching my dad run various companies – some failed, others were successful.  While I was in high school, my dad started the final company that he would run – it became very successful and provided him with years of enjoyment until he retired several years back.  Exposure to these companies and the environment in which my brothers, sisters and I grew up in made me realize that at some point in my life I wanted to be in a leadership position – I wanted to run the world!  If I had only known then the growth I would need to be in the position that I hold today!

So why am I rambling on about my early career?  Well, at one point, I had several people attempt to convince me not to move from development into a management role.  I was reminded of this recently because someone that I’m acting as mentor to, is having the same experience.

Moving into management is tough for someone who is in a technical role.  I’m not saying it isn’t tough for other professions – it probably is.  That said, I’m speaking from the personal transition I went through.  I was used to being the one in control – at the end of the day, I could look back at the success I’d had that day pounding out the code.  I was good at what I did – I liked the tough technical problems and my managers relied on me to solve problems.  I absolutely enjoyed being a developer – it was fun, I got to solve problems, I got to play with new stuff that nobody had ever seen, I was recognized for being a person that could just get stuff done.

Eventually, I got to the point where I decided I wanted to transition into a management role.  As I began to tell people that management was something that I wanted to try.  I got feedback from all over the place that I should just stay where I was at, to eventually become a lead or an architect.  Many folks had an opinion to share and staying technical seemed to be the theme behind most of the comments.

Well, for me, it came down to what I wanted not what other people wanted for me!  This is important; you can’t let someone else determine your path forward.  If you know what you want to do with your career, then you have to make it happen.  You can blindly sit there and wait for someone to notice you and maybe give you the opportunity, or you can take proactive steps that will get you into the position you want to be in.

I recently sat down with someone who is contemplating making a similar move in their career.  We had previously discussed this “change” in their career and I know that the individual has communicated with their boss about finding a path between their current role and into a management role.  This individual than began to tell me of all the feedback they were getting from all over the place on why they should stay in the role that they are in.

I let this individual pour it all out on the table.  Then I asked them, "who cares what everyone else wants, when you look at yourself, what is it that you ultimately want to do with yourself?"  Now, I fully recognize that this individual is really good in their current role – and I mean really good.  That said, how happy are they going to be in the future if they at least didn't try?  This individual didn't hesitate, looked across the table and said, “I know I’m meant to be a manager!”  My reply, “Then why are you letting other people create doubts about what you can become?”

I have no doubt that this individual will experience some challenges moving out of the role they currently play and into a management role.  I also have no doubt that this individual will be successful in either role.  I also know the people this individual works for will provide the support needed to transition into the new role – they've done it with other folks on the team!

Sometimes you can’t listen to those around you and you need to chart your own course.  Don't be afraid to make a change and when you make the decision - proactively take steps to make it happen!

See more about my life in technology via: http://anidea4today.blogspot.com/

Practicing What We Preach …

This week, I got a small dose of humble pie from our CIO.  I was in his office discussing the difficult time that one of my teams was having filling a key position.  Finding someone is critical to the success of this team and it has been difficult finding candidates that would be able to come in, hit the ground running and make a difference.  We have key criteria for this position, and I’m not willing to budge – this is one of those times where I don’t have the luxury of training someone, I need someone with a specific skillset and experience.

Before everyone goes all crazy on me for speaking out both sides of my mouth, I normally utilize a very aggressive internship program to fill open positions within my team.  It is rare that I hire experienced candidates.  When I do, I am very specific about what I am looking for and I stick to my guns.  I won’t hire someone just for the convenience of filling the role, I will wait until I find a candidate who fits the needs that I have and that be a net positive for the team.  I’ve bent in the past when I felt I just needed to get a body in the door, and it’s a painful experience.

So, then, let’s get back to the story.  I’m sitting in-front of my boss – our CIO – explaining what steps I’ve taken and where we are at in the process.  He’s letting me vent and as we get close to wrapping up this part of the discussion he asks a simple question, ‘Have you considered hiring someone remote?’

Whack – right to the center of the forehead!  Ok, so you need to understand for the last several years, I’ve been the most vocal proponent inside the organization to allow our team members to work remotely.  We have successfully introduced it into my teams and this has slowly crept into a couple of other areas of the company.  This has been allowed in a very limited fashion, but has proved to be successful enough that a key member of our team moved to another state and organizationally, nobody questioned his ability to continue working for us when he asked if he could do so prior to moving.

Additionally, via an acquisition several years back, one of my teams is split geographically with the manager located at our main facility with half of his team and the other half all working in disparate locations across the southern US.

So there I am the biggest proponent of getting people to work remotely sitting there in front of my boss looking like a fool! Organizationally, we are ready to expand this program.  In fact our COO has recently spoken about the need to show flexibility in where our teams are located.

What could I say, but, ‘You’re right! I guess it’s time for me to step up to the plate and take the next step and push this program forward!’

As leaders within an organization, we have to remember the things that we are fighting for and when given the chance, we need to implement those changes into the organization.  Our bosses expect it of us and we expect it of the people that report up through us – we need to remember, the same rules apply to us.

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

Leadership - Getting Beyond Management!

Are you managing or are you leading?  The two are very different and if you're not leading, you shouldn't be a manager!

Managing is handling the tactical day to day activity within a group of people.  Ensuring that milestones are hit, coordinating activity between your team and other teams, reporting progress, etc.  In short the manager maintains the status quo - acting within the defined processes to keep the business moving.  They manager accomplishes activity due to their authority.

Leading means changing the dynamics to get the best from the processes and people.  A leader inspires the people around them to effect change.  They can establish a vision and know how to tap into individual team members to get them to see the vision and how they can contribute to the overall vision.  Leaders instinctively know what motivates an individual within the team and can appeal to that individual to use their strengths to close the gap between today and where the leader wants to be tomorrow.  Leaders are focused on the longer term vision.

I freely admit that there are moments in time where I must manage - stepping out of my normal role and acting in a more tactical fashion to help the team push something across the finish line.  This isn't a bad thing, and to be quite honest I think as a leader sometimes you need to do this to ensure that you understand what is really happening within your teams.  I also, sometimes by choice, make the decision to drop into meetings I normally would not attend - project status meetings, implementations, integration test sessions.  Not only do I get the benefit of getting to know some of the team members I would otherwise not interact with on a regular basis, but it also gives me a temperature of what is really happening within various projects.

However, my daily focus is, and should be, at a different level within the organization.  My job is to look ahead of the teams and remove roadblocks.  Understand processes that are not working and change those processes.  Identify when changes in the business may require organizational changes within the teams that I manage.  Identify opportunities within the industry and find ways to get ahead of our competitors.  Find ways in which we can change that will improve the experience of our customers.  Working with our Human Resources team to build pipelines to talent pools so that we can fill vacancies or know where we need to go to find resources when we expand our teams.  It's also my responsibility to look beyond the tactical needs of the organization and create the vision for my part of the organization.  Where do we need to be and what and how do I change things to get us there - then driving that vision down and through my organization.

When I first moved into a management role -- I figured my job was to be the tactical expert.  Help my individual team members get stuff done.  Now as a Vice President, I still need to be in tune with my team members and help them get stuff done, but along the way, I've learned being a manager/leader is so much more.

I want my managers to be leaders within their teams and within the organization - no, they don't necessarily have the influence that I have to effect change, but they can lead and drive change within their teams and the processes they interact with/manage:

1. Managers are the closest link to individual Team Members.  They need to be driving the growth of each team member.  One of the mantras that I have within my teams is that you can't get promoted to the next level until your doing the job of the role you want.  In other words, if you want to move from a Software Engineer I to a Software Engineer II, you must demonstrate you can perform the duties of that new role.  It is the Managers job to establish a growth plan with the individual Team Member and guide them/mentor them so that they can see that promotion.  I ask each of the managers within my team to establish individual learning plans with each team member and constantly work those plans with the team member.
2. Managers see the reality of the process works versus the theoretical process that was defined.  I encourage each of my managers and direct reports to constantly provide feedback on what is working and what isn't and most importantly, if they think it is broken, how do we change the process to make it work better.  Even better, if they are working a project and want to try a new way of doing something, let's talk, give it a whirl and see if it gains us anything.
3. Managers are the actual touch points between their department and other departments, I expect them to drive the relationship and identify how to improve communications between not only the departments within my organization, but departments reporting up through my peers.  It is an expectation that they act as a role model to their team members in showing that we can establish positive working relationships between departments - that doesn't mean we always agree, but that we find a way to move the conversation forward in a professional and positive way.

This isn't meant to be an exhaustive tale of how I see my management team playing within their roles, more of a prime to get people to see that they can play more than a tactical role.
 
I once had one of my bosses tell me, "I don't know what it is you do, and quite frankly I don't have the time to figure it out.  When you need something, tell me who I need to talk to and what I need to say."  Was this the worst person I 've worked for, no.   Did I have any respect for this person, no.  While he had the title of Director, he didn't mange, nor did he lead his organization.  He came in in the morning and sat behind a closed door - rarely interacting with any of us.  Luckily, he was gone within 6 months - the company had seen fit to move him into a different role.  I left the organization shortly after that, but have never forgotten those words.

Are you being a leader for our teams?  Are you setting the table and letting people within your organization lead where they can?

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

Implementations - When Things Go Bump In The Night!

Sometimes bad things happen.  The question - how fast are you able to respond and put things back on track?

Technical teams need to plan and test their ability to rollback changes that are negatively impacting users.  This needs to be a formal part of your process - sometimes that means falling forward, fixing the broken functionality in production; sometimes that means falling back and reverting to a known state where the application was functioning properly.

Let's be honest - none of us are perfect all of the time.  Occasionally, we are going to miss something and move code into the production environment that ends up breaking things and making life miserable for the folks actually using the application.  

What have you done to prepare for this moment?

1. Does your implementation plan include steps to proactively monitor the system as changes are moved into production?
2. Does your implementation plan allow time for you to look at patterns of application activity to validate that you are not seeing patterns that would indicate that something is broken within the application?
3. Does your implementation plan include validation steps to ensure that the application is acting accordingly and that the new/changed functionality is working?
4. Does your implementation plan identify risk points and fallback strategies?
5. Have you tested your implementation plan?
6. Have you tested your fallback plan?

Every environment is different - but we mostly face the same types of challenges.  Breaking things that users expect to work is not what we want to do, but occasionally, it happens!

Yes, planning your implementations takes time.  Yes, planning validation steps and inserting them into the overall implementation plan takes additional time.  Yes, testing your implementation plan chews up more time.   And, yes, testing your fallback plan takes even more time.  That all being true, failing to do any of this means that your operating by the seat of your pants and your recovery time when things go bad will hurt you worse.

1. When your application fails - the reputation with your customers takes a hit.
2. The longer the outage increases the risk that your customers will walk away from you and begin to use a competing application?
3. Will an outage impact your revenue stream?

Now, all that said, sometimes even with all of the best planning, you're going to get caught.  It's bad enough when it's a web based application/service where you can make immediate changes or perform and immediate rollback.  However, what if it's software that you're sending out to customers - that they install on their systems?  How do you think Microsoft feels when they send out one of their regular patches only to find out that it causes the blue screen of death.  This can affect millions of computers around the globe.

Not to hit Microsoft too hard - but, in April they released a patch to Windows 8.1 that was required before any other updates could be applied.  This impacted retail customers as well as corporate customers and was not fixed until early May.  I'm sure that they ran their standard quality processes against the code prior to the initial release in April - but something obviously got by the testers, and it wasn't a minor issue.  It took time for Microsoft to hit the reset button, but in the meantime their customers were in an uproar.  

I'm going to walk softly here because as a developer it could happen to me or the teams that I lead.  I'm not trying to single out Microsoft - anyone that writes software has had to recover from a misstep when loading code into production or sending out a new release.  What I'm advocating for is that you implement solid processes that minimize the risk to your customers, your team and your organization.

What are you doing to mitigate the risk of an implementation/software release going bad?

Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making; Project Management; SDLC; Lifecycle;

For more information on David L. Collison: LinkedIn Profile

Languages, Languages, Languages ...

I speak regularly with High School and College level students promoting careers in technology - specifically careers with Applications Development, Quality Assurance and Project Management.  I enjoy interacting with the students and telling them what they may experience as they transition from the role of a student into the professional workforce.  Along the way, I also ask students to think about interning - either with my organization or some other organization in the area.  This is a fantastic opportunity for students to get real-world experience, become visible to an employer, and begin to understand some of the concepts taught in the classroom as they apply them to tasks in the workplace.

Many times, students ask me why we use the languages that we use and why we don't take advantage of the latest scripting or language fad.

My answer - why should I?  They seem to be stumped by my response.

Well, really, why should I?  Why should my team be disrupted on a regular basis just to use the latest language fad?  Why should I continually experience a productivity loss as team members shift between languages?  Why should I take the risk of bugs being introduced into production systems because the developers are not experienced with the language/tools that they are using?  Why should I risk customers being subjected to performance issues because the developers haven't figured out how to optimize the programs they're creating?  Why should I make the on-boarding experience for new developers more difficult?

Look, there are a handful of languages that we've committed to within our organization.  Four languages are used to generate all of our production level systems.  A couple of additional scripting languages have been used to create internal tools that assist us in production setup, as well as assisting us in ripping through logs to find specific information when we are researching issues in our environment.

Programming languages are programming languages - if you're a good programmer, you can pickup any language.  If you're a good developer, you understand that once you understand the various constructs of a language - learning a new language simply means translating the specific syntax of the language you want to learn to the languages you already understand.  It's translating how to use an if statement, a loop, a case statement, etc.  

Let's say it take you a month to become familiar with the new language - assume that your productivity drops by 50% and for 6 months after your initial learning period, you're running at only 75% productivity.  That means that over a 7 month period - you're productivity has cost the organization 8 weeks of development time.  Now multiply that across the entire team.  Assume their are 10 members on the team - that's a total of 80 weeks of lost development effort.  Assuming this same 10 member team and an average of 2 weeks vacation time for each team member - you have a total of 500 weeks that you can allocate to development efforts.  The end result is that you've stripped the team of 16% of the overall capacity of the team for the year.

Now, the numbers discussed above don't even take into account the impacts down the line as we move through test, implementation and post-implementation support.  How much more time will the Development Team need to create and execute unit tests?  How much time will the Development Team need to perform integration and regression testing?  How much time will the Development Team need to perform load testing?  How much extra time will the Quality Assurance Team need to test the application?  What additional issues will be experienced during the implementation of the code into production?  Can you quantify the number of additional issues that will be identified post-implementation that will need to be fixed and how much additional time it will take to address those issues?
 
The impact on productivity across the organization is significant and material - that is real time that prevents projects from being initiated or completed.  That's time that allows your competitors to either close the gap or get further ahead.

I don't mind taking on a new language when there is a need, or when there is a specific purpose.  Over the last couple of years, we've actually brought in specific tools that have allowed us to move in to the mobile market.  At this point, a select number of developers within the overall team have been exposed to these new tools.  Over time additional developers will be brought in to the loop.  Here, there is a specific need - our tools at the time did not lend themselves to creating cutting edge mobile apps.

Take a step back and look at the decisions being made within your organization.  There's usually a reason that organizations aren't moving as quickly from one language to another as developers would like.  To the developers that would like to get an organization to change - don't just go in and say that you need to be able to use a new language.  Document what you feel the benefits are, and just as importantly recognize the impact to the organization and craft your discussion points to address the costs that the organization will incur.


Tags: Development; Programming; Programming Languages; Change; Decisions; Decision Making;

For more information on David L. Collison: LinkedIn Profile