Trying this out today for a remote client meeting. So far, I like it. Will update after the meeting…
Trying this out today for a remote client meeting. So far, I like it. Will update after the meeting…
I facilitated this workshop today for a senior leadership team. I mostly employ famous quotations familiar to many to provide a brief overview of Servant Leadership as well as a learning framework for systematically building capacity in others while improving the systems in which they work. The folks in the workshop seemed to really connect with Scott’s CLEAR model (not so famous but ingenious in its deceptive simplicity). I offer it as a guide for designing CLEAR acts of leadership.
So you are embarking on an Agile transformation. One important thing you need to figure out (and hopefully you have some consultants helping you) is how many Scrum Teams you will need for product development and how many Kanban teams you will need for operations, deployment, support, maintenance, keeping the lights on, etc. Because when you create a bunch of cross-functional teams they will have gaps in their Agile engineering practices and their definition of “done” will have to be limited by several organizational factors. The teams won’t have access to many of the environments and there won’t be enough specialized resources to assign to each team. Plus, the nature of the work coming into the ops and support teams are much more finely grained and varied than user stories in a Sprint Backlog and it’s important that the Scrum teams focus on their products and are not disrupted by every little change request from the business. So you need Kanban teams to do the work that the Scrum Teams can’t do yet as well as the stuff that you don’t want your Scrum Teams to be distracted by.
That’s more or less the popular consensus on the role of Kanban in the Agile community. Some acclaimed thought leaders have even written popular books and blog posts about it. But if one digs a little deeper, one finds that there is much more to Kanban than meets the common agilist’s eye (although clearly this is changing, evidenced by the existence of this piece of writing). So here are the 14 things that I can think of off the top of my head:
If you are interested in the history of the Kanban Method, start here.
Best starter book: Essential Kanban.
Hi Everyone, I don’t do announcements on here too often, but I wanted to let everyone know about the official launch of our new product: the Scrum Team Assessment – an online tool for your team to get a report on how well they are using the Scrum framework… and most importantly, helpful recommendations on how to improve! This is a fully automated Scrum maturity assessment tool!
The Scrum Team Assessment is based on the years that I and two other coaches (Paul Heidema and Travis Birch) have been working with Scrum and Agile teams to improve business and technical results. The Scrum Team Assessment is a joint effort that has resulted in a fully automated virtual coach for your team.
The analysis is both statistical and expert-system based. This means that the report has basic information about how the team is following Scrum, and, more importantly, clear how-to advice to get your team to make improvements. There are “quick wins” which are easy but will have a significant impact as well as long-term recommendations that are often harder, but will drive your team to a high-performance state.
The Scrum Team Assessment includes a survey of about 100 questions that focus on seven broad categories:
Every team member fills in the survey to help us generate a valid set of recommendations.
The Scrum Team Assessment is $496/team/use (that’s Canadian dollars). If you have several teams or wish to obtain an enterprise license, please contact us at firstname.lastname@example.org or +1-905-868-9995.
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.
I had the privilege of attending Scrum.org‘s 2-day seminar on Scaled Professional Scrum. The Nexus, a connection or series of connections linking two or more things (direct translation from Latin a binding together), is the recommended scaling framework. The purpose of the Nexus is to manage dependencies between 3-9 Scrum Teams towards “reification”, to make an abstract idea real or concrete. This is ensured mostly through a single Product Owner, single Product Backlog, integrated (Nexus) Sprint Planning, Review and Retrospective and the addition of a Nexus Integration Team whose membership is made up mostly of Scrum team members internal to the Nexus, but often also includes other support personnel. The structure is very similar to LeSS, but perhaps even less prescriptive and is certainly much less prescriptive than SAFe. This is probably my favourite thing about the Nexus – the fact that it has just enough structure to be a model for scaling Scrum, but is light and flexible enough to accommodate all of the nuances that “just depend” on your situation. Like the other two above-mentioned scaling models, it places emphasis on the need for strong technical practices, continuous integration and the synchronization of events to facilitate integration. There is flexibility around synchronization, in that if the Nexus Sprint is 4 weeks in duration and teams within the Nexus want to do 2 or even 1 week Sprints, the model accommodates – as long as all of the teams’ work is combined into a fully integrated (reified) increment of potentially shippable product by the end of the Nexus Sprint.
The other day a technology leader was asking questions as if he didn’t agree that things like pair programming and code review should be part of the Definition of “Done” because they are activities that don’t show up in a tangible way in the end product. But if these things are part of your quality standards, they should be included in the definition of “Done” because they inform the “right way” of getting things done. In other words, the Definition of “Done” is not merely a description of the “Done” state but also the way(s) of getting to “Done” – the “how” in terms of quality standards. In fact, if you look at most of any team’s definition of “Done”, a lot of it is QA activity, carried out either as a practice or as an operation that is automated. Every agile engineering practice is essentially a quality standard and as they become part of a team’s practice, should be included as part of the definition of “Done”. The leader’s question was “if we’re done and we didn’t do pair programming and pair programming is part of our definition of “Done”, then does that mean we’re not done?” Which is sort of a backwards question because if you are saying you’re done and you haven’t done pair programming, then by definition pair programming isn’t part of your definition of done. But there are teams out there who would never imagine themselves to be done without pair programming because pair programming is a standard that they see as being essential to delivering quality product.
Everything that a Scrum Development Team does to ensure quality should be part of their definition of “Done”. The definition of “Done” isn’t just a description of the final “Done” state of an increment of product. In fact, If that were true, then we should be asking why anything is part of the definition of “Done”. This is the whole problem that this artifact solves. If this were the case, the team could just say that they are done whenever they say they are done and never actually identify better ways of getting to done and establishing better standards. We could just say (and we did and still do), “there’s the software, it’s done,” the software itself being its own definition of “Done”.
On the contrary the definition of “Done” is what it means for something to be done properly. In other words, it is the artifact that captures the “better ways of developing software” that the team has uncovered and established as practice because their practices reflect their belief that “Continuous attention to technical excellence and good design enhances agility” (Manifesto for Agile Software Development). The definition of “Done” is essentially about integrity—what is done every Sprint in order to be Agile and get things done better. When we say that testing is part of our definition of “Done”, that is our way of saying that as a team we have a shared understanding that it is better to test something before we say that it is done than to say that it’s done without testing it because without testing it we are not confident that it is done to our standards of quality. Otherwise, we would be content in just writing a bunch of code, seeing that it “works” on a workstation or in the development environment and pushing it into production as a “Done” feature with a high chance that there are a bunch of bugs or that it may even break the build.
This is similar to saying a building is “Done” without an inspection (activity/practice) that it meets certain safety standards or for a surgeon to say that he or she has done a good enough job of performing a surgical operation without monitoring the vital signs of the patient (partly automated, partly a human activity). Of course, this is false. The same logic holds true when we add other activities (automated or otherwise) that reflect more stringent quality standards around our products. The definition of “Done”,therefore, is partly made up of a set of activities that make up the standard quality practices of a team.
Professions have standards. For example, it is a standard practice for a surgeon to wash his or her hands between performing surgical operations. At one time it wasn’t. Much like TDD or pair programming, it was discovered as a better way to get a job done. In this day and age, we would not say that a surgeon had done a good job if he or she failed to carry out this standard practice. It would be considered preposterous for someone to say that they don’t care whether or not surgeons wash their hands between operations as long as the results are good. If a dying patient said to a surgeon, “don’t waste time washing your hands just cut me open and get right to it,” of course this would be dismissed as an untenable request. Regardless of whether or not the results of the surgery were satisfactory to the patient, we would consider it preposterous that a surgeon would not wash his or her hands because we know that this is statistically extremely risky, even criminal behaviour. We just know better. Hand washing was discovered, recognized as a better way of working, formalized as a standard and is now understood by even the least knowledgable members of society as an obvious part of the definition of “Done” of surgery. Similarly, there are some teams that would not push anything to production without TDD and automated tests. This is a quality standard and is therefore part of their definition of “Done”, because they understand that manual testing alone is extremely risky. And then there are some teams with standards that would make it unthinkable for them to push a feature that has not been developed with pair programming. For these teams, pair programming is a quality standard practice and therefore part of their definition of “Done”.
“As Scrum Teams mature,” reads the Scrum Guide, “it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” What else is pair programming, or any other agile engineering practice, if it is not a part of a team’s criteria for higher quality? Is pair programming not a more stringent criteria than, say, traditional code review? Therefore, any standard, be it a practice or an automated operation, that exists as part of the criteria for higher quality should be included as part of the definition of “Done”. If it’s not part of what it means for an increment of product to be “Done”—that is “done right”—then why are you doing it?
Becoming familiar with the “User Story” approach to formulating Product Backlog Items and how it can be implemented to improve the communication of user value and the overall quality of the product by facilitating a user-centric approach to development.
User stories trace their origins to eXtreme Programming, another Agile method with many similarities to Scrum. Scrum teams often employ aspects of eXtreme Programming, including user stories as well as engineering practices such as refactoring, test-driven development (TDD) and pair programming to name a few. In future modules of this program, you will have the opportunity to become familiar enough with some of these practices in order to understand their importance in delivering quality products and how you can encourage your team to develop them. For now, we will concentrate on the capability of writing good user stories.
A User Story has three primary components, each of which begin with the letter ‘C’:
As a <user role> of the product,
I can <action>
So that <benefit>.
The test for determining whether or not a story is well understood and ready for the team to begin working on it is the INVEST acronym:
I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
Note: The INVEST criteria can be applied to any Product Backlog Item, even those that aren’t written as User Stories.
Sometimes a user story is too big to fit into a Sprint. Some ways of splitting a story include:
WARNING: Do not split stories by system, component, architectural layer or development process as this will conflict with the teams definition of “done” and undermine the ability of the team to deliver potentially shippable software every Sprint.
Like User Stories, Personas are a tool for interactive design. The purpose of personas is to develop a precise description of our user and so that we can develop stories that describe what he wishes to accomplish. In other words, a persona is a much more developed and specific “who” for our stories. The more specific we make our personas, the more effective they are as design tools.iii
Each of our fictional but specific users should have the following information:
Only one persona should be the primary persona and we should always build for the primary persona. User story cards using personas replace the user role with the persona:
so that <benefit>.
i The Card, Conversation, Confirmation model was first proposed by Ron Jeffries in 2001.
ii INVEST in Good Stories, and SMART Tasks. Bill Wake. http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
iii The Inmates are Running the Asylum. Alan Cooper. Sams Publishing. 1999. pp. 123-128.
This is the story of how the Scrum of Scrums has evolved for a large program I’m helping out with at one of our clients.
The ultimate purpose of Product Backlog refinement is to ensure an ongoing conversation that increases transparency of the Product Backlog and therefore the Product itself – to orient everyone on the team to breaking out of their waterfall silos and focus on delivering business value, period.
On mature teams, a lot of the refinement work happens as ad hoc conversations while they are sitting around and thinking together about how to build something great because they are just motivated by that and it becomes part of their mode of operation.
The objective of the refinement work of any given Sprint (that often needs to be repeated over and over like a mantra with new, immature teams) is to ensure that the items at the top of the Backlog are transparent enough that the Development Team considers them ready to pull and get “Done” in the next Sprint. This is where the concept of the Definition of “Ready” (DoR) comes from – the Scrum Team defines the DoR and spends up to 10% of its capacity refining enough items at the top of the Backlog so that it can provide estimates (if required) and have a reasonable degree of confidence that it can deliver the items in the next Sprint.
Refinement is NOT solutioning – I think this is the big trap that a lot of teams fall into because there is a false assumption that technical solutions need to be hashed out before estimates can be made (part of the carried-over lack of trust and communication between the business and IT) – I would almost rather throw out estimates in cases where this is not improving – The Planning Game exercise, when facilitated well, lends itself more to increasing transparency rather than solutioning.
The fact that teams are telling us that they need to solution before they can estimate is also an indication of weak Agile Engineering practices such as refactoring, test-driven development and continuous integration (XP). The best refinement sessions are those in which the team is able to focus on the “what” – the business benefit results that the Product Owner really wants – rather than the “how” (solution). Strong teams emerge in an environment in which they are trusted by the business and management to find the right solution as a team. They don’t need to have it all figured out before giving an estimate because they are not afraid to give a bad estimate and fail. Also, if the team is struggling to give estimates, this is often a sign that the Product Backlog Items are too big. Most likely the team also needs to expand the Definition of “Done” to include testing against acceptance criteria within the Sprint so that they can estimate based on that criteria.
The “how” (solution) should be mapped out by the Development Team at a high level in the 2nd part of Sprint Planning (partly why the time box is bigger than they often think they need) and more detailed architecture, requirements and design work as part of the Sprint Backlog
But this level of maturity is very hard to do and it will take a while to get there, perhaps even years.
It also depends on your interpretation of “detail”, the word used in the Scrum Guide to describe what the team does in Product Backlog refinement. To me, it means understanding in more detail what the Product Owner really wants and needs. What does it mean to you?
The Product Backlog is often described as the primary input to Scrum. The Sprint starts with Sprint Planning and Sprint Planning starts with the Product Owner and the Product Backlog. In principle, this makes perfect sense and hopefully it is enough for most teams and organizations to just start with the Product Backlog. And if you don’t have a Product Backlog, then just start without one, get some stuff done that the team thinks is important, invite some people to the Sprint Review and most likely one of those people will end up becoming the Product Owner and gradually take on the responsbilities of that role. I believe in just starting if you can. I even wrote a blog post about this a while back and I stand by it.
I have served as a Scrum Master and coach for a number of teams and I have identified some patterns that I think are worth addressing. Newly-formed teams tend to ask for (and need) a little more help than this in order to feel ready to start. And I have learned from experience that it is usually more effective for the adoption of Scrum and team development for the team to feel ready enough to just start.
The Scrum Guide recognizes the following inputs to Sprint Planning:
A newly-formed team often needs to address the following before the first Sprint:
If these are not addressed before the first Sprint, then they will likely need to be addressed during Sprint Planning, which can place a lot pressure on a new team (especially in environments where it is difficult to build shared understanding of the work).
Keep it simple. It’s an ordered list of all the features, functions, enhancements and fixes that might be needed in the end product. Get the Product Owner to blow these things out into a list. It doesn’t need to be a complete list. Just the most important things right now. A good test is to give the Product Owner 5 minutes. Whatever the Product Owner can think of in 5 minutes is important enough for the team to start working on. There are all kinds of techniques that can be used to order the Product Backlog. The simplest way is to just have the Product Owner eyeball it. If people are uncomfortable with this, then introduce the other ways. It doesn’t need to be perfect. It will get better and become refined and adapted as you go.
Multiply the number of working days in the Sprint (total days minus Sprint Planning, Sprint Review and Sprint Retrospective, rounding down) by the number of Development Team members by the average percentage team member dedication (hopefully 100%). If you have weird things going on with team member allocation (not 100%) then you may find it helpful to refer to this blog post. According to what the Scrum Guide says about Development Team size and Sprint duration, this number could theoretically be smaller (Sprint less than one week), but in most cases no less than 12 (3-member Development Team in a one-week Sprint) and no more than 207 (9-member Development Team in a one-month Sprint with 23 days – the maximum number of weekdays in a month).
This is a list of all of the activities that will go into the intended Increment of the first Sprint in order for it to be done. The team needs to know this before it can estimate the items in the Product Backlog as a team. Estimation is not a requirement of Scrum, but is often very helpful in refining the Product Backlog, tracking velocity and making projections into the future based on historical actuals.
In the first part of Sprint Planning, the team looks at the items at the top of the Product Backlog in order to determine what can be done in the Sprint and the Sprint Goal, keeping in mind that it will need to complete the items according to its Definition of “Done”. Once the team has set a Sprint Goal, it can then create a set of tasks that represent how the work will get done. All of the tasks should fulfill a specific attribute of the Definition of “Done” or be about the technical parts of the system that need to be built. The team should try to create a set of tasks each of which are a one-person day effort or less. Count the number of tasks. If the number of tasks are close to the number of days of the team’s capacity, the team can be confident that it has a decent Sprint Backlog. If not, then the the Sprint Backlog and likely the Sprint Goal will need to be adapted.
Lots of smart people have already come up with lots of ways of doing adaptive planning, and chances are someone has already come up with some variation of this particular approach. I have not yet had the benefit of reading everything that everyone else has already written about Agile and planning, so this has been generated by my own experiential learning on the ground as an Agile coach. Sometimes, as a ScrumMaster/Agile Coach, you are called upon to be a two-trick pony. This is my other trick.
A Scrum Team that is estimating effort against Product Backlog items for project planning and timeline projections and changes team membership for one or more Sprints must also re-estimate the remaining items (or at least the items that will be part of the Sprints in which the different/additional team members are expected to participate) regardless of estimation method (Agile Planning Poker or otherwise). The people involved in doing the work (Development Team members/Sprint) must also be involved in providing team estimates. The Development Team is responsible for all estimates as a whole team and therefore should provide estimates as a whole team. The Planning Poker game is widely understood by Agile experts and successful Agile teams as the best tool for facilitating team estimation. Part of what makes Planning Poker so effective is that it does not only provide accurate timelines, but it also facilitates knowledge-sharing among team members as everyone on the team is required to endeavor to understand the degree of complexity of the work of all other team members in order to deliver each item according to the team’s Definition of “Done”.
Sometimes, the Development team will have people partially dedicated to the team. After one or two Sprints, it becomes apparent that full dedication of all Development Team members is required for optimal team performance. As result, management can be assisted to reconsider allocation of team members towards 100% dedication to the work of a single Scrum Team. Increased (or decreased) dedication of team members can also be expected to have a corresponding impact on velocity (effort points completed per Sprint). However, the Scrum Master needs to help the team (and their managers) to be careful to avoid planning against the unknown. Scrum allows a team to adapt based on actual historical data. Therefore, planning against minimum historical velocity is strongly recommended as a general best practice. At the same time, if a team starts off with, say, 50% allocation of team members and management decides to bump it up to 100%, it is fairly safe to assume that you will actually get somewhat more out of the team. How much more is never possible to know, as human beings are reliably incapable of predicting the future. The moderate way to approach this is to plan the next Sprint based on previous velocity, finish the planned work early in the Sprint, get a bunch of “extra” stuff done, then calculate velocity of the new and improved team and plan against the new and improved velocity. This allows the team to adapt to actuals and not be blind-sided by unforeseen impediments/bottlenecks.
Sometimes, there is a need for management to get a sense of how much more velocity the team will get from increased team member allocation in order to feel that an informed decision has been made. There is a simple (though not risk-free) method for doing this that I have whipped up after being put on the spot on several occasions. I have decided to call this the Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game.
The purpose of this exercise is to provide decision-makers with a sense of how much they are going to get out of adjusted allocation of team members to Scrum Teams. Scrum Teams perform optimally when all team members are 100% dedicated to the team. This game should be used with caution and as a means to help organizations move closer to 100% dedication of all Scrum Team members (at least all Development Team members) and, therefore, eliminate the need for this game. Great care should be taken to not encourage perpetuation of dysfunctional Waterfall habits such as “we will now go twice as fast and get done twice as early with twice the allocation of resources because we have this shiny new crystal ball called Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game that tells us so.” As long as no one believes that this is magic, it is likely safe enough to proceed to Step 1.
After the first Sprint, the team should be able to count up the number of Product Backlog items completed and add up the corresponding number of “Effort Points” established during its initial estimation (Planning Poker) sessions. Let’s say for our example that the number completed for Sprint 1 is 21 Effort Points. Therefore, the current velocity of the team is 21. Let’s say that this is not a comfortable realization for the team because at some point in the past it had been estimated that this project would take the team about 5 Sprints to complete. Now, the team has done 21 points in the first Sprint and the total number of Effort Points on the Product Backlog estimated by the team is just under 210. Uh oh… 10 Sprints! Whoops! Now what do we do?! Are the new estimation values wrong? Should we stick to the 5 weeks and just have everyone work overtime on this project? Should we take this to management? Let’s say that this team decides to take it to management. But what if management needs more information than “team velocity = 21, Product Backlog = 210, therefore it’s going to take us 10 Sprints instead of 5”? Never fear, Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game is here!
As part of Sprint Planning, the team needs to have a sense of its capacity in order to create the Sprint Goal and Sprint Backlog. Therefore, the team should already have a sense of its own capacity. Let’s say for our example that the (fictional) Development Team had the following projected allocation for the first Sprint:
50% Chris P. Codemuncher
50% Larry Legassifulunch
25% Beth Breaksidal
40% Gertrude Gamesthadox
40% Dana Deadlinedryver
The team is doing 2-week Sprints. After calculating the time that the team has allocated for Scrum Events, the remaining time for doing the work of the Sprint is about 8.5 days. Therefore, we can calculate the total allocated days per team member as such:
8.5 x 50% = 4.25 days Chris P. Codemuncher
8.5 x 50% = 4.25 days Larry Legassifulunch
8.5 x 25% = 2.13 days Beth Breaksidal
8.5 x 40% = 3.4 days Gertrude Gamesthadox
8.5 x 40% = 3.4 days Dana Deadlinedryver
17.43 Total combined available days per Sprint
Let’s round that down to 17. That’s the number used by the team to understand its capacity for Sprint Planning. This is a powerful number for other reasons than what we are trying to get at here, but they are worth pointing out nonetheless. For generating the Sprint Backlog in Sprint Planning, this is particularly useful if each task in the Sprint Backlog is a maximum of a one-person-day. Therefore, this team should have a minimum of 17 tasks in the Sprint Backlog and these tasks should all be a one-person-day or less amount of effort. If the team has more than 17 tasks which are all about a one-person-day of effort, chances are the team has overcommitted and will fail to deliver the Sprint Goal. This should trigger the adaptation of the Sprint Goal. In any case, it provides the team with simple transparency that can easily be inspected and adapted throughout the Sprint. For example, with one-person day tasks, each team member should be able to move at least one task into the “Done” position every day and point to that movement every day during the Daily Scrum. Also, this team should be burning down at least 5 tasks every day. If either of these fails to occur, this is a clear signal for the team to inspect and adapt.
Now, let’s get back to our Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. As a result of Steps 1 & 2 we now know that the team’s velocity is 21 Effort Points and that the team’s capacity is 17 person-days per Sprint. For short, we can say:
(WARNING: This number is dangerous when in the wrong hands and used as a management metric for team performance)
Let’s say a friendly manager comes along and says “you know what, I want to help you guys get closer to your original wishful thinking of 5 Sprints. Therefore, I’m deciding to allocate more of certain team members’ time to this project. Unfortunately, I can only help you with the ‘developers’, because everyone else reports to other managers. I’m concerned that Beth is going to become a bottleneck, so someone should also speak with her manager. But for now, let’s bump Chris up to 100% and Larry up to 75% and see what that does for you. We’re also going to throw in another ‘specialist developer’ that you need for some stuff in your Product Backlog at 100%. How much more velocity can I get for that?”
Okay. So…more allocation = more capacity = more velocity, right? If we acknowledge that this is highly theoretical, and remember the initial WARNING of the game, we can proceed with caution…
But just as we get started on calculating the adjusted allocation of team members, we find out that Beth was actually more like 50% allocated, Dana was more like 15% allocated and Gertrude was more like 30% allocated. We need to recalculate our actuals for Sprint 1:
8.5 x 50% = 4.25 days Chris P. Codemuncher
8.5 x 50% = 4.25 days Larry Legassifulunch
8.5 x 50% = 4.25 days Beth Breaksidal
8.5 x 30% = 2.55 days Gertrude Gamesthadox
8.5 x 15% = 1.28 days Dana Deadlinedryver
16.58 Total combined ACTUAL available days in Sprint 1
16 Actual capacity (rounded-down)
21/16 Actual V/C
As a side note, Beth had to work on a Saturday in order to increase her capacity but she spoke with her manager and thinks that from now on she will probably be able to maintain this degree of dedication to the team without having to work any more overtime.
Now the team can calculate its hoped-for capacity for Sprint 2 and beyond:
8.5 x 100% = 8.5 days Sally Supaspeshalis
8.5 x 100% = 8.5 days Chris P. Codemuncher
8.5 x 75% = 6.38 days Larry Legassifulunch
8.5 x 50% = 4.25 days Beth Breaksidal
8.5 x 30% = 2.55 days Gertrude Gamesthadox
8.5 x 0% = 0 days Dana Deadlinedryver
30.18 Total combined hoped-for available days in Sprint 1
30 Hoped-for capacity (rounded-down)
21 Actual Historical Velocity
16 Actual Historical Capacity
30 Hoped-For Future Capacity
x Hoped-For Future Velocity
Some simple math, loaded with assumptions:
Actual Historical Velocity/Actual Historical Capacity = Hoped-For Future Velocity/Hoped-For Future Capacity
Therefore if 21/16 = x/30, then x = 21 x 30/16 = 39.375
39 Hoped-For Future Velocity
Hopefully, not much. The best thing for the team to do at this point is to plan against its actual historical velocity of 21. If team members finish their work in the Sprint Backlog early, they should help out with other tasks until the Sprint Goal is delivered. Then, if the team achieves the Sprint Goal early and has extra time left before the end of the Sprint, then the team can pull additional items to work on from the Product Backlog. If the velocity of the team actually increases as a result of actual increased capacity, then the team can safely plan against its increased velocity beginning in Sprint 3. However, Hoped-For Future Velocity is often way too tantalizing for a team that already strongly (and to some extent, logically) believes that it can get more done with more capacity. So, most teams will usually plan to do more in light of this knowledge and that’s fine. Scrum allows them to inspect and adapt this plan at least every day. The team will figure it out.
Thank you for playing Theoretical Team Member Allocation Adjustment for Team Capacity Adaptation Projections Game. I hope it was as fun to play as it was to create!
See you next time,
Feedback from first version incorporated.
I am currently working with a relatively new Scrum team (5 Sprints/weeks young) that needs to rewrite their Personal Development Plans (PDPs) in order to better support Scrum and the team. PDPs are still the deliverables of individuals required by the organization and likely will be for some time. The organization is still in the early days of Agile adoption (pilots) and they are large. So, instead of giving them a sermon on why metrics for managed individuals are bad, I am going to help them take the step towards Agility that they are ready to take.
I’ll follow up with another post to let everyone know how it goes.
I recently had the opportunity to help facilitate a client’s “Innovation Challenge”. Basically, the concept is to get a bunch of people in the room, give them a business challenge and see what they come up with.
I have to say that the format of the workshop that I used is heavily inspired by a training that I did recently called Specification By Example by Gojko Adzic. I strongly recommend this seminar as well as the book. Another strong influence is The Inmates are Running the Asylum… by Alan Cooper. The workshop that I have developed is a sort of hybrid approach, with my own flavour added to the mix. During an early iteration of the workshop, I didn’t have a title and one of the participants suggested “Agile Inception”. I think that title works in a space where Agile is established and well understood (e.g. hopefully this blog). At the same time, this workshop can be run with people who have no prior experience or knowledge of Agile and without even mentioning the word Agile. This is also good in certain environments where people have developed an Agile allergy.
Anyhow, my goal for the day was to facilitate the building of shared understanding of the challenge itself as well as some ways that the organization could innovate around that challenge through conversation and collaboration.
From the opening remarks it became clear that the product at the centre of the “challenge” was actually in deep crisis: a shrinking market combined with shrinking market share. The product had generated approximately $18M in revenue in 2009, compared with $10.4M projected for 2014. That’s half dead in some people’s books. The clear Goal was to reverse that trend, starting with at least $11M in 2015. They needed a powerful jolt of life-giving innovation energy to defibrillate their failing product’s heart.
There were no shortage of ideas about how the product could become better & more profitable. In fact, there were many, many ideas. Too many, perhaps. Once we had established our working agreement for the day, we did a Starfish Retrospective exercise to make visible all of the things that the group wanted to keep doing, start doing, stop doing, do more of and do less of. Many post-it notes were stuck on the board and we left them there as a reminder of all of the things that people were thinking about that could help us to consider how the product and ways of working on it could be improved.
Then we talked about the Goal. True innovation—that is, tangible, innovative results with clear benefits—requires a group to focus on a single, clear, SMART (Specific, Measurable, Achievable, Relevant and Time-bound) Goal that everyone in the organization understands and is committed to achieving. Often times, as was the case with the group on Thursday, taking time to establish shared understanding of the goal can seem redundant and tedious (“we already know what the goal is…”). However, as we learned through the process of working in small groups to re-articulate understanding of the Goal back to the “customer” (the person paying for everyone to be there) this often requires some further conversation. Indeed, when the groups presented their understanding of the Goal, there were gaps that needed to be filled by the “customer”. It took less than 30 minutes to discuss, adapt and confirm the Goal with the customer. The value of this investment of everyone’s time was tremendous. The conversation made it clear that shared understanding had already been established to a degree and enabled the group to build on what was already there to make the Goal “SMARTer” in the minds of all of the participants.
A single, transparent business Goal helps us to innovate with focus—to create the right thing. In addition, we need to develop a single Persona—the ideal, “imaginary” user of the product. The larger group broke into smaller groups for the subsequent discussions. The groups worked separately and generated a the details for a few personas. All 3 personas added value to the conversation. The Persona of “Lisa” was particularly compelling to the “customer” because she had a clear goal of her own and through innovation, her goal could be aligned with the overall business Goal to create a powerful, “new” product that just might reverse the downward trend.
The next step in innovating with focus in order to generate the best ideas possible: build shared understanding of how Lisa can pursue her goal through her experience of the product in order for the business Goal to be achieved. In other words, Lisa needs a story. Her story needs a beginning and an end (for now, until the next story) and all the stages of her journey need to be integrated into a coherent whole.
The last step was for the groups to brainstorm and come up with different ways that the product can deliver Lisa’s story in order to realize the Goal.
I wish I could say more about the really cool ideas that the group came up with, but I am erring on the side of caution when it comes to protecting my client’s competitive advantage.
To wrap up the session, we took a quick, anonymous gauge of how confident the participants felt about achieving the Goal. Of the 13 participants, two gave their confidence a score of 8/10, six gave a score of 7/10, four scored themselves a 6/10 and one was a 3/10, for an average of 6.5/10. Not bad, but clearly some work still to go. So what’s next for them?