Organizational effectiveness/Learning center/Software and technology

This is a page about a strategy included in the organizational effectiveness learning center.

Use this page as part of the organizational effectiveness tool.

Software development and technology work

Please take another look at the section in your organization’s Organizational Effectiveness Questionnaire Report about software development and technology work (Question in your report). This section includes a chart that may indicate specific places where you have high scores (4 or 5) or low scores (1, 2 or 3). Below, we’ve listed a few questions you may want to think about before taking a closer look at these strategies and resources.

Is this strategy a strength or a challenge for you? What are you good at, and what are you less good at?
Does everyone in your group agree on your scores for this strategy? Is there variance (differences between your scores) or consensus (everyone has about the same score)?
Are any of these scores unexpected? Does it seem like they accurately reflect your organization’s capacity in this area? Are there key strengths or challenges that the Questionnaire or your scores do not capture?
Within this strategy, are there particular strengths or challenges that your scores reveal?
How important is this strategy to your organization’s ability to achieve impact? Is it a key strategy for your organization, or an optional strategy?
Is this an area where your organization is interested in prioritizing capacity building?

Recommendations for technology work

If your organization wants to get better at software development and technology work, here are some concrete recommendations that may help your organization build capacity in this area. Some of these recommendations may be more or less applicable depending on your organization’s strengths and gaps in this area, and your organization's context. We realize many organizations are already using strategies like these.

Phase 0: Ideation.

You have an idea for a technology initiative, and are considering it as part of your organization’s programmatic work.
Understand your highest priority, and how technology relates to solving it. Technology should not be regarded as something to add to a program portfolio for its own sake, but should directly support the organization in executing in alignment with its strategic objectives and core competencies.
Wikimedia is an open source project. When identifying a problem that has a technological component, try to determine the role individual volunteer contributors can play -- in the short term, or in the long term -- in developing technical solutions to solve it.
Don’t reinvent the wheel. Evaluate existing solutions to a given technical challenge carefully before undertaking a new technology initiative. Don’t skip this step -- the set of available features, tools, gadgets, and third party solutions for a given problem is constantly changing.
Communicate publicly, early. The aforementioned practices are reinforced by using public communication channels from the start. This brings your project idea to the attention of individual volunteers, movement partners and members of the technical community.

Phase 1: Planning. You have decided to take on a technology initiative as part of your programmatic work.

Understand your capabilities. Do you have someone on your team who has managed engineers, product managers, and designers before, or who has hired executive level staff who have done so? If not, this constrains the kind of project you can undertake. Specifically: Ensure that you can answer the following questions
Who will hire the developer(s)? What criteria are used to do so?
Who will drive the requirements gathering for the project?
Who will validate, on a week to week basis, that those requirements are being met?
Who will define the measures of success, and validate that these are being met?
Who will design user interface?
Who will review the code for security, performance, architecture, quality of automated tests, etc.?
How does the team work? For projects above a very basic level of complexity, understand that you may need an operating model for the team (e.g. a well-defined agile development process) and a person specifically responsible for process/project management.
Understand your dependencies and communicate with movement partners. If you expect other organizations to allocate resources for code review, integration, design, testing, or even hiring and management, begin negotiating this before even submitting a formal plan.
Understand minimum viability. In product development, there is the term “minimum viable product”. What functionality do you need to develop to make a basic determination about whether what you’re trying to do is working at all as early as possible?
Don’t over-specify requirements too early. Be clear about the high level success measures you want to hit as early as possible, while decomposing complex problems as you get closer to solving them. Undercommit -- software engineering projects are almost always more complex than they at first appear.

Phase 2. Execution. You are undertaking a technology initiative.

Work through the standard venues of the Wikimedia technical community. Track your project through phabricator.wikimedia.org; explain it on wikitech-l; document it on mediawiki.org; version it in Wikimedia’s version control system; use compatible open source licenses. There can be reasons to make exceptions to these rules, but they need to be clearly articulated.
Include the broader community of online contributors in the process. Post updates to relevant wiki pages, mailing lists, and newsletters. Understand community needs and concerns as part of the development process.
Support and accept volunteer and third party code contributions. Even if you are driving the project, demonstrating a commitment to working with volunteer and third party developers early helps create the conditions for sustainability even if you have to reduce the level of investment in the project later on.
Don’t forget about maintenance. Even fairly self-contained tools will break over time as APIs change; code deeply integrated with MediaWiki itself is even more likely to incur maintenance cost. As your initial “project” comes to a close, you will be faced with different choices:
Continued investment. If your project is successful and important to the movement, continued investment in maintenance may be justified.
Killing the project. Disabling or discontinuing software features is a normal part of the software lifecycle. Functions served by your tool may now be served better by other solutions, or new ones -- or the project may be unlikely to achieve its success criteria.
Volunteer maintenance. This will have the highest chance of success if you’ve already cultivated relationships into the volunteer developer community through the project’s lifecycle.
Maintenance by another organization. Be upfront throughout the development of your project if you expect other organizations to take on increased maintenance responsibility over time.
Keep measuring. Keep optimizing. Keep learning. Software development is among the most complex work any movement organization can undertake. Expect to make mistakes, conduct retrospectives/postmortems, continually revisit the metrics you collect, survey the health and effectiveness of your development teams, and keep optimizing. This never stops.

Wikimedia organizations with expertise in technology work

If your organization has expertise in software development and technology work, please list yourself here and briefly describe your expertise that others wanting to build capacity in this area can contact you:

Wikimedia UK has a range of experience as regards working with volunteers and welcomes contributions from Wikimedians further afield to our discussions
Please add your organization’s name here, with a description of your expertise.
...

Learning patterns related to technology work

Here are some learning patterns related to this strategy. Create your own learning pattern here, if you have learning to share in this area.

{{{learning patterns}}}

Ongoing challenges in the area of software development and technology work

If your organization would like to share an ongoing challenge in this area, that is or is not addressed in these recommendations, please write it down here as a starting point. We can try to build resources in this area or help different Wikimedia Organizations connect to address the challenge together.

Please add a description of your challenges in this area here.
...

Community resources

Please add useful resources you know about, whether created by the Wikimedia movement or in another context.

Create a capacity building plan for software development and technology work

If your organization has decided to prioritize capacity building to improve your ability to software development and technology work, please create a table like the one below. The steps in this table can be part of your organization’s master capacity building plan, as suggested in the User Guide.

If you would like to share your capacity building plan publicly on Meta, you can use this button to create your capacity building plan.

Coming soon!