How do you transition from one tool to another or make the decision to change the type of development paradigm that your teams are using? I'm not going to pretend it's easy, nor am I going to pretend that I'm an expert at it. But, I have been through several of these across different organizations and the path is similar. What I'd like to do is share some of the insight that I've gained throughout my career and ask that others provide feedback on what they've seen and experienced.
I've seen organizations shift their development processes back and forth between very informal processes, to formal processes, to something in the middle. Sometimes adding/changing/removing processes or tools, sometimes swapping out the entire paradigm by which the team operates. All of this is being done in the name of improving time to market, increasing quality and/or improving the productivity of the team members. Admirable goals, no doubt. In fact, consultant organizations have popped up over the years that specialize in taking teams to specific development paradigms and switching the entire tool sets used across the entire lifecycle. This is not something that is done lightly. There is usually a loss of productivity through the transition period and an outlay in real dollars as the organization trains entire teams on the new paradigm. Market opportunities are impacted as teams shift to the new paradigm and the potential to fall behind the competition is real.
Software Engineering is both an art and a science. The science part is the syntax - this is straight forward and understood and can be taught. In fact we have excellent resources - both formal and informal - that allow anyone interested in getting in to software development to learn. On-line tutorials, books, free on-line courses, paid on-line courses, high school courses, college courses, and seminars. Along the way, at any level, prospective and experienced developers can get assistance via dedicated web forums, videos, and sites that hold sample code. If you need help learning how to code a particular language or a specific function, you can find help on the web. I still remember my amazement back in the late 80's when I posted a development question up on a early portal and received an answer within a matter of hours from someone half-way around the world.
Project Management is also both an art and a science. The science part is managing the defined process and set of artifacts. Knowing when certain activities need to be completed. Understanding when a team member or portion of the team needs to complete specific artifacts. Managing the Risks and Issues. Understanding when to communicate to the team, individual team members, across and up through the organization.
The art of Software Engineering and Project Management is the individual. Put two engineers in the same room to solve the same problem and you will invariably get two different answers. Assign two different Project Managers to the same project and they will drive results differently - one may be more of a driver - managing the process by proof; the other more of a expressive - using relationships to primarily drive the process. Making software development work is not always taking preexisting components and placing them together. It is not like building a prefabricated home. It is knowledgeable people understanding how to finesse the tools and the processes to move the ball forward.
Development Paradigms and the Development Lifecycle (SDLC) are the sauce that brings order to the development process. Attempting to provide the pieces needed at the appropriate times to allow all parties to be satisfied. Moving from no development process or paradigm to a structured paradigm can be difficult - trust me, I've been there, done that. However, moving from one structured paradigm to a different paradigm is often worse. When there was no process to follow, getting someone to create a specific artifact or to follow a specific process is an effort, but can be done. Getting someone to change the way they create an artifact or to stop creating the artifact altogether is tough. All of a sudden, fifty people will show up to explain why they need the artifact the way that it is today, or that by not producing the artifact, you are going to break 100 different things across the organization.
Fundamentally, I guess I've always asked for feedback on the processes and tools that are used within the organizations that I'm leading. Yes, I want to bake in what we are doing, but I also want feedback, and if I can be convinced of the value, I'll work with the teams to make the changes and to drive overall improvement. Here are the ground rules that I ask people to consider before recommending changes to the processes, tools and the overall development paradigm that we use:
- How will this impact the customer? Everything that we do must be in the context of our customers. What's the worst case scenario if we suddenly transition from the way we currently do something to the new way being proposed? What are the perceived benefits of making the change?
- What does this do to our quality? Yes, this is related to the first item, but stands alone on the overall merits. Does the change allow us to fundamentally alter the quality equation? Can it reduce the efforts needed to validate existing quality? Does it provide additional quality measurements that are not used or possible today? Does it expose us from a quality perspective and unintentionally add risk to our systems?
- What does this gain us against our competition? Does it allow us to leapfrog with some feature set or capability? Does it alter the balance and allow us to take advantage of competitive weaknesses?
- How does this impact the flow of data through the organization - does it reduce the quality of data, does it reduce the number of places data is stored, does it reduce the number of times data is entered through various systems?
- Can the change provide a significant reduction in the time it takes to move through the overall lifecycle and improve time from concept thru delivery?
- Does it impact our security stance? Does it improve or decrease our ability to secure our intellectual property (IP) and the data held within our systems?
These are not conversations based on the concept of - hey, I found this great new tool on the internet and played with it at home, so I want to start using it at work! The dialog must cover the above points and we must also take in to consideration the impact across the team.
I can't afford to change tools, languages, processes or artifacts on every project that runs through the organization. That said, I'm always interested in having a discussion on ways we can make positive changes that can reduce our internal efforts, improve the security stance of the organization, drive better quality within the products we build, and reduce the overall time to market.
As it sits today, I have people trying out different processes within the way that we run our project meetings. I have people making recommendations on new tools that we can use within the lifecycle. Team members are also making recommendations on changes to some of the artifacts that we use. Will all of these changes make it in to production - probably not. Will some - I hope so. Over the last six years we've made significant strides that have allowed the organization to dramatically increase the number of projects being worked as well as the quality of products being delivered. Now we must change to meet the future needs of the organization. We must continue to innovate and deliver solutions that make a difference.
When and how do you allow changes to be made to your overall lifecycle, the tools that you use and the artifacts that are generated?
Tags: Project Management, SDLC,
Project, Management, Project
Manager, Software Development Lifecycle, Project Lifecycle, Project, Manager, Development, Paradigm
For more information on David L. Collison: LinkedIn Profile
Before I get started with this post, I want to spend a little time discussing my last post focused on Developers. One response came back and had several great points that I wanted to echo back to the full audience.
In summary, JR made the point that Developers are generally a smart crowd and provide passive resistance when they sense the PM is playing games with the team. To the point made in the response, the PM role and most other roles in the entire lifecycle support the applications being created by the development team and are there to help increase the efficiency of the team. Great Project Managers will put the needs of the entire team before themselves and will work to increase the efficiency of the individuals - software engineers, quality assurance engineers, infrastructure engineers, UAT Teams, marketing, etc. They will focus on removing roadblocks, opening communication and staying ahead of the team.
Now, on to the topic at hand. One of the things that I've seen frustrate Senior Leadership Teams is when Project Managers and Project Teams begin to use the process as an excuse for not delivering! The process is in place to ensure conformity to a basic set of processes and procedures. That doesn't mean that every project needs every step of the process, nor does it mean that every project needs every artifact defined within the process.
I challenge each of you to look at the projects that are running through your organizations and ask the following questions:
- How complex is the effort defined within the scope of the project?
- If this is a minor change to a system already in place, and there's agreement on the scope and requirements, why would you force the weight of the entire process and slow down the delivery? Skip the scoping document, skip the full requirements analysis, get the right people in a room to create an impact statement showing what will be touched so that everyone knows what needs to be tested, and get on with it.
- What is the risk to the organization if this project does not succeed?
- If this is a low risk system with very little impact to the organization, why would you waste a lot of internal resources and time to create all the formal documentation? Identify a minimum set of documentation that gives the team the information they need, verify with the sponsor that they are on board, and bang it out. Don't slow it down.
- What is the risk to the organization if specific features/functionality are not delivered?
- Again, if this is a system that is used by a small number of people, has very little risk to the organization, does not manage key data, then move it along. Talk with the sponsor, find out what it means if specific features are skipped for this release. If they are on board, get it done. Maybe they don't need the features right away, maybe some of the features were wish list stuff that isn't needed to really get the job done. Narrow the scope and provide the key features/functionality to the users.
- What is the overall size of the team providing this solution?
- If it can be defined and worked by 1 or 2 people sitting in a room together, why would you waste putting the entire process in place? Seriously, put the end user in the room with the developer and let them get it done.
- Who are the end users of the system being delivered?
- If the system being developed is used internally, do you need all of the pieces of the lifecycle to be used to deliver the functionality? I ask this question seriously. Sometimes you do because the data being touched is critical or because the system being worked provides key data used to manage the place. However, sometimes internal systems don't need all the fluff.
Ultimately, you have to look at what is the risk to the organization - what data is being touched, how complex is the functionality being delivered, what is the impact if it doesn't get delivered or if it is pieced out over multiple deliveries?
Part of our jobs is to reduce the clutter and allow the team to get the work done. As a Project Manager, you need to review each project that you're given and begin to make recommendations back to the Project Office and the Project Sponsor when you feel you can skip pieces of the lifecycle and certain artifacts.
Trust me, your Team will love you when you tell them that you can speed things up. Look, the people that work on your teams know when stuff is being done just to click off a check box versus adding real value to the process. If you can come in and show them that your stripping away the stuff that doesn't need to be there, that you're working on their behalf, you're going to get a lot more respect from the team. They'll work harder and make your life easier. However, if you continually tell them that they need to fill out this form or that form because the process demands it, you aren't going to get very far.
I would challenge you to go as far as formalizing the process used to reduce the artifacts and skip phases of the lifecycle! The Teams that I work with have defined a process that we use up front and along the way through gating meetings where we can recommend specific activity or artifacts be skipped. This gets presented to the Project Sponsor and decisions are made and documented about what will and won't be done through the following phases. Reviewing this at each gating meeting allows us to adjust this decision based on new facts that present themselves during the overall project.
How are you removing the clutter within your projects?
Tags: Project Management, SDLC,
Project, Management, Project
Manager, Software Development Lifecycle, Project Lifecycle, Project, Manager, Development
For more information on David L. Collison: LinkedIn Profile
Developers, Software Engineers, Code Guru's, Programmers ... this one is all about you! Yep, I've published several posts, but haven't directed any at the folks slinging the code on a regular basis until today! When I look back on it, that's pretty amazing, considering software development is where I started and that it is an integral part of the Software Development Lifecycle. So, today we're going to mix things up and put the spotlight on this merry band of coders!
I've had the pleasure of meeting lots of developers from around the world in many different organizations that I've worked for - either as an employee or as a consultant. I'm still surprised when I meet individuals that think of this profession as some sort of magic. They are perplexed that men and women sit down and create all of this stuff that we now use as a part of our regular lives - apps on our smartphones, apps on our tablets, the programs we use on our laptops and desktops to the applications that we run on our thermostats in our homes. You seemingly can't go anywhere without running in to things that are run by software.
My first professional programming jobs used things like dBase III, Clipper and Basic - storing information in dBase III file formats. And yes, I've just dated myself! Anyhow, I then graduated on to Visual Basic, C, C++, C#, Java, JavaScript, Ruby, Ruby on Rails, a very brief stint with Assembler. Data was stored in Oracle, DB2, MySQL and SQL Server You get the idea, I've worked in a lot of languages and haven't even listed all the scripting tools I've used over the years. I've used these languages in all sorts of shops - sometimes it was on projects where I worked alone (oh, how I long for those days). Sometimes it was in large organizations, with sophisticated development processes, where teams were located across multiple locations and continents. Sometimes I got to sit next to the people who would end up using the code that I was writing. Sometimes I never met the people - I worked from written documents and interacted with the project manager and quality assurance team. Sometimes the code that I wrote was used by 1 or 2 individuals, sometimes it was used by people across the globe.
I love writing code, and even though it's not my role anymore, I still write code at night so that I can continue to learn and keep my skills somewhat fresh. I won't kid myself to think that I can get back down in to the trenches with some of the developers that do this all day long, day in and day out. However, creating software is still something that I like to do - I can really get in to the zone and not realize that hours have gone by, before I come up for air.
Now, along the way, I caused my fair share of Project Managers to loose sleep, go grey prematurely, and I'm sure I did a number on their blood pressure. In many ways, when I first started, I didn't understand my role in the whole project thing. Wasn't I just supposed to sit at the keyboard and make it happen! As sure as I'm sitting here writing this article, I'm positive that my old managers, and project managers that I worked with, would tell you that I wasn't too keen on following the rules. To be very blunt, I was aggressive in the way that I approached my job. I wanted to get things done - heck, talk to the people I work with today and they'll confirm that last statement. I'm still aggressive - the difference is that over the years I've learned to temper my natural tendencies and understand that sometimes rules and process do add value to the overall flow of the Project Lifecycle.
Wow, that was a long winded intro to the topic! And, if you haven't figured it out yet, I want to talk about the person generating the code and their role in the Project Lifecycle process.
Take a look at the titles at the top of this posting - I generally don't care what you call yourself, you're developing software and you do have some level of responsibility to your team. Even if you consider yourself a team of one, unless you are the only person that will ever use the software you are creating, the team is larger than yourself. At a minimum, it is two people, yourself and the one other person on the face of the planet that is using your app. Hopefully, the number of people using your app is a lot larger. Many times, working in an organization, you will be one of a larger team - other programmers, the project manager, quality assurance, end users, designers, etc.
If you are developing code that others are going to use, you have a responsibility to the other people that are on the team.
- Setting proper expectations as to when you will hit specific milestones.
- Holding yourself accountable to complete the identified work between milestones.
- Making sure that the quality of code being delivered to the test teams is adequate.
- Keeping everyone that needs to know in the know on any issues that come up that are preventing you from making progress.
- Helping to create mitigation plans when something goes off the tracks and is jeopardizing the milestones, the quality or the functionality of what is being delivered.
- Ensuring that you keep focused on assigned project activity.
I will be the first to admit that creating software can be an art. However, that doesn't absolve you of your responsibility to fit in with the team and support the goals of the project.
You see, here's the rub, when you miss the milestones for work your responsible for, the project and future projects all get impacted. Somewhere, in the organization, plans have been made on specific things happening within a specific order. Project A gets completed and moved in to production. While Project A is moving it's way through the Project Lifecycle, typically Project B will get started so that when the developers are done with activity associated with Project A, new work is waiting for them. If the work your responsible for is acting like a logjam, then Project A isn't going to get in to production and Project B's work is going to get delayed. Now Sales and Marketing have a problem because they've promised customers that they'll be able to use the functionality by July 1st - whoops just kidding, can't get it to you now until September 30th. Oh, and that new project you wanted started, we can't touch that yet - don't even bother to ask us about the delivery date.
This is real stuff, sometimes contracts have been written around the delivery of specific functionality, or entire marketing campaigns are laying in wait ready to go. Sometimes those contracts have costs associated with them if the company you're working for can't deliver. Sometimes the marketing plans are time sensitive and if you're late delivering the code to production, they have to spend additional dollars replacing the pieces of the campaign that no longer make sense.
And just so you don't think it's the non-technical teams that are affected, what about your buddies down the hall in the quality assurance area? Any idea on what they are trying to juggle? No, it's not just your project. They have multiple projects coming through the pipeline hitting their test environment. When they have to keep retesting your package because the quality is horrid and you keep crashing their system. When they can't test because you can't deliver code in to their environment. What do you think happens to finely tuned dance of projects winding their way through the various environments in to QA? It all comes crashing down. What you're not noticing is the scramble happening behind the scenes to put all the pieces back together.
Did you do a design? Did you base your estimates off the design vs a hunch? Those are bad problems to have. Ok, there all bad, but those are really bad. Did you misjudge one of the requirements and underestimate the time needed to develop something? Did you encounter something in the test environment that caused your code to fail that wasn't within your control? Those aren't good, but at least there's an explanation. It's your responsibility to quickly inform the Project Manager of issues and whether you can get back on track, whether you need assistance in removing the road blocks, or if the problem really is of the type where there is going to be an unexpected delay.
I'm going to go back to a statement I've made before, we're human. Sometimes we make mistakes. Here's the million dollar question - did you make the mistake because you didn't want to follow basic rules when it comes to developing software. Yeah, those rules, the ones your company calls the Software Development Lifecycle. If you're not supporting the process, you're working against the team, your manager, the project manager, the department, the organization and ultimately your customer.
Tags: Project Management, SDLC,
Project, Management, Conflict, Resolution, Project
Manager, Software Development Lifecycle, Project Lifecycle, Project, Manager, Development
For more information on David L. Collison: LinkedIn Profile
