November 2015 – Innovators Guide To the Galaxy

THE POMODORO TECHNIQUE®

November 30, 2015January 2, 2018Posted in Method, PlanningTagged Pomodoro, time management, TimeboxLeave a comment

The Pomodoro Technique® is a time management method created by Francesco Cirillo. The method is a technique to stay focus on your task and get more done. Continue reading “THE POMODORO TECHNIQUE®” →

T-SHAPED COMPETENCE

November 30, 2015January 2, 2018Posted in Agile, competenceTagged competence, t-shapedLeave a comment

The T-Shaped competence is an idea how to recruit and develop competence in an organization. The T symbolize both dep competence “vertical” in an area, like an expert where the horizontal bar is describing a broader competence. The horizontal bar is for collaboration and how much knowledge an individual have in other areas outside their own.

In agile “cross-functional” teams is a standard phrase that the teams are supposed to handle as much as they can within the team and solve it together. For this to work the team members need to be able to help out in different areas outside there own expertise.

With T-Shaped concept you got a goal for creating a team culture where they help each other and at the same time can be expert in their fields.

Usually there are challenging to create a cross-functional teams because it take time to learn new skills. So here it is important to have an overall strategy and follow it through, even when it is tempting to pinpoint task on individuals.

T-Shaped competence also prevent key dependence on single individuals but in the same time demands more from every individual, patience and support from stakeholders.

Thanks to Jimmy Janlén for letting me use his pictures from Agile Topics Cards.

6 hours work days, will this experiment work?

November 30, 2015Posted in UncategorizedLeave a comment

In Sweden a couple of organizations have introduce 6 hours workday with same pay as an experiment. One organisation is an elderly home in Gothenburg that have tried this and the results are already better. Continue reading “6 hours work days, will this experiment work?” →

WORKING AGREEMENT

November 30, 2015January 2, 2018Posted in Agile, MethodLeave a comment

Working agreements is a way for teams and organisations to set rules, principles and process between individuals, teams and different decision.

The purpose is for the teams to focus on creating value instead of work against each other. So its important to set some ground rules. In the best scenarios teams figure this out by them self. The create implicit and explicit patterns of whats okay and not. Effective teams work out agreements about how the should do things and make sure the agreements are flexible.

Usually there are several agreements for different task and situations. There are also important to make the agreements visualized for every one to see. Put it up on the wall, intranet or the team board.

For more tips about visualization see Jimmy Janléns book here

Definition of Done is a classic working agreement that many teams use to make sure that a task is really done “shippable”.

With working agreements you create a foundation for “right” expectations and minimize misunderstanding between groups.

Thanks to Jimmy Janlén for letting me use his pictures from Agile Topics Cards.

More to read: Norms, Values, Working Agreements, Simple Rules – Esther Derby

COLLECTIVE CODE OWNERSHIP

November 23, 2015January 2, 2018Posted in extreme programmingTagged architect, developer, empowering, owernshipLeave a comment

Collective Code Ownership is an idea that everyone owns the code. It encourages that the whole team contributed with ideas and every developer can change, fix bugs, improve design and refactor.

There is no “chief architect” that you need to ask for answers or permission. Collective ownership when it works is much more powerful, engaging and empowering than putting one person in charge. And when you have one person in charge you take away the responsibility from the team.

With this you minimize key dependence from team members.

Start to talk about what this means for your team, and when you could adopt it. Then you induce them to share and engage in each others code.

USER STORY

November 23, 2015January 2, 2018Posted in Method, RequirementTagged req, User StorysLeave a comment

User story is a popular method in agile software development to capture the need of user of a function or feature that are being developed. A User story consist of couple of sentence that describes “Who”, “What” and “Why”.

In the requirements process User Storys can be used as a method to define business value that needs to be created. Often and preferably the User story should be handwritten on a paper or post-it to make sure you can’t write too many details.

Usually the stories are written by the customer or the business user to influence the functionality and make sure to answer “Who”, “What” and “Why”.

When it’s time to write a User Story, make sure to gather the right team and don’t do it by youself. At least one from the development team should participate to ensure that the stories capture as much as possible.

User storys can preferably be used as a acceptance criteria or/and acceptance test case before the task is done “shippable”.

Thanks to Jimmy Janlén for letting me use his pictures from Agile Topics Cards.

SLACK

November 23, 2015January 2, 2018Posted in teamTagged buffer, schedule, SlackLeave a comment

Slack is the team’s/individuals personal buffer time. When the task is complicated and complex like software development are, we need slack time to handle random problems that are impossible to plan ahead. If you maximise and stretch the system too much you risk to break it.

If you don´t buffer money for unplanned expenses you risk to break you finance, its the same in organisations.

Organizations that doesn’t work with slack is either so routine that you can let robots do the work, or the organizations have big trouble in getting the predicted output.

One way to introduce slack is to schedule important, useful work that isn’t time critical. Then you hopefully can work on technical debt, team activities, innovate new products or somethings else that are good for the company if the planed slack time is left after an iteration.

Is tempting to maximize an plan to much and this is often correlated to our obsession to measure 40 hours week. Getting the slack time right is hard so the only way is trying, learning and adapt. If the organizations is really good in estimation the slack time can be smaller, but remember to plan for other task like technical debt in the iteration instead.

CODE REVIEW

November 23, 2015January 2, 2018Posted in Agile, extreme programming, MethodTagged fagan, learning, pair programming, XPLeave a comment

Code Review “peer review” is technique to examine and review software code, often together with someone else.

The intended is to find mistakes and correct bugs early in the development process. With this method you get two more eyes to help you find mistakes in the code. It´s easy to get “blind” for your own creation and together with someone it´s possible to streamline the process and get the code in a better shape.

If the team are working with a complex code, critical system or in a complete new area, code review is a good method to help the team to get achieve high quality and minimize the risk.

Its also a great method to share understanding, knowledge, ideas and minimize bugs in the code for the team. So before you start a new iteration and planing for QA and testing, create a “definition of done” criteria on the task, that it´s first need to be reviewed be someone else before its done. In that way the team wont miss out the part of securing quality and learning.

The Fagan inspection is a more formal and structured process to review code where you have entry and exit criteria for the review.

Then you can use a more lightweight review with lesser overhead and planning. Pair programming is one way to achieve a good result and sharing knowledge between team members and this is also done on the fly when the code is written.

PAIR PROGRAMMING

November 23, 2015January 2, 2018Posted in Agile, extreme programmingTagged communication, learning, pair programming, XPLeave a comment

Pair Programming is technique where two programmers works together on one computer. One programmer write the code and the other observe and review the code on the fly.

The roles (programmer/driver) should be switch between the programmers so they can learn from each other.

As an observer you have the time to write down ideas and improvements to review together after the session. That means the person who write codes can focus on that. Pair programming works either as:

Expert – Expert
Expert – Novice
Novice – Novice

depending on the situation.

This is an excellent method to enhance learning and satisfaction. It´s also good for team building, communication in the team, code design and quality.

Remember that pair working is difficult and needs practice. When you work together like this you open up yourself and your work. You also need to explain your ideas and thoughts out loud to another person.