There’s a very funny response to a question on Quora doing the rounds at the moment. The question is “Why are software development task estimations regularly off by a factor of 2-3?”
The response (go ahead and read it) makes an analogy to hiking from San Francisco to Los Angeles to visit friends, underestimating the distance, terrain and rate of progress as well as encountering a number of impediments like the weather, colds, blisters and so forth. It’s a really good read.
It was mentioned on the Australian Alt.Net mailing list, this week and followed up with the question of “so what do we learn from it?”
Two simple lessons come to mind.
On any reasonable project don’t expect to be accurate if your estimate takes you less than 5 minutes to arrive at. In the example, it’s pretty obvious that little time was spent coming up with the estimate for how long the hike might take. Once they’d decided they were going to hike, taking time to estimate how long it would take was just stealing time from actually hiking!
As developers, we allow ourselves to do this all the time. “I like to write code, I don’t like to estimate. If I get the estimate done quick then I can get back to doing what I like.”
Stop it. You’re only storing up pain for yourself down the track.
When you estimate think about what might slow you down. Very few teams do this but it’s critical if you want to be more realistic about how long something will take.
Most developers estimate with the same approach that they test their own code. They only consider the happy path.
You can hear them in their heads saying “It takes this long to do that. And that long to do that. And … then put it all together and the estimate is X months!!”.
Very few developers then say, “so the baseline is X months. Now what is likely to slow us down?”. Yet there are so many things that can do just that.
Want a basic list? How about the following:
That’s a starting list of things all teams should consider when estimating and all of those items should be used to take your “happy path” estimate and adjust it from there.
So next time you need to estimate something, keep these two simple lessons in mind and good luck!
The title says it all really.
Modifications to the framework need to be approved by Ken Schwaber and Jeff Sutherland (co-creators of Scrum), and to be honest there are likely to be very few, given it’s such a simple framework.
The more interesting thing to keep an eye on will be the Extensions. As a Scrum Coach and Trainer, I’m often asked what teams should do in a specific scenarios. Scrum is silent on those situations because they aren’t generic enough, and yet there are generally accepted, healthy behaviours teams should have in those situations. That’s the essence of an extension. The healthy, beneficial practices team can use to complement Scrum to help teams in Situation X.
This a is great move by Scrum.org and a very welcome one!
Scrum Extension Library and Submission Guide
Scrum Modification Submission Guide
Let’s say you work in an internal IT department, largely doing maintenance work on software solutions. Solutions that are by and large built by external vendors through an outsourcing arrangement and then brought in house once they’ve gone live and the initial warranty period has elapsed.
Let’s say every time you look at one of these solutions that you now have to maintain you find the grand sum of zero unit tests. Without exception. Every single application has nary a unit test to be seen. Not even a hint that one might have existed and been removed at a later date.
“Why?!” you cry to yourself. In frustration you cry “Why!!?” to management as well. Their answer: The vendors tell us “it will cost more and take longer to do unit testing” and of course, they reason with you, if that’s the case then why would we pay for it? You know this is a bad argument and the logic is built on sand, so what’s your comeback? How do you get it across to management that a vendor that ignores unit testing is a bad vendor and is actually more expensive overall?
So my initial response to their claims would be along the lines of “So do I assume they’re not actually testing the software they write for us then.” and then explain how manual testing takes (much) longer than developing automated tests, assuming of course that the code being written is in any way testable. If they develop poorly and have a lot of tight coupling between concrete classes or make a lot of static calls to HttpContext or develop in SharePoint for instance then the application might not be easily testable, but hey! That’s their problem not ours. The good news is that anyone with a business brain can understand the benefits of automation for tedious repetitive time consuming processes – heck, we worked that out during the industrial revolution.
Let’s try a different angle in case the first, most obvious one doesn’t work. If you consider a lack of automated testing to be merely another form of technical debt then it’s just like poor design and architecture, horribly complex methods, N+1 ORM queries, poor UI’s, high bug counts, etc. It’s something that will cost you. So, if a vendor delivers you software with a high level of technical debt and you’ll be maintaining it, then you’re going to have a lower long term ROI and higher TCO from those vendors versus what you might have from a vendor who keeps their debt levels low. So while the cheap guys may argue that it will cost more and takes longer to write code with unit tests then what they’re really saying is this
“It costs US more and takes US longer to do unit testing because the developers we hire are the cheapest and suckiest we could find. They don’t understand good development practices and we’re not about to teach them because they’ll leave in the next 3 to 6 months. Also manual testers here are cheap-as-chips and lose staff too quickly, so it’s easier for US if we just get the software to ‘it kind of works’ and then give it to you so we can get our money and hope you won’t notice”.
Also, don’t forget that post delivery, all those bugs and problems that snuck through from the vendor will end up becoming your bugs and problems to fix as part of your maintenance work. So the company is either paying for it with internal staff costs (often seen as a hidden/sunk cost) or, if the vendor is also charging for maintenance, paying for it once a development project is concluded. Development takes longer, it’s harder to find and fix bugs, it takes longer and longer to test the application manually, etc. These all add up to time, and in software development time is money!
With that, good luck convincing management to change their vendors, and if you’ve got a better reason to present yours case I’d love to hear it.
Note: I’m not implying manual testing is bad. In fact I think you should be doing manual testing; but only manual exploratory testing where testers are trying to break your code. It’s rote, repetitive manual testing that is neither cost efficient or effective.
Found via Rob Conery’s blog – A Methodology for Better Website Development
My eyes! They burn!! Make it stop!!!
It’s waterfall being touted as the best way to do web development! Seriously!? Who wrote this article? Wait a second while I look…. Oh, it’s the CEO of Ektron, the makers of Ektron CMS. A product so good that the only times I’ve heard of it has been from companies that bought it, got screwed by poor service, bad documentation, horrible support and the vendor’s inability to supply updates in a timely manner, and that have then written it off as a mistake, and then kicked it out so it can be replaced by other commercial products or solutions from that most waterfall-ish of development environments, the open source world! This explains so much!
It seriously annoys me that people write this sort of article as if it’s the one true way and even more when a publisher like ZDNet doesn’t include a public health warning with it.
This isn’t to say agile is the only way to do web development either, not by a long shot. Agile is a mechanism that has been shown to work well in web development and we’ve seen time and again that short development cycles and rapid, continuous releases are a path to success. The real secret to success though? Find the best people you can, educate them in how to best communicate with you and each other, then tell them what you want and then get the hell out of their way!
Individuals and interactions over process and tools.
I think I need to take an aspirin and go have a lie down. Reading that article gave me a small aneurism.
Just a quick note letting you know that I’m running a PSM course in Perth. February 3rd & 4th, 2011. If you’re interested in registering then head over to http://scrummastercourse.eventbrite.com/ for the details.
I’d also encourage you to have a look at the details of the Scrum.org PSM course and the curriculum before registering. And before you ask, no, you do not automatically get a certification for just attending.
I was talking to someone yesterday telling me about her previous employer and the scrum team they had. I almost fell over when she said they had 50 people on their team at the time. Surely that was 6 or 7 smaller teams right? No – just one team.
In fact there were so many people at the daily stand up that they used to pass around a microphone so everyone could hear! However, things weren’t quite as bad as I might think because of pair programming. Only one person in two actually had to talk because the second person in each pair would’ve just said the same as the first. What about rotating pairs during the day? And even then, 25 people in a team is too large. At that size it’s not a team anymore – it’s just a crowd.
Remember, it’s 7 plus or minus 2 for the ideal scrum team size. Not 50!
Deadlines!! Panic mode!! You’ve been there. Go on. Admit it! Some of you are probably there right now, though how you have time to read a blog post I’m not sure :-)
We know how it happens. You started a project and provided some initial estimate which, like all estimates, was wrong. Even so, someone in the business promised delivery of the project to their customers based on those estimates. You realise those estimates are wrong pretty early on, but don’t want to look like you don’t know what you’re doing so you hope that you’ll catch the time up later. You don’t tell anyone that you think you’ve screwed the pooch and stuffed up. It’s only late in the development process when all hope is lost of ever catching up that it really becomes visible to others and a sense of panic ensues as everyone on the team starts to rush to get things done.
As this rush starts the panic grows and grips people and they forget all about those good, disciplined developer practices that you’re meant to be following and start doing things the quickest, ugliest, dirtiest way possible. It doesn’t matter how much of a kludge or nasty hack it is, as long as it works and you finish quick you’ll be happy. That impending sense of doom you’re feeling drives you to make all the shortcuts in the world that you promised yourself you would never do again. You’re aiming for that short term goal of meeting a date with something, anything, which kind of works and you don’t care how many kittens have to die to get there.
So here’s the rub. Because you delivered and maybe even satisfied the customer under these circumstances it becomes acceptable to do the same thing again the next time there is a hint of a deadline looming. All too soon it becomes commonplace to ignore good practices completely and just do whatever happens to work.
Your management doesn’t see how much sticky tape and string are needed to hold things together so to them this short-cut behaviour simply teaches them that when they pressure you, you can deliver something in a shorter time frame than you originally thought possible. Good for them. Less time means lower costs means more profit, right? Armed with this knowledge management then kicks off the next project with all the ammunition they need to pressure you to deliver in an even shorter timeframe than ever before. What’s worse, is because you as a developer don’t push back on estimates you then respond to these deadlines by making even more shortcuts than ever before. Ugly, ugly, ugly! And we wonder why we look at our code some times and get embarrassed. We’re a victim of our own “success”!
The other problem panic mode brings is that overtime is almost always involved. Because the hours worked by you and the team are generally well above and beyond the standard 40 hour week it looks like you complete a lot more work and thus achieve what seems like higher productivity. More ammunition for management!
And yet, your short term burst of speed, no matter how good it looks, is really quite bad. Because you’re tired and worn out from your panic mode overtime work, all the work you do after that will be far less effective plus you’ll also be dealing with all that stuff you threw against the wall to get things done. Extra bugs, terrible design, copy and paste development and technical debt up the wazoo! Because management isn’t really aware of these problems or the impact of them, they start to get upset that your productivity has fallen away. “What’s wrong with you lazy developers?!” they ask.
So, as tempting as it is, when a project is late is not the time to panic. Panic mode rush jobs should be avoided as much as possible because of the downstream ramifications. Obviously take into consideration the larger business implications – if not delivering means the company goes out of business and you have no job, well that’s extenuating circumstances, but if it’s just to meet an arbitrary date…? Hmmm.
The real secret, and the thing to aim for, is to manage expectations earlier and avoid panic mode altogether. As soon as your initial estimates look messed up, admit your mistakes, talk with your customers and have those difficult conversations early, whilst there is still time to adjust plans. Hoping you’ll catch time up later is a sure fire way to get yourself in a deep dark hole – so stop lying to yourself about catching up. You know that the only way to catch time up is to cut corners, and you know what happens when you do that...
Agile frameworks and approaches put a high degree of attention on getting things done quickly and efficiently. The end goal being to get software into production as efficiently as possible with a level of quality that makes the customer happy and provides a good return on investment. You will often hear people talking about agile (and lean for that matter) also talking about waste and using “inspect and adapt” to minimize wasted effort.
One of the things I see teams doing regularly is taking a day to day approach to development that completely ignores personal time management. A team may estimate a task to take, say 8 hours, and generally it will get done in or around that timeframe (it is an estimate after all), but if you actually watch how people approach completing that task it soon becomes apparent that the 8 hours spent on that task isn’t really 8 hours of good solid effort at all.
The task may have had 8 hours elapse between when it was started and when it was finished – but the actual time spent on the task is typically somewhere between 4 and 6. Where did the other 2 to 4 hours of time go? Sure there’s toilet breaks, coffee runs and helping out others on the team out, but that’s not 2 to 4 hours each and every day is it?
This lost time is what teams typically refer to in planning meetings as their “focus factor”. Some teams have a focus factor of 50%, other teams a focus factor of 75%, whatever. Either way, teams are looking a potential performance improvement of between 33% and 100% right in the face and doing absolutely nothing about it! In fact, they are institutionalising low productivity and calling it good planning. Really, all they are doing is admitting that change is hard and giving up before they even try and improve things.
This is where a team doing retrospectives and wanting to improve can really make a big gain.
As an example of this lost time, let’s have a look at just two things that tend to suck up those non-development hours.
Maybe that’s going a little too far :-) However the next time you get an email from someone, see how long it takes to put your response together. If you write a response that has more than one or two lines in it then I’m going to guess that it will take you a LOT longer to write that response than it would have if you had just talked to the person in person or over the phone.
In fact if you really want to scare yourself, go grab a copy of ManicTime and use it see just how much time you spend in your email client of choice. In fact, do it anyway. Download it, install it and run it just for one day and look at the results. You might just find that your focus factor of 75% was too high! Maybe that explains the difficulty you’re having getting sprints completed well.
Oh, if you’re in one of those organisations where email is used as the ass-covering tool of choice, don’t forgo conversations and revert to email just to cover your butt. Use email as a confirmation tool and note down bullet points from your conversation – during the conversation – to later send through a “just confirming what we talked about in our phone call” email instead. It’s much quicker.
Multi Tasking is the other great way to slow yourself down. The cost of task switching for humans is nasty – our brains just aren’t wired up the right way to be able to swap in and out of context quickly. We may convince ourselves that we can, and we may try to lie to ourselves about how the tech generation are all skilled multi taskers, but really, it’s all bubcus and an excuse for being unable to concentrate for more than 2 minutes at a time.
Short attention spans create an illusion of being productive through the act of being busy. We generate lots of movement and energy when we’re busy, but in reality all that movement just creates a big dust cloud that masks just how little progress we make.
For us humans, the best way to finish tasks as quickly as possible is to do them sequentially. This costs us a single context switch between tasks instead of a context switch each time we change from one task to another. For us developers locking in on a single task also gives us the opportunity we need to get us into the zone – that magical place where high quality code just seems to fly out of our fingers, where we flow from one thing to the next with ease, and where we get stuff done ten times faster than we would have normally.
Sure it sounds great, but development has so many chances for distraction. Not sure how to do something? Google it, see something else interesting and go investigate that instead. The task we’re doing is boring? Let’s take a little break and play solitaire for a few minutes. This compile is taking more than 5 seconds? Maybe we’ll just check email while we wait. it’s all self induced ADD and we need to learn to stop.
It comes to this: Personal time management, discipline and focus. How do you, yourself, personally, manage your time as an individual? How do you maintain focus? How long do you maintain it for? When do you take a breather since all that concentrating can be tiring? How tired are you right now?
First up, let’s deal with some simple distractions. Have a look around you right now at all the possible distractions you have – twitter, facebook, rss feeds, email, news sites, instant messenger, a side conversation you could join in on, that delicious smell coming from the kitchen, txting, flash games, the list goes on. Things like twitter, outlook and IM in particular can be really nasty because of their interrupting “new message” toaster notifications and beeps. Turn those notifications off. Do it. Go into settings and turn them off. Right now. It’s OK to leave those apps running, just delay checking for new tweets, emails and messages until until you finish what you’re doing.
What if you’re waiting for that compile or CI build to complete, what do you do? Press Alt+Tab and go read a blog entry or 5 for the next few minutes? It’s easy for that few minutes to turn into 10 or 20. And yet the compile itself only took 3 minutes to complete. That’s a lot of wasted time and a definite mental context switch you have to deal with. Yet watching a compile is mind numbingly dull. So why don’t you think about some refactoring you could apply, or the next test that you could write, or the design for the next task that you’ll get started on next. There’s plenty of non-keyboard activities you can do that keep you focused on the task at hand and not chasing squirrels.
This is also where techniques such as the Pomodoro Technique and pair programming can help.
Pairing provides a focus boost simply because you have someone next to you who is also focused on the same goal as you. The two of you keep each other on track. I’m not going to delve to much into pairing here, however if you consider what it does for our focus factor you can see how teams that use pairing can easily get a return on the supposed cost of putting two people onto a single task, simply because they won’t get as easily distracted and can thus complete their tasks faster.
1. Choose a task to be accomplished
2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4. Take a short break (5 minutes is OK)
5. Every 4 Pomodoros take a longer break
Quite simply it says focus on just one task until either the task is complete or 25 minutes is up. When that happens, give yourself a mental break. It’s effectively a series of short, sharp personal sprints.
When you’re working on your 25 minute pomodoro you don’t open email, you don’t look at twitter, you don’t check news sites, you don’t get a coffee or anything else. You just work on the task. All those other things are for filling those 5 minute breaks you have. And if you’re in an organisation with a plethora of email – then one of your pomodoros should probably be spent dealing with that email!
Oh, don’t worry if you don’t have a clock that looks like a tomato either. Just grab yourself one of the many pomodoro timer apps, such as FocusBooster, and use it instead.
You may find this hard at first, but once you do it a few times, you’ll find it becomes easier and easier to do. You’ll find that without any changes to technology, skills, work hours, or otherwise that doing this will result in an increase in team productivity and velocity – and all you’ve had to do is be a little more disciplined and a little more focused on the task at hand.
Let’s work smarter, not harder, right?
P.S. The irony that a long post like this isn’t likely to be read all the way through by people with short attention spans isn’t lost on me! ;-)
Good luck!
Ken Schwaber (co-creator of Scrum) moved on from the Scrum Alliance last year to found the Scrum.org organisation specifically to meet some goals that differ in purpose to those of the Scrum Alliance. To quote from the Scrum.org front page
Scrum.org is staffed by the developers of Scrum and the best Scrum practitioners in the industry, and was founded to:
- Help individuals assess their knowledge of Scrum and how it is used.
- Help organizations find the best training courses, coaching, consulting, and topical Q&A sessions to optimize their use of Scrum.
- Help Scrum teams and organizations learn how to optimize their Total Cost of Ownership for systems and products built using Scrum.
- Initiate innovative programs, such as the Certified Scrum DeveloperTM and Professional Scrum DeveloperTM, to accelerate the effectiveness of Scrum.
Note that last point. The one that talks about the Certified Scrum Developer program. It turns out that the Certified Scrum Developer trainer program has recently been formally announced on the Scrum.org web site. You can read the full announcement for yourself but to save yourself a little time here’s the summary (quoting again)
The PSD program:
- Has been built from the ground up specifically for developers
- Focuses on both teamwork and on technical practice, because software development in the 21st century relies on people skills as much as on tech chops
- Addresses head on the people and technical issues that I know other Scrum courses shy away from
- Simulates a real working environment – no “chalk and talk”
- Utilizes an innovative continual assessment model to support student development beyond the course
What’s even better is that there are actually two flavours of this course coming. One for .NET developers and one for Java developers as the toolsets they use are quite different.
I’ve been fortunate enough to be a lab rat for the .NET version of the course and I really enjoyed it. That said I should take a moment for some full disclosure; I’m looking to be a Certified Professional Scrum Developer Trainer so that I can deliver it publicly through Readify (my employer) in the near future. Now that that’s out of the way I’ll continue :-) …
In my opinion the Professional Scrum Developer course does a really good job of addressing the issues that .NET teams have doing development in a scrum environment. Being a .NET course it specifically targets TFS 2010 and Visual Studio 2010 as tools for supporting the scrum process and providing a platform for strong agile engineering practices. Obviously you can use tools other than these for supporting your efforts, and I don’t want to open up arguments about which tools are best, however given the majority of companies have TFS and Visual Studio it makes sense to target these platforms as a starting point. If there’s enough interest for delivering the course using other tools such as open source alternatives then maybe an OSS version of the course can be developed but for now, it’s the pure Microsoft stack.
From a process view point the course also provides students very practical hands on experience in the tools and scrum via a series of short sprints over a 5 day period to ensure that students get a feel for the rhythm of how scrum teams should work on a day by day basis and how the tools can support them in that work. This is, I think, where the real value of the course lies. I’ve seen too many teams who think they’re doing scrum or agile and who are so far from it that it’s laughable, yet they just don’t realise that they’re doing things wrong. A course like this is a great way for these teams to see the mistakes in what they’re doing and to get some practical experience on how to do things right that they can then take back to their offices to improve what they’re doing and to get higher quality software into production on a more regular basis.
One other thing to note about this course is that students who get to the end of it aren’t automatically granted a Professional Scrum Developers certification. They will have to pass an exam to prove that they know their stuff. This is so much better than how past scrum related certifications (think CSM) have been run and adds some weight and value to the certification process.
I’m personally quietly excited that this is happening and I’m looking forward to being able to start training others in this area. I’ll be post some more information about it as it becomes available.
Close on the heels of TechEd Australia, Readify have announced the latest Dev Days events for both Sydney and Melbourne.
When we last ran these we had multiple tracks which presented tough choices on what to see at times, so we’ve changed things around and will now run separate morning and afternoon tracks instead. It means you can now get to everything, or just come for the half day session you are interested in and go to the beach for the other half of the day (or do some work if you must).
I'll be presenting the morning session in Sydney, covering Software Quality and Application Lifecycle Management split across two subjects:
In the afternoon, Tatham Oddie (MVP) will be covering Building for the Web with .NET through three different presentations:
To find out more or to book just point your browser to http://readify.net/training-and-events/rdn-dev-days/. See you there!
Over recent times there’s been a slowly growing number of people interested in software craftsmanship and just recently those people published a manifesto to explain their ideals(http://manifesto.softwarecraftsmanship.org/). The manifesto is based on the agile manifesto (http://agilemanifesto.org/) and simply takes the values of the agile manifesto and adds riders to them.
I’ve been mulling this whole craftsmanship thing over in my head for a little while now to try and figure out why it is that I’m not that keen on it. I know that might surprise some of you, and considering my involvement in both the Sydney and Oz Alt.Net communities, you probably have reason to be surprised. After all,many people would consider that software craftsmanship movement and alt.net are both seeking the same thing; namely an improvement in the level of quality and the way software development is done, because quite frankly, how most development is done these days is laughably poor.
After some thinking, I’ve decided that what bothers me isn’t the manifesto per se, but rather the “craftsmanship” aspect of it. To me, craftsmanship implies an attitude and approach to development that is more about art and polish and finish and ego and even guilds that goes beyond functionality and quality alone. It also creates mental connections for me of higher cost products that take longer to produce and come out in much lower volumes than regularly produced products.
Let me make a potentially bad analogy. Consider furniture. I can go out today and buy a chair from a craftsman that was lovingly made, hand carved, manually upholstered, had the craftsman’s style all over it and so forth and I would have bought a functional chair that looked great, assuming I liked the style of it. However I would also pay a premium for it knowing that there would be few other chairs like it. Alternatively, I could go out buy a chair from IKEA or some other retailer that would also be a functional chair with a great finished quality and a nice look, but it would also be 100 times cheaper than the other chair, and maybe even more comfortable to sit on.
So I ask myself this, does craftsmanship really matter? I think so – but only to a limited number of customers. On the flip side, a desire for quality is common to all customers. No one wants to buy a chair that has uneven legs or makes you wonder if it will fall apart when you sit on it. IKEA sell thousands of chairs each year because they make a quality product very efficiently and can therefore sell it at a competitive price and still make a profit. Craftsmen can only sell limited numbers of chairs each year because all that crafting takes time.
Unfortunately for those who would like to put on the rose coloured glasses, feel warm and fuzzy about their profession and believe that our industry can absorb the cost of developers lovingly polishing their code, the reality is that software is a commodity item. Businesses focus on ROI (Return on Investment) and as such will purchase from the people that can give them the best quality software at the cheapest price and can do so consistently. It’s possible that a few customers may choose the craftsmanship route, they will be few and far between limiting the number of people who can take a crafting approach to code to a few niche players. The rest of us will be out in the cold hard commoditised world wondering why our beautifully crafted code isn’t winning us any business and why those guys over there who write functional and maintainable code, but definitely not the best crafted code ever are raking in the big bucks.
One of the recommended practices when doing agile software development is to get estimates from each of the individuals in the team without having them influence each others thinking. That way you get multiple points of view on an item and avoid the issues of having one person estimate on behalf of everyone else in the team. You also foster greater communication amongst those estimating and greater collective ownership of the estimates themselves.
Another recommendation is to use relative estimating and banding/bucketing of estimates. Relative estimation is just a matter of estimating the size of one job compared to another. Doing so makes it easy to understand the relative difference between an estimate of 1 and 2 but the relative difference between a 28 and 29? Who cares – it’s so small it doesn’t really matter. For that reason the use of banding is encouraged to avoid wasting time trying to get the perfect estimate. An estimate is what it is – an estimate.
Enter Planning Poker. Planning Poker is a very simple process that helps teams estimate using the above recommendations and works as follows:
All pretty simple, right? Well it is, until you try to do it in practice. I’ve found that a lot of teams find the idea of playing with cards during work hours just a little too geeky and it makes the adoption of the planning poker process a little harder than it should be. Oh yeah, and you also need to make sure you have a deck of cards for everyone in the team.
To make adoption a little easier I use a “rock, paper, scissors” style of planning poker. I make sure the team know the valid numbers they can choose from for estimating and then do all the same steps as for normal planning poker, but instead of holding up a card to indicate they are ready, they just hold two fists out (or put them on the table) to indicate they have an idea in mind.
Once everyone is ready it’s then just a case of saying “1, 2, 3, go” to get everyone showing their estimates at the same time. The number of fingers held up indicates the estimate. For numbers above ten, e.g. 21, people would show two fingers on the right hand and one on the left. Simple enough.
The advantages? It feels less geeky than using cards, you don’t have to ensure everyone has a deck of cards to start with, and you don’t have to watch people fumble around getting the card they need to choose for the estimate.
If you look around the internet you’ll find lots of information on refactoring your code, making it more testable, improving its maintainability, and using DI/IoC techniques to increase the ease in which you can make changes to it. A very large element in all these subjects is having code that is loosely coupled and learning how to take existing tightly coupled code and improve it.
That’s great…. and making these changes is a laudable goal, but what do you do when you look at the code you work on each and every day and you see how tightly coupled it is and then look at just how many more changes and features your customers are asking you to add and make to your application. You know you want to clean things up to make it easier to get through that backlog of requests but when is it right to decouple and when is it OK to leave code as is? It’s a valid concern and was asked as a follow up to my screen cast on Decoupling Your Code by Example.
So first, let’s be clear; tightly coupled code is a form of technical debt that will decrease your ability to quickly and cleanly make changes to an existing code base and thus slows the rate at which you can get through that backlog of customer requests. And since those customers making the requests are in all likelihood the same ones that end up paying your wages then it’s probably a good idea to go as quickly as you can.
OK, fine; but now let’s consider the agile principles of not wasting effort and delivering business value to the customer as quickly as possible. If we have an existing code base that is full of tight couplings then we can’t very well ask our customer for x-weeks of time to let us refactor the internals of the application to reduce coupling. It’ll would add zero business value to the customer because in x-weeks we would have delivered zero new functionality. We would also very likely be changing parts of the application that are not going to see any changes in the future – thus it would include wasted effort.
It’s therefor pretty logical that we really only want to decouple code when we’re actively changing it. We should apply the boy scout rule and “leave the campsite better than we found it”, or in our case, the code base. Also, we don’t want to go fixing stuff up that we aren’t currently changing, no matter how ugly it is or how tempting it is to improve it – if we do we are only slowing down our development efforts on the items we need to be delivering now, items which our customer is expecting. In doing so we also run an increased risk of introducing new bugs. Why? Well, if we only have a certain amount of time to finish something then we really don’t have enough time to do a proper clean up of things outside of the area we are currently working on. So we’ll probably do what most of us do when time is short; make a change that we think is OK (but isn’t) and we won’t worry too much about the tests.
The agile principle of wasted effort can also come into play when looking at coupled code in an area of the application we are actively changing. Some tight coupling just isn’t worth the time and effort to change. Let’s say we have a tight coupling to ADO.NET which makes our code a bit clunky in places. It’s awkward at times to use and we could be faster if we changed it, but is it really worth x-weeks to rework our code to use an improved data access mechanism just so we can have a more loosely coupled design? Is there enough payback in making that change that it benefits the customer directly, or even indirectly by saving us more than x-weeks worth of effort further down the track? Maybe; maybe not. In most cases probably not. And if the payback isn’t there, then don’t make the change.
So, should you decouple your code? The answer is, like all things in software development: it depends. These two questions can probably help you make that call.
If you can answer “Yes” to both of those, then it’s probably time to decouple your code. If you can’t, then get on with giving your customer what they asked for – new features in their application.
James & Martin are running a survey trying to get a feel for how Scrum is being dong within Australia.
The more responses the better, so head on over and give it a run through. It’ll take you all of 5 minutes, if that.
The Waterfall Development model is something we all know and loathe. Thankfully in recent years we’re seeing the industry slowly turning away from this model and moving back to the iterative development models used in the 1950’s, before the rise of waterfall. What’s ironic about waterfall development is that it’s creator (Winston Royce) never actually intended it to be a model for software development!
Royce says this in the paper where the model is shown: “I believe in this concept, but the implementation described above is risky and invites failure” and he explicitly mentions that changes can cause anything up to a 100% overrun since it may involve going right back to the drawing board. He then goes on to evolve that model and introduce safeguards to minimise the risks of change.
So how did this initial model turn into the “One True Way” of software development?
First consider that Royce’s paper was published in an IEEE publication – IEEE is a well respected industry body and anything they publish is going to immediately have substantial respect. But now consider the background of the author. To quote again: “I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis.” He was working at NASA in the hey-day of the space industry! The whole world was looking at everything these guys did and reading it as gospel! After all, these were the people who managed to put man on the moon and bring him back again using nothing more than a tin can, some electronics, a couple of goldfish bowls sewn into to some silver jumpsuits and one freakin’ great big rocket! Of course people were going to listen to what he said!
Tarmo Toikannen said this about what happened next:
“
If you look at the scientific articles on software engineering that discuss the waterfall, they all cite Royce’s article. In other words, they’re saying something like “The waterfall is a proven method (Royce, 1970).” So they base their claims on an article that actually says the opposite: that the model does not work.
This is how science (unfortunately) often works - researchers just cite something, because everyone else does so as well, and don’t really read the publications that they refer to. So eventually an often cited claim becomes “fact”.
“
But why did so many people reference the broken model? You might laugh at this, but it’s probably because the model shown was the first diagram in the article. Instead of looking at the other diagrams to see how the broken model is then evolved into the model that Royce finally proposes they just copied the first image they saw and went from there.
mmmOkay. But that still doesn’t explain everything. Why did a model that those in the real world knew didn’t work gain so much traction? Well, you can thank the US Military for that one – in fact you can specifically thank the geniuses who wrote DOD Standard 2167 – a standard which was not only waterfall based but also heavily documentation focussed. As soon as the military decided all software should be written to that standard, it became the de-facto for all other large scale development. You can imaging the thinking “If it’s what the military uses to get high quality software then shouldn’t we do the same?”. The problem was further compounded when other countries followed the Don’t Reinvent The Wheel principle and adopted the existing US standard for themselves. Now it was a global standard.
Thankfully the US Military amended their standard in 1995 and multiple times thereafter but by then the damage had been done. Waterfall was the only thing being taught by academia and the industry was too earning much money by doing things poorly to quickly change to something that made sense.
Only now are we seeing a strong resurgence of the working, iterative, incremental development model of the 1950’s – and it’s got a name now: Agile.
P.S. If you want to read something a little more in-depth on this subject have a read of Iterative and Incremental Development: A Brief History (2003).
References:
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
http://www2.umassd.edu/SWPI/xp/articles/r6047.pdf
http://en.wikipedia.org/wiki/Waterfall_model
http://www.product-lifecycle-management.com/download/DOD-STD-2167A.pdf
http://www.stsc.hill.af.mil/crosstalk/1995/04/Changes.asp
I haven't tried this yet - I'm more curious than anything else as to your opinions.
I use Ventrilo (a VOIP utility) for gaming quite a bit and I never seem to get the voice glitches that Skype & Live Messenger seem to get. It's low on CPU (important when gaming) and high on sound quality – a pretty good mix in my book.
Since I regularly have up to 6 way conversations with it, I was then wondering how well it might work for remote software development teams. I can imagine an arrangement where everyone would run Ventrilo during the day and could chat with the rest of the team at any time they needed. They could also use the push-to-talk feature so that background noise wouldn’t be coming through all day long, and because it's so low on CPU usage it wouldn't affect the all important activity of software compilation :-)
So, do you think it would create a better sense of connectedness between team members? Do you already do something like this in your remote teams? Or am I just day dreaming here?
Opinions welcome.
One of the big gripes people have about the CSM (Certified Scrum Master) accreditation is that you can get your CSM simply by attending a 2 day training session. You could all but sleep through the course and still be certified.
Well, that's all about to change. I had a heads up on this earlier this year and all I could say then was "Hallelujah!". My feelings now are still the same. It's a long overdue improvement to the certification process to require proof of knowledge and understanding by people being certified.
The process itself will be fairly simple - a straight up multiple choice exam, but at least it ensures that people now have a minimum guaranteed level of understanding and that can only help improve the strength and integrity of the certification process overall. It's not a complete answer to the certification process but it's a step in the right direction, and that's what agile is all about :-)
InfoQ also has some thoughts on this at http://www.infoq.com/news/2008/11/scrum-certification-test