Process Specialist: Tools are just the things you use to do the process; the value is in the process. Let’s do a process first roll out.
Tools Specialist: Tools are the things people actually use. Process is academic and is constrained by the tool features anyway. Let’s do a tools based roll out.
In Holistic Software Development the real value is not in the tools or the process but in the people. Process and tools are something that you add if the people need them.
Tools can be a catalyst for process which can help people be more productive by being a source of common agreement on ways of interacting and a library of practices to choose from but the real value in knowledge work comes from people working together. To that end we recommend that communities of specialists choose the toolsets that will help them (potentially democratically), not those that manage budgets.
We’ve noticed a general trend towards developers seeking open-source and internet based tools which are often very cheap (if not free). Executive management, on the other hand, is the driver for expensive tools packages from large vendors. Give the developers what they need and want, it’s cheaper and better than swallowing a large vendor sales pitch.
When working across teams or across physical areas (even in the same building) we recommend use of development collaboration tools and business collaboration tools.
Development collaboration tools such as work item trackers, (agile) planning tools etc. can be useful to provide a record of items such as Requirements, Changes, Bugs etc. and the links between them. Although often the best tool for this information is a whiteboard and some sticky notes, that solution isn’t very scalable. If a team is entirely self-contained and collocated, then a physical work item tracking mechanism such as a planning wall or board might be more appropriate.
Teams benefit from a single work-item tracking tool so that they can send each other bugs, changes, requirements and other items. A single tool also allows for links between items and wider collaboration on major problems. Avoid tracking work items for reporting purposes, track them for internal team workflow.
Business Collaboration tools such as document/media sharing and editing platforms and social business software (blogs, wikis, instant messaging etc.) help teams communicate both internally and externally and can be extremely valuable in terms of enabling continuous communication between business people, technical people and wider stakeholders. We recommend that Business Leaders honestly and actively engage with the people in an organization using social business tools, as well as in person, to reach a wide audience and gather the most feedback. Business Collaboration tools, while useful, are no substitute for direct face to face communication however.
Self-Organizing Teams vs. Common tooling
Self-organizing autonomous teams should ideally be able to select their own tooling, picking and choosing the tools that best suit them as time goes by. However, if teams need to widely collaborate and tools need corporate hosting, backup and recovery, common authentication, licenses, support etc. there are numerous business reasons to implement common tooling stack(s) for teams to use rather than have every team making different tooling decisions leading to a fragmented chaotic tool environment.
We recommend that communities of interest (organically formed rather than appointed) are invited to come together to make tooling choices. Those that care can join the discussion and help make the decision. The daily users of a specific set of tools are best placed to make the decisions about which tools to use. In this way communities can self-organize and choose their tools that can then be hosted organizationally.
Very few, if any, complex organizations will get away with a single common tool stack, needs for niche tools such as specialist code editors, visual planning plugins etc. will likely vary from team to team. We recommend supporting this variation where integration to common workflow / repository / artefact management is possible.
Tools environments will change over time as new and better tools become available and so we recommend that tools implementation is made with an expectation that tool choices will change.