80 ways to become a 10x developer

The notion of a 10 times more productive developer has long been a controversial topic in the dev-world. Is it really possible for developer A to finish a product in 1/10th of the time developer B would use?

I would say yes if the circumstances are right. Developer productivity, performance or efficiency is a fuzzy concept in the dev world. It is inherently hard to measure productivity because it relies so much on experience, knowledge and creativity. There are infinite ways to complete a piece of software.  For comparison, lets take the job of building a house. In the construction engineering discipline there’s highly established practices for how to construct and assemble the pieces of the house. All the building blocks are standardized and well known. In the dev world we are often free to do whatever we like. We don’t rely on physical items with known tangible properties that need to be put together in a specific way. Instead everything is just lines upon lines of code. Everything is abstract and can be written in infinite ways as long as it compiles.

The 10x developer is a misleading term as there is no agreed upon evaluation criteria and no established way of measuring it. Anyway, in this blog post I’ll list several ways I believe can propel you towards becoming 10x more productive. I am not saying I am a 10x developer but here are some ways I myself and others I have observed have become more productive.

1. Improve your typing skills. Buy the Das Keyboard, a completely blank keyboard with no letters.
2. Learn OS and IDE shortcuts so you don’t have to move the hand over to the mouse.
3. Get an overview and basic understanding of different tools and frameworks out there. This will help you choose the right tool for the job. 
4. Learn about the pros and cons of Open Source and the different licensing models. Learn when to build it yourself and when not to. 
5. Get deep knowledge in architecture, programming languages, algorithms, coding best practices, clean code, design patterns, agile methodologies, XP, unit testing and the other core things related to the art and craft of software development. 
6. Improve your memory. If you can remember details you save time trying to look things up. Do memory exercises, learn recollection techniques etc.
7. Improve your cognition. If your brain can operate at a higher speed you will be able to learn faster and connect the dots faster making your productivity higher. Although you are born with a certain IQ, you can always maximize your cognitive potential. Exercise your brain and stay sharp by always challenging yourself.
8. Be flexible, open-minded and tolerant. If you are, you will be better liked and you’ll have a positive work environment. A good work environment gives you energy and you will boost your productivity. 
9. Learn how to most efficiently use Find and Replace also with regex.
10. Remove repetitive work. An example of repetitive work is writing boilerplate code. Writing boiler place code does not make you a better programmer. You want to do things that serve multiple purposes. Use better tools, make code that writes itself, automate etc.   
11. Work hard and show you have grit. Show that you are willing to get your hands dirty. Don’t shrug off tasks you think will be hard or boring. You do it knowing it has to be done in order to get on with the more fun work. If you constantly complain your way out of tasks that has to be done anyway you just kill productivity. Sacrifice yourself for the team and do the boring task. Over time it will pay off. Show-stoppers or impediments usually escalate. Over time more and more people get invovled in discussing how to deal with it, as time goes there'se more and more noise. All of it could perhaps be avoided if you just sat down at the outset and just fixed the darn issue.
12. Take care of your personal health. Developers who do not take care of their own health and wellbeing are at higher risk of decease. If two years from now you develop diabetes you will for sure be impacted and loose productivity. If you party getting blackout-drunk every week your health will decline and that will impact your ability to stay sharp and learn (see life-long learning).
13. Learn how to analyze stuff. If you can analyze complicated issues you will be better equipped to make better decisions. With better decisions you can avoid going down dead-end roads of development or you will more likely choose a route that will lead you faster to the goal. Learn how to use simple pros and cons lists, learn how to understand complexity. Learn how to decompose issues, view them from different angles, learn about System Dynamics and Systems Thinking.
14. Learn all the code snippets / templates / macros that are available in your IDE.
15. Don’t use plain text editors over fully fledged IDE’s just to show off. (unless you are writing something that is not supported by your IDE)  
16. Build understanding and empathy. If you don’t empathize with your team mates, your boss or your customers you are most likely going to be seen as egocentric, arrogant or distanced, which will create opposition or friction.
17. Memorize language and framework library syntax so you don’t have to google it every time you need to use some feature. 
18. Have stability in your life. With predictability and routines you can better plan your day and devote time for learning. Know your values and stick to them. 
19. Learn to write readable code. Learn all you can about Clean Code, SOLID principles etc.
20. Have focus in your life. Don’t engage in everything that comes to your attention in the private life or at work. If you try to do everything you will be less productive because you waste time on all kinds of things that may not contribute to your long term goals.
21. Always learn. Get obsessed with reading and learning from videos. Coursera, PluralSight, Udemy, YouTube are you friends.
22. Have balance in your life. Don’t work insane hours. Have some fun. Live life. Balance in your life is important to preserve good health. Maintain a sustainable work pace. Knows how to not overwork to avoid and crash and burn.
23. Workout. Maintain a level of physical fitness. Going for a run will clear your mind and you’re head will be ready for more action.  
24. Prioritize and set goals for learning and improving your skills.
25. Learn everywhere. Learn while on the treadmill. Learn by listening to podcasts in your car.
26. Know how to research and make good decisions.
27. Reinforce what you learn by trying it out in practice or by blogging about it, giving talks about it etc. Do Coding Katas or have pet projects where you practice your skills. 
28. Stop wasting time. Of course you are not playing Pokémon Go or watching crap TV. Do you really need to watch season 20 of WhatEverSeries on HBO/Netflix? Don’t watch a movie unless you know it has 7+ stars on IMDB.
29. Invest in developer tools and other software for efficiency. 
30. Invest in hardware such as monitors, a faster computer, a noiseless computer, good prescription glasses, good air-condition, an ergonomic desk and chair.
31. Internalize and reflect on what worked and what didn’t. Don’t just try and fail but understand why things failed. 
32. Spend time on post-incident reviews. Do root cause analysis of failures to learn and prevent the thing from happening again.
33. Be curious and always try to understand how things are connected. This will help you understand how things lead to other things and you’ll get better at deciding what should be fixed right away so it don’t come back later with 10x the negative impact. (see technical debt)
34. Don’t be afraid to ask. Rather than spending days trying to figure out some technical issue on your own, ask a coworker who you think may know. Maybe you just overlooked something. Don’t be afraid to lose face. All in all you’ll excel faster if you let go of the fear to look bad when asking questions.
35. Learn how to write good code. Know how to avoid bugs that will come back to haunt you later and make you spend days trying to debug it.
36. Know what to document and not. Document things that you or the team will get back to many times and will save you time. Don’t document things that only create noise.
37. Spend time on reflection and to come up with the really good ideas. During a typical hectic day at work you may be in a multitasking act and react mode with little time for deep thinking. Find time at a less hectic day or during the weekend for lateral thinking.
38. Stay agile. Be aware of just how much to do e.g. features, documentation, communication etc. not wasting time on things that are not important or deliver value. 
39. Improve your creativity. Learn how the creative process works. Know how to do brainstorming. Learn techniques such as the Six Thinking Hats technique.
40. Dear to try new things. Be open to trying new frameworks etc. (if analysis suggest there is value in using it). Sometimes it pays of a lot to replace some old buggy system with something new.
41. Know how to plan. Good planning goes hand in hand with good decision making. If the plans are bad you’re of course at higher risk of failure. Failures along the way leads to wasted time and less productivity. 
42. Learn how to do requirements specifications. Understand business needs so you don’t start developing something that is not needed or wanted. If you have to scrap a module and start over because the customer rejected it on the grounds it was not what they wanted then you have just wasted a heck lot of time. 
43. In your office room agree not to make phone calls at the desk unless you have to. Always go elsewhere when having a private call so you don’t distract the others.   
44. Build up general knowledge on all aspects relevant to development. If you have some basic knowledge in all relevant areas you are less likely to make bad decisions and you don’t have to rely on others to cover all the things you don’t know you don’t know.
45. Learn to write readable code so you understand the code you wrote 6 months earlier.
46. Learn how to get into the zone.  Find time to shut out everything so you can get into the zone or the flow.  Close down the e-mail reader, social media sites etc. Turn off sounds and vibration on the phone.  
47. Improve your communication skills. With bad communication skills you may miscommunicate which can lead to lots of wasted time. Miscommunications may even result in team misunderstandings and distrust that may lead to long lasting conflicts which of course will be a lot of wasted time and energy.
48. Unsubscribe to e-mail newsletter you rarely read.
49. Share knowledge with your team. Help make the team more effective. If the others are productive people you reduce the chance of being held back by someone who’s unproductive.
50. Only sit near people who you need to communicate with as part of daily work. If you sit near people you don’t work closely with you’ll find yourself distracted when they are on the phone or when someone comes over to their desk discussing things that are irrelevant for you.
51. Agree with your coworkers to always detail out meeting invitations. Have a clear agenda and purpose for a meeting well in advance. If you don’t people will come unprepared to the meeting and many meetings will be a waste.
52. Don’t have meetings unless it’s really needed. Read about good meeting best practices. But don’t take it too far. Meetings can be a good way to let people feel they are heard. If there are no channels for giving input or feedback some people will become dissatisfied.  
53. Know when to outsource, when to hire, when to build or buy. 
54. Be proactive. Sense and foresee things to engage in before it becomes an issue and a big waste of time for everyone.
55. Have an eye on details when programming. Ensure the small things don’t get overlooked.
56. See the big picture. Have an overview and total understanding of the things you are developing and why it’s developed.
57. Get involved in meetups, seminars, conferences etc.
58. Take courses.
59. Take a few breaks during the day to clear your head.
60. Read up on the latest in software engineering best practices on everything from bug tracking, agile methodologies, design patterns, continuous integration, unit testing, integration testing to application monitoring, code reviewing, scalability, cloud hosting, containers, databases, etc. etc.
61. Get deep understanding of the programming languages and frameworks you use.
62. Stay sober with a sharp mind. Limit alcohol intake. No drugs. Eat healthy and get a good night’s sleep. Don’t drink too much coffee too late in the day.
63. Be critical. Don’t take things for granted. Know when to ask critical questions like "What was the reasoning behind choosing this solution?" Asking questions brings new insights. 
64. See challenges in a bigger perspective. Avoid getting completely bogged down in a detailed technical challenge. Rethink, think out of the box and make the problem disappear by seeing it in a completely new light. Instead of asking how can I solve this problem, ask instead is this really the problem, what other things could be solved at the same time if I expanded the scope and introduced more simple solution? 
65. Work on projects that motive you. That usually means choosing to work at a place that can give you challenging and interesting tasks.
66. Don’t delay tasks. Tasks waiting to be done contribute to stress and extra work in the form of overhead. Typically you will regularly have to explain to the team why you’re not doing it and all this noise may even become more time-consuming than the actual time needed to complete the task. 
67. Complete one thing at a time if you can. If you are multitasking and working on many tasks simultaneously during a day you’re not likely going to get into the flow where you can create elegant solutions.
68. Do the things with the most risk first so you can be confident that you’ll succeed with thing you’re working on. If you constantly worry that you may not make the deadline it will be a stress factor that may keep you out of zone.
69. Lean how to do Requirements gathering, making sure that the right questions get asked. Again it is all about making good decisions.
70. Know when to analyze and when to just go and prototype the darn thing. Avoid analysis paralysis but don’t just jump into the task without thinking if there are risks involved, if there are path dependencies etc. 
71. Learn about the business you are in. If you are working as a programmer in bank then learn what you can about banking. Get domain knowledge. Of course you can't learn all there is about banking but sure you can learn about areas within banking that are closest to the system you are working on.
72. Write a ToDo list at the start of the day.
73. When debugging use mock data rather than debugging against a remote API or a big ass database table join to save time waiting for the response.
74. Be part of a great team. A team that stands together and fulfills each other will be stronger and will allow you to become more productive. There’s two ways to become part of a great team, either you switch job/department or you work with what you have and spend more time on recruitment, on knowledge transfer. Be inspiring and lead the way.
75. Be a team player. A team player creates a positive environment that over time creates synergy in that everyone wants to contribute. As everyone on the team is enthusiastic it creates a positive spiral of learning and achievement.
76. Make sure the compilation time, application startup time, debugging cycle time etc. is low so you don’t have to sit and wait doing nothing or even worse, you may be tempted to go on Facebook while you’re waiting. 
77. Set up a proper dev, staging, QA, production environment.
78. Use sticky notes as reminders or as cheat sheets.
79. Close windows and tabs you are not using. They just contribute to noise and make it harder to switch between the tabs/windows you are actually using. They may also distract you and eat CPU/memory. 
80. Understanding the Project Management Diamond/triangle. Learn the tradeoffs between cost, time and scope. Again it all comes down to making good decisions. Now you may say that it’s the manager’s job to make decisions. Eventually you will have to make some decisions yourself and you will also want to have your say in the decisions being made.
81. Be passionate about programming. If you’re not you are not likely to have the motivation and drive to keep learning every day. 
82. Keep a notebook to log your work, scribble down ideas and to take notes. You will need it.
83. Get everyone in the office to agree to only disturb others when there is an urgent matter or the thing to discuss is too complicated, sensitive or risky to be described in an e-mail. Sending an instant message or going over to someone’s desk to ask something will take that person out of the flow. 
84. Don’t listen to music at work. If you need to keep noise out use a noise cancelling headset with no sound. Music may be nice and make the workday more pleasant. My position is that music will lead to distractions. You will have control the audio player, change playlists, share songs with friends etc. It will take away focus when you really need to think super hard about something complicated. If you really want to be 10x then you will have to make sacrifices.
85. Anticipate changes. Always consider feature/change requests that are likely to come. Instead of implementing strictly what the requirements says, evaluate likely changes down the road. If the changes are easy to implement now and would be very difficult to implement later then make all the changes at once.
86. Use naming conventions. All too often I have seen noise and misunderstandings because of unclear, vague or incoherent naming. Stakeholders needs to spent time trying to agree on what to call things. DDD helps in this regard.
87. Understand Statistics and cognitive biases. This is important to be able to judge data and how you and others interpret those data, this again will make you a better decision maker. Poor decisions will take you down roads of wasteful development.

A 10x developer is one who is not just doing things the right way but more importantly doing the right things.

How to rate internal product quality during systems development

There are many ways to define and rate product quality. This product quality rating is based on typical product quality assessments for software products and in particular online software.
This post was written for dev teams who do not have a dedicated QA manager or the like.

Why

So why should you do a product quality rating? It will give you an indication of how well the product is engineered in a more holistic perspective. Many will judge the quality of the product based on what end users say about the product. While end user feedback is a very important indicator of quality or value, the product may still have many issues underneath the covers that are just waiting to blow up and become a big issue for the user or other sides of the business.

This product quality review helps to get a complete overview of the product and its strengths and weaknesses. It helps to plan ahead and reduce risk.

How

The rating can be conducted by the product development team, perhaps in collaboration with others such as internal users and other stakeholders. As several of these categories are only known to the dev-team this rating cannot be done by customers or other external stakeholders.

A score from 0 to 10 can be given where 10 would be the score that the best product on the market would receive in that category.

Extensibility

Is the product considered to be extensible? Can it be enhanced with new capabilities or functionalities without hampering its existing functions?

Availability

Is it product ready for immediate use? Does it require a lot of configuration including technical setup? Is it difficult to get started with the product? Are there long start-up times?

Features

Features are the “bells and whistles” of products. How complete is the product? Compared to competitors how would you rate the feature-set in terms of user value? Are you missing important features? Are there many half-finished features?

Performance

Refers to throughput and latency. Can the system handle the user load? Is the system perceived as slow at times?

Accessibility

Is the system accessible for impaired/handicapped users?

Reliability

Does the product perform flawlessly under stated conditions for a long period of time?

Correctness / Conformance

Is it free from faults/bugs? Is it aligned with specifications? Does it conform to standards?

Efficiency

Does the product perform effectively without wasting resources?

Maintainability

Is it easy to maintain code?

Understandability

Is it easy to understand and grasp what the product is for? Does it seem too complex?

Usability

Is it easy to use and learn?

Supportability

Is it well documented? Is it easy to support?

Scalability

Does the product scale well and can it handle controlled increased load? Is it efficient when new resources are added?

Robustness

Is the product able to withstand harsh conditions and rough handling? It should be durable enough to endure erratic variations in stress as well as pressure that too with minimal damage or alteration to its functionality. Does it handle bad or corrupt data?

Security

Are there any likelihood of potential security breaches due to poor coding practices and architecture etc? Have you done penetration test or security audits? Do you have logging, exception handling etc.

Elegance

Is the product stylish, good looking, giving a good first impression?

Further reading

http://sloanreview.mit.edu/article/what-does-product-quality-really-mean/

Why testing tasks should be part of the task board when you don't have experienced testers

Many Scrum teams feel there's something not quite right about testing and their use of a task board. In this blog post I'll go in-depth on the issue of having testing-related tasks or not on the task board. I have found that this is a typical question especially in beginner Scrum teams.

Example Scrum team scenario

To keep this blog post relatively short I will focus on the following scenario:

1. Automated testing code coverage is medium to low so there is an extra need for manual testing.
2. The product is relatively complicated with lots of intricate scenarios/settings to test.
3. The product is a SaaS with thousands of users.
4. You do not have dedicated testers but you have plenty of access to people outside the team that can help to carry out testing. 
5. Testers are not experienced in testing. They know the product to be tested but are not super users. They prefer not to use developer oriented testing tools because they are not highly technical persons. 
6. Testers outside the team come and go and they are quite busy so they need a simple way to carry out the tests without having to log in to a complicated testing suite. Because of the turnover you do not want to provide a lot of training for testers. 
7. You do not have a test manager, QA lead etc.
8. Developers are also inexperienced testers and have limited knowledge about QA.
9. Developers are writing the test scripts because the testers are not qualified to write high quality test cases. 

This scenario may describe a team with a medium Agile maturity level so other more fundamental actions could also be needed such as QA coaching, adding QA related metrics etc. but we will focus on the question of testing tasks on the board.

What is testing anyway?

You should never rollout a feature/User Story/Product Backlog Item (PBI) without testing. Someone has to test it. This might take the form of unit testing, acceptance testing, security/penetration testing, exploratory testing, regression testing, performance testing, load testing, code review, integration testing, web tests e.g. Selenium. In addition to local testing during development. Maybe you want to add UX user testing and maybe you even need to do some regulatory testing.

The purpose of the task board

Before we discuss if testing tasks should be on the board we should first do a recap of what a task board is for. The task board, as the name implies, is for tasks. The purpose of the task board is to keep track of tasks and create visibility to the team and other stakeholders. This helps the team make sure the right things are completed at the right time [4]. The three pillars of the Empirical process which Scrum and Agile is based upon is Visibility, Inspection and Adaption. Tasks on the task board enables visibility and transparency.

Now, some teams try to cram more information onto the board by adding lanes for server environments or lanes such as "Ready for testing", "In testing", "Ready for staging" etc.
The starter task board with the 3 lanes: "To do", "In progress/WIP/Doing" and "Done" is still the recommended basic setup [1],[2],[3],[4],[5],[6],[9]. Remember that the task board is primarily for tracking tasks.

A task can be in progress, done etc. To say a task is in QA/staging or in testing does not make sense. A user story/feature can be in testing but a task is a piece of work to be done. You don't test a testing task. This inconsistency lies at the root of disagreements on how to visualize testing on the board.

Why not have explicit testing tasks on the board

Typical arguments for not having testing tasks for each story:

• It's extra work to add test-related tasks to each user story. Each user story will often have the same duplicated testing tasks. Seems like unnecessary extra work to add them for each story. 
• Testing is an integral part of development so we don't need tasks for it. It is part of the programming work.  
• More tasks means there will be more overhead needed to pass all the tasks through the lanes of the task board.
• The board gets messy when we add tasks that are to be partially carried out by others not in the core team. We like to have full control of what all the tasks are and not have things that relate to other persons in there.
• Testing is something that is done after we have deployed to the QA servers. Seems out of place and not logical to have them on the board. Testing is sort of another phase of the process and it seems illogical to have it alongside programming tasks. 

Some of these arguments include faulty assumptions.

• "The board gets messy when we add tasks that are to be carried out by others not in the core team". This claim assumes that the team don't need to do anything related to testing. Someone has to write the test cases, make sure the test environment is testable, someone has to coordinate testing, make sure testing gets done, provide support for testers etc. There are also tests that only developers can do like performance testing.
• "Testing is sort of another phase". According to Agile practices this is just wrong [7],[8],[10],[11]. This thinking leads some teams to add a testing lane to their board which again strengthens a view that testing is a phase in the sprint and so test-related tasks are not needed on the board.
  

  

  Example task board with lane for testing

  This can also have the effect that epics are not broken down into small enough user stories and tasks. Since it does not always make sense to have a task in testing you may end up having tasks that are actually user stories. When a task on the board is actually a user story it makes sense to have the "task" In testing. 

Testing is not a phase, but a way of life
   - Elisabeth Hendrickson

Ideally testing should be a collaborative effort between developers and testers going on in parallel [8],[10],[13],[14]. In our scenario this is difficult since there are no skilled testers so developers have to step up and write test cases, provide testing support and coordinate testing [11].

In Scrum and Agile development we strive to complete one by one user story. Testing is of course part of that. One by one story is completed to reduce risk and to be able to deliver value increments.

Alternatives to testing tasks on the task board

Based on our scenario I have identified a few alternatives to having testing tasks.
  

Alternative	Implication for test script writing	Implication on carrying out the tests
Developers write test specifications at the start of the sprint based on the requirements specifications, dev tasks, DOD and Acceptance Criteria.	You don't yet have a working feature so you will not be able to try it out and come up with all the test cases at the start. There will be changes underway so the test script will be outdated. To avoid rewriting the test cases or have to come back to it at a later time the developer will delay writing the test cases. Eventually the developer may forget to do it.	Poor test coverage and outdated test cases that cannot be carried out. Rush at the end of the sprint to get the test script together.
Developers update the test specification continuously as they go along.	Will be forgotten because the developer is in a coding mode and the team does not yet have a high quality focus.	The developer may forget to do testing tasks such as performance tests, integration tests, code reviews, security/penetration tests etc. Rush at the end of the sprint to get the test script together.
Developers write the tests when all dev tasks of a story are done.	Who is responsible? Several developers have worked on the user story. It is not clear who should write the test cases so it doesn't get done.	Rush at the end of the sprint to get the test script together.
Developers write test cases for each dev task.	Many tasks are not testable [12]. Often there are no relevant manual test cases to write and there are different types of testing needed of different tasks and so the developer would constantly need to think about testing. Not all developers care that much about quality. Also the test script needs to be organized into a readable non-overlapping set of test cases. You may not end up with a complete and easy to use test script just from piecing together tests from the individual dev tasks. There is no reminder or test task to check off as completed so the developer may forget about it or defer writing the test cases.	Missing test cases. Tests that are hard to understand. Overlapping tests. Rush at the end of the sprint to get the test script together. If you have a lane for testing this does not mean that tests will automatically be carried out. Because some tasks are testable and others not you don't get into a systematic process of writing test cases and eventually things are forgotten or delayed. Also there might not be a clear mapping between the dev task and its test cases so others will not know if the test cases are written or not.
Developers write the tests at day x into the sprint.	The developer will always want to complete as much features as possible to look good or because he don't like writing test specs. Quality is jeopardized because the developer rush to complete the test specification in order to be able to complete the testing before the sprint ends. This is not Agile.	Testing is postponed, it gets chunked up towards the end of the sprint. You may not be able to complete any stories at all because testing was halted for some reason. The feedback cycle lags behind so critical bugs found during testing could not be fixed in time before the sprint ended or the team have to work overtime, again.
Developers test by trying to break each other's code and find bugs.	In this case there is less need to write a test script. Although this may sound fun to developers this alternative ultimately depend on the QA maturity of the developers and the process. If developers are poor in testing they will find fewer bugs.	Without specific tasks with a timeslot developers may do a sloppy testing job especially if there are no guidelines from managers on expected quality levels or if there are no other incentives for finding bugs.

Some readers might have noticed how central the test script has become in our scenario. Maybe you would like to suggest dropping test scripts all together and just end the discussion right here. Developers should be end to end developers and have the skills needed to test everything along the way as until the story is done [14]. In our scenario with a complicated product this is simply not an option because a test script is absolutely needed for QA to make sure edge cases are both identified and tested. Without a test script you get into a testing procrastination situation. You don't know where to even start testing and what has been tested. Systematic testing is needed in our scenario.

Typical problems in immature Scrum teams when not having testing tasks for each story

Developers usually don't like to do or prepare testing other than technical unit testing and performance tests so you may end up with poor tests and test scripts being ready too late. Developers love to code and develop stuff and often find test-related work boring.

Typically the team will end up postponing testing as a bulk job to be done towards the end of the sprint [7]. As you don't have explicit tasks for writing test specs and the task of writing them is usually seen as boring work for developers they will tend to focus on development and postpone writing test scripts as long as they can. This means that they will usually start to work on another story before the first one has gone through testing. You are now in a situation where developers try to have all stories ready to be tested some time before the sprint ends so testers can take over and begin their work. This is what we would call mini-waterfall (not Agile).

Another problem is responsibility. Who is responsible for writing the manual test scripts, the acceptance tests etc? Who is responsible for coordinating or doing the actual testing. If there's no assigned person you can bet it will be deferred or not done at all when the QA maturity level is low amongst developers.

Another side-effect of not having testing tasks on the board is that some person will voluntarily or not take the role of writing the test specifications because that person know it is the only way it will be done. This person might be good at it and he might even like to do it. The problem here is that it creates a dependency. What happens if this person goes away on vacation or is busy doing other stuff for a period of time? The testing grinds to a halt or you have a severe drop in test coverage.

Why have testing tasks as part of the task board

Example of Scrum board with testing tasks

Better estimates

Time will go into writing test specs, so estimates for it should be registered somewhere. Time will be spent setting up the test environment, doing initial integration tests, regression tests etc. Time will go into fixing the bugs found during testing.

By using test-related tasks you can during Sprint planning have a more conscious discussion around what kind of testing is needed, how much time will be needed and how much extra time should be added for fixing bugs found during testing). With explicit testing tasks you will be able to plan better and come up with better estimates. 

Increased Quality

Sometimes tests can only be done by developers. E.g. performance testing or testing that require specific tools e.g. testing infrastructure related stuff. By defining these tests as explicit you don't forget to do them and you have accountability. Everyone sees who is responsible and if it has been done or not.

If you add test-related tasks during sprint planning you will have a slot to think about testing. You will be able to kick-off some thoughts about what needs to be tested, how thoroughly etc.

If there's no defined task for writing the test script you might be pressured to hurry the job of writing the test cases because the burn-down chart will look bad if you spend too much time writing it. When there are no testing-related tasks on the board there are no estimates to burn. The developer might feel he look less productive than other developers who are working on defined dev tasks so the developer may want to just get the test cases done as quick as possible. Not thought through test cases = poor testing.

If you have testing-related tasks on the board you will be reminded if there are some other types of testing missing.

Who is responsible for updating the test scripts when a bug is found and there was no test to cover it? Without a person in charge of overseeing the testing of a user story this may very well be forgotten.

Reporting and status visibility

If you don't have a task for testing the user story you can't display the status of the testing work on the board. There is no way to see if the testing has started and how many hours remain etc. Testing-related work as any other task can have impediments. If you have test-related work on the board it's easier to have discussions about status and impediments.

Efficiency

In our scenario someone in the team has to coordinate or connect developers with testers. Testers will have questions for how to carry out some test task. There are usually questions such as; is it a bug or is it a known issue? A developer has to be available to answer questions such as why a test task is not testable. The correct conditions, for example the right data might not be present to be able to carry out the test. Without a explicit task for the responsibility of coordinating and supporting the testers the tests might very well stop without anyone knowing. You might have unclear communication lines and get extra noise in the team because people don't know who is responsible for overseeing the testing.

Avoid duplicated work. If the developers test each other work it is still useful to have testing tasks so you know which developer is testing who's work.

Continuous improvement

Reducing waste is central to the Agile movement. If everything is visible you get a better overview of everything going on and how things depend on other things. With testing tasks you can more easily improve the entire process.

Without tasks and responsibilities you don't have accountability. If the test script is bad and there are bugs because of poor tests we know who wrote the test spec and we can improve the process by talking to the responsible persons.

References

[1] http://www.clemensreijnen.nl/post/2012/05/24/09-Getting-Testing-Done-in-the-Sprint-e28093-Test-Tasks-on-the-Board.aspx
[2] http://www.mountaingoatsoftware.com/agile/scrum/task-boards
[3] https://msdn.microsoft.com/en-us/library/jj161049.aspx
[4] http://leankit.com/project-management/task-boards/

[5] http://blogs.atlassian.com/2012/08/greenhopper-bonfire-agile-development-testing-awesomeness/

[6] http://manifesto.co.uk/agile-concepts-scrum-task-board/

[7] http://www.ambysoft.com/essays/agileTesting.html
[8] https://www.youtube.com/watch?v=bqrOnIECCSg
[9] http://www.slideshare.net/mikedep01/building-scrum-boards-that-radiate-information-generic
[10] http://smartbear.com/all-resources/articles/what-is-agile-testing/
[11] https://www.atlassian.com/software-testing
[12] http://programmers.stackexchange.com/a/113837
[13] http://www.scaledagileframework.com/developers-and-testers/
[14] https://www.youtube.com/watch?v=yRP29wFqu20

Why fixed length sprints are important in Scrum

Have you been on a scrum team that sometimes change the length of a sprint or postpones a sprint? You are not alone, and in this blog post I list reasons why doing this is a bad idea. 

Oh, and in case you wondered; fixed sprint length IS a well-documented best practice of Scrum [1, 2, 3, 4, 7, 8, 9, 10].

Sprints best have consistent durations.... A new Sprint starts immediately after the conclusion of the previous Sprint [1].

Some common reasons why a team would want to alter the sprint cadence now and then:

• Vacations.
• Important deadlines/releases.
• Unforeseen issues taking up a lot of time of the sprint.
• Now able to complete important user-stories to be released. 
• Staff unavailable (sick team members etc.) 

Here is the full list of why you should stick to a fixed length sprints (fixed cadence):

1. Improve coordination with the rest of the organization 

It will be easier for everyone to know what kind of Sprint phase the team is in (e.g. planning, development, testing, reviewing). This predictability allows for better coordination and planning throughout the organization. The entire organization can self-organize around this rhythm. 

It also helps you to steer expectations. With a fixed length sprint everyone (PO, management, customers, users, and other stakeholders) will know when they can expect new updates. They will know that a new updates typically comes every 3 weeks (or whatever your sprint length is).

2. Save time planning and booking meetings

With a fixed sprint length you can schedule and make plans more easily. A sprint is always the same length, that's it. Now you can schedule Scrum events for the next year ahead and you can do it in one go. You will have less overhead in planning because you don't have to negotiate what should be the sprint length each time, you don't have to make complicated man-days calculations and you don't have to change all future sprints because you changed the length of the current sprint.

Since you can schedule meetings in advance, people can plan their appointments around the Sprint events, rather than sprints being tweaked to fit the calendar of key team members or stakeholders. 

3. Better quality

In general a fixed-length sprint will remove variability and this will lead to more predictability, stability, better flow, better and more sustainable work environment, less chaos. This of course leads to higher quality. 

If you allow sprints to be shortened, say for example because the top management really want to have the next release earlier you not only loose rhythm but you will either have to work overtime, reduce quality, add more resources, or scope down the current sprint. If you scope down you waste resources and throw away planning/analysis that is already done and other work that has been started. If you decide not to scope down you are typically left with one option on such a short notice. You end up reducing quality for example by pressuring the testing to complete faster or by not letting developers do refactoring and other chores. If you decide to work overtime you still jeopardize quality since tired or pressured team members make more mistakes. 

4. More effective work with better flow

With fixed length sprints it is much easier to get into a flow of doing all the Scrum related events such as backlog grooming, retrospectives, sprint reviews. With a predictable schedule you don't have to think about these events. When is the next meeting, will there even be one?

Without this fixed start and stop you may be tempted to move the start and stop date. You might even delay starting the next sprint long after the previous one ended. Beginner Scrum teams in this situation might not schedule the sprints for the months ahead but instead just start a new sprint when it makes sense. Before you know it you skip a retrospective and have to do sprint planning in the middle of a sprint. All this leads to more unpredictability, questions, chaos and less flow which eventually results in lower performance of the team.

5. Improve estimates

Empiricism [10]. If the sprint length varies from sprint to sprint, then the amount of work accomplished in each sprint tells you next to nothing about what to expect in future sprints. If you know there are many vacation days coming up in the next sprint you are better off continuing with the regular sprint length/cadence, be it with fewer actual work days and just disregard the burndown or dev velocity of that sprint.  

6. Enable continuous improvement 

Sprints can more easily be compared. In Scrum we try to fix as many parameters as possible; Time, Quality, Resources are fixed but we change the work from sprint to sprint. By reducing the complexity down to just one adjustable parameter (backlog items) it will be easier to have discussions around opportunities for improving the process. The more variables you change the more complex the dynamics of the process will be and it will be much more difficult to compare sprints to improve the process. If you change multiple parameters around each sprint, how are you going to know for sure what actually contributed to things going better or worse?

7. Improve ability to predict when future features will be released

The organization or customer will know how long it will take to get new releases out the door if suddenly a new feature absolutely has to be introduced as soon as possible. E.g. If the team is in the middle of a sprint and the sprint length is 3 weeks it will take about 5 weeks to see the newly requested feature in production. If the sprint length is variable it would be far less obvious when you could expect the new feature.

For products planned several sprints down the road it would be even more unpredictable without a fixed length iteration.

Velocity (the rate at which a team delivers stories from the product backlog) is useful in forecasting when capabilities can be deployed and available to end users. Without fixed-length sprints, any measure of “work accomplished” is useless in forecasting. Alternatively you will have to make adjustments in the calculations of velocity based on the sprint length. These sorts of calculations become a waste of time as they are hard to get exact and just add extra work to the Scrum master. You can never hope to be 100% precise on task estimates so Velocity will never be exact science anyway. By having fixed length sprints you reduce one source or error in calculating velocity. Keep it simple, stay lean and pragmatic. Aim for predictability and simplicity and forecasting will be easier and less time consuming.

Sure there will always be holidays, sick days, etc. If a sprint has less resources you simply commit to less [5]. You calculate how many man hours is available and plan the scope accordingly. You may now say that this will affect velocity and number of storypoints delivered for these sprints will be lower. Yes and that is fine because you know the reason why. In the Velocity-over-time-graph you can just make a small note about vacation etc. when velocity had a dip. If you know most of the sprint is going to be all messed up because too many people are away you can also decide for the team to do something completely different. You could let developers take the sprint off doing courses, prototypes etc.

8. Improve team motivation

Fixed length sprint helps the team to deliver continuously and provides a sense of accomplishment at the end of every sprint. The team also commit to a chunk of work at the start of the sprint. The team gets motivated to deliver as they themselves committed to doing the work.

With fixed length sprints you have predictability and the team feels more at ease. People like to have routines and familiarity [5]. Fixed length sprints contribute to discipline, habits and traditions that creates team identity. "This is our team and this is how we do it." This again strengthens cohesion and team spirit, which is important for highly effective teams.

If Scrum events falls on random days of the week every sprint then it is hard to build good habits.

9. Accountability

Fixed length sprints with reviews at the end of the sprint encourages the team to deliver on the sprint review. Without a fixed sprint calendar the chance of skipping reviews gets much bigger. Without this regular review delivery the team may procrastinate, get caught up in coding what is fun rather than sticking to the plan or get distracted by other things. Developers don't want to look bad so they will deliver when it is demo time.

10. Better planning of backlog and roadmap

PO can better prioritize and split user stories now that meaningful data on velocity can be accumulated from sprint to sprint. PO can use this velocity as a guide to plan upcoming sprints.

11. Essential for multi team synchronization and alignment

When you scale to multiple dev teams doing Scrum (co-located or not) contributing to the same solution or product, it is obvious that synchronizing the teams will be more effective [6].

If the different teams operate with different Sprint lengths it goes without saying that the teams will not be in sync.

Conclusion

Scrum is all about delivering software in regular intervals to enable fast feedback and to get a effective cadence for the team. Variable Sprint lengths may seem like a good idea, especially in the short term, but in the long run it will be devastating to the progress of a team. There will always be sprints with  holidays and sickness but the show must go on. Do not postpone sprints or adjust the length of the sprint, just keep moving and avoid unnecessary chaos by accepting that some sprints will have lower velocity.  

If you liked this blog post, you may also want to read Scrum Best Practices: Choosing the Right Sprint Length.

References

[1] http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf
[2] http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

[3] http://www.agilitysw.com/blog/31-scrum-whys-fixed-length-sprints
[4] http://books.google.no/books?id=3vGEcOfCkdwC (page 67)  

[5] http://whitewaterprojects.com/2010/12/07/2-models-to-address-the-holiday-sprints/

[6] http://scaledagileframework.com/sprint-execution/
[7] http://www.agileadvice.com/2013/05/15/referenceinformation/the-rules-of-scrum-every-sprint-is-the-same-length
[8] http://blogs.telerik.com/agile-blog/posts/13-09-11/the-importance-of-timeboxing-and-iterations-for-agile-planning
[9] https://www.scrumalliance.org/community/articles/2012/january/a-sprint-is-not-a-mini-waterfall

[10] https://artisanagility.com/never-extend-a-sprint/ 

Systems Thinking usage survey 2013 results

Background 

In August 2010 Ilia Bider posted the following question on LinkedIn; “If System Thinking is such a good method (especially for solving poorly defined problems), why it is not that widespread?”

Similar questions have been raised several times in the Systems Thinking World group on LinkedIn.

In an attempt to move from talking in circles on this topic I developed a survey to get some data that could be used to analyse why Systems Thinking (ST) is not more widespread.

Summary of results

The table below shows the most common answers to the questions of why respondents were not learning more about ST and why they were not using ST more than they already were. These reasons can be seen as key obstacles to the wider adoption of ST. The sample size was 86.

Group	Obstacles in learning about ST	Obstacles to the use of ST
Non-experts	Don't have time. Poor quality of learning material. ST has no process or framework so it becomes too abstract and philosophical. Difficult to understand. Not convinced it is (more) effective.	The mainstream is overly focused on short term goals.  Don’t know enough about ST.  Difficult to apply on real world problems.  ST does not match how things are being done in the organization. Task focus in organizations. No incentives or rewards for using ST.  People do not understand or see the value of ST presentations. System thinkers do not want to impose their style of thinking on others. ST is too vague. There are no fixed criteria you can use to tell if you are using it or not.  Managers are not interested in what the ST analysis show.  ST is abstract and ill-defined.
Experts	ST is not perceived by peers as professional.  There is no ST diploma or skill level to brag about. Theoretical disagreements and change.	The mainstream is overly focused on short term goals.  Managers are not interested in what the ST analysis show. System thinkers do not want to impose their style of thinking on others.  Hard to introduce ST because of the dominant linear way of thinking.  ST does not match how things are being done in the organization.  Difficult to communicate.

The summary above is based on the most frequent answers (>10% of responders marked the same checkbox question) and issues that could be identified by grouping similar free text responses.

Survey method

The survey was carried out during February of 2013. We invited participants by using social media and by sending a broadcast e-mail to all members of the Systems Thinking World LinkedIn group. We encouraged only people who had been introduced to ST to participate.

At the time of writing 89 responses had been registered. The survey can still be viewed at the following locations:

Survey form	http://bit.ly/XPdc6f
Automated visual summary	http://bit.ly/YljT27
Raw data spread sheet of all responses	http://bit.ly/Zk4XBE

In the survey we asked questions such as why they did not use ST more often and why they did not learn more about it. The survey did not cover the opposite aspects of why people were using it and why they wanted to learn about it. Our focus was on the obstacles and barriers to the wider adoption of ST.

There are also topics that could be included but I did not think about during the design. One such topic is the fear of carreer suicide and the undermining of power-holders.

There were both multiple choice answers and free text fields for respondents to fill out. Google forms were used as the survey engine.

Issues with the survey design 

The survey did not define ST or what was meant with using ST. This may have led to different interpretations of questions such as “Why do you not use it more often?”

The definitions of what ST is and what it means to use ST are still heavily debated. It seems that some think of “using ST” as simply having a certain mind-set. Others see it more as using a diverse set of modes of thought and different systems related disciplines for analysis and synthesis, while others tend to see ST more along the lines of a methodology to be used in inquiry and problem solving. These different interpretations of ST have surely influenced what respondents answered on the question “How often do you use Systems Thinking?”

The use of a Google form as a survey does not exactly meet the highest scientific standards but it was an easy way to get relatively good data.

Grouping of results

We have divided all respondents (n=86) into two groups. We call these the “experts” and the “non-experts”. The reason for this separation is that the results from these two groups are quite different and it makes sense to divide into these two groups for later analysis. If we are to answer the question of why ST is not more widely adopted it is more interesting to look at answers from non-experts. The non-experts are those who adopt ST. The experts are instrumental in the adoption.

Group	Respondents	Description
Experts	46	Respondents who say they contribute to the field…provide training etc    AND Respondents who say they have been following Systems Thinking and related topics for years...
Non-experts	40	All respondents – Experts. People who have no prior knowledge of ST have not been invited and included in the survey results.
Deleted	3	Empty or invalid response data
Total	89

¨

Survey results details 

Age profile of respondents

Stated frequency of the use of Systems Thinking

Experts in response to “Why do you not use it more often?”

The mainstream is overly focused on short term goals, bottom line and quick wins.	9	18.4%
Managers don’t care what my ST shows anyway. They only hear what they want to hear	5	10.9%
I do not want to impose my style of thinking on others.	5	10.9%
ST does not match how things are being done in my organization	4	8.7%
ST is not comprehensive/complete. I can only use it for parts of the inquiry	3	6.5%
People do not understand or see the value of my ST presentations	3	6.5%
I feel I don’t know enough about ST	2	4.3%
You can’t measure its effect.	2	4.3%
I am rewarded for doing specialized tasks. Not for predicting the future and pointing out how things may be connected.	2	4.3%
I am afraid that people will think I am crazy when I show them my lengthy ST analysis.	2	4.3%
ST is too vague. There are no fixed criteria you can use to tell if you are using it or not.	2	4.3%
I do not want to be looked on as the besserwisser.	2	4.3%
I don’t want to think all day long. ST requires too much thinking.	1	2.2%
I am not convinced it provides added value for the problems I am working on.	1	2.2%
ST requires a suspension of self-interest. I am not able to push my interests.	1	2.2%
I don’t want to think all day long. ST requires too much thinking.	1	2.2%
I am just too impatient	0	0%
I find it difficult to apply on real world problems	0	0%

32 (70%) of experts say they are using ST as much as they can when they come across situations that warrants its use.

Free text answers from experts on “Why do you not use it more often?” 

Hard to introduce ST because of the dominant linear way of thinking 

“…the evaluation community is a tightly knit community that is immersed in the reductive, linear paragdigm – even if you were once part of that community – just talking about ST pushes you out into the periphery to a position of less power and legitimacy, even if you previously had more legitimacy with less professional experience.” 

“I use it often. But I can say why people surrounding me don’t use it often. They think it’s abstract. It’s not solving problems the way they would like, because they are stuck with the linear model and can’t see the big picture. Not only they can’t see it, they don’t want to see it. Their daily life is based on linear assumptions, and the status quo is what they look for. They are wealthy Swiss people, and are not interested in changing anything around them. It’s understandable. Short term future is all what our brain seems to be programmed for. It needs effort to look further away. ST needs some effort before really grasping its concepts. People are too busy maintaining their achievements – both material and spiritual – to decide to look further away.” 

“Audience thinks context is irrelevant and are confident in their assumptions, if they even know what they are.” 

“Until the ‘T’ in ST is expanded to mean modes of thought other than the use Aristotelian logic and Cartesian assumption about the nature of the mind we will make no progress...”

Difficult to communicate 

“Other people don’t understand it easily and it can be hard to collaborate.”

“I use it regularly for my own work and personal life. However, I have trouble explaining it to others.”

“If others understood ST better, it would be easier to use more frequently.”

“Also, I find that the language of ST is often exclusionary. For our workshops, we've had to make the language of ST more relate-able to our audiences who come from all walks of life and have varying levels of education.” 

Not seen as important or significant

“Currently it is not a priority at my place of work.” 

“Others discount its value, saying everything is connected to everything else, so what?“ 

Time consuming 

“It is time consuming to use well. Others are impatient with process analysis.“

“Boundary issues are difficult to define.”

Experts in response to “Why are you not learning more about Systems Thinking?”

ST is not perceived by my peers as professional	7	15.2%
It is difficult to learn about ST. Poor quality or ambiguous learning material/courses.	4	8.7%
There is no ST diploma or skill level I can brag about.	4	8.7%
I don't have time.	3	6.5%
I am not convinced it is more effective than other ways of doing inquiry.	1	2.2%
I don't feel welcome in the ST community.	1	2.2%
ST has no process or framework so it becomes too abstract and philosophical for my taste.	1	2.2%
I don't care about systems. I already have enough things to think about.	1	2.2%
I am not convinced it is more effective	1	2.2%
I find ST difficult to understand.	0	0%
I don't like the ST community.	0	0%
ST is not sexy, cool or trendy. (Appealing)	0	0%
ST is boring.	0	0%
I have little or no use for it.	0	0%

23 (50%) of experts say they are in the process of learning more about ST.

Free text answers from experts on “Why are you not learning more about Systems Thinking?” 

Theoretical disagreements and change 

“Gets a bit atomistic with people proselytising their favourite words and models and flogging old horses with new names, loosing its pluralistic origins. On the other hand I am learning and advancing the thinking everyday, but it's not the be all and end all.”

“I had to create my own interdisciplinary PhD program (2001 to 2005) to learn about ST as part of a health policy and evaluation PhD. Luckily, I had access to some stars in the field - but even they argued with each other a lot, especially about how to use ST and complex systems theory in evaluation. That is continuing to be a big debate!” 

No community 

“Before STW, there wasn't enough group support to motivate continued learned, even from my worldwide network of ST colleagues (who tend to be mere critics and non-joiners)” 

No best practices for teaching ST 

“As a teacher, I find that really good introductory books for non-technical graduate students are rare and many consultants' books tend to be too expensive for use in only 1-2 class sessions within a course. Guidance how to teach ST to others has been difficult to locate. The ST community seems to be insular and focused on talking to each other and the ST past.”

Not seen as important or significant by managers

“...no perceived value by the public. This leads mgmt to put roadblocks in the way and substitute bureaucracy like cmmi, agile, and just plan erroneous but popular approaches.“ 

Too academic 

“I would like to say that I think ST has been marketed as a tool for academia, business management and maybe management of governmental agencies. I have done a lot of searching online and there are very few people (online at least) who are trying to give ST tools to non-academic, non-managerial people. I think this is a huge loss and keeps ST stuck in an ivory tower when it should be down on the ground helping with the daily chores. Linda Booth Sweeney is doing an incredible job, teaching children systems thinking...“

Experts in response to “How often do you use Systems Thinking?”

Daily	38	82.6%
Once a week	6	13.0%
Once a month	0	0%
Rarely or never	0	0%
No answer	1	2.2%

Non-experts in response to “Why do you not use it more often?”

The mainstream is overly focused on short term goals, bottom line and quick wins.	16	40.0%
I feel I don't know enough about ST	15	37.5%
I find it difficult to apply on real world problems.	11	27.5%
I am rewarded for doing specialized tasks. Not for predicting the future and pointing out how things may be connected.	9	22.5%
ST does not match how things are being done in my organization.	8	20.0%
People do not understand or see the value of my ST presentations.	6	15.0%
I do not want to impose my style of thinking on others.	5	12.5%
ST is too vague. There are no fixed criteria you can use to tell if you are using it or not.	5	12.5%
Managers don't care what my ST shows anyway. They only hear what they want to hear.	4	10.0%
I am not convinced it provides added value for the problems I am working on.	2	5.0%
I do not want to be looked on as the besserwisser.	2	5.0%
ST is not comprehensive/complete. I can only use it for parts of the inquiry.	2	5.0%
I don't want to think all day long. ST requires too much thinking.	2	5.0%
I am just too impatient.	2	5.0%
I am afraid that people will think I am crazy when I show them my lengthy ST analysis.	2	5.0%
I am just too impatient	1	2.5%
You can't measure its effect.	1	2.5%
ST requires a suspension of self-interest. I am not able to push my interests.	1	2.5%

30.0% (12/40) of non-experts say they are using ST as much as they can when they come across situations that warrants its use.

Free text answers from non-experts on “Why do you not use it more often?” 

Abstract, vague and ill-defined 

“I find my peers surprisingly uninterested, i also find that, similar to sustainability, people have different interpretations and understandings of systems thinking…”

“The main reason is that few people are able to grasp it and fewer willing to apply their minds to it.” 

“I remain to be convinced of the value and credibility of the approach” 

“Seen as too complex.” 

Requires buy-in 

“Requires a lot of trust that other people/parts of the Organization will buy-in to the approach over the medium to long term.”

“Lack of local movement that would give more reason for business to use ST.” 

Non-experts in response to “Why are you not learning more about Systems Thinking?”

I don't have time	9	22.5%
It is difficult to learn about ST. Poor quality	8	20.0%
I find ST difficult to understand	8	20.0%
ST has no process or framework so it becomes too abstract…	6	15.0%
I am not convinced it is more effective than other ways of doing inquiry.	5	12.5%
There is no ST diploma or skill level I can brag about	2	5.0%
I have little or no use for it.	1	2.5%
ST is not perceived by my peers as professional	1	2.5%
ST is not sexy, cool or trendy. (Appealing)	1	2.5%
I don't like the ST community.	0	0%
ST is boring.	0	0%
I don't feel welcome in the ST community.	0	0%
I don't care about systems. I already have enough things to think about.	0	0%

57.5% (23/40) of non-experts say they are in the process of learning more about ST.

Free text answers from non-experts on “Why are you not learning more about Systems Thinking?”

Difficult to use 

“It is difficult to start modeling and applying ST to own problem domain even I have read books and articles with clear and good examples.”

“Being reminded, or told, how ST could help with particular things I am working on. The provision of a resource that promised to be intellectually exciting and practically helpful might be a prompt. That would be something that explained the principles (and pointed to other sources where they already exist) but then had lots of examples of how you could use it practically in your day to day role as a manager, consultant or whatever.”

“I haven't seen practical examples of it being used successfully in everyday business affairs and am not sure what techniques to use when.” 

Not seen as important or significant 

“…It is not that there are reasons not to (boring, not sexy etc.). It is more a question of if and when it rises high up enough the priority, or 'to do', list to actually get done. That's not quite the same as 'don't have time' - there is time, but there are many competing pressures for it.“ 

No authority on the common place to start learning 

“I don't know how to start, what path to follow. How to pick materials to learn from.” 

“I haven't found a way to actually learn ST. What I started to read wasn't appealing enough to dig into it all”.

No community 

“I think doing ST together with others (best: interdisciplinary) is a bigger learning experience than trying to figure things out alone. Finding others who are nearby, open and interested to do this together needs some time and luck :)” 

Non-experts in response to “How often do you use Systems Thinking?”

Rarely or never	12	30.0%
Once a month	11	27.5%
Once a week	10	25.0%
Daily	6	15.0%

Afterword

With this I hope the survey has given the ST community valuable data for further analysis.

I hereby encourage you to use the data to come up with solutions to how we can make ST more widespread, as I strongly believe that an appreciation for Systems Thinking among the population would make the world a better place.

Checklist before launching a website

If you are developing a small website for a hobby project or similar you might not have test scripts or a test plan. Here's a simple check list you can use for testing your site.

Design / Sign off

• All relevant persons/stakeholders have been given the chance to comment on the design.
• Relevant persons understand the concept/point of the site.
• Someone other than you can use the site with ease.
• Design has been tested on old projector with poor contrast. (There are tools to do this also)

Features

• All pages have valid title and meta tags.
• Other typical SEO guidelines.
• 404 page.
• Internal Server Error page.
• Content can be printed? (Print style sheet).
• Meta tags.
• Fav icon.
• Semantic Html
• Added analytics. Website visitor tracking statistics. E.g. Google analytics.
• Site map.
• Friendly URLs
• Form validation.
• Mobile support.
• Share buttons: Twitter, facebook, LinkedIn etc.
• Contact form works.
• humans.txt

Performance

• Yslow.
• Stess test.
• Pages checked for page size. Page footprint of more than 1Mb is bad.
• Caching evaluate. (Page output caching, data caching etc, web server caching, E-tags etc)
• Log been checked for errors.
• Home page downloads within 10 seconds or less.

Stability / accessibility

• Tested in all relevant browsers such as IE, Chrome, Firefox, Safari, Opera on different OS and with different versions?
• Site tested without JS enabled in the browser.
• Tested with various screen resolutions both small and large.
• Site tested with W3C CSS validator.
• Site tested with different screen resolutions and on iPad.
• Site tested on mobile.
• Site tested using accessibility toolbar etc.
• Site tested with full JS error notification turned on.
• Do you know your monthly bandwidth limit? Make sure your site resources are not to big and visited by to many people.
• All assemblies checked for memory leaks.

Security

• Backup.
• Robots file.
• System been evaluated against security threats.
• OWASP guidelines evaluated.
• Need to set up e-mail or SMS alerts? (There are monitoring services you can buy)
• ASafaaWeb security analyzer

Content

• Content placed consistently.
• Tense/Style of writing consistent.
• Dead links check.
• No empty pages.
• No Lorem Ipsum pages.
• Pages spellchecked.
• Content formatting consistent.
• Alt text on images.
• You have contact info, privacy, feedback, terms and copyright info.
• Site tested with realistic content.
• Site checked for missing resources (404 on images , js, etc.).

Content publishing related editor support

• Nested lists.
• Links.
• Images in text.
• Other text formatting.