Tag Archives: agile

cross-functional enough? (from old article by @henrikkniberg)

“Cross-functional team doesn’t mean everybody has to know everything – this seems to be a common misinterpretation though. Cross-functional just means that the team as a whole has all skills needed to build the product, and that each team member is willing to do more than just their own thing.”

(my emphasis)

star map – interesting tool from Henrik Kniberg: Is your team cross-functional enough…

do this excercise against your top backlog items.

….

I like this exercise because:

It’s quick & easy.

It triggers valuable discussions.

It helps visualize the team’s strengths and weaknesses.

It encourages teamwork (“how can we help each other succeed”)

It counteracts pidgeon-holing (attitudes such as “I’m the Java guy and you’re the DB guy, so the DB stuff is your job!”).

It helps people get to know each other better.

It takes into account the fact that people can (and often like to) broaden their skills.

kanban and the perfect job

-by Dennis Stevens

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

This is the 5th principle behind the Agile Manifesto.

….
The Motivating Potential of Kanban

When implemented well, Kanban creates a work setting where the job design delivers on the five core dimensions of the job characteristics model.

Skill Variety: In Kanban, the team members are involved in the daily planning of their work, engage in discussions around how to get the work done, perform their specific work, and may swarm on other related work.
Task Identity: In Kanban, the entire focus is on the flow of work. The team members see the work flow from start to end.
Task Significance: One of the focuses of Kanban is to improve the lives of the team members themselves. The focus on flow of value also helps the team understand how they are improving the the work of the customer and/or the people their organization.
Autonomy: Kanban allows teams to schedule their work through the pull mechanism. The self-organizing nature of the work also helps them decide how to care it out.
Feedback: Managing Cycle Times, explicitly tracking defects, and the rapid feedback cycles associated with the limited WIP create feedback on effectiveness at multiple levels.

Kanban inherently results in job design that improves intrinsic motivation and the resulting high levels of performance.

via dennisstevens.com

Slack creates opportunities for improvement without needing to schedule them

Finally, by having fewer work items in process, then the team is able to focus more on the larger goals, and less on individual tasks, thus encouraging a swarming effect, and enhancing teamwork. Limiting WIP like this can seem unusual for teams, and there is often a worry that team members will be idle because they having no work to do, but are unable to pull any new work. The following guidelines, in priority order, can be useful to help in this situation.

Work directly on existing work to progress it

Collaborate with team members on existing work to remove a bottleneck

Begin working on new work if capacity is available

Find some other useful work

When team members have to find some other useful work then “bubbles of slack” are formed around the work. This creates opportunities for improvement without needing to schedule them with techniques such as Gold Cards. This can be work which won’t create any work downstream, but will improve future productivity and can be paused as soon as existing kanban slots become available. Investigative work such as technology spikes, refactoring or tool automation, and personal development or innovation work, are all activities which might help the team in the future.

via methodsandtools.com, Aspects of Kanban by Karl Scotland

(my emphasis)

So, IMO, slack is unplanned improvement work.

“Recipe” for what to work on next:

1. Can you help progress an existing kanban?
Work on that.

2. Can’t do that?
Find bottleneck and work to release it.

3. Can’t do that either?
Do work which
– won’t create any work downstream,
– will improve future throughput and
– can be paused as soon as existing kanban related work is available.