| Software development work is hard. No way around it, it is one of the hardest things i have ever done. It's not so much the coding/programming work but the complex coding, testing, building, deploying.... and most importantly communication AND collaboration. New requirements for an application come in and from the drafting of the requirement document to the deployment of the feature it is like a game of telephone. Every step of the software development process is crucial in feature delivery. If one step is not done or done incorrectly it will impact the outcome. |  |
Requirement gathering.. I was going to start with this one but there is actually one step you need to complete before you get to this step.
Feedback gathering and documentation
There needs to be some understanding of HOW this will be done. A process if you will. Sometimes folks get all bent out of shape when a 'process' is mentioned but without process the team cannot be in sync. Everyone cannot use their own steps when trying to work together. This process would define who, what, where, and how requirements and documentation will happen:
Who:
Requirement breakdown and Prioritization
Each requirement needs to be discussed, planned, and brain stormed, by the project manager and tech leads. Thinking about the design, implementation, deployment, and training of new features is critical here. Spend the time and document what it will look like, how it will operate, how the user will interact with it, etc. Visuals are important here; mockups, data flows, system diagrams, etc. Everyone will have a picture of what it will do and/or look like in their mind you NEED visuals so everyone can see what the collective sees. A lot of time and effort will be wasted with assumptions; product owners assuming the development team understands the requirement can lead to problems later. Along that line, if there is too much time between the requirement discussion and the actual work it will take the team time to understand the requirement all over again and where/how it fits into the application they are building. Just like multitasking it takes time to shift from one thing to another.
Breakdown the requirements into small issues to ensure the team does not overextend themselves when planning an iteration. What is 'small'? That is a whole other blog :) The team should be providing the level of effort on the issues so inexperienced/non-technical folks are not providing the wrong expectations on the work. The team doing the work should be estimating the work. Story points vs hour estimates.. Doesn't really matter what matter is the team has decided on the scale that will be used and what it means to them. And you have to be consistent with this scale from sprint to sprint and while doing estimations.
The "real" work
This section is what most folks think of when they think about a software development team. A group of developers that are skilled in writing code in a language or multiple languages and producing a tool/application. But it's more than that, much more. A typical software team will have a list of issues/stories/tasks prioritized and ready for work. Developers will take a task/issue/story to work and go 'head down' into coding the feature/bugfix. Along with the coding the dev should be creating new tests for new code and update existing tests for any code updates. So for any piece of work started there really is a lot of other work already attached to it; code, test, build, code review, merge(version build), deploy. Before any line of code is started the team needs to understand the work! Don't skimp on the Sprint Planning (if doing Scrum) the more discussion in the planning session the less questions should arise during the work cycle. If you have a question about the work ASK NOW there really is no dumb question (as they say) and others might have the same question or worse yet, no one has thought about your specific question and you just saved yourself and the team a lot of heartache later. Read the issues all the way through, sometimes teams get so used to pulling in work into the sprint during planning that they don't go through and review the issue, description, overall goal of work, and the acceptance criteria. Development work is a discipline once you start getting lazy, issues will start arising in other areas of your work. Cut corners and you will feel the pain later. My advise, take the time up front because once you are working on the code you have set the expectation that you(and the team) can accomplish it, if you can't deliver that code on time and in the amount of effort discussed it impacts the whole process.
Deploy
After the code has been written, tested (both with automated and manual testing), reviewed, merged, and version tested... it is time for a production deployment! My biggest advice in this section is if there is anything manual you are doing during your deployment take the TIME AND AUTOMATE. There are CI/CD servers for a reason and it is to make the building and deployment of code consistent. You might be thinking.. O the 2 minutes I take every deployment to run a DB backup script or do the VM snapshot doesn't take long.. It doesn't, but it does take time AND God forbid you forget these steps when deploying. Build them into your deployment plan, if you think they are too complicated to script discuss it with the team. Take those ideas and break them down into their own game-plan on how you can make small changes to improve the overall deployment process. (2 minutes x 52 releases/year = 104 minutes which doesn't sound like much but a lot of shops these days are doing multiple deployments a DAY!)
Another part of the deployment plan should include deployment verification. How is your team verifying the deployment was successful (above the CI/CD saying it was)? Are you doing health monitoring on the server? Are you running a list of tests against the production server to verify API and basic application functionality post deployment?
Feedback!
The job is NOT over after the deployment has been made. There needs to be interaction with the user base to see how the new features have been improving their work life. Did it save them time? Did the feature get delivered the way the user group expected? Or are there a lot of 'this is great but..' conversations happening after deployment. This could point to multiple problems in the overall process. The team needs to identify where the disconnect has happened and fix the problem.
My advice here for feedback is to bake in as many ways of getting feedback as possible. If using metrics generated by your application is possible use it! Put in counters and controls to tell you what pieces of the application are being used and which ones are sitting collecting dust after a release. If a user base is not using new features after a deployment it could be a matter of the prioritization of the requirements is wrong.. You are delivering things that aren't crucial to the user base. or worse yet, THEY DON"T CARE and you are working on a tool/application that would not be missed if the lights were turned off. The only way to know any of these things is to keep that open line of communication between all the teams, personnel, management, and users. (I also wrote a blog about picking a communication medium everyone can agree on.)
Feedback gathering and documentation
There needs to be some understanding of HOW this will be done. A process if you will. Sometimes folks get all bent out of shape when a 'process' is mentioned but without process the team cannot be in sync. Everyone cannot use their own steps when trying to work together. This process would define who, what, where, and how requirements and documentation will happen:
Who:
- Who will be collecting the feedback/requirements/needs?
- Who will be providing the feedback/requirements/needs?
- Who will be present for these discussions? Project Manager, Stake holder, Lead/Sr Developer, Users
- What will they capture?
- What will be discussed?
- Where will the notes/discussions/documents be stored? (Central Documentation repository/Idea Central):
- Where will the discussions take place? Face to face, Virtual environment/Webex, Phone, ??
- How will the requirements get captured? Overall Goal of tool/application, High Level ideas, detailed requirement documents, word docs vs confluence pages
- How will the PO and Team breakdown the requirements into working issues?
Requirement breakdown and Prioritization
Each requirement needs to be discussed, planned, and brain stormed, by the project manager and tech leads. Thinking about the design, implementation, deployment, and training of new features is critical here. Spend the time and document what it will look like, how it will operate, how the user will interact with it, etc. Visuals are important here; mockups, data flows, system diagrams, etc. Everyone will have a picture of what it will do and/or look like in their mind you NEED visuals so everyone can see what the collective sees. A lot of time and effort will be wasted with assumptions; product owners assuming the development team understands the requirement can lead to problems later. Along that line, if there is too much time between the requirement discussion and the actual work it will take the team time to understand the requirement all over again and where/how it fits into the application they are building. Just like multitasking it takes time to shift from one thing to another.
Breakdown the requirements into small issues to ensure the team does not overextend themselves when planning an iteration. What is 'small'? That is a whole other blog :) The team should be providing the level of effort on the issues so inexperienced/non-technical folks are not providing the wrong expectations on the work. The team doing the work should be estimating the work. Story points vs hour estimates.. Doesn't really matter what matter is the team has decided on the scale that will be used and what it means to them. And you have to be consistent with this scale from sprint to sprint and while doing estimations.
The "real" work
This section is what most folks think of when they think about a software development team. A group of developers that are skilled in writing code in a language or multiple languages and producing a tool/application. But it's more than that, much more. A typical software team will have a list of issues/stories/tasks prioritized and ready for work. Developers will take a task/issue/story to work and go 'head down' into coding the feature/bugfix. Along with the coding the dev should be creating new tests for new code and update existing tests for any code updates. So for any piece of work started there really is a lot of other work already attached to it; code, test, build, code review, merge(version build), deploy. Before any line of code is started the team needs to understand the work! Don't skimp on the Sprint Planning (if doing Scrum) the more discussion in the planning session the less questions should arise during the work cycle. If you have a question about the work ASK NOW there really is no dumb question (as they say) and others might have the same question or worse yet, no one has thought about your specific question and you just saved yourself and the team a lot of heartache later. Read the issues all the way through, sometimes teams get so used to pulling in work into the sprint during planning that they don't go through and review the issue, description, overall goal of work, and the acceptance criteria. Development work is a discipline once you start getting lazy, issues will start arising in other areas of your work. Cut corners and you will feel the pain later. My advise, take the time up front because once you are working on the code you have set the expectation that you(and the team) can accomplish it, if you can't deliver that code on time and in the amount of effort discussed it impacts the whole process.
Deploy
After the code has been written, tested (both with automated and manual testing), reviewed, merged, and version tested... it is time for a production deployment! My biggest advice in this section is if there is anything manual you are doing during your deployment take the TIME AND AUTOMATE. There are CI/CD servers for a reason and it is to make the building and deployment of code consistent. You might be thinking.. O the 2 minutes I take every deployment to run a DB backup script or do the VM snapshot doesn't take long.. It doesn't, but it does take time AND God forbid you forget these steps when deploying. Build them into your deployment plan, if you think they are too complicated to script discuss it with the team. Take those ideas and break them down into their own game-plan on how you can make small changes to improve the overall deployment process. (2 minutes x 52 releases/year = 104 minutes which doesn't sound like much but a lot of shops these days are doing multiple deployments a DAY!)
Another part of the deployment plan should include deployment verification. How is your team verifying the deployment was successful (above the CI/CD saying it was)? Are you doing health monitoring on the server? Are you running a list of tests against the production server to verify API and basic application functionality post deployment?
Feedback!
The job is NOT over after the deployment has been made. There needs to be interaction with the user base to see how the new features have been improving their work life. Did it save them time? Did the feature get delivered the way the user group expected? Or are there a lot of 'this is great but..' conversations happening after deployment. This could point to multiple problems in the overall process. The team needs to identify where the disconnect has happened and fix the problem.
- Was it an issue with requirement documentation? not enough details? Too many details? missing mockups so the user group didn't understand the way a new feature would 'look' before it was delivered?
- Was it an issue during development? Did the developer not understand the requirement?
My advice here for feedback is to bake in as many ways of getting feedback as possible. If using metrics generated by your application is possible use it! Put in counters and controls to tell you what pieces of the application are being used and which ones are sitting collecting dust after a release. If a user base is not using new features after a deployment it could be a matter of the prioritization of the requirements is wrong.. You are delivering things that aren't crucial to the user base. or worse yet, THEY DON"T CARE and you are working on a tool/application that would not be missed if the lights were turned off. The only way to know any of these things is to keep that open line of communication between all the teams, personnel, management, and users. (I also wrote a blog about picking a communication medium everyone can agree on.)
RSS Feed
