Timeouts and retrospectives
We use timeouts and a couple of different retrospectives to drive improvement. Stop-the-line events like Pomodoro timeouts and Pomodoro retrospectives happen spontaneously within the team to solve problems immediately and produce small continual improvements. We also use a monthly retrospective for the product stream to reflect on how it's working and conceive bigger, more strategic improvements.
Pomodoro timeoutOne of our norms is that anyone can call a timeout. The team calls timeouts frequently, usually more than 1 a day; they seldom last 25 minutes and if they need longer they just run another Pomodoro. People huddle in the bullpen, sometimes around a whiteboard, to discuss something within the remit of the team and collectively decide what to do. Whether the purpose is to discuss a technical issue and define a set of spikes to prove the way forward, explore options to get around an obstacle, or investigate a process issue, the timeout often creates opportunities to make improvements.
On-demand Pomodoro retrospectiveWhen something extraordinary happens the team runs a Pomodoro retrospective in 25 minutes, as soon as possible after the event, to find the root cause and agree 1 specific and clearly defined action that can be taken immediately to prevent it reoccurring. We like to use the 5-whys technique but we also use other activities (within the format - brainstorming, affinity mapping, dot voting, decide what to do) depending on what had happened. The retrospective is always done standing up to keep people focused and energetic. Most of the time the retrospective concentrates on events that the team could have controlled or avoided. However, sometimes it investigates problems in the
product stream that were outside the team but nevertheless impacted them, in which case appropriate people from the stream also participate.
Monthly retrospectiveOnce a month the facilitator runs a structured retrospective for the
product stream (that involves setting the stage, gathering data, generating insights, and deciding what to do, close). Everyone in the team attends, including the technical mentor, as does the business sponsor, product owner, team leaders from the business users plus a handful of their staff, and other people from the various business disciplines within the stream. The purpose of this retrospective is to step back and look at the big picture, including any external factors that have affected the stream, and identify any trends. We challenge how we currently work and try to get beyond the obvious to discover transforming ideas that would make the product stream more effective.
Labels: pomodoro, retrospective, timeout
Links to this post
Product stream
A descriptionThink of a product stream as a small company working exclusively on a product and delivering features that excite users to maximize profit and growth. The stream invests in its relationship with users and is set up to compete on the basis of speed. It has everything it needs to conduct business, from concept to production to operational support, and unlike a project it persists as long as the product is in service. It includes a dedicated and diverse technical team that is actually part of the business and helps them use software more effectively. It self-organizes for optimum delivery and minimum risk, and produces flexible software that responds as the business learns from user and market feedback.
Everyone in a stream is located together in the same place and works full-time to develop a common understanding of what users value, and to achieve a shared vision for the product against which success is measured. People in the stream collectively own the product and share responsibility for achieving results. Cash flow is key. Everyone understands the financial consequences of decisions and actions, or lack thereof, so people think in terms of delivering value to users as quickly as possible and cost effectively. Only people in the stream work on the product; in a transparent environment they collaborate intensively, communicate honestly and keep the right information visible so that informed decisions can be made at the right time.
A stream has 4 key roles that together provide entrepreneurial leadership and unified direction:
- The business sponsor is a product champion and a visionary. He owns the budget and is ultimately responsible to the company for the overall product stream and is accountable for its results. With empathy for users, a deep knowledge of the market and an understanding of the stream's capabilities, he defines the strategy and makes business decisions quickly.
- The product owner is the sponsor's right-hand man and also a product champion. Synthesizing the needs of different users (and stakeholders), he focuses delivery on evolving features in response to their feedback and changing market conditions to facilitate business agility.
- The technical mentor is a master craftsman with business acumen, extensive knowledge and vast experience in delivering high-quality software products to market. He coaches the technical team on a journey that they cannot take on their own, using earned trust to show them new skills, techniques and thinking processes.
- The facilitator actually leads the technical team with passionate support and faith in their work; he manages the budget and is responsible for results. Facilitating without detailed or coercive direction, he lets people self-organize, steering with a light touch. He helps the team function effectively by providing everything it needs, driving consensus decisions, removing obstacles that impede delivery and creating an environment in which peoples' potential is developed based upon mutual respect and cooperation.
The technical team comprises all the technical skills it needs to develop software for production and operational use. There are specialists such as testers, system administrators and designers, however everyone works to acquire more general skills to build resilience into the team. A stream is always learning. It works continuously to eliminate waste and improve through reflection and experimentation. Creative energy flows, existing knowledge is shared and new knowledge is created as everyone works with shared responsibility to improve quality, remove causes of failure and find better ways of working.
Over time the composition of a stream varies to suit the needs of the product. However, it retains the skills and expertise it needs to deliver the highest possible quality and service to users. The business sponsor, product owner, technical mentor and facilitator are always present.
Shorten the value stream by bringing it insideOur goal, starting and ending with the user, is to shorten the value stream and encapsulate it within the product stream. We aim to seize a crisis and initiate kaikaku events to eliminate some of the more obvious non-value adding steps. We collocate and remove dependencies to eliminate handoffs between teams, co-ordination overheads with other teams; waiting around for information, approval, access to business people or shared resources; chasing people in different locations for responses. We favor open-source software rather than relying on core teams producing platforms and infrastructure systems, and we remove all other dependencies by absorbing skills and responsibilities into the product stream. For example, in a recent stream we had established a cooperative partnership with the company managing the datacenter where our production environments were hosted and they agreed to implant a system administrator into the stream to work as a member of our technical team.
Within the product stream, the necessary conditions are nurtured to enable frequent delivery of features to users, at a predictable and reliable rate. Work in progress is limited to the capacity of the technical team (minus some slack) to avoid people burning out and they always stop to fix problems before continuing. Working at a sustainable pace, they even out the arrival of work by making stories approximately the same size, use pull scheduling and release every week to create flow.
The technical team operates all the environments, including production. They automate as much as possible and manage the monitoring, alerting and capacity planning. Consequently they develop expertise in how the product runs, which enables them to diagnose problems more effectively. They also get to innovate in the 'system space' to meet business and user needs. They select the technology stack, deploy the product to the production environments, and they operate and support it, 24/7. If they do something to break production, they feel the pain straight away. They work hard to prevent that happening by delivering high-quality, well-tested software and, with end-to-end knowledge and full access, the team works continuously to eliminate complexity and duplication across the system, and to reduce the overall maintenance and support effort.
Labels: product stream, value stream
Links to this post
Rolling ownership of stories through the team
We
added rolling ownership to our pair-programming back in April 2008 and we've been using it since.
Rolling ownership enables as many people as possible to get involved in delivering a story. When a new story is started, someone volunteers to own it and another person volunteers to pair in. They work on the story until lunchtime. After lunch, the pairs swap. For each story in progress, the owner moves off the story passing ownership to his morning partner and a new volunteer steps in to pair. This rolling effect allows tacit knowledge of the story to be retained across pair-swaps. When each person owns a story they add their initials to the right-hand side of the card. Repeated everyday, most, if not all, of the team play a part in delivering each story. We've found that rolling ownership facilitates shared learning and decision-making, helps spread knowledge of the product around the team, and the pair-swaps and shifting ownership keeps people communicating.
Labels: pair-programming, rolling ownership
Links to this post
Two stand-ups a day
For a long time now we have run 2 stand-ups every day, first thing in the morning and first thing after lunch, always at the same times and always around the board.
The morning stand-up discusses the work-in-progress and allows the team to co-ordinate their efforts to get stuff done. It usually lasts no longer than 10 to 15 minutes and starts from the top of the board and works downwards to cover any defects followed by the user stories, debt and design work. People stand in a semicircle and face the board. Each story owner steps out front, faces everyone, and speaks about progress on their card. In terms of the acceptance criteria on the reverse side they describe the current focus and the next steps. They also share what they've learned and what has consequently changed in the story. When progress on a story is obstructed a pink Post-it note is stuck to the card, which says BLOCKED and includes a brief description of the impediment. When all the stories and impediments have been discussed the team forms pairs to work on the cards.
The afternoon stand-up is usually done in less than 5 minutes and focuses on
rolling the ownership of stories and arranging new pairs. It's also an opportunity for people to provide updates on anything significant that had occurred during the morning.
Labels: standup
Links to this post
Using the Gordon Pask Award to share with people
We've got some ideas on how we can give back to the software community but we'd like to hear your ideas.
What would you like to hear more about?
Where do you want it delivered?
Conferences are an obvious choice. I'm interested in usergroups.
Please write your suggestions as comments to this blog post.
Links to this post
Concept to cash every week at JAOO
Yesterday at JAOO, Gus and Kris talked about going from
concept to cash every week. It's describes how we're currently working at
Energized Work and some of the experiments we're running to find new and innovative ways we can improve and be more effective.
Here's a zip file with the
slides and narrative.
It's great to get feedback and it seems the session was well received. 166 people attended with 26 leaving before the end. 74 said it exceeded expectations, 65 said it met expectations and 11 said it didn't meet expectations. Here are some of the tweets:
sejacobsen: The "Concept to Cash" talk is fast-paced and unrelentingly delivered by @guspower and Kris Lander - much like their core message #jaoo
christerdk: "Ensure change is cheap", "Care about the software", "Don't get bogged down by technical debt","find and fix immediately"
christerdk: Doing pomodoros (and break) in the middle of a session! :-)
jakobfaerch: Listening to The EnergizedWork people. Are work habits like the ones they describe really possible? #jaoo
jduchess: Lander & Power #jaoo: keep it moving, keep it working, keep it together, keep it real!
tjementum: "Turing on a sixpence" by Gus Power and Kris Lander at #JAOO was the best. They are pushing agile to the limit. Got lots of ideas.
alradk: #jaoo, just saw Gus Power in Turning on a 6 pence. Damn, this was a powerful prensentation! From now on i'm working wednesday - tuesday!!!
Links to this post
