Five Symptoms of a Dysfunctional Software Development Group
1. "We released poor quality software because the testing team didn't do their job well"
2. "We can not start development unless the requirements are frozen"
3. "Unit testing and integration is not a developer's job"
4. "Don't tell me how to manage software development. In my previous organisation we were CMM Level 5"
5. "I need more resources otherwise the release date will slip, unless we reduce the scope and plan a separate testing/hardening phase"
There are more but these are my top 5.
Do you agree? What are your top 5?
Enterprise Architect - Head of AI practice at Navikenz
10yVery much true.
India's largest group of stars, professionals,leaders !(50000+)
10yBrilliant observations and solutions! Education,experience and ownership counts.
CTO, Executive Vice President @ Capgemini, Product Innovation with AI & GenAI, Ex-Microsoft, Ex-Jio, NICE GCC Site Lead, People Analytics, Educationist, TEDx, Executive Coach, Book Author, Startup Advisor & Investor
10yWith my 19+yrs of experience, I have seen all of these reasons and more. While some of the reasons might be genuine - It is the ownership that matters. The best reason I always here is - this project is "different". Sure, since this project is different that is why we are doing this - else we could have used the famous feature Copy+Paste. I think, the underline core issue is "accountability" - are we holding people accountable for what they are supposed to deliver? Business Analyst - should be held responsible to correctly capture the needs & requirements Developers - should be careful about the quality that goes out to the testing team. Assuming there is somebody there who will test - is not a good attitude. The mantra I use is "If somebody else can find a defect - why can't you yourself find it". Also, delivering on time is their responsibility. Testing - testing team is not responsible to find defects (that should have been done by the development team while doing unit testing). Tester's job is to "Ensure" that there are NO defects. They are the final gatekeeper - they should be freed up to find those difficult defects rather than expecting them to find simple / straight forward defects that the developer could have found/avoided. I was able to implement several of these practices in multiple groups in Microsoft. This resulted in improvement in the project success rate in terms of ontime delivery and with NO major defects. The inherent formula for success was - asking each individual to commit to certain KPIs that they are comfortable, right from the estimates, planning, delivery and schedule. I have documented these experience in my book.
Entrepreneurial executive - M&A Dealmaker - Family Office, Private Equity & Venture Capital
10yBased on CMM level 0?
Good samaritan
10yHey Manoj good points! One thing I have learnt being more on the domain exerpertise side of the software development business is the huge disconnect between what the end user really wants and what the developer understands it to be! I am not saying anything new here and there have been several famous jokes on this disconnect. But the amazing thing is that this continues in every project and needs to be addressed actively. Think there are several root causes for this- a)Software industry typically paying less than the domain industry especially in financial services thereby not able to attract best talent there.b) BAs in IT industry are at best domain aware but not domain thought leaders c) business requirements from client side are either lacking in thoroughness and detail or are too tunnel visioned d) business and IT don't see eye to eye in many organizations and politics often blurs clarity e) multi-departments in business often don't spare or get enough time to define requirements in a wholistic and consistent manner f) often in many organizations this job is left to external consultants who mainly try to impress the senior managers with trendy powe points and blue skying but miss dotting the eyes and crossing the Ts when it comes to defining relevant and applicable solutions at the ground level. All these and many more that I can think of keep the gap wide and often result in Projects failing to have a successful outcome. I see some organizations crack this well, one example is BTG Pactual a marquee investment bank in LATAM who have a really smart IT cum business team that defines and drives projects with clear responsibilities and accountability to create a smart IT ecosystem in the organization, which is a primary driver for their stupendous success. What do you think and what are potential solutions to bridge this gap ? Bhaskar