On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.
Agile Advice was started in 2005. In ten years, we have published over 850 articles (an average of just about 2 per week!). Here are some collections of the ten “best” articles. I hope you enjoy looking back at (or discovering for the first time!) some of the things that have made this such a great joy for me.
Ten Most Popular Agile Advice Articles
- How Two Hours Can Waste Two Weeks (75,000+ visits)
- The Seven Core Practices of Agile Work (25,000+ visits)
- Eight Barriers to Effective Listening (17,000+ visits)
- Seven Essential Teamwork Skills (17,000+ visits)
- 24 Common Scrum Pitfalls Summarized (15,000+ visits)
- Mentoring and Coaching: What is the Difference? (14,000+ visits)
- Wideband Delphi Estimation Technique (14,000+ visits)
- The Pros and Cons of Short Iterations (13,000+ visits)
- Three Concepts of Value Stream Mapping (13,000+ visits)
- Agile Work and the PMBoK Definition of Project (11,000+ visits)
Ten Most Commented Upon Agile Advice Articles
- 24 Common Scrum Pitfalls Summarized (19 comments)
- Agile Becomes Easier with Useful Tools (12 comments)
- Important Words about Scrum and Tools (9 comments)
- The Skills Matrix and Performance Evaluation on Agile Teams (9 comments)
- The Definition of Done is Badly Named (8 comments)
- How Two Hours Can Waste Two Weeks (7 comments)
- Agile is Not Communism (7 comments)
- Agile Tools vs. Agile Books (6 comments)
- The Decline and Fall of Agile and How Scrum Makes it Hurt More (5 comments)
- The Planning Game: an Estimation Method for Agile Teams (5 comments)
I also want to acknowledge that there are a number of other contributors to Agile Advice besides me (Mishkin). These contributors are all experts, all have great experiences, and all are fantastic people to know. I’m grateful for their contributions since they have all made Agile Advice a better place to browse!
Five Most Frequent Contributors (of Articles, besides Mishkin)
- Paul Heidema (34 articles)
- Travis Birch (24 articles)
- Christian Gruber (19 articles)
- Mike Caspar (16 articles)
- Shabnam Tashakour (13 articles)
Plans for the Future – Five Top Ideas for Series
- Essays on each of the Values and Principles of the Agile Manifesto
- Summary articles of several Agile methods including Scrum, OpenAgile, Kanban, Crystal, XP, and others
- Real Agility Program case studies
- Reviews of other scaling / enterprise Agile frameworks such as Disciplined Agile Delivery, Large Scale Scrum, Enterprise Scrum
- New guest articles from thought and practice leaders.
In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams. It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment. The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective. They were functional teams (e.g. a team of testers). But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration. So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team. Everyone was involved – all the people who would be on the teams were in the room. Those teams stayed together with the same membership long after that meeting.
This “team creation event” was a fantastic success for that particular department. What made it a success?
- Everyone participating already had Agile training and experience. They knew what they were getting into and why they were doing it.
- Everyone was encouraged to participate through the way the meeting was facilitated. No one felt like their opinion was ignored.
- The meeting was long, but also time boxed. It wasn’t an open-ended discussion that could go forever.
- It was in-person!!! Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
- It was honest: tough things were discussed including potential personality conflicts. This open discussion required expert facilitation.
- Management was not involved in the decision-making during the meeting.
- The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
- A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
- Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)
In the Real Agility Program, the team creation event is used to launch a Delivery Group. The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people. Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day. Longer is not recommended. For larger Delivery Groups, we recommend that the team creation event be held off-site.
Facilitation of the team creation event is usually done by the process/people Real Agility Coach. If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.
The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work. If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again. A few days should be the maximum delay.
One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready. In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees). As a result, the teams created in the team creation event were not really properly stable. This caused a great deal of disruption and even significant morale problems for some teams. It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event. That includes any necessary means to encourage people who are thinking of leaving to reconsider. It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.
So, to make it systematic, here are the steps required to run a team creation event:
- Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
- The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
- The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
- In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group. Is it for a specific Program? If so, what is the objective of the program from a business perspective? It should not just be a one-time communication. This should come from the business Real Agility Coach.
- The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations. These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.
TEAM CREATION EVENT AGENDA
- The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
- Management stakeholders make their presentations to ensure that participants have a clear vision.
- The business Real Agility Coach summarizes the vision presented by the management stakeholders.
- The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
- Multi-skilled (see the Skills Matrix tool for ideas here).
- Correct size (usually 7 +/- 2).
- People who want to work with each other.
- People who want to work on that particular team’s goal (if such is set).
- Everyone must be on a team.
- Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
- Everyone starts self-organizing! Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams. These optimization opportunities should always be offered as suggestions rather than being directive.
- As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
- Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
- The people/process Real Agility Coach closes the meeting. It is critical to record the final results of who is on which team. It may be easiest to get the teams themselves to do this before leaving the meeting.
- The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
- The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone. Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
- Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
- A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.
Have you experienced an event like this? Did it work? What was different from what I described?
Although Agile methods are very popular (particularly Scrum), there are still many organizations or departments which may not yet have official support for adopting Agile methods formally. In some cases, management may even be hostile to the concepts and practices of Agile methods. If you are interested in Agile, you don’t have to give up hope (or look to switch jobs). Instead, here are some tips to start using Agile methods even in hostile environments.
Some Agilists claim that the retrospective is actually the key to being Agile. In some ways, this is also the easiest practice to introduce into an organization. Start with “easy” retrospectives like “Pluses and Deltas” or “Starfish“. These are retrospectives that can be done in 15 minutes or half an hour. Try to do them with your team weekly. If you are are a team lead or a project manager, it will be easy to include this as part of an existing weekly status meeting. If you are “just” a team member, you might have to get some modest amount of permission.
So why would it be good to do a retrospective? Because it’s a high return-on-investment activity. For a few minutes of investment, a team using retrospectives can become aware of dramatic opportunities for improvement in how they are functioning. Here are a couple more articles about the importance of retrospectives:
Although I strongly recommend starting with retrospectives, sometimes that’s not the best way to start. Myself, my first formal Agile environment, I started with the Daily Scrum. Another time less formal, I started with Test-Driven Development. In both cases, starting with a single practice, done well, led to adding additional practices over a relatively short period of months. This gradual adoption of practices led, in time, to attracting positive interest from managers and leaders. This is the practice-by-practice approach. Start with a simple Agile practice that you can do without asking anyone for permission. Make sure it is a practice that makes sense for your particular environment – it must produce some benefit! If you are technical contributor on a team, then practices such as refactoring or test-driven development can be a good place to start. If you are more business-oriented, then maybe consider user stories or one of the Innovation Games. If you are responsible for administrative aspects of the work, then consider a Kanban board or burndown charts.
It is important to get the chosen practice done consistently and done well, even when the team is struggling with some sort of crisis or another. If the practice can’t be sustained through a project crisis, then you won’t be able to build on it to add additional Agile practices.
Sometimes you get an unusual opportunity: a project that is funded but hidden from the bureaucracy. This can happen for a variety of reasons, but often it is because some executive has a pet project and says (effectively): “make it so”. This is an opportunity to do Agile. Since there is little oversight from a process perspective, and since the overall project has a strong executive sponsor, there is often a great deal of freedom on the question of “how do we actually execute.” There can be challenges as well: often the executive wants daily insight into progress, but that level of transparency is actually something that Agile methods can really support. In this case, there is no need to ask anyone on what method to use, just pick one (e.g. Scrum or OpenAgile or XP or Kanban or Crystal or…) and go for it. Don’t talk about it.
The “just do it” approach requires that you have some influence. You don’t have to be an influencer, but you need connections and you need charisma and you need courage. If you don’t have at least two of those three, you shouldn’t try this approach. You have to do things and get away with things that normally would get people fired – not because they are illegal – but simply because they are so counter-cultural to how your organization normally works. Here are a few comments on Stealth Methodology Adoption.
There’s nothing like working with a band of rebels! If you can find one or two other people to become co-conspirators in changing your organization, you can try many lines of action and see which ones work. Getting together for lunch or after work frequently is the best way to develop a common vision and to make plans. Of course, you need to actually execute some of your plans. Having people to work with is really part of the other tips here: you can have co-conspirators to help you launch a practice-by-practice Agile transformation, for example.
But, like any rebellion, you really need to trust those you work with in these early stages. Lacking that trust will slow everything you do possibly to the point of ineffectualness. Trust means that you have, for some time, a formal vow of silence. Not until you have critical mass through your mutual efforts can you reveal the plan behind your actions.
Read “Fearless Change”
I can’t recommend this one enough! Read “Fearless Change” by Mary Lynn Manns and Linda Rising. This is a “patterns” book. It is a collection of techniques that can be applied to help make organizational changes, where each technique has its own unique context of use. Lots of research and experience have gone into the creation of this book and it is a classic for anyone who wants to be an organizational change agent. Patterns include basics such as “Do Lunch” to help build trust and agreement with your ideas for change or “Champion Skeptic” to leverage the value of having systematic, open criticism of your change idea.
Don’t Call it “Agile”
This isn’t really a “tip” in the sense of an action item. Instead, this is a preventative measure… to prevent negative reactions to your proposals for change. The words “Agile” or “Scrum”, while they have their supporters, also have detractors. To avoid some of the prejudices that some people may hold, you can start by _not_ calling your effort by those names. Use another name. Or let your ideas go nameless. This can be challenging, particularly if other people start to use the words “Agile” or “Scrum”. By going nameless into the change effort, people will focus more on results and rational assessment of your ideas rather than on their emotional prejudices.
A minor variant of this is to “brand” your ideas in a way that makes them more palatable. One company that we worked with, let’s call them XYZ, called their custom Agile method “Agile @ XYZ”. Just those extra four symbols “@ XYZ” made all the difference in changing the effort from one where managers and executives would resist the change to one where they would feel connected to the change.
Get Some Training
Okay, some blatant self-promotion here: consider our Certified Real Agility Coach training program. It’s a 40-week program that takes about 12 hours/week of your time for coursework. The next cohort of participants starts in June 2015 and we are taking deposits for participants. This training is comprehensive, top-notch training for anyone wishing to become an organizational change agent focusing on Agility.
You probably already use an Agile Estimation technique such as the Planning Game or the Bucket System, but surprisingly few people understand the underlying principles of Agile Estimation. This lack of understanding often causes confusion or stress for the people who try to use Agile Estimation techniques. The discrepancy between traditional estimation techniques and Agile techniques is large and it is hard to bridge that mental gap without understanding the principles involved. There are three fundamental principles of Agile estimation:
Principle One: Collaborative
Agile estimation methods are collaborative. This means that multiple people work together to arrive at estimates for work in an Agile project or product development effort. Traditional estimation techniques (such as those related to bottom-up or top-down) tend to focus on individuals estimating the work that they are responsible for doing and “trusting” those individual estimates. Collaborative estimation means that most estimation is done by people in formally facilitated meetings where people are present in-person.
Collaborative techniques are generally used where there is some expectation that multiple minds are better than a single mind in discovering some new knowledge or solving a problem. Teamwork and groupwork are based on this concept. This idea of collaboration for problem solving is also applied to Agile Estimation and it has some interesting ramifications.
The most radical consequence of collaborative estimation methods is that there is no possibility to trace a particular estimate for a particular item to a particular individual person. This lack of traceability is important to create a sense of safety on the part of participants in the estimation effort. This safety is necessary to allow participants to be fully honest about estimates even if those estimates conflict with expectations of powerful stakeholders. Another way of stating this principle is that no individual can be punished for a bad estimate.
Many Agile estimation techniques take this principle beyond just mere collaboration to the level of consensus-building techniques where everyone in a group doing estimation work must agree on the final estimate for each and every item being estimated. This strengthens the idea of safety to the point where no participant in an estimation effort can ever say “I didn’t agree with that” and thereby leave other participants “on the hook” for a bad estimate.
Principle Two: Relative Estimation
Imagine you are shown a glass bottle with some water in it. You can see the water sloshing around. Someone asks you, “how much water is in the bottle?” You might, at first, think about the overall size of the bottle and respond by saying “it’s 1/3 full.” Or, if asked to provide a measure in units like millilitres or fluid ounces, you might mentally compare what you see in front of you to some container (e.g. a measuring cup) where you know the quantity. In both cases, you are doing a relative estimate of the amount of water in the bottle. You are comparing the amount of water to a known quantity.
Imagine a counter-example: someone walks up to you with a red pen ask asks you “what is the wavelength of the light being reflected from this red ink?” If you are like most people, you have probably forgotten (if you ever knew) the wavelengths of light in the visible spectrum. You have no basis for comparison. You might take a wild guess, but it is just that. Going back to our relative measure, you might be able to easily say if it is darker or lighter than another red colour, or you might even be able to tell what hue of red it is. But those cases are, again, relying on our inherent ability to see relative differences.
So instead of ignoring this capacity, in Agile estimation techniques, we leverage it. When estimating effort, we start by setting a clear baseline for what we are comparing: another piece of work. The baseline piece of work is often given an “estimate” that is arbitrary and in some non-standard units. For example, it is common to use “points” when estimating the effort for Product Backlog Items.
When doing relative estimates it is very important to ensure we are comparing “apples to apples”. Both the piece of work to be estimated and the comparison piece should both be work items that are not yet done! If you have already completed one of the pieces of work, you have prior knowledge that you don’t have for the work to be estimated.
This last point is subtle, but important. If you have already done something, you know much more about it. If you try to compare to something you haven’t yet done, you will be tempted to assume that the two things will be more similar than they may be when you actually get to work on it. By comparing two pieces of work that you have not yet done, you become much more conscious of the risks of comparing, and that consciousness will help you make better relative estimates.
It is important to note that one side advantage of using relative units for estimation is that it makes it much more difficult to use estimates as a baseline for either measuring performance or for tracking schedule variance, both of which are essentially meaningless in a good Agile environment (which should be almost entirely results-oriented).
Principle Three: Fast
In Agile estimation we don’t care (!!!) about accuracy nor about precision of estimates. Whoa! Why is that? Because estimation is waste. You can’t sell estimates, and estimates don’t affect the “form, fit or function” of the thing you’re building. Therefore, both Agile and Lean concur: do your utmost to eliminate that waste. There are actually lots of Agile practitioners who think estimates are evil (and they have some good arguments!)
In order to do Agile estimation in a maximally non-evil way, we need to make estimation fast! Really fast!!! Many of the Agile estimation techniques allow you to estimate a product release schedule lasting as much as a year in just a few hours given a reasonably well-crafted Product Backlog.
There are really only two modestly good reasons for doing estimation in an Agile project or product:
- Estimates provide simplified information to the Product Owner to allow him/her to make sure the Product Backlog is ready for the next Sprint (ordered, refined).
- Estimates allow stakeholders, including the team doing the work, to generate high-level common understanding and expectations without dwelling on details.
As a business stakeholder, one can do a simple mental exercise. Ask yourself, “how much money would I be willing to spend to accomplish those two objectives?” Whatever your answer, I hope that it is a very small amount compared to what you are willing to spend on getting results. If not, perhaps you haven’t really embraced the Agile mindset yet where “the primary measure of progress is working software” (the Agile Manifesto).
Bonus Principle: We Suck at Estimating
Most people doing estimation in traditional project management try to measure in units like person-days or dollars. There is no doubt that these units are useful if you can get good estimates. However, most of the people doing estimation are fundamentally and irredeemably bad at it. How do I know? Because they are not wealthy… and have thereby proven that they cannot predict the future. If you can predict the future, even just in limited circumstances (like estimating effort or revenue), you can leverage that to generate almost untold wealth. Given that, it is fruitless and wasteful to try to get better at estimating. Instead, the principles of Agile estimation help us focus our attention on the right things: collaboration, comparative estimates and doing them fast so we can get to the real work, and most importantly: delivering valuable results now. Understanding these principles helps teams overcome many of the struggles they have in using Agile estimation techniques.
If you are a ScrumMaster or Coach or Project Manager or Process Facilitator of any kind, I encourage you to become a master of Retrospectives. I just happened upon this great little set of slides and presentation notes about Retrospectives by a couple of people, Sean Yo and Matthew Campbell, done a couple months ago. Very helpful with some practical information, some great links… I strongly recommend checking it out. My only concern is that they limit the scope of retrospectives too much. I have a list of topics that I think can and should be considered in a retrospective:
- Technology / tools
- Work space / physical environment
- Corporate culture
- Corporate standards and policies
- Work planning and execution
- Skill sets
- Interpersonal dynamics
- External groups
- Personal circumstances and needs
- The process you are using
This list comes from a presentation I used to include as part of my Certified ScrumMaster course. (Now, in my course I teach three specific methods of doing retrospectives as part of an in-depth simulation exercise.) Here is a PDF version of the Retrospectives Module.