This is the second in a series of blogs on how we are using the Agile methodology at Open Knowledge International. Originating from software development, the Agile manifesto describes a set of principles that prioritise agility in work processes: for example through continuous development, self-organised teams with frequent interactions and quick responses to change (http://agilemanifesto.org). In this blogging series we go into the different ways Agile can be used to work better in teams and to create more efficiency in how to deliver projects. The first post dealt with user stories: this time we go into methodologies.
More efficiency in project delivery is the name of the game. Working together in teams or with other people requires us to put in places methods and methodologies to accomplish that. A shared set of methods that allows team members to walk into a project and start delivering as soon as possible.
Glossary
- Method – A systematic procedure.
- Methodology – A series of related methods or techniques.
- Methodology size – Number of methods/techniques used in the methodology.
- Methodology density – Amount of precision/checkpoints needed. More density is a higher ceremony methodology (more formal one)
- Criticality – The nature of damage of undetected defects (impact if we forget something). Higher criticality means worse impact.
What is a methodology
A methodology consists of 10 elements, of which one, the team values, permeates all of them. Let’s first put them in a pretty picture and then list them out with descriptions:
- Team values – What the team strives for, how they’d like to communicate and work together. The values affect each element of the methodology so different values create different methodologies.
- Roles – It’s best to think of this as the job descriptions we’d put into the ads when you need to hire more staff.
- Skills – The skills needed for the roles we need.
- Team – This is the group of people that will tackle a project and what roles they have.
- Tools – The tools people use either within a technique/method or to produce a deliverable according to the standard.
- Techniques – The methods used to get stuff done (generate work product), this can be everything from work changing techniques like breaking up into sprints (time blocks for work), to games played to achieve a specific output like planning poker (for estimates), to just a description of what is done to make things happen like “write a blog post”.
- Activities – The meetings, reviews, milestones and other things people do or attend. The most obvious activity is “create deliverable” or something like that, but the more interesting activities are the events that take place.
- Standards – Description of what is permitted and not permitted in the work product. These can be standards such as what programming language or security measures to use, how management is handled or how decisions get made (e.g. RASCI) and other project conventions.
- Work Products – Not only the final product, this is also the internal products, i.e. what each person or team hands over to another person or team, something like user stories or mockups.
- Quality – Often not considered explicitly but these are the rules and concerns that need to be tracked for each deliverable (work product). This could be a part of activities but it’s so important that it’s better to split it out.
Principles for picking/designing methodologies
There is no one size fits all methodology. There are methods one reuses between them (the shared set of methods/techniques people know about) and probably a default set one uses in absence of something more fitting. However, in general one needs to think about and pick/design methodologies based on two things:
- The project itself
- The number of people on the project team
The nature of the project calls for different methodologies, some projects can get away with a very lightweight methodology, where it won’t be the end of the world if something is forgotten, while others call for more publicly visible correctness where bad things happen if things are forgotten. For example, paying salaries requires a methodology with more visible checkpoints and correctness than responding to Tweets. People might lose their houses if they don’t get paid, but nobody will be out on the street for missing a possibility to retweet.
A lot changes based on the number of people involved. Communications become harder to do and the effectiveness of individuals decreases as a result the methodology must get bigger to tackle all of these:
Picking/designing a methodology has to be based on these four principles (they have to be kept in mind so because they aren’t all achievable always, notably number 4 in our case):
- Bigger teams call for a bigger methodology
- More critical projects call for more methodology density (publicly visible correctness)
- Cost comes with weight (a small increase in methodology adds large amount of cost of the project)
- The most effective communication is face to face and interactive (everyone participates instead of just doing a broadcast).
Agile development
We have agreed on adopting the agile values (slightly adapted from the agile software values) as our team values where we can. That means we value:
- Individuals and interactions over processes and tools
- Working stuff over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
We value everything that’s mentioned above, we just value the things on the left (the bold) more than the things on the right. There are also 12 principles we try to follow as much as we can:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable things.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working stuff frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and implementers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a team is face-to-face conversation.
- Working stuff is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
As an encouragement and because you were just bombarded with a long list of things and a discussion about planning how we plan work, here’s something from XKCD to keep in mind as we dive into methodologies:
Tryggvi Björgvinsson is the Unit Head of IT and Dissemination for Statistics Iceland. He previously worked for Open Knowledge Foundation, and is one of the founders of the Icelandic Digital Freedom Society (FSFI).
