Home » Posts tagged 'agile'
Tag Archives: agile
This is part 2 of a series of posts that show how we can model virtual kanban systems on TFS 201x.
If you didn’t read part 1, I would recommend that you start there.
Big gotcha with regard to this blog post
You cannot access the TFS data warehouse (which we will need to do) using Visual Studio Online and as far as I know, there is no way to access the data stored there in any way yet. As such, this post will make the assumption that you are using TFS 201x on-premise and can access the TFS Data Warehouse.
Same assumptions from part 1 apply and I’ll re-iterate them here along with a few other assumptions.
- You are a TFS user and will understand the features that I’m using.
- You have a basic understanding of TFS Process Templates
- You have a basic understanding of the Iteration Path hierarchical work item field that is present in the various Process Templates
- A basic understanding of virtual kanban systems as they pertain to software development
- NEW – You have a basic understand of how TFS Work Item States work
- NEW – You have a working knowledge of Excel 2010+
- We’ll be connecting to databases and programming in VBA
Just as a quick review, here is the current state of our virtual kanban system implementation.
Remember that we are using iteration paths to represent the backlog (uncommitted work) and the kanban system and the only work item state we will be (really) interested in is “Done”.
Calculating Basic Lead Time Metrics
Using the movement of a work item into the kanban system iteration path, until it gets to a “Done” state, we can now calculate the lead time for that item. The easiest way I’ve seen to do these analysis, after your kanban system has been setup and running for a while, is to use Excel to consume and analyze TFS data warehouse data about work item changes.
Developer Ribbon in Excel
The first thing we need to do is turn on the Developer Ribbon in Excel. After you’ve started Excel (I’m using 2013), right click on the ribbon and select the Customize the Ribbon option.
Turn on the Developer tab by checking the box and pressing OK.
Prepping the Spreadsheet
For this exercise, I like to create three sheets in my Excel workbook.
We will refer to the names of these sheets in our Excel VBA code.
Getting Data From TFS
Excel has the functionality to connect to easily connect to SQL Server databases and that is exactly where TFS stores all of it’s data. TFS stores the data that we are interested in in a database that is called Tfs_Warehouse.
Navigate to the Data tab on your spreadsheet and put the caret on cell A1.
Now create a connection to Tfs_Warehouse by visiting the Data tab, clicking the From Other Sources button and selecting From SQL Server.
Enter the name of the database server that is the backend for your TFS installation and use the appropriate credentials (SSO or SQL Server account) in the connection dialog and click Next.
Note – You will need to able to access the server with either your domain account permissions or a SQL Server account that has permissions to access Tfs_Warehouse database.
Select the Tfs_Warehouse database on the server and the DimWorkItem table and click Next.
Change the name of the connection to something more friendly like LeadTimeConnection.odc and set the friendly name to something more descriptive and click Finish.
An Import Dialog will pop open once you have hit Finish. Select the Properties button on this dialog.
On the Properties dialog, click the Definition tab and then change the Command Type to SQL and enter the SQL statement below in the Command Text textbox and press OK.
Now press OK on the Import dialog and you should now see the Data sheet fill up with data from your TFS database.
VBA Magic to the Rescue
Now that we have our work item data coming, we need to do a couple things:
- Narrow it down to the time period under review
- Determine what started and finished within that time period
- Calculate the Lead Time for the items that completed during this period
Caveat – I’m not a VBA Script writer by trade! I’m fairly certain there could be better ways to write this code, but since writing elegant VBA code is not my objective, I’ll just get you to the lead times. If you have any suggestions on how to better code this out, I’d love to hear from you.
Create a VBA Module
On the Developer tab, click the Visual Basic button to get to the VBA IDE.
Once you are in the Visual Basic editor, create a new module for holding your code by right-clicking on the Module node of the tree and inserting a new Module.
Now we can just start entering all of the code from below.
Declare String Constants in the Module
These strings (global) allow us to do set our sheet names and change the iteration paths that we use to model our kanban system.
Determine Vertical Range of Data
This code needs to discover the length of the data set that we’re processing. This function does that.
Create Lead Time Generation Function
This code is pretty messy but isn’t actually very complicated. What happens in this function is that we go through each row of the source data set and look for the work item entering the kanban system iteration path. We then look for the work item getting to the done state.
If a Start Date and and End Date are discovered for the work item, we make an entry in the LeadTimeReport sheet with the calculated Lead Time. If we do not find those dates, no entry is made.
You can step through the code in the IDE using F8 to step through each line of the function.
Create Public Access and Initialization Function
This code is the function that is going to be invoked by the button we put on our parameters sheet. It sets all of the global values for the module, acquires the start and end date of the period under observation, modifies the command text of the SQL query to use the dates in the query,
Now that the module has been created that does all of the data transformation work, we need a simple UI that allows us to pick a Start Date and an End Date for the period under observation and a button to kick the whole thing off.
After you have selected the Parameters worksheet, in cell A4 type out “Start Date”. In cell A6 type out “End Date”. And finally on B3 put “Period under Observation”. These are labels for our UI.
Now on the Developer tab, click the Design Mode icon on the ribbon. Now we can Insert 2 Date Picker controls onto the worksheet. Click the Insert icon on the ribbon and then click the the very last icon on the bottom right.
In the More Controls dialog that comes up, select the Microsoft Date and Time Picker Control 6.0 (SP4) and then click OK. You will now be able to “draw” out the new control on the worksheet. Draw out the first control roughly on cell B4. In the Excel Name Box, name the control startDatePicker.
Repeat the process for the second date time control and draw the second control roughly out on B6. In the Excel Name Box, name the control endDatePicker. These names are used in the script to find the range parameters.
Now we need to add a button. Click the Insert icon again and select the first icon on the top left and draw out a button roughly on cell Here is what it should look like when complete.
Generating Lead Time Data
We should have completed all of the steps required to generate lead time data for the kanban system that we’ve model in Part 1 of this series of blog posts!
If you press the buttons and everything has been typed in correctly, you should see data populate the LeadTimeReport worksheet. This will look roughly like this.
You can format the first row of the LeadTimeReport sheet however you see fit. If you want to add more rows of labels, you will need to edit the scripts as they start adding lead time entries on row 2.
I’d like to point out that in this case, I’m using the Brian Keller ALM VM for Visual Studio 2013.4 and the Fabrikam Team Project inside of that VM for data. You will need to change the script to reflect the iteration paths that you are using your kanban system in TFS.
This has been a fairly long and detailed post and I hope that you’ve been able to follow it and get the lead time data generation working in your environment.
There are more sophisticated ways of generating this lead time data (programmatically more advanced applications). The reason I wanted to use Excel and Visual Basic was to allow anyone to generate lead time data with the basic tools that are available in a normal IT shop that uses TFS. If you’d like to expand on this approach and develop an application that does this (which I have already done elsewhere), I hope that you can use this example as a guide to what you’ll need to do to write your application.
Thanks and I hope to hear from you in the comments soon. Let me know if this worked for you or how I can make this example better.
Just wanted to point out that the Lean Kanban United Kingdom videos are all up! Check out my talk on Myths and Misconceptions about the Kanban Method in addition to all the other great talks from this conference.
You can find a lot more information on the LeanKanban Conference series here.
I hope you all have Happy Holidays and a Prosperous 2014!!
I’ve recently stumbled upon two blog posts that got me thinking about agile adoptions and why they might fail (not in a safe way).
First there was this post that I saw because it resonated with a colleague and he shared it.
I don’t know Guillaume and I’m sure he is a very nice guy, but the post struck me as from someone who didn’t understand the Agile Manifesto and was confusing it with the prescriptive guidance in the Scrum Guide or the guidance of The Lean Startup.
As I was reading these two posts, I started asking myself Why are these authors making these statements? Why are they observing these effects? The way that I’ve understood the Agile Manifesto and its intent, you shouldn’t see these effects, at least not for very long. It struck me though that this is a story that I hear over and over again.
Then I had a light bulb moment.
We often talk about an “Agile Buffet” as a set of tactics or practices we can pull from and use as best fits within our organization. I like this. As a passionate Kanban Method practitioner, the idea that we’ll continuously discover
problems opportunities for improvement and that we’d want to leverage past industrial learning is a core philosophy for me. But the Agile Manifesto is NOT a buffet. We should not pick and choose which of the values and principles that we will follow and aspire to. They are all necessary ways of thinking if we’re going to pull our industry out of the dark ages.
Now I am not suggesting we shouldn’t be finding the best way to, in context, live up to those values and principles. We should be very disciplined in What we pull from the Agile Buffet and When we pull the improvement. This is where a Kanban Method approach to continuous improvement is enormously beneficial. With a functioning kanban system, we have data that allows us to make informed, economically sound decisions about improvements and a mindset that we are going to improve incrementally and in an evolutionary manner. We are actually slaying a software development dragon with a 1-2 punch of Agile Manifesto thinking and Kanban Method thinking. We’ve got something guiding us towards what a successful software development team would behave like (Agile Manifesto) and we’ve got something showing us how to get to that goal in a humane, intelligent, and economic manner (Kanban Method).
I would like to encourage you to go read the Agile Manifesto again and to go read about The Kanban Method. They won’t tell you how to do things, but they are telling you what you should aspire to do. Now with that in mind, go and look at the Agile Buffet. Read the Scrum Guide. Read the kanban blue book as well as look at case studies from teams that have used the Kanban Method. This is your buffet of tactics that can help you solve your problems. Start pulling from this buffet of industrial learning. Develop a capability to understand what works for you and perhaps more importantly what doesn’t.
But please remember, these value systems are not a buffet and you don’t get to pick and choose from the values and principles they provide.
Wow! I just got back from #Agile2013 in Nashville and I have to say it was a great experience and my brain is overflowing with ideas! Which is always good for blogging.
One of the things that occurred to me while I was there was the seeming surge in the competitiveness amongst methodology practitioners. There were numerous tweets and blogs, sessions and conversations all discussing the pros and cons of one method versus another. Here are just a few things that I’ve seen… (FYI, I pick on everyone equally. Let’s call it an evolutionary fitness test.)
The people from SAFe are at the Agile Confernce this week. They had no where else to go, since RUP and waterfall don't exist. Be polite.—
Ken Schwaber (@kschwaber) August 06, 2013
@agustinvillena i think there is no question it should be. is in our kanban. What do they say it is in LKU Kanban?—
Al Shalloway (@alshalloway) August 05, 2013
David J Anderson (@djaa_dja) August 02, 2013
So we have a lot of posturing and positioning, and I actually don’t mind that. With noise comes interest, with interest and curiosity comes exploration and learning, and we can all grow. I hope though that by reading this blog and the other blogs and by exploring the topic, you gain a greater understanding of the items under discussion. It was with this intent that I had a really good conversation (or two) with Al Shalloway and Nayan Hajratwala about SAFe and the current thinking about The Kanban Method and Kanban/kanban in general.
Nayan Hajratwala (@nhajratw) August 05, 2013
Dave White (@AgileRamblings) August 06, 2013
So we were hearing the noise, exploring the enemy, probing for weaknesses and then trying to sway the enemy to our side. ;P
Today I had a realization about the experience. I learned about SAFe. I learned more about Scrum. I expanded my own understanding of The Kanban Method and kanban in general and I discovered more refinements to my thoughts when having this conversation! The Kanban Method, as David has been saying and said in the post above, is not the enemy of SAFe or Scrum or any other practices-based methodology that is a manifestation of the Agile Manifesto. It isn’t even comparable. It isn’t an Agile-practices based methodology at all, which is why David (and many of us at LKU) have been saying that The Kanban Method isn’t an Agile methodology! It is the vehicle that GETS you to Agile, wherever that may be for you! It is the vehicle that you use to encourage a collection of weird-acting individuals (people in an organization) to do something, such as adopt a bunch of agile-influenced tactics that might be described within any of the other practices-based methodologies!
Let me draw a picture!
We all start on these process adoption/organization transformation/improvement initiatives from a current state. Very often we can’t even describe the current state, but that is where we are. And very often, we can’t accurately describe the desired end-state, but let’s suggest for a moment that we can. So we know where we are (maybe) and we know where we want to go (maybe) but how to get there?!?! Some folks would have you believe you can jump there by telling the organization to put something in place.
I don’t mean to pick on Scrum. I like Scrum when it is the right fit. But it is frequently adopted blindly and prescriptively because it provides a lot of guidance on specific practices. But what if Scrum doesn’t fit? (Are there any DevOps people reading?) What if Scrum doesn’t help with the capability that you’re interested in? Or what if you’re problem is a scaling it out problem, which Scrum has troubles with. Good news! SAFe is right around the corner!! And virtual kanban systems! And Random Acts are there too!!
These are all methodologies with some great tactics to use for organization improvement right?! If you just tell everyone to do Scrum, SAFe, virtual kanban, or random stuff (heros, cowboys and smart people), we’ll achieve the improvements we’ve been struggling to get for the last 50 years in our industry!! But I heard this awesome comment from Linda Rising at #Agile2013 during her talk. I forgot to attribute it to her in my tweet though!
Dave White (@AgileRamblings) August 06, 2013
This is part of the problem with prescriptive approaches to process adoption. And unfortunately, Scrum and SAFe as described are easily prescribed. I’d even venture to state that the authors and evangelists of these methods want them prescribed. “If you do this, everything will be ok.” Of course they will not admit that they want you to blindly adopt all of the tactics, but in my opinion, the way those methodologies are described and evangelized, that is how it works out in the end.
And never mind that we still don’t really know if the methodology that we’ve selected will get us to the desired improvement given the context in which we are applying the methodology! Do the people in your organization want Scrum? SAFe? virtual kanban systems? Will they be able to pick up all the necessary practices? Apply them properly? Will the organization have the maturity to get through the hard parts? What if you’ve picked the wrong method? And what if the actual end-state option that you need isn’t the one you thought you needed at the start?
Has this happened to you? Have you seen this happen?
I want to reiterate at this point, I don’t think that the practices and tactics described in Scrum are bad. I don’t think SAFe tactics are inherently bad. I don’t think that “Kanban is so easy” crowd (proto-kanban or basic virtual kanban systems) are bad. It’s just going to be harder, longer, and more costly to get to an end-improvement than it should have been. You’re increasing the chance of your improvement initiative being interpreted as a failure, or being aborted early. Or leaving improvements undiscovered!
Another thing that I think is really interesting is that most of the practices-based methodologies describe themselves as an end-state. Like there is no more to learn and no more reason to grow in your context. What if the discovered end-state is a healthy, functioning Scrum implementation. Is that the end? Is there no where else to improve? What guidance does Scrum give you if you find an improvement that is counter to a described Scrum tactic? Or SAFe for that matter? Should we have end-states?
I think we are far better served trying to create an organizational capability to identify improvement opportunities and use any/all available tactics that we think will move us towards the desired improvement, once we know what the specific problem is. I think we are better served by creating an organizational capability to understand the attributes of the work that we do (volume, frequency, size, complexity) and understand the capability of the organization to execute that work. And I think that we are better served by facilitating the creation of a kaizen culture within the organization that will continuously seek out opportunities to improve because then the people own the problem and the improvement!
I want a vehicle to get me to my currently planned destination!! I want to be able to make informed decisions and change the destination! I want all my peers to dynamically guide their team to the next improvement that is discovered in the context of doing the work! And I don’t want to limit my destinations! I want to know that I’m making progress!
So we know you’re organization is ‘here’! Sounds silly when you say it that way but even if you can’t describe it, you are where you are. And there is some value in describing where you are because it will make progress measurable and discrete instead of abstract or qualitative. And we know that we need to be… faster let’s say. It should be more elaborate than that but bear with me for a moment. Now we have to convince everyone involved to paddle in the same direction!
What can I use to do that? Will Unit testing help? Will team structures help? continuous delivery? project roll-up techniques? Will any of these specific practices help me create an environment that causes groups of people to understand the problem, understand the capability, formulate a plan to improve and then determine if the execution worked? I do not think so. Are they all good things? YES! Unequivocally! Are they good things for everyone? All the time? No.
The Kanban Method will foster these capabilities for you because that is what it is designed to do. It is not designed to make you code faster or with higher quality. It will help you understand the cost of poor quality and then allow you to experiment with quality improving tactics like Unit testing/TDD/ATDD/BDD/xDD. Will it help you deploy your application faster or sell more units of your product? No, you have to use tools or LeanStartup for those kinds of things! Will it help you create a kaizen culture within an organization? Yes, because that is what it is designed to do. Will The Kanban Method encourage you to adopt concrete practices from any other methodology? Yes. Can you use a SAFe tactic if it seems logical in your context? Yes! Scrum tactic? Yes! virtual kanban system? Absolutely!
I keep coming back to something that my friend Frank Vega has said numerous times.
“The greatest learning happens at the boundary of disagreement.”
It was because of the disagreement that Alan Shalloway and I have about how we should guide people that I had these conversations. It was because of the respect and curiosity that we both have that we continue to meet at this boundary.
It think it is important though to be clear and compare like things.
The Kanban Method is not an Agile Manifesto-inspired practices-based methodology like Scrum or SAFe. It is an approach that is intending to create a capability within organizations to do incremental, evolutionary improvement. It is a transition method that understands people and the various factors that cause people to disengage. It is a transition method that provides high-level guidance for the creation or adoption of specific practices in a situation where a problem has been identified. It is a transition methodology that sees no end to the improvement cycle and as such, does not provide guidance on concrete tactics or the order in which you adopt concrete practices.
And because of the opportunistic nature of the culture created by a Kanban Method implementation, all the specific practices that are described by Scrum, SAFe, XP or RUP for that matter, are viable improvement options to specific problems that you may encounter on your journey of continuous improvement.
So get in your vehicle, start improving and go until you hit the horizon!
Part 3 of my Exploration of Estimation
In part 1, I posed the question of Why are you estimating! I hope that you thought about it and may have found an answer or two.
Part 2 explored What are we estimating. Usually we are asked to estimate effort (cost) which is then turned into a schedule (duration) which are two very different things.
The next question I’d to explore is Who is doing the estimating?
In my experience, normally it is the technical people who will be doing the actually work (coding, sql, ux, etc) that are asked to provide an estimate. Developers are the best and most familiar example. And while at first glance this seems reasonable, when you start to dig into the entire workflow required to move an idea to reality in software, it begins to look a bit inadequate.
As we can see in the workflow, there are several phases of life that a feature/user story/use case goes from to be brought to life, only one of which is development. Often, there are many tasks across elaboration/analysis, development, quality assurance, user acceptance and IT/Ops just to name a few common phases. Are developers performing all of these tasks? Do they take into account the effort required in all of the other disciplines when they do their estimates?
So why is it that developers are usually the only ones estimating effort?
Surely developers aren’t the only one working on your projects!! (Don’t get me wrong. I was a developer growing up, so I’ve definitely thought that the software development workflow revolved around me!) But this is a team sport, and without the business analysts, QA professionals, IT professionals and what ever other role is in your delivery workflow, we may have a difficult if not impossible time getting our software out the door!
So as a part of your estimation process, how do you understand the effort and/or time required to get work through the entire delivery process? Do you take into account all of the phases of life, and hand-offs, and interactions in your delivery process? Do you get all of the people involved in the estimation process? In fact, I’ve seen (not often) teams involve a tester in the estimation efforts, but very infrequently do I see analysts, DBAs or IT/Ops folks involved in the process, even when they’re role is critical to the delivery of the product!
So who is involved in YOUR estimation process? Do you have all the people you should have involved?
And are you asking yourself this question in conjunction with the other two questions I’ve already asked you about? Hmmm….. I hope you’re all thinking about all of these questions! I hope to present a couple more questions in the next week and then start to tell you how I think we can start make some real changes in the way that we do all of this estimation stuff!!
Part 2 of my Exploration of Estimation
In part 1, I posed the question of Why are you estimating! I hope that you thought about it and may have found an answer or two.
The next question I’d love for you to think about is What are you estimating?
I was just in a meeting that was discussing a RFP for a client. This is pretty common in the consulting industry where we see a Request For Proposal and in that, we need to define the scope of work that we can address, align our skills and services to deliver that scope of work and then provide an estimated cost for that service. Seems kind of normal. But then we are also sometimes required to provide an estimated calendar duration for the project. So in essence, we are being asked to provide 2 estimates. We then present our guess (educated) at how much work needs to be done, and here is our guess (educated) about how long it will take the team to execute on that vision.
So when the developers were being asked to provide estimates to the work in the RFP, what do you think were they estimating?
I haven’t had a chance to ask them yet, but based on my experience (as both a developer and a person being asked to provide project duration estimate), the development team is probably estimating effort and not duration.
So who estimates duration then? How do we get duration from effort? And if we stacking a guess (how fast we deliver) on top of a guess (effort), are we getting a meaningful expected duration value?
If you go back to my rant on estimation (which I will reference often in this exploration series) you will see how most organizations, in my experience, do mental and mathematic gymnastics to come up with an expected duration value.
My belief is that we are not getting a useful duration value. But everyone treats it as useful, starts building elaborate project plans and organizational activities around this duration value, and then we are all shocked when we have to change request the project, drop scope, or scramble like crazy (and usually with questionable quality) in the latter half of the project when it becomes painfully obvious that we’re not going to make our original duration estimate. Either way, the initial setting of expectations based on the layer of several guesses seems to be a Bad Thing™.
So I’ll leave you with this final question, what are you estimating?
p.s. I will explore better ways soon! Just bear with me for a bit longer!
Part 1 of my Estimation Series
A while I go, I wrote up a bit of a rant on a crazy estimation scenario that was presented to me by a colleague. If you didn’t get a chance to read it, you can find it here. We’ll call that rant Part .5 of this series of blog posts on estimation.
Since then, I’ve seen a bit of a swell on twitter of the #noestimates hashtag and a lot of discussion on topic. I was recently saw a tweet from Allan Shalloway that prompted a bit of a conversation:
(click imagine to see original tweet and conversation)
As you might have guessed, my thinking is more aligned with the #noestimates crowd and I’ll elaborate that over the coming months here, but this tweet started a conversation that I’ve had before.
Why do you estimate?
If I’m going to encourage you to stop estimating, it’s really important that we understand what I’m encouraging you to stop vs. what you might actually be doing.
As the conversation continued, Allan stated:
…which made wonder if we’re confusing prioritization with sizing, which is actually quite common.
So I won’t re-post the entire twitter conversation here, but I’ll start to share my thoughts on the why of estimate.
When I engage in an “estimating” exercise with a team, I very often try and restate the activity as a sizing exercise. For me, this starts us down the road of using the language that more accurately describes the end goal of our exercise. We want, to the best of our ability, describe how “big” we think this work item is. I’d like the team to use their past experience and compare the current work item (requirement, user story, etc.) against similar work items they’ve worked on before. This is a relative sizing technique that is used all the time by other agile methodologies such as Scrum or XP. You’ll often here the term “yesterday’s weather” in the same conversation about agile estimation techniques. The best predictor of today’s weather is yesterday’s. The team’s recent experience is the best predictor of its near-term current capabilities.
To me, the really important point of this exercise is sizing! Not scheduling. Not prioritizing. Those are completely different activities! The product owner/business representative on the team will tell you, perhaps with size as a decision input, what is next and when they might hope for it to be done. I generally expect them to help the team constrain the story, but the delivery team are the ones that are responsible for determine the size of the story.
So in my mind, the intent of the “estimation” exercise is to allow the whole delivery team to determine the relative size of the story compared to work items they have done in the past.
So why are we asking delivery teams (Development, Ops, anyone who is creating value) to size their work items? This is where I think all of the estimation craziness and problems start.
We need to provide some sort of indication of the anticipated financial impact to the organization making the request of this work item. We also need to provide information that would allow us to set a delivery timeframe expectation. And the next level of this problem is to take 100s (or 1000s) of these work items and provide the same financial and delivery timeframe expectations. This is, for most teams, really really hard.
And I will state that it is my belief that size is not the primary factor in determining cost or delivery timeframe. Will a bigger story cost more? Usually, yes, but not always. Will a bigger story take longer? Usually, yes, but not always. What if to delivery a story, a team has no external dependencies? What if it does? What if the story is big, but a really well known problem? Unknown problem? What if the team is missing a team member when it finally pulls the story from the backlog? What if the team composition has improved? There are so many things that can change the cost and expected delivery timeframe in addition to the size of the story that are very difficult to predict.
So in my mind, we are trying to size our work so that we can help business decision makers make the best decision for the organizations economic well being.
I’ll leave you with a couple homework questions. What is the intent of your team’s estimation exercises? Why is your team performing those exercises?
Part 2 will explore my approach to providing business decision makers with better information so that a team (business and delivery groups) can make better decisions on behalf of our organizations.
I don’t think I can fully communicate the value of co-location.
Any time I have been asked to help a company in recent years, the engagements have started out with an assessment. I don’t believe that I can provide sound advice unless I understand what the problems are and what the organization’s capabilities are.
One problem that EVERYONE has had so far is the absence of an effective place for their teams to work. Software development is a highly creative endeavor that requires (usually) a significant amount of collaboration between teammates and it constantly surprises me how organizations build terrible places for teams to try and achieve this!
When we started out with the client whom all of these Success Factor posts are about, the development team was spread out across ½ of a floor in an office tower and there were 2 members in a different city. Check out my hand-scribbled floor map with the initial, planned layout of the team members.
This is actually not bad compared to many companies I have observed, but this is far from optimal. The deficiencies that aren’t obvious from this floor map include:
- No team-specific collaboration space. Had to book meeting rooms and hope one was available.
- The Devs and PM have no whiteboard space. They are in cubicles.
- The BA, TW (Technical Writer) and CSM (ScrumMaster) were packed into a large office with minimal whiteboard space.
- PO (Product Owner) and HW (Hardware guy) were alone in their offices.
- There was no place to have daily stand-up meetings or to have our card wall up where everyone could see it.
- The sponsor was on the opposite side of the building.
For a team that is intending to collaborate frequently and intensely, this is a very poor setup. Our sponsor was spending in excess of $100k/month on the team in that room and he wanted to make sure we had every advantage to maximize that cost. So before we even kicked off the project, we made a rather bold request to have a board room near the sponsor converted into a team room. And our request was granted!! The facilities people were a little scared that we’d damage the boardroom table that was in there, so they had that taken out quickly, but the resulting floor plan looked like this:
Now we were excited! We had a room that could hold everyone. There was room for everyone but the PM and HW guy, due to the nature of their roles, didn’t need to participate as intensely as the rest of us, so they maintained their offices. And since our PO was also maintaining some business workload, she maintained her office as well. But all three team members attended all the meetings that we had in the team room and would often drop in to see how things were going. Let’s take a look at the team room.
I have to say, this is the best team room I’ve ever had the pleasure of working in. We had wall-to-wall whiteboards on the West and South walls, and the North and East walls where covered with large PostIt notes. The SE corner of the room had a projector screen and the projector sat on the SE corner of the team table. The computer on the East wall ran Skype and TeamPulse, the Agile Project Management Tool that we used on a daily basis (from Telerik). The room had a Skype account that was always logged in and you could call up that account and it would always auto-answer with video and put the caller on the projector. There were two microphones in the middle of the big table that would allow everyone to talk from where they were sitting with whomever called in.
I can’t say enough about the sheer wall space in this room. It was fantastic. On the wall-to-wall whiteboards, we had everything from architectural diagrams, to class diagrams, server layouts to retrospective results. We had everything on those whiteboards and they would be able to stay up for as long as needed for the team. We would write our retrospective notes up there, and leave them for the entire next sprint. Then the that sprint’s retrospective notes we be put up, and compared, and discussed. Then the former sprint’s notes would be erased. We had a constant rolling reminder of how important continuous improvement was to us.
The PostIt notes were used to keep less volatile things like our value statements right up in front of us. Also, team policies like our Definitions of Done, or our Prioritization logic where up there for everyone to see. There was never any doubt about how we wanted to work when you were in the team room.
We were creating a mobile system that included on-board tablets in trucks and we had our QA station right there behind our QA professional team mate, our PO and our BA! They could check specs, and then turn around and try it out right there in the QA environment. And if there was ever a problem, the developers could (and usually would) hear about it right away. That was one great aspect of our room that allowed our quality process become pervasive of everything that we did in that room.
I can tell you about a time that our QA lead was working on a test script in Microsoft Test Manager. Then he turned and tried the test step on the tablet and discovered a bug for a feature that was in the iteration. He called the developer over, who saw the defect right away. The QA lead logged the bug and the developer, whom had luckily just finished up a task, was able to pick up the bug and fix it right away. Our QA process was such that we could fix a bug, submit the code, all the automated quality checking mechanisms would run and then we could push the passed build up to the QA tablet where the bug had been fixed. In this particular case, the whole process took less than 1 hr. Discovered, Logged, Fixed, Built, Deployed, Re-tested, Passed. It is very rare for me to see a team perform this well.
But I totally believe that a big contributor is the team room that we’ve built for this team. Every team member feels the others pain when something doesn’t go right. This causes us to behave differently. Less selfishly and with a much more holistic approach to building the software solution.
And that was a known feature. The benefits of having the Product Owner, Business Analyst and Sponsor all within 20 feet of the developers is unbelievable. When anyone has a question about a feature or an idea that we’re trying to make real, the entire stack of business-focused people are right there, immediately available to answer the question. The only time that this team ever builds the wrong thing is when we are building something for someone who isn’t in the room. And you can bet that we escalate that immediately to our sponsor. Because he is 15 feet away.
And he just drops in all the time!! If he has a problem, he tells us. If he is curious how we are doing, it pokes his head in. He will see us working on a problem with our process and lend a hand if he can. And you can bet that this closeness has made the team much more aware of his concerns and challenges. It never feels like Big Brother is watching because there is so much transparency on the team that it is always about trust and helping to get the job done.
I could probably go on and on about all the benefits of this team room but I’ll wrap it up for the moment and leave the rest to your imagination so that you can think about what the benefits of this team room would do for your team.
Warning: This is a bit of a rant. If at any point in this post, I seem like the crazy one, please tell me somehow. Comments, Twitter, LinkedIn. It would be really valuable to hear your thoughts. But I also encourage you to think about the situation, context and information I provided and decide for yourself whether the way we are acting is crazy. There are craziness checkpoints along the way! And if you think any of this is crazy as well, try to do something about it!
I had a work colleague recently ask a question on our internal mailing list. A summary of the question would be:
A company that is using ‘agile’ wants to know if their formula for converting story points into hours is sound because executives are doing short term (< 6 months) planning.
This is an example of how they break down their work. Seems reasonable and just like many other companies.
They also provided a formula. This is where the craziness starts which is startlingly common in our industry.
… and a sample of how the formula works.
Ok. At this point, all that is going through my head is “OMG”. Now comes the process by which they populate the formula.
- PMs provide the Epic Point estimate
- Developers decompose epics and provide point estimates for the user stories.
- Teams points (epic points or user story points?) per resource per sprint are tracked.
This is COMMON in my experience working with many organizations in our industry.
In all fairness to my colleague, he knows this is crazy. The developers in this organization know this is crazy. This is a typical scenario when executives and senior managers are trying to get information but using techniques that we have proven don’t work in our industry.
The good thing is, the way that they decompose work is fine and the formula will work as long as we don’t have have 0 velocity or 0 team members.
The existence of the formula and the process by which we find numbers to put into it are where the craziness begins. First, a bit of information on “story points”.
Dave’s Craziness Meter
Story points are an abstraction agile teams use to REDUCE the perception of accuracy. 1 story point will require “some small” bit of effort to complete. 2 story points should require about twice as much effort as 1 story point. So that would be 2 times “some small bit of effort”. 5 story points require about 5 times “some small bit of effort”. I hope I’m clear about how we are purposefully reducing the perception of accuracy. Why? Because it incredibly difficult (usually impossible) and time consuming to create accurate estimates for the effort required to do knowledge work using the time units desired by decision makers!
I don’t even advocate using story points to my teams anymore. As numbers, it is too easy for people to plug them into a formula to convert them into something they are not intended to be converted into. I now generally only advocate sorting work by sizes like Small, Medium and Large.
Now let’s discuss the numbers that go into the formula from the example.
To start, a PM will make an point estimate in story points. In the example, it is 200 story points. I don’t know why a PM is doing an estimate on technical work.
Point estimates are bad. They imply accuracy where it normally does not exist. We have a point estimate of an abstraction that is trying to reduce the perception of accuracy. At least it is a single point estimate using an abstraction, so it could be OK except humans are optimistic estimators. Our interpretation of an estimate usually means that we expect the epic to fall in the middle of a normal distribution of epics and we have a 50/50 chance of falling under either side of the curve.
The problem with this is that the magnitude and likelihood of doing better than our estimate is the same as the likelihood and magnitude of doing worse than our estimate. And the other problem with this approach is it’s wrong. Using information from industry observations, we see that plotting the actual effort of our epics will form a log-normal distribution .
On a log normal distribution, the chance of doing better than our estimate is smaller than the chance of doing worse than our estimate. This means our epics usually fall behind the mode which means that they took more effort to complete than we expected. Simply put, when humans provide point estimates, we are usually wrong.
Let me state that again. When we estimate in knowledge work, we are usually wrong! And the formula above actually understands that!! The historical team buffer is a built-in admission that we need to add 20% to our estimates to make the numbers get closer to the actual values we observe!!! And I’ll bet that most epic actual values exceed the padded estimate!
Dave’s Craziness Meter
Ok, so point estimates are bad. And humans are bad estimators. That all came from the first point of the PM creating an epic point estimate. The rest should go more quickly. We’ve covered a lot of ground in that first exploration of the situation.
Next we have the developers decomposing the epics into stories and providing point estimates on those stories. All of the problems that we encountered in estimating above apply at this level as well.
The problem now is that it doesn’t work to simply sum up the points for the stories to get the points for the epic. If we look at the problems with point estimates, imagine doing that 20-100 times and adding the value together. We know that our our estimates are wrong (by at least 20% and probably more) and the impact of how wrong you are has a significant impact on effort. The only way to potentially add up the stories to see how much the epic will be is to estimate stories with an expected value that is the mean on a log-normal distribution and run a Monte Carlo simulation using all the stories in the epic. (That is an whole other blog post!)
I’m betting that a Monte Carlo simulation isn’t being used to turn the developer’s stories estimates into a meaningful epic estimate. Never mind the observed expansion (dark matter as David Anderson refers to it) of requirements that we see as we build the software and discover what we’ve missed. It’s always there, we just needed to build the system so that we could find it.
So our estimate is probably wrong. Significantly wrong. Period. Let’s move forward.
The next part of the formula is:
and the data in our example looks like this:
10 points is the average points per resource (I hate that word) per sprint. I’m assuming that they have standardized sprints for all teams in the organization. 2 is the number of team members (much better description) that will be working on this epic.
Do all developers produce 10 points per sprint, regardless of the task? Regardless of the skill level? Are we talking senior or junior developers? Is the business problem something they’ve done before, or something novel? Technology is know or new? Stat holidays? What if a developer is sick?
That 10pts could also be interpreted as developer velocity, and as we know, velocity can be highly variable for a team and is even more variable for individuals. In Scrum, we always talk about team velocity because it hides the variability of individual velocities that we know exists by averaging out the effort expenditure across multiple people over time. And we also know that velocity cannot be compared between teams! One team might have a velocity of 10 while another may have a velocity of 20, but the former team is more effective. The velocity number itself should not be interpreted as a standardized representation of effort that can be applied to any large scale planning activity (multiple project, multiple teams). It only works when you know the project and you know the team and it’s capabilities and past delivery history in specific contexts.
Dave’s Craziness Meter
So we have an epic estimate (crazy) divided by a developer velocity # multiplied by the number of team members (crazy). The next step is to multiply by the Historical Team Buffer otherwise known as padding the whole estimate.
The number from the formula is 1.2 in order to make the whole estimate 20% larger or 120% of the original estimate.
As I mentioned above, this buffer is a built-in indication that our estimates are wrong! We know we can’t deliver the epics as expected given our estimations, so we pad the estimate to make it closer to what we actually expect to do.
Dave’s Craziness Meter
So after all of that, we’ve arrived at a value of 12 sprints required to deliver this epic.
Phew!! Now we need to turn this into an expectation of effort expenditure or schedule.
Oddly enough, based on the question from our internal mailing list, we were not able to determine what the executives wanted. They either want to know how long it will take or how much it will cost. Unfortunately, I’d guess that they expect to get both from that number. They expect that the project will be done in 960 hours of developer effort which will occur in 12 weeks of calendar time.
That is 12 sprints and 80 hours of effort per sprint. That seems to be 2 developers for 40 hours per week or 80 hours per week.
So, I can with a fair bit of confidence tell you that the work week is 40 hours, 2 man weeks is 80 hours, and if a sprint is 1 week long with 2 people, the project will spend 960 hours of effort in 12 weeks.
What I can’t tell you is if both developers will work 40 effective hours per week. You almost certainly will pay them 40 hours per week, but whether all of that effort is applied to the story is another question. Emails, meetings, slow days, coffee cooler conversations, code reviews, design sessions, non-project related tasks are just some of the kinds of things that eat into that 40 hour work week. Never mind sickness or other work absences. Most people I speak with use 6 hours as a number for planning how much time a developer can effectively spend on a story. I’ve seen organizations where a team member regularly, for a variety of necessary reasons, spends less than 2 hours per day on a project they are supposed to be full time on.
So that does two things to our calculation. We’ve determined that the story is now about 960 hours in effort. If the developer can’t work on it 80 hours per week, the number of iterations has to go up! If the developers are only effective 4 hours per day, that means we have to spend 24 iterations on the project to get it done. Or potentially, the developers can deliver it in 12 weeks, but have to work 40 hours of overtime per week, which means the costs go WAY up for the project as the organization has to pay overtime. Let’s not even try to incorporate the diminishing returns on overtime hours, especially in an environment where that overburdening is chronic.
So as an executive, I wanted a fairly certain number for how much effort a specific epic is going to take so that I can do appropriate planning for the next 6 months. And 960 hours and 12 weeks calendar time is something I’m going to hang my hat on. I mean, 960 is a pretty precise number, and the “confidence” that the process has given the organization in that number must be pretty good.
Dave’s Craziness Meter
And since we’re doing organizational planning and planning multiple epics for multiple teams in the six month period, I’m also making the assumption that all epics that are 200 points are the same. And I’m assuming that all story points are the same effort. I’d have to deduce that that any epic of 100 points would take exactly half as much effort or half as much time as any 200 point epic. Any 200 point epic is exactly the same as any other 200 point epic. There is a lot of confidence in our formula and approach.
Dave’s Craziness Meter
Ok. I’ve maxed out my craziness at this whole endeavor. My hope is that you think this is all a little crazy as well because if we start to accept that we’re acting a little crazy we can start to do something about it.
I’d like to clarify that this post is not intended to be critical of people who are using Agile estimation techniques and trying to fit inside of an organizational traditional project planning methodology. We are all trying to do the best that we can. But sometimes we get stuck in a way of thinking. I’m hoping that this blog post might just jolt some of you into thinking about these problems and deciding to try and do something about them.
The formula used is as an example in this post is just that. A formula. And a very common kind of formula as well. The values you input into the formula will work as long as you don’t have 0 velocity or 0 team members. (No one likes division by 0.) In Kanban we use a lot of formulas and a scientific approach to understanding our work and workflows.
It’s the drivers underlying how we want to use formulas that we really need to be critical of. The formulas and the data that we feed into them has to make sense and drive us towards creating valuable data points on which meaningful decisions can be made. If we use complicated formulas and suspect or fictitious data as parameters, that makes the output worse than garbage because it provides some sort of sense of accuracy and a false sense of confidence because we think “this must be right. Our formula is sound.”
As long as we, as an industry, support this behavior, we’re are contributing to the continuation of this problem.
There are solutions to this problem, but exploring those options will be explored in another blog post.
But in the mean time, I’d love to hear your feedback! Do you think I’m crazy or do you think our industry is crazy?
Humans love pictures.
We have numerous sayings in our cultures about how powerful visualizations are.
“A picture is worth a thousand words“
“The drawing shows me at one glance what might be spread over ten pages in a book.”
“Every picture tells a story.”
One that the challenges with knowledge work is that for the most part, most of our work is invisible until it’s done. Only Neo can see bits and bytes which leaves the rest of us a little in the dark. If you’re building a building, or digging a hole in the ground, progress is obvious! For invisible work, progress is very difficult to monitor.
So we track work in some software system, but then we hide all of our knowledge in text and numbers! Our love of spreadsheets is epic in proportion. Status reports! MS Project files! All of this data!! For all intents and purposes, our work is still invisible! We often mistake this data for knowledge and understanding and the true insights are left hidden in the numbers.
On our project, we knew it would be very important to understand at a glance where we were in our workflow. We were doing something very novel for this organization and in order to mitigate the risk of heading too far in the wrong direction (which could be any direction at this point), we needed knowledge. We needed to quickly identify roadblocks to progress, which often included self-inflicted delays. We needed to engage with our sponsor in a meaningful manner.
So we started drawing pictures!
The most important “picture” that we have used has been our storyboard. This board is very important to us. It is a muster point for our daily stand-up meetings. It is a place on which to hang “adornments” that help us quickly assess our current state. It is a tool that promotes conversations. And it is always there, silently reminding us to be disciplined with efforts to visualize our work.
Our storyboard looks like pretty much like any other Agile teams storyboard in form, but this one is a unique work of art. Well, unique in that it is exactly what we need it to be at the moment. It represents our workflow. We have our WIP limits on it. And because we are fairly disciplined in maintaining the current state of all our work, it’s always up to date.
We also visualize our tasks and review these daily as well. TeamPulse has a story board as well as a task board for more granular visualizations.
We don’t have WIP limits enabled on the tasks boards, but again, the intent is to see work flowing through the system. And with an explicit policy that tasks should have a cycle time of 1 day, any time an item is discussed at 2 stand-up meetings, the team knows that the work isn’t progressing as expected and some sort of investigation and corrective action may need to take place.
Finally, we use TeamPulse dashboards to visualize our progress over the course of an iteration.
Everyday, we review the storyboards and the tasks boards during our stand-up, and then we review the dashboards to bring the entire conversation back to our progress versus our (the team’s) expectations for the iteration. These dashboards provide that high-level perspective that ties everything back together.
And all of this information is available on the web, to everyone on the project team, including the sponsor. There is no need to interpret numbers. There isn’t a report that needs to be compiled. And the information we want to present is immediately available in a very easy to consume and impactful format because a picture is worth a thousand words!
Going back to the first ALM Adoption Success Factor of Transparency, having something to be transparent with has been a key enabler of success for our team as we strive to deliver this project and continuously improve and get better as we do it.
- Success Factor 1 – Transparency
- Success Factor 2 – Visualize Your Work
- Coming soon – Success Factor 3 – Co-location
- Coming soon – Success Factor 4 – Invest In Your Tools
- Coming soon – Success Factor 5 – Retrospectives