Culmination of 20 years of growth and experience from a junior software development engineer up to COO and later Direction of Engineering for an entire site, I have a strong belief that the core of building a great team and delivering above expectations is one thing: values; www.failmasterdiaries.com documents my experiences including some real-life software engineering anecdotes. Enjoy!
Sunday, June 28, 2026
Monday, December 9, 2019
Intermediary sprints
The main goal for a Release sprint is to have a product release in the end, but when we are not yet ready to release then we also have an option to initiate an Interim sprint that will not end in the product release but will instead produce one or more building blocks necessary for the eventual product release.
Interim sprints are used when the team has unknowns ahead and needs to perform analysis, research, learning in order to be able to know how to plan a future Release sprint in details.
Even if the work ahead for the product release is well known but there is too much of it for the team to finish everything in a single max-length 4-week sprint, then having one or more connected Interim sprints is the solution.
Keep in mind that the main expectation for any kind of sprint is to have finite and measurable deliverables in the end which applies to Interim sprints as well. For the Interim sprint the deliverable will not be a product released to production but something smaller - some examples are:
- When looking for the best way to find out how to develop something then do the hands-on approach: develop a prototype or attempt to build a proof of concept
- It is still OK if this Interim sprint deliverable might not be used in the final product in production as long as we learned from the exercise and can now plan enough time to do it right
- It is also OK if the proof of concept turns out to be impossible to build, i.e. due to technical limitations or external constraints that we have now clearly identified and have removed all unknowns from our path
- When fixing a complex issue or optimizing performance we need to plan out enough time to attempt several or all potential fixes or experiments that will lead to resolution or improvements
- It is OK to have limited incremental success here without committing to specific outcome or specific numbers in the end as long as we have systematic progress and can keep stakeholders updated what worked / didn't work
- When researching and need to figure out how comps are doing things, or to learn more about a subject that is new but without possibility to build a tangible prototype even if it is thrown away in the end: it is OK to just do a detailed summary on the subject or ideally a plan on how we'll approach the next Intermediary or Release sprint
How much time can be allocated to an Intermediary sprint?
- Max-length applies to all types of sprints and it can never be longer than 4-weeks
- If multiple Intermediary sprints are needed then it is OK to connect them one after another but with explicitly approved plan on how many such sprints will exist before the next Release sprint
- Sprint planning time for an Intermediary sprint cannot be longer than 1 day
- Remember that if you have unknowns that are to be clarified during the Intermediary sprint then the sprint plan can be somewhat looser, i.e. Team member 1 Day 1, Team member 2 Day 2, etc. but this is an edge case applicable to time-boxed research only - everything else
Monday, December 2, 2019
Product release sprints
1) Sprint planning
- Team has two days max to plan out the new sprint
- This is more than enough time for a quick research of goals ahead and a detailed sprint planning
- Take your time for sprint planning, up to several hours for the entire team is sometimes needed and the entire team needs to be present to take part in sprint planning, this is not something a single person (i.e. ScrumMaster) should do
- In case we have more unknowns then the team should not recommend a Release sprint but rather an Intermediary sprint where the primary goals will be to clarify the unknowns through hands-on proof of concept / prototyping or documented plan / deliverable, or to build necessary prerequisites for the eventual release
2) Sprint
- Maximum sprint duration is still 4 weeks or 20 workdays
- Each Release sprint will be divided into two structured wholes: Work phase and Test plan execution phase
- Maximum time allocated for Work phase shouldn't exceed 3 weeks or 15 workdays
- During this time the team should fix bugs, implement features, and complete other general Product Ownership related goals agreed on sprint start
- Work goals should be made in such a way that we can drop off some of the goals during the sprint and still achieve the release: i.e. drop off some of the planned new features, fix less bugs than planned
- If the team doesn't have a Test plan for the product that is up-to-date then one of the work goals needs to be to update the Test plan: this work is owned by the team SA but needs to get a buy-in from the entire team
- Maximum time allocated for Test plan execution shouldn't exceed 1 week or 5 workdays, and should match Test plan execution time estimate in team days
- During this time the entire team will focus on testing the product build in development by following previously prepared Test plan and by splitting test areas among all team members, both developers and SAs
- Test plan execution is "All Hands on Deck" time meaning that no team member is allowed to work on anything other than executing regression test to figure out quality of the current build
- There is no more "inter-team cross-testing" meaning you shouldn't send your build to other teams or other SAs to test it for you
- This doesn't mean that inter-team cooperation isn't allowed - actually it is still a good thing to do cross-testing with other teams especially when other teams are relying on your products and may be affected with the new release
- Devs must still execute "internal cross-testing" and verify each other's bug fixes (i.e. Dev1 tests bug fixes for Dev2, Dev2 for Dev3, Dev3 for Dev1 and final report is sent to SA)
- When the sprint ends the team will figure out how many bugs were found that SA will report in the bug tracker, and will estimate how much actual work remains to release the product
- Not all bugs found are blocking bugs (more on this soon)
- We just need blocking bugs fixed in order to release the product
- At this point the team will know if blocking bugs can be fixed within the Release phase time (see below) or not and will decide one of two things: we are going to release or we need to start a new release sprint in order to fix remaining blocking bugs that will take more than one week's time
- We need to watch out not to begin Release phase if we are uncertain that the remaining blocking bugs can be fixed within the allotted time: it is of no consequence to begin a new Release sprint, but there will be many affected stakeholders if we decide to enter the Release phase and fail to release on time
3) Release phase
- This is instead of what was previously known as "Test phase" but with main difference being that we are no longer spending time to test the product build for the first time but are focusing entire team efforts to release the product
- Release phase can take up to 6 days including the release day which is also considered the first day of the new sprint planning phase
- SAs no longer invest time into test plan or bug prospecting efforts as this is supposed to be already finished during the sprint
- Devs fix only blocking bugs and nothing else
- SAs verify fixed bugs only until we ensure there are no more blocking bugs
- Remember: the ultimate goal is to release a build that is equal or better in quality than the current one in production, nothing more, nothing less
Saturday, February 3, 2018
Customer correspondence 101
Customers are generally satisfied with both our service coming from Sales consultants (SCs) and our technical support from Support engineers (SEs). However it still happens from time to time we drop the ball on some cases and run into issues between teams which shouldn't happen
Our goal must always be a satisfied customer and that's the only proof that shows we're handling our business correctly and are doing our job well
Below are listed a few important things that you should already know, but please make sure to read them carefully again and implement them in all future cases:
- SCs job and responsibility is to forward customer emails who have technical questions/issues to the support team and follow up on the progress early and often to make sure a customer got all the answers and the help he needed
- SEs job and responsibility is to include corresponding SC in all conversations they have with the specific customer and to also let SCs know when the support job is done; although SCs won't participate in this "technical part", they will see the progress of the case and will be able to plan their future activities
- SC responsibility is to make sure a customer always gets what he needs (a technical support, a quote, respond to a specific question, etc.)
- SEs - during the business hours (M-F 8-5 US ET), we should acknowledge all emails within an hour, provide actionable response within 24 hours and have a resolution within 72 hours
-- If we get an email after business hours, SE on duty should ACK email, while the product owning SE should provide actionable response on the next business day
-- Here it is very important to know that if the SE on the job doesn't know the answer to some question or he is not sure about something, ignoring an email until he gets an answer *is not an option*; SE must reply (ACK email) and provide an ETA when more details will be provided
- SCs – during the business hours, we should acknowledge all emails within 15 mins and provide actionable response within an hour; if the assigned SC finished the shift and a customer sends an email, a colleague from the team should respond and provide all necessary details
- Not responding to customer emails and not following the rules above is not an option; we need to be responsive to our clients and honor the things we put on our website such as our availability and resolution times
-- If we don't honor our commitment it creates dissatisfaction for our clients that has already in several cases directly or indirectly influenced client's decision to purchase our products
- After the customers purchase our products our job is not done – we still need to care about their satisfaction and to make sure we solve all the problems they run into
-- If we can't solve a problem immediately we can at least be responsive to provide all the info and all the help that we can to at least workaround an issue or provide an ETA for full resolution
- When replying to customer's email, it's desirable to always have following guidelines on your mind:
-- Read every email twice very carefully, and then once again
-- Make sure to provide an answer to every question a customer asks
-- Reply inline and use a different color (except red)
-- If you don't have an immediate resolution, make sure to provide an ETA to the customer for the question or issue he/she has reported
-- Always provide an ETA for the next step if the ball is in our court; if we miss that ETA for whatever reason then follow-up to provide a new ETA without forcing customers to follow-up first
Our goal must always be a satisfied customer and that's the only proof that shows we're handling our business correctly and are doing our job well
Below are listed a few important things that you should already know, but please make sure to read them carefully again and implement them in all future cases:
- SCs job and responsibility is to forward customer emails who have technical questions/issues to the support team and follow up on the progress early and often to make sure a customer got all the answers and the help he needed
- SEs job and responsibility is to include corresponding SC in all conversations they have with the specific customer and to also let SCs know when the support job is done; although SCs won't participate in this "technical part", they will see the progress of the case and will be able to plan their future activities
- SC responsibility is to make sure a customer always gets what he needs (a technical support, a quote, respond to a specific question, etc.)
- SEs - during the business hours (M-F 8-5 US ET), we should acknowledge all emails within an hour, provide actionable response within 24 hours and have a resolution within 72 hours
-- If we get an email after business hours, SE on duty should ACK email, while the product owning SE should provide actionable response on the next business day
-- Here it is very important to know that if the SE on the job doesn't know the answer to some question or he is not sure about something, ignoring an email until he gets an answer *is not an option*; SE must reply (ACK email) and provide an ETA when more details will be provided
- SCs – during the business hours, we should acknowledge all emails within 15 mins and provide actionable response within an hour; if the assigned SC finished the shift and a customer sends an email, a colleague from the team should respond and provide all necessary details
- Not responding to customer emails and not following the rules above is not an option; we need to be responsive to our clients and honor the things we put on our website such as our availability and resolution times
-- If we don't honor our commitment it creates dissatisfaction for our clients that has already in several cases directly or indirectly influenced client's decision to purchase our products
- After the customers purchase our products our job is not done – we still need to care about their satisfaction and to make sure we solve all the problems they run into
-- If we can't solve a problem immediately we can at least be responsive to provide all the info and all the help that we can to at least workaround an issue or provide an ETA for full resolution
- When replying to customer's email, it's desirable to always have following guidelines on your mind:
-- Read every email twice very carefully, and then once again
-- Make sure to provide an answer to every question a customer asks
-- Reply inline and use a different color (except red)
-- If you don't have an immediate resolution, make sure to provide an ETA to the customer for the question or issue he/she has reported
-- Always provide an ETA for the next step if the ball is in our court; if we miss that ETA for whatever reason then follow-up to provide a new ETA without forcing customers to follow-up first
Monday, January 22, 2018
Support engineer medior - Level 2
The path to Support engineer Level 1 or "SE certification" as we commonly call it is relatively straightforward:
a) Get to 100% unified metrics in at least 3 consecutive months:
-- ZIGS 100% - easy enough with majority of our products, just be as hard on them as possible
-- Writing 100% - this is the most challenging part as it requires constant learning and systematic weekly writing ideally without ups and downs
-- Support coverage divided between colleagues and following The Support Engineer’s Creed
b) Contribute to your team by helping them own all of the content
c) Contribute the team with product ownership - comp analysis
d) Cover the operational work of getting the products through the testing and out to production
When you have the metrics and both your team and internal customers provide good values feedback you are all set for Level 1 certification - on average this takes 9-12 months but we did have some cases (one of them only a few months back) of certifying in 6 months flat
SE Level 2 shares all of the requirements with SE Level 1 except that metric requirements are higher
However simply achieving higher SE metrics won't be enough to get certified for SE Level 2 as the standards for contributing to the team and the company are also higher - meeting those standards is a requirement for a positive Level 2 values review by stakeholders and internal customers
Standards
Here are some specific examples of higher standards expected from SE Level 2:
1) QA - as level description also says:
-- Provide real-world testing vs. just some easy to catch surface bugs or edge cases by pounding your mouse and keyboard until something breaks
-- Be an advocate for automation vs. allowing others to ask for test automation from your team
-- Plan your work and be meticulous with regression testing, never allow the same bug to resurface in production
-- Know your products performance, usability (UX especially) and quality and raise issues vigorously and frequently; don't allow customers or others within the company to do this for you
2) TQM - keep owning the content including everything you previously wrote and is available in production as it must be kept up-to-date
3) Earn the respect of your team:
-- DON'T keep quiet and allow for known issues to go unchallenged
-- DON'T be stubborn and insist on low-ROI fixes and changes
-- DO stand your ground when you know and have the facts that the issue you raised is valid and important to the customers
4) Lead or assist with company-wide initiatives
-- Update and create standards that affect multiple products
-- Raise issues with content and products owned by other teams
Time period
Expected time period to gain the necessary experience for SE Level 2 from day one on the job is at least 3 years
This depends on each person individually but if you started working without previous database administration / development industry experience then you can consider yourself a fast learner if you certify as soon as you hit this mark
No regression
More so with SEs than with other roles, regression is an automatic process based on metrics
This also means that you can't regress when it comes to values and contribution you had in order to achieve Level 1 and must keep hitting the high notes most of the time
Hard skills
This will come naturally with experience through the creation of new content, real-life use case testing, test automation, and other work
Being T-SQL guru or knowing secrets of SQL Server and cloud administration isn't the goal, but knowing your owned products well and related technologies is
Ultimate test
Success = results / time / stakeholder_time
Note the last variable in this equation: stakeholder time
Ask yourself how much time do you save to stakeholders?
a) Are you being reminded to update owned content (roadmaps, articles, videos)
b) Are others in the company raising endemics and red flags in your products
c) Do stakeholders have to invest much time in order to review your content (articles, release notes, F matrices, etc)
d) Are you being asked questions about the team status that catch you by surprise
e) Are you unable to answer a functional question related with the owned product
f) Are you unaware of a comp status or a melting iceberg affecting your team
g) Is your view of the product PUQ different from reality
h) Have you recently approached product development and design like a "coder" instead of a customer
If you've answered any of the above with a Yes then that is a potential blocker you need to remedy
a) Get to 100% unified metrics in at least 3 consecutive months:
-- ZIGS 100% - easy enough with majority of our products, just be as hard on them as possible
-- Writing 100% - this is the most challenging part as it requires constant learning and systematic weekly writing ideally without ups and downs
-- Support coverage divided between colleagues and following The Support Engineer’s Creed
b) Contribute to your team by helping them own all of the content
c) Contribute the team with product ownership - comp analysis
d) Cover the operational work of getting the products through the testing and out to production
When you have the metrics and both your team and internal customers provide good values feedback you are all set for Level 1 certification - on average this takes 9-12 months but we did have some cases (one of them only a few months back) of certifying in 6 months flat
SE Level 2 shares all of the requirements with SE Level 1 except that metric requirements are higher
However simply achieving higher SE metrics won't be enough to get certified for SE Level 2 as the standards for contributing to the team and the company are also higher - meeting those standards is a requirement for a positive Level 2 values review by stakeholders and internal customers
Standards
Here are some specific examples of higher standards expected from SE Level 2:
1) QA - as level description also says:
-- Provide real-world testing vs. just some easy to catch surface bugs or edge cases by pounding your mouse and keyboard until something breaks
-- Be an advocate for automation vs. allowing others to ask for test automation from your team
-- Plan your work and be meticulous with regression testing, never allow the same bug to resurface in production
-- Know your products performance, usability (UX especially) and quality and raise issues vigorously and frequently; don't allow customers or others within the company to do this for you
2) TQM - keep owning the content including everything you previously wrote and is available in production as it must be kept up-to-date
3) Earn the respect of your team:
-- DON'T keep quiet and allow for known issues to go unchallenged
-- DON'T be stubborn and insist on low-ROI fixes and changes
-- DO stand your ground when you know and have the facts that the issue you raised is valid and important to the customers
4) Lead or assist with company-wide initiatives
-- Update and create standards that affect multiple products
-- Raise issues with content and products owned by other teams
Time period
Expected time period to gain the necessary experience for SE Level 2 from day one on the job is at least 3 years
This depends on each person individually but if you started working without previous database administration / development industry experience then you can consider yourself a fast learner if you certify as soon as you hit this mark
No regression
More so with SEs than with other roles, regression is an automatic process based on metrics
This also means that you can't regress when it comes to values and contribution you had in order to achieve Level 1 and must keep hitting the high notes most of the time
Hard skills
This will come naturally with experience through the creation of new content, real-life use case testing, test automation, and other work
Being T-SQL guru or knowing secrets of SQL Server and cloud administration isn't the goal, but knowing your owned products well and related technologies is
Ultimate test
Success = results / time / stakeholder_time
Note the last variable in this equation: stakeholder time
Ask yourself how much time do you save to stakeholders?
a) Are you being reminded to update owned content (roadmaps, articles, videos)
b) Are others in the company raising endemics and red flags in your products
c) Do stakeholders have to invest much time in order to review your content (articles, release notes, F matrices, etc)
d) Are you being asked questions about the team status that catch you by surprise
e) Are you unable to answer a functional question related with the owned product
f) Are you unaware of a comp status or a melting iceberg affecting your team
g) Is your view of the product PUQ different from reality
h) Have you recently approached product development and design like a "coder" instead of a customer
If you've answered any of the above with a Yes then that is a potential blocker you need to remedy
Monday, October 31, 2016
Software developer on steroids - Level 2
Getting from a Jr. Software developer to Software developer Level 1 might have seemed like a long way to go but this is just the first step for a Software developer career in ApexSQL and all the future steps have even steeper learning and growth curve
If you've certified as a Level 1 dev then it means:
a) You've been working in a fully functional team the company can rely on
b) Have been a leader at least for a specific task or a goal within the team to carry your own weight
c) Have gained enough experience with how we work and have already mentored other colleagues or can do so now
d) You've grown and developed your hard skills just enough so that for any new challenges you encounter you already know how to approach resolving them even when it requires more learning
e) You are successfully saving time to stakeholders and are working with them vs. working for them or thinking there is us-and-them
Time period
How long will it take to get from the day 1 in ApexSQL to a Software developer Level 2 will depend on each person individually - if you started as a Jr. Software developer (Level 0) then you'll need at least 3.5 to 4 years to be able to check off all of the items below
No regression
The first expectation is that you constantly confirm the level you're currently at which means you don't regress by no longer doing the work you were successfully doing before, or by doing it slower (i.e. you caught lazies)
If you had regression in your performance then it is critical to first make sure you get back on track and have consistent high performance of at least 3 or more months in a row - not doing so risks actual regression back to a Level 0
Soft skills + 1
When doing a Level 2 values review expectations will be one step higher than those for a Level 1 performance review
If you had a "Needs improvement" score for any of the values but have still managed to certify for Level 1 then those values if not improved in the meantime will read as "Unsatisfactory" during the Level 2 review which is a showstopper
If you had a "Meets expectations" score for a value then you need to have displayed consistent or improved values match in order to keep reading "Meets expectations" for the Level 2
Hard skills++;
Jr. Software developers can best testify the amount of new development knowledge and skills gained when going from Level 0 to Level 1 - the same goes for a Level 1 dev aiming to certify as Level 2
Each team has a bit different hard skills requirements depending on the owned product set so the only common metric here is how have those hard skills helped you be more efficient during work
Success = results / time;
The better hard skills you gained then you'll contribute to your team with more results over less time
Value added time saver
Can you confirm all of this:
1) Are you self-sufficient enough so that others don't need to "manage" you by asking questions and giving directions / frequently correct you
2) Do you communicate proactively and in an actionable manner with the stakeholders / no surprises caused by you and your team
3) Do you educate stakeholders and provide suggestions and guidance yourself
4) Can you be a role model for all Software developer Level 1 peers
Achievements
Additional information we should put on a table before starting the perf review for Level 2 is the list of achievements you can brag about since you've certified for Level 1
If you don't have anything exceptional to show for as a Level 1 dev then how can you justify you have earned the next level
This is also a great personal litmus test you can do for yourself before reaching out - are you able to provide a list of at least three achievements that you are proud of during your Level 1 tenure?
But don't say that i.e. you're proud of showing up for work every day or that you've managed to complete 3 sprints in a row as these are just normal everyday expectations so you won't be doing yourself a favor
For example:
a) Took initiative to build a component / engine / feature which helped the team by ...
b) Improved communication of the team with the stakeholders
c) Helped the team achieve PUQ superiority by fixing X bugs in Y time / by improving performance by x% / by identifying and fixing usability issues
d) Mentored new colleagues so that they have achieved ...
e) Suggested [and helped implement] a feature / functionality that directly helped with Platinum goal
f) Successfully managed X subcontracted projects
g) Worked with team SEs to ensure uninterrupted team content flow
h) Took ownership of a standard and helped everyone enforce it
Also such achievements are good to have but aren't the ones we're looking for:
a) Learned to write thread safe code like a boss - good for you
b) Read 3 books on design patterns - congrats
c) Went to a .NET conference - nice
d) Learned angular / js / css - great if it'll help you get the job done, but the focus is on the achievements that are "done" and have directly helped with your team and the company goals
If you've certified as a Level 1 dev then it means:
a) You've been working in a fully functional team the company can rely on
b) Have been a leader at least for a specific task or a goal within the team to carry your own weight
c) Have gained enough experience with how we work and have already mentored other colleagues or can do so now
d) You've grown and developed your hard skills just enough so that for any new challenges you encounter you already know how to approach resolving them even when it requires more learning
e) You are successfully saving time to stakeholders and are working with them vs. working for them or thinking there is us-and-them
Time period
How long will it take to get from the day 1 in ApexSQL to a Software developer Level 2 will depend on each person individually - if you started as a Jr. Software developer (Level 0) then you'll need at least 3.5 to 4 years to be able to check off all of the items below
No regression
The first expectation is that you constantly confirm the level you're currently at which means you don't regress by no longer doing the work you were successfully doing before, or by doing it slower (i.e. you caught lazies)
If you had regression in your performance then it is critical to first make sure you get back on track and have consistent high performance of at least 3 or more months in a row - not doing so risks actual regression back to a Level 0
Soft skills + 1
When doing a Level 2 values review expectations will be one step higher than those for a Level 1 performance review
If you had a "Needs improvement" score for any of the values but have still managed to certify for Level 1 then those values if not improved in the meantime will read as "Unsatisfactory" during the Level 2 review which is a showstopper
If you had a "Meets expectations" score for a value then you need to have displayed consistent or improved values match in order to keep reading "Meets expectations" for the Level 2
Hard skills++;
Jr. Software developers can best testify the amount of new development knowledge and skills gained when going from Level 0 to Level 1 - the same goes for a Level 1 dev aiming to certify as Level 2
Each team has a bit different hard skills requirements depending on the owned product set so the only common metric here is how have those hard skills helped you be more efficient during work
Success = results / time;
The better hard skills you gained then you'll contribute to your team with more results over less time
Value added time saver
Can you confirm all of this:
1) Are you self-sufficient enough so that others don't need to "manage" you by asking questions and giving directions / frequently correct you
2) Do you communicate proactively and in an actionable manner with the stakeholders / no surprises caused by you and your team
3) Do you educate stakeholders and provide suggestions and guidance yourself
4) Can you be a role model for all Software developer Level 1 peers
Achievements
Additional information we should put on a table before starting the perf review for Level 2 is the list of achievements you can brag about since you've certified for Level 1
If you don't have anything exceptional to show for as a Level 1 dev then how can you justify you have earned the next level
This is also a great personal litmus test you can do for yourself before reaching out - are you able to provide a list of at least three achievements that you are proud of during your Level 1 tenure?
But don't say that i.e. you're proud of showing up for work every day or that you've managed to complete 3 sprints in a row as these are just normal everyday expectations so you won't be doing yourself a favor
For example:
a) Took initiative to build a component / engine / feature which helped the team by ...
b) Improved communication of the team with the stakeholders
c) Helped the team achieve PUQ superiority by fixing X bugs in Y time / by improving performance by x% / by identifying and fixing usability issues
d) Mentored new colleagues so that they have achieved ...
e) Suggested [and helped implement] a feature / functionality that directly helped with Platinum goal
f) Successfully managed X subcontracted projects
g) Worked with team SEs to ensure uninterrupted team content flow
h) Took ownership of a standard and helped everyone enforce it
Also such achievements are good to have but aren't the ones we're looking for:
a) Learned to write thread safe code like a boss - good for you
b) Read 3 books on design patterns - congrats
c) Went to a .NET conference - nice
d) Learned angular / js / css - great if it'll help you get the job done, but the focus is on the achievements that are "done" and have directly helped with your team and the company goals
The art of specs
In the initial The art of subcontracting article we've covered in short differences between functional/technical and requirements/specification
When preparing initial documents to describe a subcontracting project we have 4 distinct levels of documentation "depth" where each is more detailed than the previous one - and you don't necessarily need to document everything down to the lowest level in order to have a successful project
Level 1: User stories
User stories are a great way to abstract yourself from the technical minutia and to define top-level goals for the subcontracting project - they are the answers to "What?"
User story is a one-liner where you can describe your project goals to a person who is seeing the project for the first time and has no idea what you want to accomplish - never allow subcontractors to figure this out for themselves
Also a user story will make sure that the user (you) achieves clarity about the project goals before going down the rabbit hole
User story has a few elements:
a) "As a user" - this puts you in the proper set of shoes on start as you are the user
b) "of the <final deliverable>" - clarify what is the expected end deliverable of the project: an app, a component, an engine, documentation, specs, etc.
c) "I want to be able to <functional goal>" - one desired project use case
Some examples:
As a user of the application I want to be able to... (one goal what you want the application to cover, i.e. allow for browsing database encrypted objects, to be able to easily decrypt database objects)
As a user of the component I want to be able to... (visually view database objects in a form of a graph, manipulate database objects as a graph)
As a user of the engine I want to be able to... (access all of SQL Server instance properties in an object model form)
As a user of the functional specification I want to be able to... (have a detailed functional requirements breakdown for the engine mentioned above).
This specific user story is great for when creating specs-for-specs (see appendix)
As a user of the automated test I want to be able to...
All but the simplest projects will have more than one user story defined - i.e. one user story per needed application/engine feature
Level 2: Functional requirements breakdown
Once user stories are defined they can now be broken down into individual and more detailed functional requirements
Functional requirement is a free-form short description that further explains a user story
To breakdown a single user story "As a user of the visual component I want to be able to view database objects as a graph":
a) Each object type should be visually represented with a different geometrical shape
b) Related objects should be interconnected using lines
c) We should have several predefined presets / algorithms for object layouts
...
Functional requirements are short and don't go into details, i.e. what kind of geometrical shape should be applied to what type of object, how will object name be displayed, color of the shape, etc.
It is critical to invest as much time as needed to define all functional requirements that we need on start.
If we uncover that we've missed to define a functional requirement during the project then all such burden of additional requirements will fall down on us (as project appendixes that bear additional costs)
Level 3: Functional specification
Each of the individual functional requirements can be further broken down to create a functional specification / functional details
Consider each of the functional requirements as a new paragraph or a separate section with a freedom to go into all the tiny details
A section "Representing object types visually" can have:
a) A mockup / picture of a representative object type
b) List of default geometrical shapes, colors, text
c) List of configurable elements, and all required shapes to be available
...
Drawing up a good functional specification is very time-demanding and depending on the project scale and complexity it can be wise to consider subcontracting this work (see appendix)
Level 4: Technical specification
The lowest level of a subcontracting document is technical specs which can be more or less detailed, or can be skipped altogether
Almost every development subcontract will have some basic technical requirements in a form of required development technology, coding standards, etc.
Anything more than that is very risky as it effectively spoon-feeds the subcontractor and requires a lot of micromanagement time on your side thus making it questionable whether you should've worked on the project by yourself from the start
A good rule of thumb is to avoid technical specification whenever possible, or if really needed have subcontractors work on it prior to beginning any actual implementation/development work
For specific projects where it is important to go down to tech spec details level, try to keep it as short as possible
Appendix - Specs for specs
The main goal of subcontracting is to help you achieve team goals as quickly as possible (success = results / time)
Smart product teams will keep this in mind at all times and will not replace their development time with spec writing time
A smart product team will spin off subcontracting projects by focusing on writing up Level 1 (user stories) and Level 2 (functional requirements) subcontracting documentation
As such you can have subcontractors write Level 3 and Level 4 (functional and technical specification) documents themselves which you can later review and approve prior to starting the implementation
a) Know thy comps - research and figure out in details who we want to better / what we want to achieve
b) Know thy goals - write up good user stories by yourself what we want to achieve (Level 1)
c) Know thy needs - write up all functional requirements (Level 2)
d) Make it so - have subcontractors do the remaining work by writing the remainder of the project documentation prior to implementation
When preparing initial documents to describe a subcontracting project we have 4 distinct levels of documentation "depth" where each is more detailed than the previous one - and you don't necessarily need to document everything down to the lowest level in order to have a successful project
Level 1: User stories
User stories are a great way to abstract yourself from the technical minutia and to define top-level goals for the subcontracting project - they are the answers to "What?"
User story is a one-liner where you can describe your project goals to a person who is seeing the project for the first time and has no idea what you want to accomplish - never allow subcontractors to figure this out for themselves
Also a user story will make sure that the user (you) achieves clarity about the project goals before going down the rabbit hole
User story has a few elements:
a) "As a user" - this puts you in the proper set of shoes on start as you are the user
b) "of the <final deliverable>" - clarify what is the expected end deliverable of the project: an app, a component, an engine, documentation, specs, etc.
c) "I want to be able to <functional goal>" - one desired project use case
Some examples:
As a user of the application I want to be able to... (one goal what you want the application to cover, i.e. allow for browsing database encrypted objects, to be able to easily decrypt database objects)
As a user of the component I want to be able to... (visually view database objects in a form of a graph, manipulate database objects as a graph)
As a user of the engine I want to be able to... (access all of SQL Server instance properties in an object model form)
As a user of the functional specification I want to be able to... (have a detailed functional requirements breakdown for the engine mentioned above).
This specific user story is great for when creating specs-for-specs (see appendix)
As a user of the automated test I want to be able to...
All but the simplest projects will have more than one user story defined - i.e. one user story per needed application/engine feature
Level 2: Functional requirements breakdown
Once user stories are defined they can now be broken down into individual and more detailed functional requirements
Functional requirement is a free-form short description that further explains a user story
To breakdown a single user story "As a user of the visual component I want to be able to view database objects as a graph":
a) Each object type should be visually represented with a different geometrical shape
b) Related objects should be interconnected using lines
c) We should have several predefined presets / algorithms for object layouts
...
Functional requirements are short and don't go into details, i.e. what kind of geometrical shape should be applied to what type of object, how will object name be displayed, color of the shape, etc.
It is critical to invest as much time as needed to define all functional requirements that we need on start.
If we uncover that we've missed to define a functional requirement during the project then all such burden of additional requirements will fall down on us (as project appendixes that bear additional costs)
Level 3: Functional specification
Each of the individual functional requirements can be further broken down to create a functional specification / functional details
Consider each of the functional requirements as a new paragraph or a separate section with a freedom to go into all the tiny details
A section "Representing object types visually" can have:
a) A mockup / picture of a representative object type
b) List of default geometrical shapes, colors, text
c) List of configurable elements, and all required shapes to be available
...
Drawing up a good functional specification is very time-demanding and depending on the project scale and complexity it can be wise to consider subcontracting this work (see appendix)
Level 4: Technical specification
The lowest level of a subcontracting document is technical specs which can be more or less detailed, or can be skipped altogether
Almost every development subcontract will have some basic technical requirements in a form of required development technology, coding standards, etc.
Anything more than that is very risky as it effectively spoon-feeds the subcontractor and requires a lot of micromanagement time on your side thus making it questionable whether you should've worked on the project by yourself from the start
A good rule of thumb is to avoid technical specification whenever possible, or if really needed have subcontractors work on it prior to beginning any actual implementation/development work
For specific projects where it is important to go down to tech spec details level, try to keep it as short as possible
Appendix - Specs for specs
The main goal of subcontracting is to help you achieve team goals as quickly as possible (success = results / time)
Smart product teams will keep this in mind at all times and will not replace their development time with spec writing time
A smart product team will spin off subcontracting projects by focusing on writing up Level 1 (user stories) and Level 2 (functional requirements) subcontracting documentation
As such you can have subcontractors write Level 3 and Level 4 (functional and technical specification) documents themselves which you can later review and approve prior to starting the implementation
a) Know thy comps - research and figure out in details who we want to better / what we want to achieve
b) Know thy goals - write up good user stories by yourself what we want to achieve (Level 1)
c) Know thy needs - write up all functional requirements (Level 2)
d) Make it so - have subcontractors do the remaining work by writing the remainder of the project documentation prior to implementation
Friday, October 14, 2016
Jr. Software developer trial period breakdown
Trial period length
Jr. Software developers have the longest trial period when compared to all other roles at ApexSQL
Many of the guys who start at this entry level position have no previous work experience or at least no experience in software development jobs, and have a limited hard skills set
Improving hard skills and earning experience is only possible through actual work by developing products and taking part in ideally every step of the product new version life cycle covering the concept, analysis, roadmap, design, development, testing, release, and agile support
ApexSQL is made of guys who are dedicated and see themselves in the IT battle trenches for years to come by sharing both success and failure with the rest of the company
How long it will be until you complete the trial period it'll mostly depend directly of you, and of your team, but specifically trial period for Jr. devs with no previous experience is usually 9-12 months and depends on your growth curve, team achievements, and individual results
Specific requirements
0) To even start talking about successful end-of-trial it is mandatory for all our devs to read in full and to share on the subject of The Inmates Are Running the Asylum book.
This step is also a prerequisite for any software design and usability improvement discussions / tasks
1) The first step of each performance review is that the team (a product team consists of both devs and Support engineers) must have a good standing and good results at least for the past 3 months.
This comes down to successful ownership of team products by:
a) Having good team transparency: no surprises for stakeholders; share proactively - raise suggestions vs. asking questions or providing one-sided decisions
b) Don't expect to be told what to do and don't allow to be asked what you're doing - if someone asks for an update then it is already too late
c) Ideally have a few product releases under your belt - not all teams have this but it is a good achievement to have if applicable
d) Uninterrupted new content flow - this part is owned by team SEs but if they get stuck it will come down to devs in the team to help out even though we'd like to avoid this as devs should focus on development work
2) The second step of the perf review is to have good individual results that speak for you and to actually own some team goals.
One option is to became a go-to guy in the team for a specific area, to directly contribute to your team through learning and sharing about a specific area, subcontract management, QA and test automation, development/implementation of a specific engine or technology, or something else.
This doesn't mean to isolate other team members from an area of code or to work alone in isolation as that should never happen, but instead take ownership of a goal within the team and with the help and collaboration from the team you complete it from start to finish
And most importantly share regularly about your team and individual achievements and progress - don't expect someone will be spying on you or monitoring your every step; no one will notice if you don't share for yourself
Also don't hide behind other team members - there's no such thing as a team lead in ApexSQL or a team PR
Owning a goal means you won't wait on everything to be reviewed by everyone else in the team and to reach a "consensus" - help is welcome and collaboration is good, but you should never wait on anything or anyone and should take full responsibility for the goals you own
3) The third step is values review from peers, mentors, colleagues, stakeholders - just read our Working Naked values statement and let me know if you have any questions
4) The final match-80%-of-job-level-requirements step is not required for a successful end of trial for devs as certifying for Software developer Level 1 requires even more battlefield experience and hard skills which can be ideally achieved in the next 6-12 months at most
Benefits
Upon successful end-of-trial performance review Jr. Software developers remain Jr. devs (Level 0) but gain paid vacation time proportionally for the given year, and are paid during the month for the ongoing month (vs. at the end of month)
Later on when you finally certify for a Software developer Level 1 it comes with commensurate increase in salary, and depending on the current company policy also covered local contractor monthly taxes and insurances
On the right track
Ask yourself:
A) Is my team proactive enough, do we get many questions from stakeholders or we're able to anticipate questions by regular sharing of our status, plans, and recommendations
B) Are we sprinting regularly in the team, learning from our failed sprints, and doing everything we can in order to succeed each of the team sprints
C) Am I contributing in my team by sharing responsibilities with my colleagues without skipping out
D) Am I there for my team members when the going gets tough
E) Am I sharing regularly with the stakeholders for both my team and myself, or am I expecting that others in the team will be sharing for me
F) Are we (devs) helping our team SEs with customer support and with content. How is my team SE doing right now
G) How much did our team and I contribute to the company when compared to other Jr. Software developer teams / individual devs
H) Am I repeating mistakes or am I learning each day so that my next day is always better than the previous one
What next
Reach out to HR and/or Facilitators whenever you have any doubts or when you lack feedback
Otherwise we'll keep an eye out and touch base when we consider you ready for a potentially positive first performance review
Jr. Software developers have the longest trial period when compared to all other roles at ApexSQL
Many of the guys who start at this entry level position have no previous work experience or at least no experience in software development jobs, and have a limited hard skills set
Improving hard skills and earning experience is only possible through actual work by developing products and taking part in ideally every step of the product new version life cycle covering the concept, analysis, roadmap, design, development, testing, release, and agile support
ApexSQL is made of guys who are dedicated and see themselves in the IT battle trenches for years to come by sharing both success and failure with the rest of the company
How long it will be until you complete the trial period it'll mostly depend directly of you, and of your team, but specifically trial period for Jr. devs with no previous experience is usually 9-12 months and depends on your growth curve, team achievements, and individual results
Specific requirements
0) To even start talking about successful end-of-trial it is mandatory for all our devs to read in full and to share on the subject of The Inmates Are Running the Asylum book.
This step is also a prerequisite for any software design and usability improvement discussions / tasks
1) The first step of each performance review is that the team (a product team consists of both devs and Support engineers) must have a good standing and good results at least for the past 3 months.
This comes down to successful ownership of team products by:
a) Having good team transparency: no surprises for stakeholders; share proactively - raise suggestions vs. asking questions or providing one-sided decisions
b) Don't expect to be told what to do and don't allow to be asked what you're doing - if someone asks for an update then it is already too late
c) Ideally have a few product releases under your belt - not all teams have this but it is a good achievement to have if applicable
d) Uninterrupted new content flow - this part is owned by team SEs but if they get stuck it will come down to devs in the team to help out even though we'd like to avoid this as devs should focus on development work
2) The second step of the perf review is to have good individual results that speak for you and to actually own some team goals.
One option is to became a go-to guy in the team for a specific area, to directly contribute to your team through learning and sharing about a specific area, subcontract management, QA and test automation, development/implementation of a specific engine or technology, or something else.
This doesn't mean to isolate other team members from an area of code or to work alone in isolation as that should never happen, but instead take ownership of a goal within the team and with the help and collaboration from the team you complete it from start to finish
And most importantly share regularly about your team and individual achievements and progress - don't expect someone will be spying on you or monitoring your every step; no one will notice if you don't share for yourself
Also don't hide behind other team members - there's no such thing as a team lead in ApexSQL or a team PR
Owning a goal means you won't wait on everything to be reviewed by everyone else in the team and to reach a "consensus" - help is welcome and collaboration is good, but you should never wait on anything or anyone and should take full responsibility for the goals you own
3) The third step is values review from peers, mentors, colleagues, stakeholders - just read our Working Naked values statement and let me know if you have any questions
4) The final match-80%-of-job-level-requirements step is not required for a successful end of trial for devs as certifying for Software developer Level 1 requires even more battlefield experience and hard skills which can be ideally achieved in the next 6-12 months at most
Benefits
Upon successful end-of-trial performance review Jr. Software developers remain Jr. devs (Level 0) but gain paid vacation time proportionally for the given year, and are paid during the month for the ongoing month (vs. at the end of month)
Later on when you finally certify for a Software developer Level 1 it comes with commensurate increase in salary, and depending on the current company policy also covered local contractor monthly taxes and insurances
On the right track
Ask yourself:
A) Is my team proactive enough, do we get many questions from stakeholders or we're able to anticipate questions by regular sharing of our status, plans, and recommendations
B) Are we sprinting regularly in the team, learning from our failed sprints, and doing everything we can in order to succeed each of the team sprints
C) Am I contributing in my team by sharing responsibilities with my colleagues without skipping out
D) Am I there for my team members when the going gets tough
E) Am I sharing regularly with the stakeholders for both my team and myself, or am I expecting that others in the team will be sharing for me
F) Are we (devs) helping our team SEs with customer support and with content. How is my team SE doing right now
G) How much did our team and I contribute to the company when compared to other Jr. Software developer teams / individual devs
H) Am I repeating mistakes or am I learning each day so that my next day is always better than the previous one
What next
Reach out to HR and/or Facilitators whenever you have any doubts or when you lack feedback
Otherwise we'll keep an eye out and touch base when we consider you ready for a potentially positive first performance review
Friday, June 17, 2016
The art of project management
Ok, so you've figured out what work to subcontract and have found a potential freelancer who will consider doing the work - congrats on learning the art of subcontracting basics, now comes the actual project management
As we already determined that every member of our product team is not just a PO but also a PM, below are a few PM operational algorithms that will help you to ensure your project is successful
Project takeoff
1) When you have project specs vetted by the team (SSE, devs, others as needed), send the specs to the selected tried out subcontractor, or send the specs to Ops for assistance in finding a subcontractor with the best bid
2) Subcontractor will usually have some questions about the project specs before providing work estimates
a) If the answers to the questions are already covered in the specs that means the subcontractors didn't bother to read through the specs and you can dismiss them
b) If there are no questions at all or no questions you hoped to hear then make sure to ask a few "control" questions of your own, i.e.: how do you plan to implement something, what do you suggest for a solution for this problem, which technology will you use to accomplish this, did you work on a similar project before, etc.
c) If you get some very basic questions about the project that should've been covered by the specs already that means that the specs aren't good enough and my suggestion is that you don’t waste time in ad-hoc discussion with the subcontractor but go back to step 1) to rewrite/update the specs to cover all important information and then send the new specs to the subcontractor
3) After the subcontractor provides work estimates and project ETA, perform a sanity check
a) If you don't agree with some of the estimates don't challenge them directly but simply ask for a more detailed breakdown and explanation how did they come up with such an estimate
b) Be constructive when talking with subcontractors, it isn't your goal to reduce the estimates but to make sure both sides are fair and professional: you are an employer but you need to treat your subcontractor as your partner
4) Once the project estimates are good define project milestones as these are critical steps along the way that will allow you to track the progress and to avoid situation where you reach the project deadline and figure out it isn't done right
a) Although we don't pay out $ when a project isn't done or done right, we still have growing opportunity cost caused by the delays which can be greater than the actual project cost
b) Each project can be broken down into several milestones with no exceptions (like a sprint PBI can always be broken down into smaller tasks)
5) Get in touch with Ops for assistance with securing project finances
6) As soon as you have a formal approval for the project, agree on a hard date with the subcontractor by when the project will be completed, and by when the first milestone will be delivered
Project cruise
A) If the subcontractors have any additional questions about the project at any point along the way, make yourself available to help out as soon as possible
a) Insist on written communication whenever possible, especially if you discuss changes in the project requirements; use Skype only when it will save you time but have all project agreements written down in case we need them later on
b) #EveryoneThinks applies to the subcontractors as well - don't solve problems for them but instead always ask for them to suggest and explain the best solution that you'll review and approve or suggest differently
B) If you uncover additional work is needed for the project along the way that wasn't covered by our original requirements go ahead and immediately discuss project appendix estimates with the subcontractor and let Ops know to assist you with financial approval
a) Be fair - if you didn't ask for that work in the original specs then don't insist for subcontractors to do it for free
C) Make sure you know the upcoming milestone ETA as well as the project completion ETA at all times
a) If the subcontractor misses an ETA you need to send a follow up immediately
b) If you don't hear back from the subcontractor send another follow up and add Ops to CC to help out
c) If someone wakes you up in the middle of the night you need to be able to immediately provide project ETAs and status
D) #EveryoneShares - be transparent towards all stakeholders (i.e. Facilitators): if you are asked about project status then you're already late
a) Push information when a milestone is approved
b) Push information when a defined ETA is changed for whatever reason
c) Push information when additional project requirements are uncovered
E) As soon as you receive a deliverable from the subcontractors prioritize reviewing it and providing feedback
a) If you need some time to review the deliverable provide the subcontractor with an ETA - what you expect from the subcontractor about giving and honoring ETAs applies to you as well
b) Check deliverable conformance to specs, functionality, quality, performance, code where applicable
c) If something isn't good enough send it back with sufficient feedback
d) If a deliverable meets all of the milestone acceptance criteria inform Ops and the subcontractors about it to cover the financial side of the milestone
Project touchdown
1) Project is officially complete as soon as all milestones are approved and all project requirements are fulfilled - you determine when this happens by giving away final project approval
a) Don't give an approval if you haven't allowed all team members (devs, SSEs) to review the deliverables and to report all found issues, provide feedback
b) Don't give an approval just to end the project sooner if there are still remaining issues - be persistent for the subcontractor to resolve all of the known issues
c) When in conflict with the subcontractor whether an issue is a bug or an additional request feel free to consult with Ops, but also remember that we need the project 100% completed as soon as possible with the highest possible PUQ so if a small additional project appendix will get us there don't think twice about it and err on the subcontractor side
d) Always remember: the more things subcontractor didn't finish the more work for you
2) Never stop thinking about additional work you can subcontract, especially if you're happy with the subcontractor
a) Spin off a new project immediately if you already found additional work needed for an R2, R3, Rn down the way
b) When applicable ask the subcontractors to do some comp research on their own and to suggest any missing features, areas where we can improve the project - senior guys who are looking for additional work will be happy to help you out with this
Key things to remember
1- You are the project manager and you own the project from start to finish
2- Ops is always there to help you out with administration and PM advice whenever in doubt
3- Don't be afraid: Failure is ok, fear isn't ;)
As we already determined that every member of our product team is not just a PO but also a PM, below are a few PM operational algorithms that will help you to ensure your project is successful
Project takeoff
1) When you have project specs vetted by the team (SSE, devs, others as needed), send the specs to the selected tried out subcontractor, or send the specs to Ops for assistance in finding a subcontractor with the best bid
2) Subcontractor will usually have some questions about the project specs before providing work estimates
a) If the answers to the questions are already covered in the specs that means the subcontractors didn't bother to read through the specs and you can dismiss them
b) If there are no questions at all or no questions you hoped to hear then make sure to ask a few "control" questions of your own, i.e.: how do you plan to implement something, what do you suggest for a solution for this problem, which technology will you use to accomplish this, did you work on a similar project before, etc.
c) If you get some very basic questions about the project that should've been covered by the specs already that means that the specs aren't good enough and my suggestion is that you don’t waste time in ad-hoc discussion with the subcontractor but go back to step 1) to rewrite/update the specs to cover all important information and then send the new specs to the subcontractor
3) After the subcontractor provides work estimates and project ETA, perform a sanity check
a) If you don't agree with some of the estimates don't challenge them directly but simply ask for a more detailed breakdown and explanation how did they come up with such an estimate
b) Be constructive when talking with subcontractors, it isn't your goal to reduce the estimates but to make sure both sides are fair and professional: you are an employer but you need to treat your subcontractor as your partner
4) Once the project estimates are good define project milestones as these are critical steps along the way that will allow you to track the progress and to avoid situation where you reach the project deadline and figure out it isn't done right
a) Although we don't pay out $ when a project isn't done or done right, we still have growing opportunity cost caused by the delays which can be greater than the actual project cost
b) Each project can be broken down into several milestones with no exceptions (like a sprint PBI can always be broken down into smaller tasks)
5) Get in touch with Ops for assistance with securing project finances
6) As soon as you have a formal approval for the project, agree on a hard date with the subcontractor by when the project will be completed, and by when the first milestone will be delivered
Project cruise
A) If the subcontractors have any additional questions about the project at any point along the way, make yourself available to help out as soon as possible
a) Insist on written communication whenever possible, especially if you discuss changes in the project requirements; use Skype only when it will save you time but have all project agreements written down in case we need them later on
b) #EveryoneThinks applies to the subcontractors as well - don't solve problems for them but instead always ask for them to suggest and explain the best solution that you'll review and approve or suggest differently
B) If you uncover additional work is needed for the project along the way that wasn't covered by our original requirements go ahead and immediately discuss project appendix estimates with the subcontractor and let Ops know to assist you with financial approval
a) Be fair - if you didn't ask for that work in the original specs then don't insist for subcontractors to do it for free
C) Make sure you know the upcoming milestone ETA as well as the project completion ETA at all times
a) If the subcontractor misses an ETA you need to send a follow up immediately
b) If you don't hear back from the subcontractor send another follow up and add Ops to CC to help out
c) If someone wakes you up in the middle of the night you need to be able to immediately provide project ETAs and status
D) #EveryoneShares - be transparent towards all stakeholders (i.e. Facilitators): if you are asked about project status then you're already late
a) Push information when a milestone is approved
b) Push information when a defined ETA is changed for whatever reason
c) Push information when additional project requirements are uncovered
E) As soon as you receive a deliverable from the subcontractors prioritize reviewing it and providing feedback
a) If you need some time to review the deliverable provide the subcontractor with an ETA - what you expect from the subcontractor about giving and honoring ETAs applies to you as well
b) Check deliverable conformance to specs, functionality, quality, performance, code where applicable
c) If something isn't good enough send it back with sufficient feedback
d) If a deliverable meets all of the milestone acceptance criteria inform Ops and the subcontractors about it to cover the financial side of the milestone
Project touchdown
1) Project is officially complete as soon as all milestones are approved and all project requirements are fulfilled - you determine when this happens by giving away final project approval
a) Don't give an approval if you haven't allowed all team members (devs, SSEs) to review the deliverables and to report all found issues, provide feedback
b) Don't give an approval just to end the project sooner if there are still remaining issues - be persistent for the subcontractor to resolve all of the known issues
c) When in conflict with the subcontractor whether an issue is a bug or an additional request feel free to consult with Ops, but also remember that we need the project 100% completed as soon as possible with the highest possible PUQ so if a small additional project appendix will get us there don't think twice about it and err on the subcontractor side
d) Always remember: the more things subcontractor didn't finish the more work for you
2) Never stop thinking about additional work you can subcontract, especially if you're happy with the subcontractor
a) Spin off a new project immediately if you already found additional work needed for an R2, R3, Rn down the way
b) When applicable ask the subcontractors to do some comp research on their own and to suggest any missing features, areas where we can improve the project - senior guys who are looking for additional work will be happy to help you out with this
Key things to remember
1- You are the project manager and you own the project from start to finish
2- Ops is always there to help you out with administration and PM advice whenever in doubt
3- Don't be afraid: Failure is ok, fear isn't ;)
Monday, April 4, 2016
The art of subcontracting
When a fully staffed product (development) team is unable to achieve all of the team goals within an acceptable time frame, the team is faced with two options:
a) Keep developing on your own and work long hours until the goals are achieved or at least until new challenging goals show up so you can work more long hours again
b) Develop smarter by temporarily increasing team velocity through subcontracting: outsource and manage development projects instead of developing everything on your own
Each team is by definition a Project management team and each team member is a PM as soon as you start thinking outside of the confines of your own 10 typing fingers
What does "subcontracting" mean in practice?
1) Identify potential projects by defining the needs in your team where you need help
2) Prepare functional/technical requirements and/or specification for the project
3) Leverage help from the Ops team to find the best external freelancer/team to complete the job
4) Communicate with the selected freelancer/team, review their progress, provide work feedback and set your expectations
5) Give your approval (or not) for parts of the project as it progresses, and for the entire project once it is complete
6) Implement deliverables in production
What all can be subcontracted?
a) Reusable UI components, shared between teams or products
b) Backend libraries / engines / frameworks, either for internal team use or for multiple teams
c) Modular features for owned products, i.e. an externally developed functionality that can be easily "plugged" into the product
d) Fully integrated features for owned products, i.e. subcontractor gets full access to a separate product code branch and adds additional functionality directly
e) Entire new products including backend functionality and frontend UI based on our standards
f) Test automation helper apps that are unaware of the product, i.e. data generators
g) Product-specific test automation helper apps specific to your product's interaction design
We can subcontract everything that we find complex?
Not just complex but even if you know how to do it internally and don't have enough time to do it (remember: success = results / time)
What's the difference between functional and technical requirements?
Functional requirements are your concise expectations of what you need completed
Technical requirements are your general technological expectations / tech limitations of how you want the project done
Requirements are short, generalized documents that provide freedom to outsourcers to figure out the tiny details along the way
At a minimum each project needs to have at least functional requirements defined
What's the difference between functional and technical specification?
Functional specification is a more detailed document providing more thorough expectations, i.e. interaction workflows, UI mockups, etc.
Technical specification is a technical minutia document which can define technical workflows or even entire development project UML
Detailed specifications are optional - they can either help our or make a project unmanageably complex depending on the type of the project
How should SSEs be involved into subcontracting?
Everyone in the team needs to spec-test functional requirements/specification, especially team SSE prior to starting a new project
Once a subcontracted project deliverable comes in such as an UI component, new product feature, new product, test automation helper, etc. SSE should review and scrutinize the deliverable prior to acceptance as if it was developed internally
How much work can we subcontract?
This is up to you mostly; as long as we have resources available to dedicate to outsourcing work you'll be able to suggest new projects for subcontracting and will get assistance from Operations to get started
a) Keep developing on your own and work long hours until the goals are achieved or at least until new challenging goals show up so you can work more long hours again
b) Develop smarter by temporarily increasing team velocity through subcontracting: outsource and manage development projects instead of developing everything on your own
Each team is by definition a Project management team and each team member is a PM as soon as you start thinking outside of the confines of your own 10 typing fingers
What does "subcontracting" mean in practice?
1) Identify potential projects by defining the needs in your team where you need help
2) Prepare functional/technical requirements and/or specification for the project
3) Leverage help from the Ops team to find the best external freelancer/team to complete the job
4) Communicate with the selected freelancer/team, review their progress, provide work feedback and set your expectations
5) Give your approval (or not) for parts of the project as it progresses, and for the entire project once it is complete
6) Implement deliverables in production
What all can be subcontracted?
a) Reusable UI components, shared between teams or products
b) Backend libraries / engines / frameworks, either for internal team use or for multiple teams
c) Modular features for owned products, i.e. an externally developed functionality that can be easily "plugged" into the product
d) Fully integrated features for owned products, i.e. subcontractor gets full access to a separate product code branch and adds additional functionality directly
e) Entire new products including backend functionality and frontend UI based on our standards
f) Test automation helper apps that are unaware of the product, i.e. data generators
g) Product-specific test automation helper apps specific to your product's interaction design
We can subcontract everything that we find complex?
Not just complex but even if you know how to do it internally and don't have enough time to do it (remember: success = results / time)
What's the difference between functional and technical requirements?
Functional requirements are your concise expectations of what you need completed
Technical requirements are your general technological expectations / tech limitations of how you want the project done
Requirements are short, generalized documents that provide freedom to outsourcers to figure out the tiny details along the way
At a minimum each project needs to have at least functional requirements defined
What's the difference between functional and technical specification?
Functional specification is a more detailed document providing more thorough expectations, i.e. interaction workflows, UI mockups, etc.
Technical specification is a technical minutia document which can define technical workflows or even entire development project UML
Detailed specifications are optional - they can either help our or make a project unmanageably complex depending on the type of the project
How should SSEs be involved into subcontracting?
Everyone in the team needs to spec-test functional requirements/specification, especially team SSE prior to starting a new project
Once a subcontracted project deliverable comes in such as an UI component, new product feature, new product, test automation helper, etc. SSE should review and scrutinize the deliverable prior to acceptance as if it was developed internally
How much work can we subcontract?
This is up to you mostly; as long as we have resources available to dedicate to outsourcing work you'll be able to suggest new projects for subcontracting and will get assistance from Operations to get started
Monday, November 30, 2015
Release process and test phases
Release process covers 3 distinct consecutive test phases for which product teams (devs and SSEs) are in charge:
1) Design and usability testing
2) Continuous testing
3) Static/release testing
Each team must have a clear test plan that will allow for systematic advancement between subsequent test phases culminating in a product release
In a good product release scenario a team should never regress from one test phase to a previous one - some guidelines follow to explain each test phase
1. Design and usability testing
During this phase the team is testing new features, changes in a product, and is working towards locking down the product interaction design
Usability testing helps make sure the interaction design is optimal and customer friendly - the team should leverage feedback from as many external resources as possible: company stakeholders, power-users, other product teams, etc.
It is ok to update interaction design, make functional UI changes during this phase, but not after this phase is locked down
2. Continuous testing
Once interaction design is locked down, the team must focus on finding as many bugs as possible and fixing them all as soon as they are found and reported
Usually this phase will help to clean up product functional bugs, regression bugs, and make sure the build is stable enough to go on to the next and final phase of the release process (for more details about Continuous testing vs. static testing read this article)
At this time we should have no usability or interaction design bugs reported, however if it happens that such a bug is found then the team must stop continuous testing and immediately regress back into #1 Design and usability testing phase
3. Static/release testing
At this time the team cannot make multiple product builds meaning the code must be fully locked down, and that only one build can be tested
If the previous two testing phases were covered well then the static testing will only reveal limited number of functional bugs
For static testing round #2 the team should fix only the most critical bugs:
a) Regression/broken bugs
b) Bugs that will clearly make the new build considered worse than the public one
If done correctly there should be no static testing round #3, but if it does happen there can be no round #4 so product release is mandatory after that
If it happens that there are design bugs or multiple "critical" bugs found during static testing then the team must stop static testing and immediately regress back into corresponding previous test phase
At any time when a process regression happens this only means that the previous testing phases weren't done well and the team must update/improve owned testing plan in order to prevent process regression from happening in the future
Remember that each team gives its own product release recommendation at the end - good litmus test question for a release: "Is this product build better than the previous one?"
The only thing that a team must follow at all times is this clear release process and must be able to provide feedback to all stakeholders about:
a) What is the current product testing phase
b) What is the ETA to go into the next phase / release
1) Design and usability testing
2) Continuous testing
3) Static/release testing
Each team must have a clear test plan that will allow for systematic advancement between subsequent test phases culminating in a product release
In a good product release scenario a team should never regress from one test phase to a previous one - some guidelines follow to explain each test phase
1. Design and usability testing
During this phase the team is testing new features, changes in a product, and is working towards locking down the product interaction design
Usability testing helps make sure the interaction design is optimal and customer friendly - the team should leverage feedback from as many external resources as possible: company stakeholders, power-users, other product teams, etc.
It is ok to update interaction design, make functional UI changes during this phase, but not after this phase is locked down
2. Continuous testing
Once interaction design is locked down, the team must focus on finding as many bugs as possible and fixing them all as soon as they are found and reported
Usually this phase will help to clean up product functional bugs, regression bugs, and make sure the build is stable enough to go on to the next and final phase of the release process (for more details about Continuous testing vs. static testing read this article)
At this time we should have no usability or interaction design bugs reported, however if it happens that such a bug is found then the team must stop continuous testing and immediately regress back into #1 Design and usability testing phase
3. Static/release testing
At this time the team cannot make multiple product builds meaning the code must be fully locked down, and that only one build can be tested
If the previous two testing phases were covered well then the static testing will only reveal limited number of functional bugs
For static testing round #2 the team should fix only the most critical bugs:
a) Regression/broken bugs
b) Bugs that will clearly make the new build considered worse than the public one
If done correctly there should be no static testing round #3, but if it does happen there can be no round #4 so product release is mandatory after that
If it happens that there are design bugs or multiple "critical" bugs found during static testing then the team must stop static testing and immediately regress back into corresponding previous test phase
At any time when a process regression happens this only means that the previous testing phases weren't done well and the team must update/improve owned testing plan in order to prevent process regression from happening in the future
Remember that each team gives its own product release recommendation at the end - good litmus test question for a release: "Is this product build better than the previous one?"
The only thing that a team must follow at all times is this clear release process and must be able to provide feedback to all stakeholders about:
a) What is the current product testing phase
b) What is the ETA to go into the next phase / release
Thursday, October 15, 2015
Scrum PPPPPPP
When planning work ahead in your sprints avoid guesstimating at all costs
Why? By guessing estimates for weeks of work ahead you're putting yourself and your team in a corner: when unplanned things show up (and they always will) there is no turning back as you've already committed to delivering per your sprint
Optimists are guesstimating for less work than there actually is which causes the need for Overtime, low quality deliverables, messed up roadmap schedule, and feeling of failure at the end
Pessimists are guesstimating for unrealistic and unjustified work which is even worse than being an optimist - this raises a red flag that a team isn't capable of doing good work in realistic time
Unfortunately even when a team is capable of finishing work in good time, by being a pessimist from the start the original estimates become self-fulfilling prophecy and the work expands to fill out all of the allocated time
Realists on the other hand are different from optimists and pessimists simply in being good JIT planners and proactive communicators
How to recognize an optimist or a pessimist?
a) Sprint contains many part1..part_n type of tasks in the sprint
b) Multiple different tasks have identical estimates of n hours (usually equal to max. daily deliverable limit)
c) There are no internal testing or peer-review tasks, only work specific tasks
How to become a realist?
1) As a ScrumMaster dedicate a few hours time to meet with your team when planning a new sprint and take input from all team members when estimating task hours.
One-man 15min sprint planning is a recipe for failure
2) When encountering goals that require more detailed research before the work can be broken down into clear daily deliverables, plan for a spike-goal of a few hours that will result in more detailed planning of the work ahead.
This is JIT planning by utilizing Spike goals and it helps to avoid doing complex planning for weeks ahead
3) Unknowns still show up even to the best of planners - when this happens figure out what happened, try to devise the best plan for solving the new situation, and if you see the original estimates are no longer viable make sure to immediately inform all stakeholders
Why? By guessing estimates for weeks of work ahead you're putting yourself and your team in a corner: when unplanned things show up (and they always will) there is no turning back as you've already committed to delivering per your sprint
Optimists are guesstimating for less work than there actually is which causes the need for Overtime, low quality deliverables, messed up roadmap schedule, and feeling of failure at the end
Pessimists are guesstimating for unrealistic and unjustified work which is even worse than being an optimist - this raises a red flag that a team isn't capable of doing good work in realistic time
Unfortunately even when a team is capable of finishing work in good time, by being a pessimist from the start the original estimates become self-fulfilling prophecy and the work expands to fill out all of the allocated time
Realists on the other hand are different from optimists and pessimists simply in being good JIT planners and proactive communicators
How to recognize an optimist or a pessimist?
a) Sprint contains many part1..part_n type of tasks in the sprint
b) Multiple different tasks have identical estimates of n hours (usually equal to max. daily deliverable limit)
c) There are no internal testing or peer-review tasks, only work specific tasks
How to become a realist?
1) As a ScrumMaster dedicate a few hours time to meet with your team when planning a new sprint and take input from all team members when estimating task hours.
One-man 15min sprint planning is a recipe for failure
2) When encountering goals that require more detailed research before the work can be broken down into clear daily deliverables, plan for a spike-goal of a few hours that will result in more detailed planning of the work ahead.
This is JIT planning by utilizing Spike goals and it helps to avoid doing complex planning for weeks ahead
3) Unknowns still show up even to the best of planners - when this happens figure out what happened, try to devise the best plan for solving the new situation, and if you see the original estimates are no longer viable make sure to immediately inform all stakeholders
Thursday, March 5, 2015
Static testing
Static testing is the main form of systematic software test cycle in ApexSQL
Purpose of having a systematic software test cycle
a) To minimize the probability of false negatives
b) To efficiently leverage limited time and resources we have when doing software testing
c) To have predictable release dates which directly help our sales
Chronology of a systematic software test cycle
1) (pre-testing) Internal developer cross-testing or Blitzkrieg testing of the new official product build being prepared for a release:
a) Blitzkrieg testing must be covered within the planned development time / within the sprint
b) Developers can only fix internally found issues based on available time planned for internal testing and fixing
c) When the sprint time runs out all remaining found issues must be sent to software testers to officially post as bugs
2) (round 1) Developers freeze the code: further code changes in this branch are not allowed so make sure to branch off further fixes and development.
Officially send the build to the first static testing round by providing to software testers as many details as possible what needs to be tested, i.e.:
Areas for testing:
a) All resolved bugs, total of N
b) GUI living standards affecting the following product UI: ...
c) Regression test the following core features: ...
d) New product functionalities / functionality changes: ...
e) Planned or a possible change in performance of: ...
f) Updated activation / product installer
g) Support for new OS / SQL Server / integration with: ...
h) Coexistence with the following products: ...
i) ...
3) (round 1) Software testers acknowledge the build sent by developers by providing a top-level test plan containing:
a) Test areas covering the whole product including full regression testing and major use cases
b) Priorities for test areas and tester assignments when multiple software testers will participate in testing
c) ETA in test-hours for each of the test areas
I.e.:
Testing can start on <date> the earliest and finished by <date>. The plan is:
1) Test all resolved bugs, tester1 and tester2, 3h total
2) GUI living standards, tester1, 2h total
3) Regression test for ..., tester2, 3h total
...
During the testing when a new release-blocking bug is found software testers will immediately report the bug number to developers to fix the bug proactively while the testing is still ongoing
When the testing is done, a standard test summary report is sent with information about remaining bugs, bug flow, and release recommendation by software testers including clarification why such recommendation is sent
4) (round 2) Developers fix all release-blocking bugs including additional quick/simple bugs that aren't related to product functionality and have minimal chance to cause new regression issues, then create a new build with internally verified fixes, and repeat the step #2
5) (round 2) Software testers acknowledge the new build and again provide detailed test areas as specified in the step #3
Note: this time around software testers can only plan and test changes that developers made, i.e.:
1) All fixed bugs since the previous test round
2) Regression test only specific functionality affected by bug fixes and mentioned by developers
3) Spot-test the product for a very short time, several hours at most
6) (round 3) Simply repeat steps #4 and #5 if there is a need to do so
7) (release) If more release-blocking bugs are found suggest which ones can be fixed immediately and release after that with intra-team verified fixes by developers, and software testers as needed
8) (post-release) All bugs that remain unfixed will need to be corrected in the subsequent releases: a patch, a quick-maint release, or a regular release
Q&A
Q1: What happens if software testers can't start testing a build for more than a week?
A1: Developers are then required to prioritize additional cross-testing themselves by providing the test plan as mentioned under #3 above and committing to transparent testing:
a) All issues found will be backlogged to software testers to retest when they can
b) Only approved issues from the list can be fixed after testing (never fix in real-time)
c) Once fixed, developers will again cross-test each other's fixes and release
d) Software testers will go over all backlogged issues post-release and officially report bugs for still unfixed issues
Q2: Can we have more than 3 static test rounds?
A2: No. We need to quickly fix only the most critical issue(s) following test round #3 and release immediately. Any remaining unfixed issues will need to be fixed in the subsequent release
Q3: But ApexSQL <insert product name> is specific and we can't test like that, we need more time, test rounds, testers, resources, etc., can we change the rules for this one product?
A3: No. If a product is specific then let's proactively work together on:
a) Planning to do some internal testing during the development of the product, actively taking part in design decisions, checking all UI changes on-the-fly, etc.
b) Creating more thorough test plan including shared sandboxes, use cases, and even individual test cases as needed
c) Automating some part of the testing with help from developers, or by outsourcing a specific test application
Purpose of having a systematic software test cycle
a) To minimize the probability of false negatives
b) To efficiently leverage limited time and resources we have when doing software testing
c) To have predictable release dates which directly help our sales
Chronology of a systematic software test cycle
1) (pre-testing) Internal developer cross-testing or Blitzkrieg testing of the new official product build being prepared for a release:
a) Blitzkrieg testing must be covered within the planned development time / within the sprint
b) Developers can only fix internally found issues based on available time planned for internal testing and fixing
c) When the sprint time runs out all remaining found issues must be sent to software testers to officially post as bugs
2) (round 1) Developers freeze the code: further code changes in this branch are not allowed so make sure to branch off further fixes and development.
Officially send the build to the first static testing round by providing to software testers as many details as possible what needs to be tested, i.e.:
Areas for testing:
a) All resolved bugs, total of N
b) GUI living standards affecting the following product UI: ...
c) Regression test the following core features: ...
d) New product functionalities / functionality changes: ...
e) Planned or a possible change in performance of: ...
f) Updated activation / product installer
g) Support for new OS / SQL Server / integration with: ...
h) Coexistence with the following products: ...
i) ...
3) (round 1) Software testers acknowledge the build sent by developers by providing a top-level test plan containing:
a) Test areas covering the whole product including full regression testing and major use cases
b) Priorities for test areas and tester assignments when multiple software testers will participate in testing
c) ETA in test-hours for each of the test areas
I.e.:
Testing can start on <date> the earliest and finished by <date>. The plan is:
1) Test all resolved bugs, tester1 and tester2, 3h total
2) GUI living standards, tester1, 2h total
3) Regression test for ..., tester2, 3h total
...
During the testing when a new release-blocking bug is found software testers will immediately report the bug number to developers to fix the bug proactively while the testing is still ongoing
When the testing is done, a standard test summary report is sent with information about remaining bugs, bug flow, and release recommendation by software testers including clarification why such recommendation is sent
4) (round 2) Developers fix all release-blocking bugs including additional quick/simple bugs that aren't related to product functionality and have minimal chance to cause new regression issues, then create a new build with internally verified fixes, and repeat the step #2
5) (round 2) Software testers acknowledge the new build and again provide detailed test areas as specified in the step #3
Note: this time around software testers can only plan and test changes that developers made, i.e.:
1) All fixed bugs since the previous test round
2) Regression test only specific functionality affected by bug fixes and mentioned by developers
3) Spot-test the product for a very short time, several hours at most
6) (round 3) Simply repeat steps #4 and #5 if there is a need to do so
7) (release) If more release-blocking bugs are found suggest which ones can be fixed immediately and release after that with intra-team verified fixes by developers, and software testers as needed
8) (post-release) All bugs that remain unfixed will need to be corrected in the subsequent releases: a patch, a quick-maint release, or a regular release
Q&A
Q1: What happens if software testers can't start testing a build for more than a week?
A1: Developers are then required to prioritize additional cross-testing themselves by providing the test plan as mentioned under #3 above and committing to transparent testing:
a) All issues found will be backlogged to software testers to retest when they can
b) Only approved issues from the list can be fixed after testing (never fix in real-time)
c) Once fixed, developers will again cross-test each other's fixes and release
d) Software testers will go over all backlogged issues post-release and officially report bugs for still unfixed issues
Q2: Can we have more than 3 static test rounds?
A2: No. We need to quickly fix only the most critical issue(s) following test round #3 and release immediately. Any remaining unfixed issues will need to be fixed in the subsequent release
Q3: But ApexSQL <insert product name> is specific and we can't test like that, we need more time, test rounds, testers, resources, etc., can we change the rules for this one product?
A3: No. If a product is specific then let's proactively work together on:
a) Planning to do some internal testing during the development of the product, actively taking part in design decisions, checking all UI changes on-the-fly, etc.
b) Creating more thorough test plan including shared sandboxes, use cases, and even individual test cases as needed
c) Automating some part of the testing with help from developers, or by outsourcing a specific test application
Blitzkrieg testing
(Wikipedia) Blitzkrieg (German, "lightning war") is an anglicized term describing a method of warfare whereby an attacking force spearheaded by a dense concentration of armored and motorized or mechanized infantry formations, and heavily backed up by close air support, forces a breakthrough into the enemy's line of defense through a series of short, fast, powerful attacks
Although we're striving to automate as much development processes as we can, in some cases of complex product releases we still need to ensure products pass human / manual testing so there are no broken functionality issues we missed
What happens when we have limited number of testers covering multiple products from multiple development teams? As we never test in parallel, one or more products inevitably gets delayed, we pile up technical waste and lose agility
Consider a typical development scenario:
1) On day 1 Dev team A works for 3 weeks and builds Product A for testing
2) On day 2 Dev team B works for 3 weeks and builds Product B for testing
3) The same software testers cover both Dev team A and Dev team B
4) Software testers receive Product A and Product B for testing on week 4
5) We prioritize products based on their ROI, date of last release, customer requests - one product still gets delayed and there is always at least one customer that we've let down
Instead of losing momentum, we can now add air support (developers) to help mechanized infantry (software testers) and blitzkrieg the product for one day
Years ago in early days of ApexSQL each developer was owning exactly one product and was also responsible to self-test the product before sending it to testers. Without this mandatory self-testing we've regressed to not doing any self-testing prior to sending products to testing
Consider different step #5 above:
5) Dev team A works together with software testers to blitzkrieg-test Product A for one day and release it as Interim build or even production build if software testers agree
6) Dev team B works together with software testers the next day to blitzkrieg-test Product B for one day and release it as Interim/production build
Critical note: developers cannot report bugs "internally" or fix them on-the-fly: all bugs must be reported to software testers who will then create bugs in the system and prioritize them accordingly
Also to avoid confusion - some online blogs say that Blitzkrieg testing = spot-testing; there is a major difference: spot-testing is quick testing by a lone scout, while Blitzkrieg is a short but major quality offensive
Although we're striving to automate as much development processes as we can, in some cases of complex product releases we still need to ensure products pass human / manual testing so there are no broken functionality issues we missed
What happens when we have limited number of testers covering multiple products from multiple development teams? As we never test in parallel, one or more products inevitably gets delayed, we pile up technical waste and lose agility
Consider a typical development scenario:
1) On day 1 Dev team A works for 3 weeks and builds Product A for testing
2) On day 2 Dev team B works for 3 weeks and builds Product B for testing
3) The same software testers cover both Dev team A and Dev team B
4) Software testers receive Product A and Product B for testing on week 4
5) We prioritize products based on their ROI, date of last release, customer requests - one product still gets delayed and there is always at least one customer that we've let down
Instead of losing momentum, we can now add air support (developers) to help mechanized infantry (software testers) and blitzkrieg the product for one day
Years ago in early days of ApexSQL each developer was owning exactly one product and was also responsible to self-test the product before sending it to testers. Without this mandatory self-testing we've regressed to not doing any self-testing prior to sending products to testing
Consider different step #5 above:
5) Dev team A works together with software testers to blitzkrieg-test Product A for one day and release it as Interim build or even production build if software testers agree
6) Dev team B works together with software testers the next day to blitzkrieg-test Product B for one day and release it as Interim/production build
Critical note: developers cannot report bugs "internally" or fix them on-the-fly: all bugs must be reported to software testers who will then create bugs in the system and prioritize them accordingly
Also to avoid confusion - some online blogs say that Blitzkrieg testing = spot-testing; there is a major difference: spot-testing is quick testing by a lone scout, while Blitzkrieg is a short but major quality offensive
Friday, January 23, 2015
Scrum tales - part 15 - success FAQ
Why does Scrum matter?
- Scrum provides structure and forces prioritization in the company
- Scrum provides maximum work transparency at all times
- Scrum provides clear insight into problems within teams
- Scrum eliminates team leaders and administrative non-thinkers
- Scrum enables regular dialog between stakeholders and teams
- Scrum allows teams to make their own commitments and estimates within reason
- Scrum allows teams to work without constant supervision and guidance
- Scrum allows for predictable work increments
- Scrum is easily scalable
Why do successful sprints matter?
Each successful sprint carries a potential production-ready deliverable increment (a new product build, a specs or a prototype for a new tool, documentation, etc.), and as each sprint is time-boxed it is easy to make systematic progress and be competitive as a company
What happens when a sprint succeeds?
It shows that a Scrum team cares about the company success and can be trusted more in the future as the team has delivered what they agreed with the stakeholders
What happens when a sprint fails?
It shows that a Scrum team needs to improve in the future, and gives the team a chance to accept responsibility and address the organizational issues themselves
Is it ok to fail a sprint if it is done for a greater cause / higher goal?
No - saying "greater cause" in this context is an excuse for doing things your way without alignment with previously agreed goals and priorities, and with lack of transparency towards stakeholders
There are no valid reasons why a sprint should fail if:
a) Communication with the Product Owner and all stakeholders was regular
b) All issues with suggestions how to resolve them were raised as soon as they showed up
c) Sufficient effort was expanded
How to ensure a sprint succeeds when unexpected issues show up?
As soon as the issues show up:
1) Consider all possible solutions to keep the sprint on track: additional research, workaround, help from other teams, or just expand some extra effort
2) Contact stakeholders / Product Owner to inform them of the issues and possible solutions
3) Recommend sprint grooming as the last resort
Both the Scrum team and all stakeholders equally wish for each sprint to succeed so consider all related communication as discussion between allies on a common quest for success
- Scrum provides structure and forces prioritization in the company
- Scrum provides maximum work transparency at all times
- Scrum provides clear insight into problems within teams
- Scrum eliminates team leaders and administrative non-thinkers
- Scrum enables regular dialog between stakeholders and teams
- Scrum allows teams to make their own commitments and estimates within reason
- Scrum allows teams to work without constant supervision and guidance
- Scrum allows for predictable work increments
- Scrum is easily scalable
Why do successful sprints matter?
Each successful sprint carries a potential production-ready deliverable increment (a new product build, a specs or a prototype for a new tool, documentation, etc.), and as each sprint is time-boxed it is easy to make systematic progress and be competitive as a company
What happens when a sprint succeeds?
It shows that a Scrum team cares about the company success and can be trusted more in the future as the team has delivered what they agreed with the stakeholders
What happens when a sprint fails?
It shows that a Scrum team needs to improve in the future, and gives the team a chance to accept responsibility and address the organizational issues themselves
Is it ok to fail a sprint if it is done for a greater cause / higher goal?
No - saying "greater cause" in this context is an excuse for doing things your way without alignment with previously agreed goals and priorities, and with lack of transparency towards stakeholders
There are no valid reasons why a sprint should fail if:
a) Communication with the Product Owner and all stakeholders was regular
b) All issues with suggestions how to resolve them were raised as soon as they showed up
c) Sufficient effort was expanded
How to ensure a sprint succeeds when unexpected issues show up?
As soon as the issues show up:
1) Consider all possible solutions to keep the sprint on track: additional research, workaround, help from other teams, or just expand some extra effort
2) Contact stakeholders / Product Owner to inform them of the issues and possible solutions
3) Recommend sprint grooming as the last resort
Both the Scrum team and all stakeholders equally wish for each sprint to succeed so consider all related communication as discussion between allies on a common quest for success
Thursday, December 11, 2014
Developer Vs. Programmer
At ApexSQL we're making killer tools for SQL Server, and to do so we're proud to have strong product and website teams currently consisting of developers and SQAs. We have no programmers in our teams and we don't need any.
What is the difference between a programmer and a developer?
Definition
Programmer is a grunt receiving orders from a team leader and/or project manager working on a piece of code outsourced for someone else's solution and based on someone else's plan.
Developer is a spec-ops, lean-mean-development-machine part of a small band of heroes owning and building top-notch solutions, come hell or high water.
Examples
Programmer has many bosses: a senior, a team leader, a project manager, etc.
Developer has only one boss: the customer.
Programmer wants to write a program or some code.
Developer wants to create the best solution for the customer.
Programmer comes to work and works for 8h.
Developer has incremental results each day regardless of hours worked.
Programmer asks questions.
Developer makes suggestions.
Programmer speaks for himself as one from the team.
Developer speaks to the team and for the team.
Programmer reads roadmaps and writes code to accommodate roadmaps.
Developer makes roadmaps and works to accommodate customers.
Programmer doesn't know the competitors and tends to be surprised.
Developer knows what competitors had for breakfast and what they plan for dinner.
Programmer schedules meetings and gives updates to stakeholders when asked to do so.
Developer has an active com-link with battle buddies and keeps stakeholders constantly informed of mission status.
Programmer learns when new skills are needed for work and/or is trained by others.
Developer learns organically and shares the knowledge by training others.
Programmer works with other teams to share personal workload.
Developer works with other teams to lessen everyone's workload.
Programmer strives not to fail the sprint.
Developer strives to add more work on top of a successful sprint.
Programmer waits for SQAs to test code changes and report bugs.
Developer self-tests new code and makes it tough for SQAs to find bugs.
Programmer is unsure about performance of created tools.
Developer perf-tests regularly and knows that owned tools are top-performers in the market.
Programmer expects of SQAs to write test cases and to regression test everything.
Developer cooperates with SQAs to write unit tests, to implement detailed logging and to automate regression testing.
Programmer uses 3rd party tools to speed up work.
Developer uses our company tools to speed up work and to help improve the tools in the process.
Programmer "overcommits", "cannot reproduce", "cannot fix", "must ask someone else".
Developer gets the job done. Period.
What is the difference between a programmer and a developer?
Definition
Programmer is a grunt receiving orders from a team leader and/or project manager working on a piece of code outsourced for someone else's solution and based on someone else's plan.
Developer is a spec-ops, lean-mean-development-machine part of a small band of heroes owning and building top-notch solutions, come hell or high water.
Examples
Programmer has many bosses: a senior, a team leader, a project manager, etc.
Developer has only one boss: the customer.
Programmer wants to write a program or some code.
Developer wants to create the best solution for the customer.
Programmer comes to work and works for 8h.
Developer has incremental results each day regardless of hours worked.
Programmer asks questions.
Developer makes suggestions.
Programmer speaks for himself as one from the team.
Developer speaks to the team and for the team.
Programmer reads roadmaps and writes code to accommodate roadmaps.
Developer makes roadmaps and works to accommodate customers.
Programmer doesn't know the competitors and tends to be surprised.
Developer knows what competitors had for breakfast and what they plan for dinner.
Programmer schedules meetings and gives updates to stakeholders when asked to do so.
Developer has an active com-link with battle buddies and keeps stakeholders constantly informed of mission status.
Programmer learns when new skills are needed for work and/or is trained by others.
Developer learns organically and shares the knowledge by training others.
Programmer works with other teams to share personal workload.
Developer works with other teams to lessen everyone's workload.
Programmer strives not to fail the sprint.
Developer strives to add more work on top of a successful sprint.
Programmer waits for SQAs to test code changes and report bugs.
Developer self-tests new code and makes it tough for SQAs to find bugs.
Programmer is unsure about performance of created tools.
Developer perf-tests regularly and knows that owned tools are top-performers in the market.
Programmer expects of SQAs to write test cases and to regression test everything.
Developer cooperates with SQAs to write unit tests, to implement detailed logging and to automate regression testing.
Programmer uses 3rd party tools to speed up work.
Developer uses our company tools to speed up work and to help improve the tools in the process.
Programmer "overcommits", "cannot reproduce", "cannot fix", "must ask someone else".
Developer gets the job done. Period.
Tuesday, September 2, 2014
Hard sh** and smart sh**
Great GSD ("Get Sh.. Done" as ApexSQL Nis office central poster says) = consistently have both short term and long term transparent results
Some teams are working using Scrum work organization through goals (answer to what?) and tasks (answer to how?), while others have monthly goals / quotas to achieve by making daily and weekly progress in smaller increments
Some teams are working using Scrum work organization through goals (answer to what?) and tasks (answer to how?), while others have monthly goals / quotas to achieve by making daily and weekly progress in smaller increments
We often forget about the goals while focusing exclusively
on the tasks at hand to get them finished no matter what, forgetting about what is actually needed in the end and in what time
Now I'm not saying that focusing on daily tasks is wrong -
one of my own email quotes from the early days said:
"Focused, hard work
is the real key to success. Keep your eyes on the goal, and just keep
taking the next step towards completing it." - John Carmack
We must
always keep in mind both the goal and have Daily deliverables at all times
But in order to grow, besides working hard we must also
be cognizant of the end goal at all times and be able to work smart to achieve the goal
GSD has two levels:
1) Hard Sh**: daily deliverables, things we must all do our part and complete in order to make daily progress, i.e. fix stubborn bugs, test bug fixes and report new bugs, write TS articles for unfixed bugs, publish articles, communicate with stakeholders, share your progress daily, etc.
2) Smart Sh**: make a dent in the universe by aligning all action with end goals and complete the goals with a reasonable amount of effort in a reasonable amount of time
1) Hard Sh**: daily deliverables, things we must all do our part and complete in order to make daily progress, i.e. fix stubborn bugs, test bug fixes and report new bugs, write TS articles for unfixed bugs, publish articles, communicate with stakeholders, share your progress daily, etc.
2) Smart Sh**: make a dent in the universe by aligning all action with end goals and complete the goals with a reasonable amount of effort in a reasonable amount of time
How does Smart Sh** translate to your everyday work?
a) Dev teams should realize that customers don't have a use
for 50 bug fixes in code and would much rather prefer 20 bug fixes in a
product build they can actually download - know when to cut and deliver.b) SQA should invest time to understand product usefulness, to learn about it and to use it as customers use it in order to test the product well, to never assume they know everything, to write about it in non-hamburger helper way, and to excel in customer support.
c) Everyone should be investing time into ERF mentorship with new colleagues so that they can start contributing back and in turn save time to you.
d) Everyone should automate repetitive work - currently a huge soft spot in multiple teams.
What does automation have to do with working smart?
A lot: one of the funnier historical examples is several devs
going rogue and writing a software that fully automates sending Daily
Scrum Summaries - while other teams were taking hours of time weekly to manually compile good Scrum Summary emails, these devs took one day and created a
two-click solution that in turn saved them days of time; I always received
spotless Scrum Summaries from their teams which was a mystery to me until I found out
about the "plot" ;) (devs are good guys, they were planning to
distribute the software to everyone when we stopped sending these emails
daily)
Time is a limited commodity so by investing some in order to automate repetitive work (smart vs. hard), devs gained more time to focus on what really matters: to write better code and to deliver great products to the customers in order to make a dent in the universe. I'm also sure devs had more fun in the process ;)
Ultimately whatever we do we must ask ourselves:
A) Can I complete the task at hand more efficiently with less effort and time?
B) What goal will be closer to completion when I finish this task today?
C) What will I deliver to customers when the goal is completed?
D) Will the customers pay me for the deliverable?
If no one will pay you in the end, why would you do it in the first place? ;)
Tuesday, May 27, 2014
ERF - Expectations, Results, Feedback
The first badge for leading and sharing is awarded for successfully leading your team to achieve defined goals, and for maintaining transparency of team progress while sharing new experience and knowledge with peers and seniors
However the second badge for leading and sharing is more challenging and requires sharing to new colleagues how they can share-and-lead
Here is a proven good way to earn the second badge through ERF (set Expectations, review Results, provide Feedback):
When in doubt, just follow the three ERF steps:
1) Set Expectations - clearly explain what is the final goal of the deliverable, why do we need it, what is the epic story behind it; provide a system description or example of similar work from before; go back to your own goals and don't interfere
2) Review Results - once the results are in, dedicate time to review them in details, what is good, what is not so good, and make notes for everything; don't fix the results yourself
3) Provide Feedback - take all your notes from the previous step, dedicate more time to make them as clear as possible before sending; finally send all the feedback and repeat expectations - go back to step #1 and repeat the full cycle until finally results match expectations
Also there are multiple ways through which you will never achieve the second badge, i.e.:
Don'ts to watch out for:
1) Don't expect results without first setting expectations and clarifying them
2) Don't yell when results are not matching expectations - instead just provide actionable feedback and repeat expectations
3) Don't set deadlines based on how much time you would need to complete the same goal; however make sure to always have clear ETAs and to follow up on time as needed
4) Don't fix low quality results yourself - instead ask for resubmission after providing feedback
5) Don't confront when you identify a problem - instead ask for clarifications and observe
6) Don't IM or voice-only your feedback - instead share it so that it can be traced back easily on G+, emails using #hash[tag]
How will you know if you have succeeded in mentoring new colleagues? They'll be the ones to achieve defined team goals and to share new experience and knowledge with you
However the second badge for leading and sharing is more challenging and requires sharing to new colleagues how they can share-and-lead
Here is a proven good way to earn the second badge through ERF (set Expectations, review Results, provide Feedback):
When in doubt, just follow the three ERF steps:
1) Set Expectations - clearly explain what is the final goal of the deliverable, why do we need it, what is the epic story behind it; provide a system description or example of similar work from before; go back to your own goals and don't interfere
2) Review Results - once the results are in, dedicate time to review them in details, what is good, what is not so good, and make notes for everything; don't fix the results yourself
3) Provide Feedback - take all your notes from the previous step, dedicate more time to make them as clear as possible before sending; finally send all the feedback and repeat expectations - go back to step #1 and repeat the full cycle until finally results match expectations
Also there are multiple ways through which you will never achieve the second badge, i.e.:
Don'ts to watch out for:
1) Don't expect results without first setting expectations and clarifying them
2) Don't yell when results are not matching expectations - instead just provide actionable feedback and repeat expectations
3) Don't set deadlines based on how much time you would need to complete the same goal; however make sure to always have clear ETAs and to follow up on time as needed
4) Don't fix low quality results yourself - instead ask for resubmission after providing feedback
5) Don't confront when you identify a problem - instead ask for clarifications and observe
6) Don't IM or voice-only your feedback - instead share it so that it can be traced back easily on G+, emails using #hash[tag]
How will you know if you have succeeded in mentoring new colleagues? They'll be the ones to achieve defined team goals and to share new experience and knowledge with you
Wednesday, December 11, 2013
Actionable inter-team deliverable approvals
Every Scrum team has either asked other teams for help with deliverables review or has provided assistance by reviewing deliverables of other teams
This inter-team collaboration encouraged as it will in turn improve inter-team communication, speed of deliverable reviews and most importantly quality of deliverables
However before Product Owners can accept a deliverable as approved, we'll need to see that the team performing the review has actually invested time to provide constructive and actionable feedback, or we'll automatically assume that deliverable isn't to expected acceptance criteria
What does this mean in practice:
However before Product Owners can accept a deliverable as approved, we'll need to see that the team performing the review has actually invested time to provide constructive and actionable feedback, or we'll automatically assume that deliverable isn't to expected acceptance criteria
What does this mean in practice:
Scrum team being reviewed - help reviewers to help you:
a) Explain to the review team the intent behind the deliverable
b) Specify areas that must be reviewed in a structured way
c) Note what kind of feedback you need in order to have the deliverable approved
Team performing the review - provide full information in your reply:
a) What has been reviewed
b) What should be modified/updated/clarified, or
c) Why nothing should be modified/updated/clarified (less likely)
d) Recommend whether the reviewed deliverable should be approved or not by PO
Why should a team spend time to review other team's deliverables if they are not direct stakeholders? Our Company values statement says that Everyone serves: "Treat
everyone as a customer, internal or external, and make responsiveness part of your
personal brand. Build effective working relationships with a focus on being positive,
informative, actionable, and helpful."
Leave-me-alone type of replies such as "Approved", "We have nothing to add", "This is good", and similar won't count as reviews at all when doing Sprint review
Friday, September 27, 2013
Efficient customer support chain
To have an efficient chain of help from customer and all the way down to developers teams should make sure to not skip steps and seek shortcuts as they will prevent internal growth but also unwillingly consume more of team time on the long run making the support inefficient and time consuming
What does this mean in practice?
1) Support - don't be a hero, you cannot isolate all bugs by yourselves as this will suck up your time and you won't be able to work on anything else that day; pass complex support cases down to QA to isolate and reproduce the issue when you define the problem itself; not passing cases down to QA will also deny them of the opportunity to grow hard skills and help you better/faster in the future
2) Support - make sure you do define what the problem is about when the customer first contacts you; this means you shouldn't forward received customer email directly to QA if you don't know the answer immediately - try to at least define the problem before pushing it down the chain to QA to isolate and report a bug
3) Support - some of you have tendencies to contact devs and discuss directly with them whether a customer report is a bug and whether or not devs can fix it easily; don't go to devs but go to QA instead because going to devs without a defined bug will only waste time for both teams
4) QA - although you no longer have unattended assistance metric this doesn't mean you should contact devs for every single support case and definitely not repeatedly when similar issues show up - I can hear directly from devs which QA team is doing better job isolating technical support case bugs
5) QA - you can and should contact customer directly when you need additional help to isolate a complex problem; contacting customer through Support will only waste time of both teams and prolong solving the case
6) Devs - help QA grow by giving them pointers what to research, check and isolate; if you always roll down your sleeves, dig down into code and isolate a problem for them, you'll be stuck doing this indefinitely while we'll have consequential impact on our product releases
Subscribe to:
Posts (Atom)