From November 2nd to November 6th the W-JAX 2015 took place in Munich. This annual conference focuses on software development & architecture, enterprise technologies, DevOps and many other interesting topics.
In a series of articles we would like to highlight some aspects of this year’s W-JAX. This first post covers outcomes of the conference’s Agile Day. There were a variety of sessions dedicated to agile development as well as team & company organisation.
Agile growth
When an organisation wants to go the agile way or wants to expand its agile concept, two important questions should be asked:
- On which (agile) level is the organisation currently?
- What do we want to change / achieve?
The Agile Fluency Model can give an answer to the first question. Released by Diana Larsen and James Shore, it illustrates different levels of agile development and the time that is necessary to advance to the next level. For more information on this model, please read Anja’s blog post.
Having the second question in mind is important to define goals for the agile improvement. Possible answers could be:
- We want to have more agile development teams or improve their methods.
- We want to have an agile product development from the first idea through to deployment.
- We want to develop a distributed product or company strategy.
Once the goals are defined, it is time to take action. This may seem a complex and challenging task at first. To tackle it, one talk suggested using agile methods to introduce agile itself, by building a cross-functional transition team over all departments and hierarchies. Using a backlog with small and verifiable tasks, the team can improve the agile strategy in iterative cycles. Public reviews and regular feedback make the work transparent to all employees.
The talk also included thoughts on how to set up new agile development teams. A good idea is to start with a small core of experienced developers. Later on, more developers can be added step by step, for example one per month. Thus, the core team has some time to develop the first rituals and workflows, and later new developers can bring their own ideas into the team.
Living agile
An agile strategy is not only about frameworks, methods and terms. An organisation does not become more open just because it uses agile concepts, and people do not change just because they get a new role title.
In order to be successful, the agile strategy has to become part of the company culture. For the employees, it is easier to accept workflows which they are comfortable with. This can be achieved by creating rituals on which culture can grow. Such rituals could be:
- Open-floor stand-ups: Public stand-up meetings, also of the management.
- Public reviews.
- Breakfast / pizza review: After finishing a large task or epic, have a review for the whole company or department, together with breakfast, pizza, etc.
- Brown bag session: Technical discussions while eating / drinking.
- Public to-do list for every employee.
- Delegation poker and delegation matrix: Which responsibilities and duties can be given to the teams?
An organisation should not create processes just for the sake of it. Instead it should ask which processes are useful, and how they can become part of the company culture. But most importantly, every member of the organisation should be involved in the agile strategy.
Distributed teams
Teams across different locations require more organisational effort than teams where all members are in the same location. In agile development in particular, a good communication strategy and well-defined rituals are necessary in order to make a team successful.
In distributed teams the role of each member has to be clearly defined. This is especially true for the product owner(s) and scrum master(s). It is not forbidden to have more than one product owner, each being responsible for a different aspect of the project. But it is essential that they communicate frequently in order to synchronise. The team can also have multiple scrum masters, each in one location, to maintain the agile process.
Regular and frequent meetings, such as daily stand-ups, retrospectives, and backlog refinements, are more important than in single-location teams. Video chat tools, that help members to see the other part(s) of the team, can prove beneficial. Technical decisions have to be made across the different locations and not only in one team. It is also a good idea to have a person from the other location in the office for two to three days a week, who acts as a proxy to the rest of the (remote) team.
Find your own way
Maybe the most important lesson of the Agile Day was that an organisation should not strictly stick to the books when it defines its agile strategy. Each company has to find its own way of implementing agile concepts. Different prerequisites can lead to different requirements and solutions. What is good for one company does not have to prove beneficial for another. The road to an agile strategy is iterative and explorative, just as the concept itself. Do not hesitate to change workflows that prove to be obstructive, and always aim for improvement.
About the author
