While providing the office coffee baristas with some free passes to my yoga studio this morning (they were super interested in trying yoga when I mentioned I started teacher training), I ran into some colleagues from my previous software development project. This brought back memories as well as strong instant reactions. Since writing can be very therapeutic, I am hoping that recording these thoughts will help me process and handle these reactions and ultimately, let them go.
My last project is a classic example of how a software project can "fail" or at minimum result in a more painful process w/ high staff turnover and a lower quality product. Most members of the project acknowledge that there were challenges - the scope was too broad, the schedule too tight, process was unclear, staff mis-alignment, clients did not understand how to build software, user community was divided with no clear arbitrator, etc. However, the fundamental issue is that there was no common understanding nor agreement on the product vision and goals. Everyone's head was in their own rice bowl and decisions were made to placate individual egos/ambitions at the expense of the product. It became an "everyman for himself" type of environment, resulted in leaders feeling powerless and cut off at the knees, and this dysfunction ultimately creeped into the design/development of a product that does not ultimately help anybody.
It's very easy to fall into this trap in software projects, since teams are composed of very diverse individuals with different skillsets. Many folks in software are highly specialized and used to thinking through one lens - i.e. "I'm a tester" or "I'm a code monkey" - it takes a lot of team leadership and individual willpower to pull the team out of that thought process and start seeing the bigger picture. In addition, software targeted to a narrow customer base [e.g. custom systems development in Defense] requires lots of domain expertise, so the development team needs time to understand the domain. For my last project, we brought in domain experts (bosses of power users...not the users themselves) to help educate the team, however this brought a host of additional challenges...where in order to ensure that the product was developed to meet their needs, the domain experts expanded their roles significantly beyond their expertise and were ultimately frustrated as well.
Fundamentally, it's a shift in attitude for everyone involved - to really see the value in the rest of the team and what everyone brings to the table and forget about "me" and "my needs." There also needs to be a high degree of both group and individual accountability - everyone has a stake in making the product better and everyone can do things better. It's important for the team to realize this and feel empowered to experiment with techniques till they find what works and what doesn't work.
There are a few techniques that leaders can apply to help the team move forward. A great one discussed during the Santeon Group's "Fundamentals of Agile" Course is to hold a team exercise to develop a charter capturing vision, goals, roles and responsibilities. This exercise allows for everyone to have input in defining the end product, and also feel a greater sense of ownership. It also provides concrete guidelines which can be used to support decision making in the future - so when the project hits bottlenecks where there needs to be some horse trading, at least decisions are based on previously agreed upon criteria.
e.g. if the team defines value as "providing working software" - if the bugs list becomes out of control, resources should be shifted to addressing bugs as opposed to building new functionality
This is not idealistic - it's very achievable to some degree even within the bounds of current contracting processes. It just requires a shift in attitude.
No comments:
Post a Comment