The retrospective is one of the most important ceremonies in all of agile. This is the time the team spends together to assess how they are working together and define steps to improve that process. It needs to be a “safe place” where people are able to speak openly and honestly. This is their opportunity to air their dirty laundry and work through their inter-personal issues. This is a time of growth for the team and for the team to take ownership of improvement. The team lead will facilitating the retrospective and should manage the interactions to keep the environment safe.
Define the Team
If the retrospective is a team ceremony, then what do we mean by team? The team includes: the team lead, the architecture owner and all other members that actively contributed to meeting the deliverables for the iteration. This includes: developers, testers, BAs, QAs, or other specialists such as technical writers, database engineers etc.
What about the Product Owner (PO)?
The PO is NOT a member of the team. They certainly interact with the team but they do not contribute to meeting the deliverables for the iteration so they are not a member of the team. They are not allowed to participate in the planning poker for the user stories for the same reason. The team votes because they are on the hook for delivering based on the sizing and the estimates but the PO is not on the hook, so they don’t get a vote.
Should the Product Owner participate in the retrospective?
In general, I would start by including the PO in the retrospectives because the team does have to learn and adjust to working with the PO. Keep in mind though that the PO may come and go but the team should stay together so it is most important that the team works well together.??As a coach, I usually talk to the PO beforehand to say that they are an invited guest and that it is a privilege to be part of the meeting so they should act accordingly. I have been in many situations where the PO was welcomed at the retrospective, and felt left out if not included. I favor building trust between the business (the PO is their representative) and IT (the team). Including the PO in the retrospective can help the PO assimilate with the team.
I have also had several situations where as the coach I had to ban the PO from the retrospective because they were too commanding and disruptive in the meeting for the team to have an effective retrospective. I have also seen many situations where the PO is also the resource manager of members of the team (which in itself is not recommended). Having managers in the room can definitely have a dampening effect on the member’s willingness to be open and honest about problems and solutions.
If the PO doesn’t participate, at least as an observer, the team runs the risk of having to “sell” the cost of their improvement actions (against other backlog items) after coming up with them. Hopefully the PO is engaged enough with the team to understand its weaknesses and support improvement in those areas whether then attend the meetings or not.
Team Decision
Retrospectives are about improving the process, and a non-trivial part of that is optimization of collaboration between the PO and the team. I would suggest that the team should decide whether or not to include the Product owner.
What about the Stakeholders?
The retrospective should absolutely be a closed door session for the stakeholders since the retrospective must be a “safe space”.
There was a twitter debate lately that talked about a team being subjected to “a drive by criticism from 2 PM’s during a Retrospective”. This is a good reminder why we constrain attendance. The “safe place” is affected by the presence of people with positional authority, potential agendas or other implicit impact.??The team may decide to invite such people – usually to ensure that they are communicating improvements needed that are beyond their locus of control.??Having outsiders as guests at the retrospective will change the dynamics but at least it is a team decision to do so.
It is very important that the team own their process. If they’re uncomfortable that someone is in the room then that person should be asked to either change their behavior or leave (perhaps to be invited back in the future).??The coach should always be thinking along the lines of “do we have the right people in the room” and then act accordingly
Isn’t agile all about transparency?
There was a twitter debate lately that centered on transparency. I believe that transparency is a key element to making agile successful. I’m all for transparency in everything about agile; EXCEPT the retrospective!??Sometimes you need to have a family meeting outside of the public eye and that is the retrospective. The retrospective is all about resolving your issues in private so that you can present a united front to the rest of the world. To use a sports analogy, an NHL coach doesn’t invite the business (fans) into the dressing room between periods. There are lots of other places for transparency; the retrospective doesn’t have to be one of them.
The output of the Retrospective
While the actual retrospective meeting is closed to other observers, I would suggest that the action items coming out of the retrospective need to be made public and posted as an information radiator for everyone to see. The changes are more likely to get implemented if the team sees them every day. The team may also want to “radiate” their improvement actions on their dashboard.
The actions and results of the actions may also be shared with other teams through what is often called a Retrospective of Retrospectives. I encourage teams to only choose one or two areas for improvement at a time to provide focus and make meaningful progress.
A few weeks ago one of my customers asked me for advice about daily standup meetings (also called Scrum meetings, morning meetings, or better yet coordination meetings). Her feeling was that her teams could become more disciplined in their approach to coordination meetings so she asked if it would be possible to see how teams in other companies run their meetings. I indicated that there are a lot of good videos on YouTube and that I would write something up soon in a blog posting. So here goes.
Put your meeting strategy on the wall. Put the rules (see below) on the wall in the space where you hold your coordination meetings. If you have virtual meetings online, capture them there (in a wiki for example). We call things like this information radiators in agile.
Coach people. It takes time to build up effective meeting skills. At first you’ll want to coach people publicly within the team so that everyone can learn. After awhile, if someone is still struggling (perhaps they’re often late to the meeting or aren’t sufficiently focused) you may want to coach them privately.
Call it a coordination meeting. Terms such as “stand up meeting” or “Scrum meeting” aren’t very clear, but “coordination meeting” is. By using clear terminology you make your expectations regarding the purpose of the meeting crystal clear, thereby reducing the chance for confusion.
Set some rules. As a team, discuss what how you intend to run these meetings. Potential rules you should consider adopting include:
Arrive on time. ‘Nuff said.
One person talks at a time. There shouldn’t be side conversations going on, not only is that disrespectful it results in those people being distracted from coordinating with the rest of the team.
Come prepared. As a meeting participant you need to know how you’re going to answer each question before you get into the meeting.
Define what you want to discuss. There are many different questions or issues that you can discuss in coordination meetings. Scrum suggests “What did you do yesterday?”, “What will you do today?”, and “What’s blocking you?”. Other questions could be “What did you learn today?”, “What will potentially block you?”, “What value did you deliver since the last meeting?” and many others.
Someone different leads each day. A common strategy is to rotate the responsibility of running coordination meetings between team members. This is a great learning experience for some people and certainly helps everyone to recognize how these meetings could be run more effectively.
Stay focused. The goal is to coordinate as a team, and the easiest way to do so is for everyone to focus on that goal. So stay off your phone, don’t be reading email, don’t be holding side conversations, and only focus on the issues/questions you’ve agreed to as a team.
Stand at first. Having people stand up tends to keep meetings short but can prove to be artificial (I’ve been on coordination calls where people working from home or other locations have been asked to stand, yikes).
Coordinate around a task board. When you gather around a task board much of the status information that you may want to communicate to the meeting is provided by the task board itself. This provides opportunity to streamline your meeting process.
Here’s a few interesting videos that I found on YouTube:
How to Hold a Daily Standup. This short video provides several good tips for holding a standard “Scrum meeting”. It suggests that people answer the three standard Scrum questions so take that advice with a grain of salt. And the background music is a bit cheesy although fun.
Agile Simulation Part 20: The Daily Standup. This video is interesting because it starts with a dysfunctional version of the meeting and then shows an effective one. The common mistakes the video shows include running it like a status meeting instead of a coordination meeting; people coming to the meeting unprepared; discussing inappropriate issues during the meeting; showing up late to the meeting; having side conversations; one person was basically checked out and was lying down on a bean bag chair; and a non-team member started driving the conversation at one point.
How a Lean Thinking Company Runs a Morning Meeting. This video overviews the approach taken by an organization’s leadership team to their morning meeting. They look at their task board, a whiteboard with stickies. They’ve tailored their meeting to reflect the needs of what they need to coordinate, and in the video they discuss how they came to putting this meeting together. It’s interesting to note that they are in multiple locations, so they video conference daily.
Lean, the Morning Meeting at Fastcap. This is another non-software development example. This team explicitly changes the leader of the morning meeting each day to help them grow their skills. One of the things I like about this video is that their focus is to share critical information with each other. This includes mistakes, learnings, and any improvements that they made. The overriding goal is to focus on learning, team building, and to celebrate their successes.
Dodgy Scrum StandUp. This video was purposely put together to show many of the bad habits that people may exhibit during daily stand ups. These bad habits included not staying on topic; getting into details that most people don’t need to hear; and asking questions around implementation details instead of taking the discussion offline. One person even threw something at another person, thereby distracting the group. Another person showed up late, disrupting the discussion. The team also didn’t refer to their task board (I assume that it was the task board behind people on the left hand side of the screen).
A few people have commented that Disciplined Agile Delivery (DAD) promotes a wide range of practices, which they like because it makes their options explicit but which they also potentially dislike because there’s so many practices to choose from. This then leads to the question of why do we need so many practices? First, there are a lot of practices out there to begin with and our philosophy is to help people know that they have options and help them to select the right ones. Second, our experience is that for a practice to be easily consumable it should be:
Small. Small practices are generally more straightforward than larger practices. As a result they’re easier to understand and to adopt.
Cohesive. A good practice addresses one issue and one issue only.
Loosely coupled. Good practices, like good software modules, have minimal dependencies on other practices.
Practices that are small, cohesive, and loosely coupled are easier to configure into more interesting solutions. For example, the practice of test-first programming (TFP) is combined with refactoring to form test-driven development (TDD). The practice of (writing) executable specifications can be combined with TDD, or TFP for that matter, to give you behavior driven development (BDD) or acceptance test-driven development (ATDD). The combination of iteration modeling, model storming, look-ahead modeling, and BDD can give you a strategy for addressing emergent requirements and design during an iteration.
Of these three aspects, we’ve found that coupling has the greatest impact on your ability to tailor your approach to meet the unique situation you find yourself in. Just like highly coupled software is difficult to maintain and enhance, processes built from highly-coupled practices are too. For example, consider the way that Scrum describes product backlogs. A product backlog is one of several strategies that agile teams may use to manage their work. In the case of Scrum, the strategy is to prioritize requirements by business value and then focus on implementing the highest priority work at all times. Unfortunately Scrum has coupled many important practices to the product backlog concept. For example, initial requirements modeling is often referred to as populating the backlog. Prioritization of new requirements and exploring upcoming requirements is referred to as grooming the backlog. There are several potential problems to consider:
The term “populating the backlog” masks the fact that not only are you writing initial functional requirements (for example user stories or features) as part of your initial requirements modeling efforts you’re also sketching things (processes, screens, data structures, …), identifying non-functional requirements, holding modeling sessions, and many other things.
It makes it harder for people new to agile to understand how it works. Think of it like this, what’s a more descriptive term, “populating the backlog” or “initial requirements modeling”?
It makes it harder to combine practices. If you wanted to swap out the product backlog for something a bit more sophisticated, such as a work item list, or something leaner like a work item pool, what do you do with the practices coupled to product backlog? Do you rework “backlog grooming” to be “work item list grooming”? Do you rework “populating the backlog” to be “populating the work item pool”? Even if these things are easy to do, seems like needless effort to me.
In conclusion, we have found that adopting small, cohesive, and loosely coupled practices enables you to adopt and tailor a process strategy that better reflects the context of the situation that you face. Not only is high cohesion and loose coupling great strategies for software, their great strategies for software process too.
Clearly mainstream agile practices such as Scrum and Extreme Programming (XP) require discipline. For example, effective Agile teams have the discipline to:
Hold short, focused, and to the point daily coordination meetings rather than infrequent and time consuming status meetings. It requires discipline to keep these meetings focused on coordination activities and thereby short and to the point.
Commit to delivering a set of work items each iteration rather than letting deadlines slip. It requires discipline to consistently fulfill the promises that you make to your stakeholders.
Remove impediments in a timely fashion rather than procrastinating in pursuing a solution. It requires discipline to tackle tough issues that are easier to ignore in the short term.
Take the time to write tests before code rather than writing code, It takes discipline to consistently work in a test-first manner instead of leaving testing to some time in the (distant) future.
Test to the best of their ability instead of throwing artifacts over the wall to testers or reviewers. It takes discipline to actively take responsibility for the quality of your own work.
Reflect on the team’s experiences and improve their processes proactively rather than relying on process dictated by project managers or external governance bodies. It takes discipline to stop and take time to reflect on how well your team is working and then act to improve it.
Have a continuously working, integrated, and tested solution rather than waiting to do so when you’re “done” at the end of the lifecycle. It takes discipline to stop all work when the build is broken so that it is repaired and the state of working, high quality solution is restored.
Work together in a common area rather than in comfortable but isolated workspaces. It takes discipline to work effectively in a team, to do so in a respectful and trusting manner.
Collaborate constantly with the stakeholders or their representative(s) to ensure that their expectations are met. It takes discipline to accept that it isn’t your place to define the requirements or set priorities, particularly when you believe that you know better.
Create and evolve deliverable documentation continuously throughout the project. It takes discipline to accept that there’s more to successfully solution delivery than producing potentially shippable software.
Self organize and plan the team’s work amongst themselves rather than relying on a traditional project manager to define, estimate, and assign work. It takes discipline to take responsibility for your own work and to respect the collective decisions of your team.
In our next few blogs we’ll discuss how Disciplined Agile Delivery builds on these practices to take discipline to the next level within the Enterprise.
Malcolm Gladwell, author of The Tipping Point, Blink and Outliers, speaking at a 2004 TED conference, offered a story of one of his favorite Americans. Howard Moskowitz is an American market researcher and Psychophysicist, which according to WikiPedia is “the scientific study of the relation between stimulus and sensation”[2] Moskowitz has worked for large conglomerates such as Pepsico, McDonald’s, AllState and Kraft and is principally known for creating the insane number of product variations you see at your grocery store.
Moskowitz determined that people often don’t know the range of options they would like to buy until someone presents them with the choice.
Moskowitz was retained by Campbell Soup Company, to help them grow their spaghetti sauce brand, Prego. With his team of researchers in tow, his team tested public reaction to forty-five different varieties of sauce. When analyzing the data, the researchers didn’t just look for the combination with the highest ratings. They believed people craved variety even if they didn’t know it. They grouped their data to look for clusters- patterns. When reporting back the executives he found people like three kinds of sauces: plain, spicy, and extra chunky.
For years the approach to gathering product requirements, consumer tastes, researchers would go into focus groups and say, “What do you want in a spaghetti sauce? Please tell us. Not once did anyone say, ‘extra chunky’, even though in their heart they craved it.” Moskowitz revealed there was no “single sauce for the market. There were sauces”
How does a product owner manage in that environment? When you read the story it’s easy for us to see the solution. “Of course we want choices. The product development team should incorporate that into their development process.” And now, admittedly this is rather common place. At the time, however, Campbell’s soup executives were astonished to hear that over 1/3 of all Americans craved chunky spaghetti sauce and no one was providing it. When the market need was met, over $600M revenue was added to the Campbell’s Soup line.
So what does this have to do with software requirements? It is a story to illustrate the folly in thinking we can always know what our client will want, specify it and then build and deliver it. Even when you are dealing with an industry as mature as consumer goods & spaghetti sauce, we see that when your product is attempting to change the category, you need experimentation in your development cycle.
MIT professor and author of Predictably Irrational, Dan Arielly, reminds us we need to have something to compare against to settle our preference.
humans rarely choose things in absolute terms. We don’t have an internal value meter that tells us how much things are worth. Rather, we focus on the relative advantage of one thing over another, and estimate value accordingly. (For instance, we don’t know how much a six-cylinder car is worth, but we can assume it’s more expensive than the four-cylinder model.
Until end-users and stakeholders have something to compare it against, they can be indecisive- slowing down projects. This explains the challenge with just getting people in a room and asking them to describe to you what they want. They probably don’t really know- even when they tell you.
Typically the approach we take when we are unsure what it is we are building, we attempt to stress more documentation and more reviews. We’ve been taught that correcting a requirements error early in the life cycle saves costs down the line. We work to reduce our discomfort with the uncertainty by forcing a someone else to make a decision so we can then narrow in on our solution. We insist on a freeze in requirements and sometimes limiting participation because “too many cooks” spoils the broth- or sauce as it were. Unfortunately, we are ignoring the sometimes less than rational way people make decisions. All the process waving and feet stomping in the world won’t change the reality of the marke, meanwhile your competitor is giving your customer chunky spaghetti sauce.
Attempting to be to deterministic in specifying our project requirements usually stifles creativity. Roger Sessions of ObjectWatch, Inc. Uses the terms directed and non-directed methodologies. Equating directed methodologies to playing the childhood game, “Hot-or-Cold”, where there truly is only one possible solution. Where as Poker is a non-directed methodology where there are multiple ways to win. Just because your client specifies the need for a straight flush doesn’t mean he won’t be happy with two pair if he wins the pot.
The practices within the application life cycle that best provide some allowance for this behavior include:
• Simulation– Using rough cut, working software simulation tools such as iRise can give clients multiple usage scenarios to evaluate.
• Integrated product design– Nothing works as well as having the entire product development team deeply involved from product concept to launch, collaborating in real time- seeing the implications of their decisions and indecision.
• Iterative development cycles– Knowing the limits of prediction, rapid feedback of working software allows for course correction in architecture and product direction before too much is sunk.
• Component Architectures– Understanding where the range of diversity in our users tastes lies then requires us to build in that flexibility.
Gladwell’s story also reminds us that solutions are a continuum. A variety of different end products and combinations will make our clients happy. Boiling down to the lowest common denominator ignores the individual and organizational diversity. It may seem logical to get the market to standardize for the best greatest use, but if that’s how we made decisions we’d all be driving Model-T’s. Thank you Mr. Moskowitz for recognizing the need for spicy sauce. Now go expand your customers range of options. Go find your secret sauces.
