I always love the articles written by Glen Wang, one of my former students. He has written another good one called “Manage Objectives, Actions, and Uncertainty in Scrum“. I’ve added a bit of feedback because I think there are some important changes that need to be made to the article, but overall I love the concepts, information and presentation.
Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)
Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards
- The team goes through all the items and chooses the one which has the lowest effort. Write the number “2″ on this card (usually in the bottom right corner).
- The team looks at the item with the highest value.
- Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20″ card. It is not permissible to select two cards.
- Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
- If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
- The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
- For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
- Once explanations are complete, the team members collect their cards and go back to step three.
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes
The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.
The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.
Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.
For a few years now I have been working with managers and executives to help them do Agile-compatible performance evaluations of their staff. The method that has been most successful is based on a tool that comes from the book Toyota Talent called the “Skills Matrix”. The basic approach follows these steps:
- Baseline the skills within a team for each team member.
- Set development goals and action items.
- Regularly review performance in relation to the development goals.
Of course, the details matter. The OpenAgile Center for Learning has published a brief overview of how to use the Skills Matrix and a convenient A0-size pdf that can be used as a template for a team’s Skills Matrix. I highly recommend using these to get started. If you are a manager, ask your ScrumMaster or Process Facilitator to arrange and facilitate a team workshop to do the initial population of the Skills Matrix, rather than doing it yourself. Once that is done you have a baseline and you should take regular digital photos of the team’s Skills Matrix for record-keeping and as a backup in case of disputes. You should also let the team know that you will be basing performance reviews on how they improve their skills.
The development goals that team members set then should be made such that every team member understands that they have a responsibility to diversify their own skill set and assist other team members in doing this. As a manager, you should review each team members’ goals for development and provide mentoring support when needed. At the end of a fixed period of time (quarterly is a reasonable period), you will review each team member’s development relative to the baseline and the goals set. Of course, normal guidance around performance (or lack thereof) can be given at these regular reviews.
I strongly recommend reading “Drive” by Daniel Pink as an important adjunct to understanding how to do performance reviews for individuals in an Agile environment. In particular, individual performance reviews should not be tied to bonuses. If bonuses are used at all, they should be measured and delivered purely at the team level or organization level without measuring individual contribution.
Of course, Agile team performance can’t simply be measured in terms of skills alone. Performance must also be related to bottom-line results. This part of performance measurement is separate from the development of the team. Another aspect of Agile team performance is how well they are doing Agile itself. Depending on the Agile method you use, there may be various tools to help with this (I would recommend our new product the Scrum Team Assessment as one possible consideration).
Transforming organizations: check out the Stoos Network. Wish I had been there! Some of my favourite people were there!
Almost three years ago we wrote a brief article about interruptions. In that article, we described four methods of dealing with interruptions. I would like to expand on those four methods and add three more to present a comprehensive set of options for organizations struggling with this.
Option One: Follow Scrum Strictly
The rules of Scrum are clear: if it isn’t part of the team’s work for a Sprint, then it shouldn’t be done. From the moment the team commits to work in Sprint Planning to the end of the Sprint with the Sprint Review, the team needs to be protected from interruptions. If an interruption is truly urgent enough to warrant the team’s attention mid-Sprint, then the Sprint can be canceled. This is a pretty extreme result however since it invalidates the team’s previous commitment.
The Scrum approach is based on the basic philosophy that Scrum is a system to expose the problems and obstacles in the organization. This is painful! In the case of interruptions, Scrum then is metaphorically throwing them back in the face of the organization and saying “this is bad behavior! Fix the behavior that causes so many interruptions, don’t find a way to accommodate interruptions.”
For example, many teams are faced with interruptions related to their support of the software they are creating. In Scrum, deflecting the interruptions forces the team and the organization to examine the root causes of the support issues and fix them. If the team is producing software with lots of defects, then that needs to change. If the team is producing software that is hard to use, then that needs to change. If the team is producing software without the appropriate level of user documentation, then that needs to change. But what doesn’t change is the team breaking the safety of the Sprint defined by the rules of Scrum.
Option Two: Allocate a Portion of Time to Interruptions
Given certain conditions, the amount of interruption of a team can be “stable”. If this is the case, then the team can reasonably set aside a certain percentage of their time to handle interruptions. Determining if this is possible can be done by tracking the occurrence of interruptions and the level of effort to handle them.
In a team using this method, there are two ways to allocate this time: everyone on the team gives a certain amount of time each day to handling interruptions OR one or two people on the team are committed full-time for a cycle to handling interruptions. In either case, if the amount of actual time spent on interruptions is less than the amount of time available, then that difference of time must be used carefully. Generally, the best use of this extra time is to work on resolving the root causes of interruptions. For example, if one person of a team is dedicated to dealing with interruptions, and most interruptions come from in-the-field bug support requests, then that person might spend any extra time working on fixing older lower-severity defects.
The amount of time that the team is allocated to handling interruptions should never be exceeded otherwise the team’s commitments at the start of the cycle are not really commitments.
This option is by far the most common systematic approach to dealing with defects
Option Three: Visible Negotiation of Change
Another common method of handling interruptions is the “fluorescent note card” method which requires visible stakeholder negotiation around the impact of interruptions. With this method, any time a stakeholder comes to the team with an interruption request, the ScrumMaster/Coach/Process Facilitator writes the request on a bright colored note card so that it is easy to distinguish it from the other tasks the team is working on in their current cycle. The ScrumMaster then asks the team to do a task breakdown on the card and using their normal process (whatever that is) estimates the work effort. The requesting stakeholder then has to negotiate with any other stakeholders (and in particular the Product Owner/Growth Facilitator about what work to remove from the iteration in order to make room for the new work. This process works well primarily because it makes the tradeoffs visible. It does not work so well with letting the team make and keep their commitments which can have a long-term impact on trust.
This approach requires a few things to be in place to be effective:
- A visible task board instead of electronic tools for task tracking. The visibility makes the change much more immediate and you must have the stakeholders involved right in the same physical space. An electronic tool makes this too abstract and can lead to some important stakeholders not being properly aware of changes.
- A team that is reasonably good at estimating. By “good” I mean both accurate and fast. If it takes the team half an hour to do an accurate estimate, then that is already a significant interruption in itself! A team should be able to look at an interruption, break down the tasks and come up with a reasonably accurate estimate within no more than 10 minutes. Remember that doing this is already task switching so there is going to be an additional cost to the team.
- Finally, and perhaps most importantly, a clear agreement must be in place among stakeholders that this approach to interruptions is allowed and that the consequence of it is that the team cannot be held accountable for their commitments!!! I cannot stress this enough!
Option Four: Separate Team for Interruptions
This option is fairly self-explanatory and in fact is just a way of saying that you have a separate support group who deals with interruptions. The more technically capable this group is, and the more authority they have to make changes to the code/database/etc., the more effective they will be at protecting the agile teams from interruptions.
In some ways, this is a good approach because it makes the cost of interruptions very visible to the business: how much does your support team cost? If this cost is growing, then it means that the development teams are creating software that is harder and harder to support.
If you follow this approach, please ensure that you do not rotate development team members through the support team as this damages the team-building process for both the development team and the support team.
(One radical option to try as an add-on to this is to defray the cost of this support team by tying developer’s salaries to the cost of support. To make this palatable, you might simply say to the development team that any time a support person can be laid off due to improved quality in the product/system, that person’s salary will be permanently distributed and added as a raise to the salaries of the development folks. PS. I’ve never seen any organization do this – it’s just a theory.)
Option Five: Extremely Short Cycles
A less common, but interesting method for handling interruptions is to have extremely short iterations. In this method, choose your iteration length to be so short that you can always start work on urgent interruptions before anyone gets impatient! This can be exhausting, but it is one of the best ways to get the team and the organization to understand the large toll that these interruptions take.
There is a simple way to determine how long your cycle should be based on measurement. Choose a “normal” duration (e.g. one or two weeks) and for several cycles track how many interruptions are submitted to the team, and how urgent is the turn-around time on those interruptions. After several cycles, the team can then adjust its cycle length so that, on average, the team is able to start and finish a cycle in a time shorter than the expected frequency of interruptions.
For example, one team I worked with found that in general, they were getting interruptions that needed to be handled within three or four days, but more urgent interruptions were rare. They decided to use a cycle that was only two days long so that on average they would complete handling an interruption in three days. (Interruption comes half way through a cycle and is put on the backlog at the top. The next cycle they start and finish the interruption. Elapsed time is three days.)
Option Six: Status Quo / Suffering
There is nothing inherently wrong with continuing with your current approach to handling interruptions. It probably makes some people miserable, but there are also some people who really enjoy crisis and constant change. In fact, it may be part of the culture of your organization or something that is strategically important in your particular industry. That doesn’t mean you can’t be agile, but it may mean that you are making compromises where you are trading off team performance for some other benefit. it is important that if you choose to continue with your status quo, that you make the trade-off transparent. Tell everyone on your teams exactly why you are making the trade-off and what is the expected benefit of doing so.
Option Seven: Commitment Velocity
The most sophisticated option is based on measuring a special kind of velocity called “Commitment Velocity”. This is a mechanism that allows both interruptions to be handled mid-cycle and for teams to make commitments that they can keep. In the simplest terms, Commitment Velocity is the minimum historical slope of a team’s Sprint burndown.
For example, if a team in Sprint 1 has 240 units of effort at the start of the Sprint, but, partly due to interruptions, does not finish and then has 40 units of effort left unfinished at the end of the Sprint, then the Commitment Velocity (slope) of the team is 240 – 40 = 200. In their next Sprint planning meeting, they would plan such that they had at most 200 unites of effort in their Sprint plan. The team then does their second Sprint and again, partly due to interruptions, they don’t finish everything. Perhaps this second sprint started with 195 units of effort (<200) and finished with 10 units of effort remaining. Their new Commitment Velocity is 195 – 10 = 185. They do a third sprint, but they finish everything.
It is tempting for the team to perhaps take an average – maybe they finished 200 units of effort in their third Sprint so they average 200, 185 and 200 leaving 195. This is not Commitment Velocity. By definition, an average means that the team will successfully complete all their work 50% of the time.
Instead, the team maintains its Commitment Velocity of 185 for their fourth Sprint. By the law of large numbers and the central limit theorem, as the team uses this tool of Commitment Velocity for more and more Sprints, eventually their ability to keep their commitments, even with interruptions) will become closer and closer to 100% certain.
Selecting an Option
Ultimately, the most important thing in selecting one of these options is to do so consciously and in the spirit of learning that underlies agile methods. Choose an option and then stick with it long enough to truly understand if it is working for you or not.
There are some things to consider as well:
- If you are trying to do a dramatic improvement in how your organization gets stuff done, I would recommend choosing either Option One (Follow Scrum Strictly) or Option Seven (Commitment Velocity). Both of these are options that put pressure on the team and the organization to improve.
- If you don’t have strong executive support for Agile, then probably Options Two (Time Allocation), Four (Separate Team) and Five (Short Cycles) are going to be your best bet at first.
- If you do have strong executive support, but you aren’t desperate to improve your organization, you might consider Option Three (Visible Negotiation).
- Of course, Option Six (Status Quo) is the easiest… I don’t really recommend it though! Agility requires systematic change to encourage continuous improvement. All the other options assist with this.
Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”. Doing Scrum really well is much harder and much rarer. Here is a list of 24 common pitfalls or bad behaviours of Scrum teams:
- Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started.
- Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well! Use manual and paper-based tracking for early Scrum use since it is easiest to get started. Finding a tool is usually just an obstacle to getting started. (And besides, check out what the Agile Manifesto says about tools.)
- Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track.
- Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members. It is better to wait for someone to step up than to “take over” and assign a task.
- Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint.
- ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.
- Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums). As well, the Product Owner should also be available during work time. Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
- Stretch Goals: The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals.
- Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team. Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
- Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems. The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
- Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog. PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
- Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint. Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
- Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing. A team member solves problems, but it is critical to know about constraints. The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
- Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit. Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
- Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped. These activities can be part of the tasks in the Sprint Backlog.
- Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint. Building prototype code just delays the inevitable need to write production code. Similarly, wireframes, detailed designs and other similar tools should also be avoided.
- Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.
- Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules. The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
- Changing Team Membership: Scrum is a framework for creating high-performance product development teams. If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence. If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.
- Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team. For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title. Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.
- Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”. It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
- Imposed Deadline Scope And Resources: Scrum is reality-based. If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum. The reality is that no-one can predict the future so any such imposition is simply a fantasy.
- Definition of “Done” Imposed: There is confusion between the concept of the definition of “done” and “standards”. Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
- ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters. They worked there together most of the time! The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team. Otherwise, the ScrumMaster should be in the team’s room.
In his book “Crossing the Chasm“, Geoffrey Moore describes the difficulty of creating a popular new product due to a conceptual “chasm” between the first people who adopt a new product and those who come later. He describes five types of people in relation to how they adopt new products:
- Innovators – always actively seeking out and trying cutting edge new products.
- Early Adopters – excited to try new things, but after the worst “bugs” have been removed.
- Then there is the Chasm – many products fail here.
- Early Majority – willing to try new things but need strong testimonials or real-world proof.
- Late Majority – require time-tested proof before they will adopt a product.
- Laggards – resistant to change and hesitant to adopt anything without strong personal incentives.
This product adoption behavior also applies to new ideas in general, and of course, to Agile Transformation [Agile Transformation vs. Agile Adoption] in particular.
Implications of the “Chasm” Model
An organization attempting to do an Agile Transformation [Kotter's 8-Step Change Model] should understand how to use this model to ensure long-term success. This diagram illustrates the concepts (click on it to see it full size):
First, the organization should start the transformation by finding the innovators and early adopters. These people can then be recruited to run the initial pilot projects. They will be enthusiastic and will typically adapt themselves to the new behaviors and thinking patterns required by Agility. If they are properly supported by managers, they will also be successful – at least within the bounds of a limited pilot environment. Success here will mean that the pilot projects deliver value, use feedback effectively, and the participants (team members and stakeholders) will be happy with the results.
In this stage, it is best to avoid putting people on the teams who are from the early majority, late majority or laggards groups. These people will tend to drag on the results of the pilot projects. This is a common mistake in running a pilot program and leads to discouraging results. One way to help filter between these two groups is simply to ask for volunteers for the pilot projects. Innovators and early adopters will be much more likely to volunteer for a new initiative.
After the pilot projects have shown some good results, the next step is to go the general roll-out. In this step, you are now working with the early and late majority. These people need much more substantial support for a change of this nature. They will require intensive training, and hand-holding in the form of coaching and mentoring. This hand-holding can come partially from your innovators and early adopters. Some of the participants in the pilot projects will have the desire to share their success. From these, you need to carefully select and prepare a few who will act as internal coaches. If you are a small organization or if you wish to do your transformation quickly, you will likely need to hire coaches from outside your organization as well.
The early and late majority require evidence of benefits and reassurance that risks are minimal or can be mitigated. This evidence partially comes from your pilot projects. However, this may not be sufficient. There are two other important sources of evidence for this group: the leadership team and external experts.
The leadership team must be committed to the change to agility and can demonstrate this commitment by doing their own management work as an agile team. The exact details of the agile process do not need to be identical to that of the staff teams, but it should be recognizably similar. As well, this “Agile Transformation Team” must make itself very visible during the general roll-out. This can be done with communication and by taking up visible residence in a central conference room or bullpen. As well, this Agile Transformation Team must work diligently to remove obstacles that are raised by staff teams during the general roll-out.
The second source of evidence comes from external sources. Published case studies are one valuable source. However, there is a huge value in a visible management investment in external support from recognized experts. This can be in the form of training, coaching, consulting as well as informal “lunch-and-learn” meetings, town hall meetings and the like. When engaging experts, it is imperative that the Agile Transformation Team act on their advice otherwise the early and late majority will take that as a sign of hypocrisy.
The final stage of a roll-out is to deal with the laggards. For the most part this is a do-or-die proposition for these people. Either get with the program and engage like a committed employee or leave the organization. If your organization is large enough, you will likely have observed some of these people leaving the organization in the general roll-out.
For some organizations, this transformation process can take many years. An organization with thousands of people should expect to be working on the pilot projects for at least a year, the general roll-out for at least three years. Often it will be longer. Good luck on your agile transformation effort!
I have worked with a lot of people, teams and organizations over the last 8 years helping them to adopt Scrum and I have seen some interesting patterns about where Scrum works well and where it doesn’t work so well. I wanted to share my observations to see if they correlate with what other people are experiencing.
So first off, I want to describe what I mean by Scrum working well:
- Teams using Scrum are obviously high-performance teams whose business results are at least 4x that of normal teams.
- The organization in which Scrum is being used experiences a change in culture to become more team oriented, more value oriented, and more customer oriented.
So now I can describe where I have observed Scrum to work really well:
- When an organization (or team) is in deep trouble and willing to admit it adopting Scrum seems to be a catalyst for creating a new culture, process and team environment where getting out of trouble is possible. This is Scrum for Crisis. The “willing to admit it” part is extremely important as I have worked with two organizations where the “deep trouble” part was obvious to me as an external person, but in both cases management and staff did not seem willing to admit the depth of their crisis and in both cases Scrum failed to act as a catalyst to get them out of trouble. In this use of Scrum, sometimes resolving the crisis then leads back to complacency and Scrum fades away.
- Small growing organizations that have no existing formal processes for development can use Scrum as an effective way to maintain their high-performance without getting burdened in bureaucracy. In this case, it is important to note that they are _already_ in a high performance state and their struggle is to maintain that while at the same time growing. I’ve worked with quite a number of small organizations where all they need is the CSM (plus maybe one or two days of coaching) to adopt and maintain Scrum. I have also worked with small organizations that were _not_ already high performance and Scrum has not typically worked to bump them up to a high-performance state.
- Pure new product development where a single strong Product Owner can be identified who has the authority to make product decisions independently of anyone else (including product budget decisions). By “pure new product development” I mean that neither the individual team members nor the team as a whole have any responsibilities outside of the product work – there is no “fractional allocation” or “resource levelling” across projects or products. The strong Product Owner is critical to success with Scrum and must understand the principles of Scrum as well as the mechanics of being a Product Owner.
I have also seen Scrum be inappropriate and not lead to the results I mentioned above:
- Management teams. It seems like Scrum could or should work for management teams, but it appears that managers have too much of the following problems to be able to use Scrum:
- operational responsibilities (non-creative, non-problem-solving work)
- urgent, legitimate interruptions (e.g. an escalated customer issue)
- real commitments to events or projects that are calendar based (e.g. a management off-site)
- ego: they don’t want to follow an apparently rigid process or they are always happy to make exceptions for themselves
Again, one might imagine that Scrum _should_ work to help resolve these issues, but unfortunately I have never seen it able to do so in this context.
- Small teams/projects. Scrum is too heavy for teams less than 5 people or for projects shorter than 2 months in total duration. Those numbers aren’t meant to be hard and fast, but when I’ve seen small teams/projects attempt to do Scrum they _always_ end up breaking lots of the rules partly because they can and partly because they must. That said, some folks have created “Personal Scrum” and other variants. I’m not sure if we as the Scrum Alliance officially recognize/endorse those variants.
- Purely operational work. There just isn’t enough creativity/problem-solving to make the Sprint an appropriate process element, nor the Product Backlog an appropriate organizing mechanism. I have seen some operational environments get some benefit from doing regular retrospectives, but just doing retrospectives is not Scrum in my book. My experience with Kanban is still a little limited, but it seems to be an appropriate approach for these environments.
- Organizations where there is very little need to change. I’ve spent some time working with big profitable banks to adopt agile and without exception, they just can’t wrap their minds around the need for Scrum… because they are already so successful as a business. The general attitude is that Scrum is popular therefore we will call what we are doing “Scrum”, but it really isn’t. It’s Scrummerfall and Scrum-Butt wrapped up in the terminology of Scrum. They will adopt some Agile practices and get very modest benefits. I have seen minor improvements in team morale and minor improvements in quality and productivity, but certainly not anything near to what is possible for improvements. When we do assessments in this type of environment, we see Value Stream maps with waste at the 80-90% level so there is huge room for improvement… but it just doesn’t happen.
Scrum can definitely transform the world of product development. It can definitely act as a catalyst to get teams and organizations out of crisis. But that isn’t the whole world of work. I’m also concerned about the idea of using Scrum for general project management. There might be some good practices that are part of Scrum that would also be valuable in general project management (e.g. regular retrospectives, daily team meetings) but that doesn’t make Scrum a general project management framework.
I don’t claim that any of the above observations are “correct”. That’s partly why I am sharing – I would love to have a good discussion here about this because I think it is critical for us as Agilists to be able to answer this question well when we are asked: “what is Scrum good for?” – particularly since Scrum is by far the most popular Agile method.
I would love to hear other people’s observations about where Scrum works well (as I have defined “well” above) vs. where it either is only a modest improvement to existing approaches or where it might even not work at all.
We have started putting together a list of topics / learning objectives for a new course: “Agile for Managers”. I am interested in getting suggestions from readers on topics to include. What are the challenges you have had with managing agile teams? If you are on an agile team, what are some of the challenges you have had with management? What are the burning questions you have as a manager about deciding to use agile methods? What have been some of the critical success factors in adopting agile methods? What about pitfalls?
I will summarize feedback in a future article as well as post a proposed agenda for such a workshop. In order to “give back”, I will also make the initial draft of the course materials available under a Creative Commons license so that others can use the materials.
I look forward to hearing your thoughts!
A former student of mine called the other day. He asked a good question: how do you calculate the budget for a project if you are using an agile approach to delivery. Here is the overview of the six steps to do this. I will follow the overview with some detailed comments.
- Prepare and estimate the project requirements using Planning Poker
- Determine the team’s Velocity
- Using the team’s burn rate and velocity calculate the budget for the Iterations
- Add any capital costs
- Using the definition of “done” add pre- and post- Iteration budgets
- Apply a drag or fudge or risk factor to the overall estimate
Prepare and estimate the project requirements using Planning Poker
The project requirements have to be listed out in some order and then estimated. If you are using Scrum as your agile approach, you will be creating a Product Backlog. Extreme Programming and you will be creating user stories. OpenAgile and you will be creating Value Drivers. Kanban and you will have a backlog of work in progress. Regardless of the agile approach you are using, in a project context you can estimate the work using the Planning Poker game. Once you have your list, you need to get the team of people who will be working on the list to do the estimation. Estimation for agile methods cannot be done by someone not on the team – this is considered invalid. It’s like asking your work buddy to estimate how much time it will take to clean your own house and then telling your kids that they have to do it in that amount of time. In other words, it’s unfair. Planning Poker results in scores being assigned to each item of your list. Those scores are not yet attached to time – they simply represent the relative effort of each of the items. To connect the scores to time, we move to the next step…
Determine the team’s Velocity
The team needs to select its cycle (sprint, iteration) length. For software projects, this is usually one or two weeks, and more rarely three or four weeks. In other industries it may be substantially different. I have seen cycles as short as 12 hours (24/7 mining environment) and as long as 3 months (volunteer community organization). Once the duration of the cycle is determined, the team can use a simple method to estimate how much work they will accomplish in a cycle. Looking at the list of work to be done, the team starts at the top item and gradually working their way down, decide what can fit (cumulatively) into their very first cycle. Verbally, the conversation will go something like this:
“Can we all agree that we can fit the first item into our first cycle?”
- everyone responds “Yes”
“Let’s look at the second item. Can we do the first item AND the second item in our first cycle?”
- a little discussion about what it might take to do the second item, and then everyone responds “Yes”
“Okay. What about adding the third item?”
- more discussion, some initial concern, and finally everyone agrees that it too can fit
“How about adding the fourth item?”
- much more concern, with one individually clearly stating “I don’t think we can add it.”
“Okay. Let’s stop with just the first three.”
Those items chosen in this way represent a certain number of points (you add up the scores from the Planning Poker game). The number of points that the team thinks it can do in a cycle is referred to as its “Planning Velocity” or just “Velocity”. With the velocity, we can then do one of the most important calculations in doing a budget…
Using the team’s burn rate and velocity calculate the budget for the Iterations
The team’s velocity is a proxy for how much work the team will get done in a cycle. However, in order to understand a budget for the overall project, we need to take that estimate of the team’s output and divide it into the total amount of work. Our list has scores on all the items. Sum up the scores, then divide by the velocity to give you the number of cycles of work the team will need to complete the list. For example, if after doing Planning Poker, the sum total of all the scores on all the items is 1000, and the team’s velocity is 50, then 1000 ÷ 50 = 20… This is the time budget for the team’s work to deliver these items. To do dollar budgeting, you also need to know the team’s burn rate: how much does it cost to run the team for a cycle. This is usually calculated based on the fully-loaded cost of a full-time-employee and you can often get this number from someone in finance or from a manager (sometimes you can figure it out from publicly available financial data). In general, for knowledge workers, the fully-loaded cost of a full time employee is in the range of $100000/yr to $150000/yr. Convert that to a per-cycle, per-person cost (e.g. $120000/yr ÷ 52 weeks/year x 2 weeks/cycle = $4615/person/cycle) and then multiply by the number of people on the team (e.g. $4615 x 7 people = $32305/cycle). Finally, multiply the per-cycle cost by the number of cycles (e.g. $32305 x 20 cycles = $646100).
This is the budget for the part of the project done in the cycles by the agile team. But of course, there are also other costs to be accounted.
Add any capital costs
Not many projects are solely labor costs. Equipment purchases, supplies, tools, or larger items such as infrastructure, land or vehicles may all be required for your project. Most agile methods do not provide specific guidance on how to account for these items since agile methods stem from software development where these costs tend to be minimal relative to labor costs. However, as a Project Manager making a budget estimate, you need to check with the team (after the Planning Poker game) to determine if they know of any large purchases required for the completion of the project. Be clear to them what you mean by “large” – in an agile environment, this is anything that has a cost similar to or more than the labor cost of a cycle (remember: agile projects should last at least several cycles so this is a relatively small percentage of the labor costs). In the previous example calculation, the cost per cycle was $32305 so you might ask them about any purchases that will be $30k or larger. Add these to the project budget.
Using the definition of “done” add pre- and post- Iteration budgets
Every agile team is supposed to be “cross-functional” but in reality, there are limits to this. For example, in most software project environments, teams do not include full-time lawyers. This limited cross-functionality determines what the team is capable of delivering in each cycle – anything outside the team’s expertise is usually done as either pre-work or after the iterations (cycles) are finished. Sometimes, this work can be done concurrently with the team. In order to understand this work, it is often valuable to draw an organization-wide value stream map for project delivery. This map will show you the proportion of time spent for each type of work in the project. Subtract out all the work that will be done inside the agile team (their definition of “done”) and you are left with a proportion of work that must be done outside the agile team. Based on the proportions found in the value stream map, add an appropriate amount of budget based on the project’s cycle labor costs.
Apply a drag or fudge or risk factor to the overall estimate
And of course, to come up with a final estimate, add some amount based on risk or uncertainty (never subtract!) Generally speaking, before this step, your project budget is going to be +/- 20%-50% depending on how much you have used this approach in the past. If you are familiar with it and have used it on a few projects, your team will be much better at understanding their initial velocity which is the foundation for much of the remaining budget estimates. On the other hand, if you are using this method for the first time, there is a high degree of anxiety and uncertainty around the estimation process. Please feel free to add a buffer that you feel is appropriate. But again, never, ever, ever remove time or money from the budget at this last step.
Please let me know if you have any comments on how you have done this – tips, tricks or techniques are always welcome in the comments.
Great article: The Changing Role of Middle Managers.
The United States Department of Defense Command and Control Research Program has published a short (10 pages) paper on the concept of Agility (by David S. Alberts) and the need for Agility for Complex Endeavors. Lots of fabulous thinking has gone into this paper which is loaded with useful definitions, useful concepts and advice about where we need to go with research. I STRONGLY recommend taking twenty minutes and reading it right now.
Now that you have read it… no? … go read it! You don’t have an excuse – you’re reading my blog aren’t you?!
Okay, really. Here a couple of highlights:
The Age of Interactions
We are no longer in the Information Age. I _love_ this concept. It gels well with what I am doing with agile in organizations, it gels with what I am doing in my volunteer work as a Baha’i. It gels well with my limited media-filtered understanding of what is going on in the world of ecology, economics, and politics.
The Age of Interactions is characterized by
unlimited possibilities… unleashed for the ways individuals and organizations can connect and work with one another. These interactions have profoundly changed our world, presenting both a set of challenges as well as providing new opportunities.
This means that ways of working with these connections (skills, processes and technology) are going to become the keys to unlocking the potential of this Age.
Mr. Alberts claims “Agility is a latent property, a potential that remains dormant until it is manifested and its power released.” (p. 9). This is incorrect. Agility can be and is an active property, not latent. Agility is manifested actively by running short-term experiments, options analysis, executing work using just-in-time principles, and systematically incorporating experience into a body of knowledge and habits that further enhance Agility.
OpenAgile is a system that helps individuals, teams and organization deliberately build the capabilities to demonstrate Agility, regardless of industry, affiliation, or context.
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
I. Agile Volunteer Team Process
- The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
- Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
- Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
- The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
- Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
- When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
- When a volunteer completes a task, they move the task into the “done” column.
- There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
- What did I do last week?
- What will I do this week?
- What did I learn/observe?
- What obstacles, if any, are affecting my ability to do work?
- New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
II. Communication Tools
- Login and read new messages
- Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
- Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
- Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
- Get work done:
- Move the task on the wall to in progress
- If the task came from an email, label the task with your name
- When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
- ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
- By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
- FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
- Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
- Task Written & Posted – apply this label after you write up the task and post it on the wall
- Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
- Website – these emails are relevant to website updates
III. What is 60/40 Time?
- Belief in the mission of the charity
- Desire to “give back”
- Meet new people
- Make new business contacts
- Invited or inspired by another volunteer or staff member
- Improve resume
- Learn new skills
- Benefits such as free events
A close associate, David Parker, has written a great little article about the use of agile methods in volunteer management.