--- title: "Organization Problems - Sounds Familiar?" url: "https://osherove.com/blog/2007/10/18/organization-problems-sounds-familiar.md" canonical: "https://osherove.com/blog/2007/10/18/organization-problems-sounds-familiar.html" published: "2007-10-18T07:08:03" updated: "2007-10-18T07:08:03" tags: ["Agile", "General Software Devel...", "altnet", "altnetconf"] author: "Roy Osherove" description: "I just finished a summary of a company's review about work modes and problems before we can start doing something about it. I'm posting part of it as anonymous because I think this seems to relate to many other…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Organization Problems - Sounds Familiar? By Roy Osherove October 18, 2007 In [Agile](https://osherove.com/blog/category/agile), [General Software Devel...](https://osherove.com/blog/category/general-software-devel), [altnet](https://osherove.com/blog/category/altnet), [altnetconf](https://osherove.com/blog/category/altnetconf) **Historical article** · Originally published October 18, 2007; technical details may be outdated. I just finished a summary of a company's review about work modes and problems before we can start doing something about it. I'm posting part of it as anonymous because I think this seems to relate to many other companies out there: > "**The QA Department** seems to be the main gripe of most of the departments in the company. The main issues are of it being staffed with personnel who does not really understand the application aspects of what they are testing, and so don’t really know **what** to test in the application. Another main issue is the lack of knowledge about proper QA methods. Each QA department seems to be reinventing the wheel and creating its own methods. This also leads to the face that most tests are not automated and most tests don’t even get repeated for regressions after each release, which leads to an overall lower quality in the product. > > ... > > **The Marketing division** seems to be a large source of problems. Most of these come from the fact that Marketing people also serve as Product Managers in the company (Those who should be truly representing the client’s real needs), setting feature priorities and agenda for the next release with ultimate decision power. Because there is a conflict of interest between the role of marketing and role of Product manager, many of the things that are requested from other departments such as Customer Support are considered haphazardly if at all, which leads to a product that contains features a real customer might not need, but misses features the customer really does need. Add in a true product manager role into the company can help alleviate many of these issues as well as the partial amount of time that marketing has of actually communicating with all relevant departments as a customer. > > ... > > **The X group** is highly motivated in implementing agile practices such as unit testing, and are suffering from lack of automation in the group, “islands” of knowledge and lack of code reviews. > > ... > > **Management** has a big role in creating the current conditions for problems. The lack of CTO, and the fact that the CEO is the one who is “acting CEO” lead to lack of real technical leadership (lack of time to handle things) and no clear “head” to turn to and get quick good answers. Management can help by supporting practices such as unit testing and automation and getting and hiring good people into the missing roles in the company (Product managers, CTO) and by allowing for real time extensions to projects that would like to implement them. > > ... > > Generally speaking, there are various “pain points” that currently prohibit the departments from either getting the full data they need, influence the current releases so they contain the correct feature set or be more productive in their work. A main example is the big confusion about the various issue management software: which is reported to be almost unusable and there is no clear sync between that and X and Y issue management software also used in the other departments. Also the fact that developers aren’t really aware of what the application is used for in the field leads to believe that more time spent with the customer can help. Overall many “small” things can make for a large difference in the organization’s ability to create quality software and get better communication between the departments more quickly. > > " ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Nov 21, 2007 ### [\[Songs\] Every Build You Break, Reflection](https://osherove.com/blog/2007/11/21/songs-every-build-you-break-reflection.html) - Nov 17, 2007 ### [Mocking LINQ Queries, Extension methods and Anonymous Types](https://osherove.com/blog/2007/11/17/mocking-linq-queries-extension-methods-and-anonymous-types.html) - Oct 12, 2007 ### [Four Resources to learn about BDD](https://osherove.com/blog/2007/10/12/four-resources-to-learn-about-bdd.html) - Oct 10, 2007 ### [Agile Dev Center on MSDN](https://osherove.com/blog/2007/10/10/agile-dev-center-on-msdn.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/