Commitment: Why and How

At the peak of sprint planning the team pledges “We commit to achieve these stories, no matter what it takes“. It’s a deal with the Product Owner (PO) and the team.

So why do teams commit?

The commitment is only valuable if the team thinks it can actually achieve it. Since the team is invited to pull the right amount of stories from the backlog, the PO trusts that the team makes reliable commitments based on their current capabilities and expected flow. This way the self-organizing team is challenged to constantly improve estimates, deliver value, as well as contribute its stake in risk management.

And how to arrive at a commitment?

  • prepare stories in Product Backlog well
  • discuss to make sure stories are understood
  • confirm the acceptance criteria (get early feedback from customer and PO)
  • discuss implementation order vs. prioritized stories
  • consider Retrospective findings, refine Definition of Done if necessary
  • re-estimate if needed
  • consider need for spike (experiment sprint)
  • recognize the right amount of refactoring and tuning requests to reduce technical debt
  • commitment is always on the story, not on its tasks

The product owner’s trust shall never coerce the team into committing a set of stories they do not feel comfortable achieving. If the team turns out to overcommit and needs to de-scope stories during the sprint, that is part of the intended feedback cycle reflected upon during retrospective, thus it will gradually increase its certainty.

two cappuccino served on cups near laptop computer

Pair Programming: Why and When?

In pair programming, two developers work together in front of one screen (or two, as long as they both look at the same screen) to get a task done faster and with higher quality. Just like a driving a car, there are two roles in the pair: The driver, who has the steering wheel, aka the keyboard in her hand, and the navigator who knows where to go and which crossroads lie ahead. As you want to switch these roles every now and then, it is very helpful to have two keyboards and mice attached to the computer you are working on or use a tool like Mango Lassi on Linux or teleport on OS X.

So why would you do work in a pair?

Fight distractions

Usually, you are not developing in a vacuum sealed room, so there will be colleagues, chats, telephone, and so on. If the navigator takes care of answering these interrupts (or at least deferring them to later), the driver can stay in the flow of writing code, and it will be easier to remain in the mindset of the task at hand. Getting back into a complex thought takes a while as we know.

Knowing what’s next while assuring code quality

The navigator does not have to care about how to auto-complete the current function, or minor details of coding. He or she can rather keep track of the next steps, which leads to less corner cases that are being forgotten and to better test cases. The immediate code review will usually produce better designs and better readable code because all work is being challenged immediately.

Knowledge sharing

Pairing is also a tool to learn and share knowledge. A pair can get inspired and learn about new technologies or new code together, and later on split up and continue to read further details. In this case, both developers start out with about the same level of (possibly little) knowledge and try to increase it as fast as possible. On the other hand, you can also learn from your co-developer: Someone who may have more experience in one area is a great navigator who you can tap while producing even greater value. Areas of knowledge that can be shared include experience in a different area of the product, or with a tool that is used to develop, or with an engineering practice, domain knowledge, or even specialized development knowledge (interface design, patterns, testing, etc). Sharing knowledge is the best way to establish collaboration as well as reducing the risk for the whole team in case one team member may become unavailable.

While pairing can be used extensively, sometimes it may not be the right tool for every situation.

Little complexity

If the task at hand bears little complexity and risk, usually its solution is very clear and well understood. In this case, pairing has very little effect on the quality of the product. Some drivers may not need a navigator to do a simple u-turn.

Distributed teams

Remote pairing just does not work as effective as local pairing yet. You can have audio and video conferencing, but I have yet to see good (and cross platform) editor/IDE integration. Without those, the navigator may get stuck with screen sharing that suffers from time lags. Plus, if you ever communicated line numbers, you know the pain.

Stealing the wheel

Good pair programmers need to learn to discipline themselves. Focus on the task is key (not on the recent vacation, or watching funny videos), but navigators must also refrain from abruptly stealing the wheel, eh, the keyboard.

Scrumtisch June – Agile Teams and Other Topics…

Neither football and nor the heat could not keep us away from the Scrumtisch on Tuesday. More than 20 people exchanged experience and knowledge about the following topics and have been listening to Bent who was talking about how to create a real team.

Topics of the open discussion:

What to do if Continuous Integration/Maintenance Bug fixing eats up more than 50% of capacity?

  • More support from the team developing
  • How to prioritize Bugs vs. User Stories?
  • Check-ins more often and smaller chunks
  • Tools pre-building or green-checking control
  • Distributed builds with fast running tests
  • Evaluate rate of technical debt reduction and decide for either a stabilization period or dedicated maintenance

One team on two Sprints?

  • Focus on one project at a time
  • Stream all stories into one unique backlog
  • Remove team members from the “old” team and start building the “new”
  • Prioritization should be unique among all stories
  • Avoid task switching and multitasking

Role in a Development Team (Rotation, knowledge share)?

  • Skill mapping an team level and set Key Performance Indicators (KPIs) for evolution
  • Pair programming

High performance teams

Thanks again Bent, for your interesting and useful talk. :-)

We also have the the slides of the talk available for download, and recommend this article on coaching Scrum Teams for further reading.

See you soon at the next Scrumtisch

Ableton Developers build a LEGO city

The Ableton application developers build a LEGO city using Scrum as part of the Scrum training.

In a second round of training the developers at Ableton have constructed another LEGO city using Scrum. Using 5 minute bursts of planning, building and retrospecting, the teams transform the high-level wishes of the Product Owner into structures.

Ableton City

Instead of writing detailed, low-level specifications, the Product Owner uses User Stories: descriptions of functionality from the end-users perspective. LEGO stories look like this:

As a citizen, I would like a two-story house so I can have a large house on a small plot of land.

The teams would estimate and commit to these kind of stories, then iteratively transform them into LEGO. Together with the Product Owner they would assess the outcome and prepare the next sprint, refining build structures or pulling in new work.

The outcome, as you see here, was a very pretty city! Extra brownie points were awarded for the wonderful setting and the LEGO Ableton logo :-)

Ableton City

black click pen beside MacBook Pro on table

Agile Estimating 2.0 – Cheat Sheet

Team Estimation Game

  • Start with a stack of ranked story cards. The team will arrange the cards so the smallest size items are on the left and the largest items on the right. Items with the same or similar size should be grouped together in vertical columns (the same place in the left-right direction).
  • Place the first (highest ranked) story card in the middle of the table (or in the middle of the board or wall)
  • Team members take turns estimating in a round-robin manner. On each turn, the player has two options, as shown below. With both options, the player will explain to the team the reasons for his or her estimate.
    • Take the top story card off the stack and place it on the table based on its estimated size
    • Move a previously placed card to a new location if you think it should be estimated differently
  • During a player’s turn, other team members may speak only to ask clarifying questions; they must not express their own opinions during another player’s turn.
  • After the last story card has been estimated, each player may take one more turn to move a card if he/she wants to.
  • Assign story point values to each group of cards. Even numbered teams use the pseudo-fibonacci sequence (1,2,3,5,8,13,20,40,100), and odd numbered team use powers of 2 (1,2,4,8,16,32,64,128)
  • You may not have stories for every number in this sequence.
  • Numbers represent the relative size/effort estimated for each story. For example, 3 story points is approximately 50% more effort than 2 story points, and 8 points are two times the effort of 4 points.

The Team Estimation Game was originally developed by Steve Bockman

Using color to visualize your backlog

  • What aspects of your stories are important for estimation? Discuss this with your team
    • Example: type of materials used, number of pieces, method of construction, etc.
  • Download Agile Estimation Cheat Sheet

This cheat sheet was part of the agile42 speech together with Propero Solutions on the Scrum Gathering Shanghai 2010.

Coaching self-organising teams

As usual we started collecting topics (timeboxed to five minutes). The list was rather short, however it contained several interesting pieces:

  • (6 votes) Management buy-in
  • (6+ votes) CSP – Certified Scrum Professional – what changes compared to the practitioner?
  • (4 votes) Roles of Management in Scrum – how do they change?
  • (13 votes) Coaching self-organising teams – team buy in.

Coaching self-organising teams – Team buy-in

As prioritised by the participants the first topic discussed was on coaching self organising teams – with a heavy focus on team buy-in. The problem described dealt with transforming water fall teams that are used to receiving their work items into self organising teams that voluntarily accept responsibility for the whole project instead of just their own little work package.

The definition of self organising here really is about teams, that have no (and need no) dedicated team leader. On the contrary: leadership is automatically transferred to the person who – based on his skills and experiences – is best suited for the user story that is being implemented at any given time.

The problem the question targets is about teams, that really are not self organising, where developers do not take responsibility for the whole project, but just for their little pieces: They have their gardens – with fences around that protect them from others but also protect themselves from looking into other pieces of the project. Even worse – they tend to take these fences with them as soon as work items change.

Several ways to mitigate the problem were discussed:

  • Teams should work in a collaborative environment, should have clear tasks and priorities, whould get some pressure from the outside to get things done.
  • Some teams need to learn what working in a team – together – really means. It may sound trivial, but what about solving problems together: Spending one day climbing hills?
  • Committments should not happen on tasks (which by definition are well defined and small) but rather on Features/ user stories. Task breakdown should happen after the committment.
  • There are patterns to break user stories that are too large into multiple user stories.
  • Teams need to be coached – not only the scrum master should get education, but the complete team. There are people interested in management that tend to read up on the topic after working hours – however these are rather rare…
  • Teams must be empowered – they must be responsible for the whole project and for the user stories they commit to. In return they must get what the need to get their tasks done.
  • Newly formed teams inexperienced with Scrum have to get the chance to make mistakes – to fail – and to learn from that.

A great way to explain Scrum really is as a two-fold process: First half is about getting a product done, reviewing quality by the end of each sprint during the review. Second half is about improving the process to get the product done. Meeting to review the process quality is called retrospective.

Management buy-in

The second topic discussed was on the role of management in scrum – and how to convince management of Scrum. To some extend, Scrum means loosing power and control for management. Instead of micro-manageing people it’s suddenly about communicating your vision and scope. To get there, it helps to view lean management as the result of a long transformation:

  • First there is hierarchical management – with the manager at the top and employees underneath.
  • Second there is shared management – with the manager sitting between his employees enabling communication.
  • Third there is collaborative management – here the manager really is part of the team.
  • Fourth comes empowering management – this time the manager is only responsible for defining goals.
  • Last but not least there is lean management – where managers are merely coordinating and communicating the vision of a project.

To establish a more agile management form, there are several tasks to keep in mind: First and foremost, do talk to each other. Explain your manager what you are doing and why you are working in pairs, for instance. Being a manager, do not be afraid to ask questions – understanding what your developers do, helps you trust their work. Scrum is established, however there needs to be a clear communication of what managers loose – and what they win instead.

Scaling can only be done via delegation – however people need to learn how to delegate tasks. In technology we are used to learning new stuff every few years. In management this improvement cycle is not yet very common. However especially in IT it should be.

Sellling Scrum to a customer

Being able to sell Scrum to customers is yet another problem: You need good marketing to sell Scrum to your customers. Money for nothing change for free is a nice to read on formulating agile contracts. Keep in mind, that the only way to really win all benefits is by doing all of Scrum – cherry picking may work to some extend, however you won’t get the full benefit from it. In most cases it works worse than traditionally managed projects.

Finally…

After two very interesting and lively discussions moderated by Andrea Tomasini, agile42, we finally had pizza, pasta and drinks – taking some of the topics offline.

Looking forward to seeing you in F-Hain for the next Scrum User Group Berlin Scrumtisch in April.

Last but not least I would like to thank Isabell for providing this nice summary, and if anybody would like to know more about Apache… Isabel’s Blog is the right place to go :-)

Ableton builds a Lego Abletown

As always we put theory into practice by building a LEGO City at the end of a Scrum training. The attendees are challenged to build a LEGO City from a Product Backlog in a very limited building time, of course using Scrum. This lets the people really feel what it means to self-organize, to sprint and to have a retrospective. Also working against a Product Backlog and with a Product Owner is something that you need to experience.

Ableton Team

In a couple of 5 minute sprints, the teams build, refactor and integrate their LEGO creations. Many aspects of Scrum in software development are also evident in this exercise. Work is prioritized on an on-going basis in the Product Backlog and the teams pull in work from this list into their Sprint Backlogs. After each Sprint the team has some time to reflect on their previous Sprint to figure out ways to improve their process.

All the hard work leads to a fantastic LEGO City, complete with a LEGO Ableton logo. Extra kudos for the impressionist river and for the name: ABLETOWN :-)

Ableton ABLTOWN

Good going guys, cool city!