Three (3) questions about the organisation (people, structure and processes)
APP development seems to be managed with a STAR-topology approach, in which nobody knows what the other people are doing and only the manager (Team Leader, or something) is supposed to know, leading to problems (e.g. BigProduct modules added to BigCustomer) and a weak sense of ‘belonging’ to a project.
Could we perhaps modify this to a more shared form of knowledge on projects, thus increasing the ‘collective ownership’ of projects?
With the new upcoming ‘SCRUM-oriented’ organization, what criteria will be used to assign people to teams?
As far as I have seen so far, the ratio of developers versus managers within a project seems to be quite low: few developers per manager, with some (perhaps one) case of the ratio being < 1. Is this going to change with the new organization, and if it is, how?
Three (3) questions about your operative tasks (all the activities that produce software, documentation and service deliverables)
Currently I am involved in some CM tasks related to automating the build of BigProductForMobile modules (which I enjoy) and advice on the projects’ app builders, and I should also be involved in active app-related development. Unfortunately for some reasons (deadline conflicts, forced vacations, conflicting priorities…) the percentage of actual development is not what we planned, and I feel that I am not yet being ‘used’ at my full potential. Since I really want to contribute shaping the future of MyCompany, what can I do to accomplish this?
In the recent Software Delivery training sessions it has been noted that we are all ‘seniors’. Given this and our experience, will there be chances to be involved also in BigProduct/BigProductForMobile development within the same ‘SCRUM team’, or will there be dedicated SCRUM teams based on technology?
I believe that every developer and perhaps not only developers must be trained in proper use of versioning systems. This is true for Engineering team but is less common in other teams. Since we are all seniors and it’s just what we use everyday, is there any plan about this, and maybe having a consistent way of using versioning tools?
Three (3) questions about impediments that impact your work the most (big one-shot impacts or smaller but repeating impacts)
Sometimes I find it hard to communicate the need and value of new solutions or ideas or just the need to carry out simple ‘housekeeping’ tasks to Team Leaders, who are first and foremost interested in the ‘cost/benefit’ figures and are less concerned about growing technical debt, or to explore possible process improvements that could save time and eliminate error-prone manual activities. What can I do to better put my point across? Shall I ‘act as a wolf’ and do what I believe is right for the project?
(e.g. BigCustomer project – automate the build of test binaries using the same artifact to be delivered to customer and not from source;
New App Builder Improvements I designed with John GoodColleague – tried many times but never actually managed to _have_ a meeting to explain its benefits to BigCustomer team
BigCustomer project – simple project restructuring)
Scheduling of the activities is complicated. There are weeks where I have a scheduling of 25 entries for 40 hours of work, which means that on average we have to schedule activities of less than 2 hours. Moreover, quite often these activities are not known in advance, say at the beginning of the week or some 1-2 days ahead, and sometimes even the correct belonging of a task under CM or under Apps development is in question, leading to delays in having tasks ready for scheduling. What actions can be taken to improve on this?
Often the technical implications of new features in app development, as far as building and packaging is concerned, are neglected by dev managers, perhaps due to the fact that their experience is mostly in the J2EE realm which is radically different than native app development. If I were a manager and I did not grasp my project’s technology I’d put a warning to myself with regards to any ‘new’ feature that’s going to be added to my project asking everybody (building and packaging included) if this would break anything, in order to avoid rushing a ‘hacked’ solution to get the package out to the customer. How can I be more effective in communicating this need?