Tools

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.

Development Tools
We recommend starting with minimal tooling focused on development environments such as IDEs, source version control tools, unit testing and build tools. The choice of these tools will be based on the technology used by the team and Enterprise Architecture constraints, however, we recommend that developers are able to install development tools and control their environments without friction.
We recommend settling on a single source code management solution rather than having several, unless niche technology constraints make that impossible. Git has become the de facto standard and so most organizations would do well to standardize on git, although a range of git servers are available.
Developers working productively is the source of Business Value generation for Software focused businesses. Slowing developers down causes system inefficiency and damages morale.
Collaboration Tools

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.