Archive

Archive for February, 2010

The Importance of Clearly Defined High Level Project Estimation

February 26, 2010 1 comment

It is safe to say that software development teams work best in the confines of each iteration. All the stories are laid out, estimated, and committed to based on conversations, designs, whiteboard diagrams, and a clear understanding of what is needed to be done. The business team works best in terms of looking at technical projects as a whole as they try to prioritize and decide what work needs to be done to drive business. And this is where the dilemma lies. The business team is looking for a general idea of how long a project will take to complete, but the development team is uncomfortable in providing one until they have all of the stories in front of them. The catch-22 is that stories aren’t written until a project has been given the green light.

Sometimes it feels like the business team and the development team are pulling in different directions.

The development team’s reluctance in providing high level estimates typically stems from:

  • A fear that the estimate they provide will be mistaken as a commitment when it comes time to actually develop the feature/product.
  • Not having the chance to fully explore assumptions and risks adds a sense of uneasiness since the estimate is usually heavily based on these assumptions (mainly technical assumptions – business questions should be answered).
  • High level estimation meetings can be difficult to facilitate, and can quickly become frustrating for everyone involved. It is very easy to lose track of the goal of the meeting.

At Point2 it is usually the Team Lead/ScrumMaster and a Business Analyst who facilitate these meetings. It is up to them to ensure that the pain-points are alleviated. If the team has a genuine feeling that the high level estimate they provide will be construed as an actual final commitment then there is probably reason for it. Perhaps this was what happened historically and the team is having a hard time getting past that, or maybe it is continuing to happen. If this is the case, as a Team Lead/ScrumMaster it is your responsibility to manage this disconnect. If the nature of the high level estimate is being misunderstood by your customer or business team it is your job to fix it.

If there is a lot of questions arising during estimation that cannot be answered in a reasonable amount of time, there’s no way around it – assumptions will need to be made. The key is to make note of these assumptions and document them as risks in your final estimation. This will be key in helping the business prioritize the project. If there is a lot of high risk items the decision to start straight away may be best. On the other hand maybe the risks just outweigh what we hope to gain, and the project is scrapped. The point is to provide enough information for the business to make an educated decision. It is interesting to note that a lot of these technical assumptions are due to technical debt. Minimizing technical debt makes high level estimation much simpler, but I will leave that topic for another post.

When we first started providing high level estimates I had little knowledge as to where to even start. Being a former developer I too suffered from many of the above points. The bare minimum is to get the team to break down the tech project into logical, more manageable pieces. Briefly discuss these logical components to ensure that everyone has a shared understanding. It’s at this point that assumptions are likely going to be identified.

Once you’re ready to estimate that specific items try what I’ve been calling the Goldilocks technique. Throw out a number like “2 weeks” and ask if it is too much time, not enough time, or just right. Modify your number and repeat as needed. It is a good idea to sometimes provide more than one estimate based on the presumption that certain risks may come to fruition.

We're all working towards the same goal.

If your team has the understanding that the estimate they are providing is an educated/best guess that is going to provide the business with the knowledge needed to steer the company in the correct direction, the more willing they will be to engage the process. These are decisions that need to be made, and I’m sure everyone is more comfortable if it is the development team providing these estimates as opposed to the executive team who doesn’t have the expertise required. In a perfect world we would know exactly how long every project would take, but this isn’t a perfect world so all we can do it work with what we have. At the end of the day we are all working towards the same goal, and as long as the development team and the business team understand the purpose as well as the limitations of the estimates, the more likely those goals will be achieved.

By Hemant J. Naidu

The Concept of Feature Fidelity

February 25, 2010 Comments off

When we’re building software, we often have a desire to deliver something that will blow people away.  It makes sense right?  Why would we want to deliver something that isn’t impressive, doesn’t work all that well, doesn’t look really pretty etc.

Well, it just so happens that there’s a good reason you’d want to do that, because it still delivers value, even in it’s often simple and unrefined form. 

Consider this scenario, a client comes to you and asks you to build them a chair for their office.  They want it to roll around, comfortable, adjustable height, nice arm rests etc, and they want it as quickly as possible because they don’t have a chair at all now.

Using the typical mentality of not delivering anything until you think it will blow people away, you go away and over the course of a month you build a fabulous office chair.  You showed some pictures of it along the way to the client and they were pleased with the design, however they really wished they could have been sitting down at their desk while they looked at your designs…

The concept of fidelity is simply to deliver the simplest thing that provides value as soon as possible, and the move on to refine it.  Using the chair example, the client wants a fancy chair, but the client also currently has NO chair, so obviously just having anything to sit on provides SOME value.  Thinking in this way, the lowest fidelity solution that will deliver some value to the client might look something like this:

milk crate

The client will obviously not be satisfied with a milk crate as the final product but it isn’t the final product, it’s the first iteration of the final solution.  You would tell the client something along the lines of “here’s what we came up with in the first day, turn this upside down and it will allow you to sit at your desk, we’ll be back in a few days with an improved version for you.  A couple days later you return with:

chairYou tell the client that it’s a little more comfortable than the last delivery, and looks better as well.  You will further refine the chair and be back in another week.  After a week you come back in with:

swivel chair The client takes a look at what you’ve delivered, sits in it, the padded chair is comfortable, it looks stylish, and they tell you this is my chair, this is what i want, don’t make any more changes.

So, what are the main differences here?  The client ended up with an end product they were happy with in both cases right?  The second method had a couple key benefits though.  First of all, the client had results in hand and was able to use them (start sitting down) the next day, instead of having to wait for a month.  Also because the team was delivering improvements regularly the client had many opportunities to suggest how they would like things changed.  Finally, the client has the opportunity to stop the development of the product early for any reason and still be left with a usable product!  So whether it turns out that the client is happy with less than they originally asked like in my example, or if the client just ran out of money and had to stop early, they are always left with something usable.

You could make the argument that this is just iterative development, and technically you are correct, however it’s important to remember the fidelity aspect which is that each iteration should provide a usable product that provides value.  Consider another way to iteratively deliver a chair to the customer.  In the first iteration you deliver fully refined wheels, in the second you deliver the adjustable chair post, in the third you deliver nice leather wrapped arm wrests, in the fourth a nice padded leather seat, in the fifth a nice leather chair back, and in the sixth you put it all together.  That’s iterative right?  You produced and delivered a piece of the product in each iteration and showed it to the client.  The problem is that you weren’t delivering any value with each iteration.  The customer doesn’t realize any value until the last iteration when you put it all together, which means if the project had to be stopped early, the client is left with nothing useful.  Even worse, the customer can’t see how everything is going to work together until you put it all together for them, so they don’t have much ability to give feedback on your work.

Always deliver in iterations that provide value to the client, so they are left with something useful that provides value no matter how deep in to the project you are.

by: Chris Dagenais

Challenges Facing the Fusion of Agile Teams

February 19, 2010 Comments off

Recently there was some major shuffling of the development teams at Point2 which resulted in me leading a team of seven developers. Of those seven only two were on my previous team. Even though all of the teams were developing software using Scrum, each of them had specific processes and practices. One of my challenges as the Team Lead was finding a way to effectively bring all of these people together who were used to their team running a certain way.

The easiest thing I could have done was to just decide how things were going to run and inform the team. This would have also been the worst thing I could have done. Teams are supposed to self-organize and they are going to have an easier time doing this if they are working in a way that they feel comfortable.

So what did we do to expedite the fusion of the team members into a new group?

  • Get the team into a room to hammer out ideas regarding how iterations were going to run such as Sprint length, required meetings, etc.
  • Encourage all team members to talk about why certain things worked well on their previous team. We want to make sure that the best processes and practices are being discussed. It’s easy for people to be less opinionated in a new group.
  • Manage the expectations of the team and the customer/business. The team and business people were likely used to work getting done at a certain pace. Getting a new team to mesh is difficult and takes time. Make sure everybody understands this to prevent the team from getting frustrated, and the business from wondering why things have slowed down.
  • Even though we do hold Retrospectives and Root Cause Analyses at the end of every Sprint, it is in the early stages of the new team that these are critical. These are the times where problems with the processes and practices will most likely be raised and discussed.
  • As a Team Lead or ScrumMaster you have probably seen what works well and what does not. Find that balance in guiding your team in the decision making process without pushing them down a path for purely personal reasons. There may be times that they want to try something that you have seen fail previously. Under certain circumstances it may be best to let them try it. If it works, great! But if it does not it can also act as a good learning experience.

The new team has been together for about three weeks and has been running quite well. Our Sprints have been a little bit unpredictable and sporatic as we are working on a mash-up of stories from previous teams. Despite that our velocity was still most impressive for a new team.

I think the majority of the success has to do with the Agile maturity amongst our developers, but I also think that the team working in a way that they have fashioned  is also playing a factor. It may seem like an obvious statement to say your team should decide how things are run, but it is also easy to get stuck in one’s ways, and just do what you’re used to.

By Hemant J. Naidu

Pair Programming Anti-Patterns

February 19, 2010 Comments off

I read an interesting blog post by Mark Needham today that talks about some anti-patterns he found himself falling into while pairing. I have also caught myself being guilty of some of these offenses so I thought that listing some here explicitly will help keep it fresh in everyone’s mind. Of coarse what works some may not work for everyone, but here is a small list of behaviors I which I find can negatively impact pair-programming…

Moving around the code too quickly

As the driver, it is normally a bad idea to be changing windows/files/tabs/etc. too quickly while you are in control of the computer. It is easy to forget that your navigator may not know what you are thinking so you find yourself flying through the UI of your workstation at lightning speeds only to have your pair say “Ok… what just happened?” Granted, following a driver’s every keystroke is not the navigator’s concern, I do find it helps collective code ownership to have the navigator pay attention to what the driver is doing. Therefor, I believe that it is always a good idea to communicate to your navigator what you are planning to do BEFORE doing it which also give them the opportunity to offer any input they have before everything has been said and done.

Grabbing the keyboard away

This one is a little more obvious as to why it is an anti-pattern but let me elaborate anyway. My opinion is that it is NEVER a good idea to take control of the keyboard and mouse without asking first. I have seen it happen for various different reasons; lack of time, lack knowledge, lack of patience, lack of discipline, and lack of respect. Sometimes you just want to finish your task and you know you can get it done quicker or maybe you are really excited about trying to solve the problem and hand and anxiously snatch control of the computer. Sometimes the guilty may have all of the above reasons for this behavior but I don’t think it should ever be acceptable. By taking control, you are giving your pair the impression that you think they can not accomplish what needs to be done or that you can do it better. It is always a good idea to ask first before taking control and if the driver was in the middle of something, you’d better have a good reason. This also promotes better communication because you more often have to attempt to explain your ideas to your driver instead of just doing it yourself.

Vacationing as the navigator

Pair programming often come with negative connotations because some ask “Well what can/should I really do as a pair?”. The reality of it is that pair-programming involves two distinct roles each with their own very engaging responsibilities. The driver is tasked with controlling the workstation to write the test cases, code, and refactor. The navigator should be involved with design decisions made while writing the code but they do not necessarily have to be reading every line of code the driver writes. Instead, they should be thinking of what test cases come next, whether or not the existing tests are passing, can we commit, and most importantly: “Are we done yet?”. This is why it is very important to not become detached from the task at hand while your driver tries to figure out where he is missing a semi-colon. Distractions like mobile devices, food, twitter, etc. can often lead the the navigator not having a plan which leaves both people in the pair asking “What next?”. This is not to say that a driver cannot become distracted as well but, in my experience, I have found it harder to fall into the trap when you are the one engaged at the keyboard and much easier when you can literally twiddle your thumbs. Just remember you are there as a supportive role to your driver and they are lost without your “map”. To help avoid this, it is a good idea to make sure you are switching roles often to keep both people engaged in the task at hand.

You can check out the original blog post which inspired this one here.

You can learn more about pair-programming here and here.

I am also interested if anyone else has any other pair-programming anti-patterns they would like others to be aware of. What do you find negatively affects a pair-programming situation? Or for that matter, any tips on how you have become more effective? Feel free to share!

Point2 Talks Software Craftsmanship at Career Fair

February 12, 2010 Comments off

This past Wednesday the Computer Science Students’ Society held their annual Career Fair at the University of Saskatchewan. Point2 has been involved in these recently and this year was no different. We had a booth set up on the main floor giving us a chance to speak with students who would soon be entering the industry. It was also a great way to showcase all of the progressive things we do to attract all of the brightest minds.

We were also given a twenty-five minute slot to present to the students, so my fellow Team Lead Mark Hollman and I used this as an opportunity to discuss how Point2 is adopting the idea of Software Craftsmanship. This is a trend that has started to gain momentum in the industry, treating software development as a modern day craft. It was great to bring this movement to the students’ attention (nearly no one had heard of it) so that they could start to think of their upcoming career as a craft.

Mark and I felt as though we did a good job in demonstrating how working at Point2 is not only a job, but also a guaranteed path to learn, to teach, and to nurture the passion that so many software developers have for their craft. It is these differences that make a job as a Point2 developer a career.

By Hemant J. Naidu

Iterative Development – An Introduction

February 5, 2010 Comments off

Iterative development is a pretty basic concept.  You just develop iteratively…  Hmm pretty sure i read once that you shouldn’t use the word you’re defining in the definition.  Lets try again.

Iterative development is the practice of developing software in small defined chunks of time.   This is in contrast with the old-school method of starting a project and working on it over the course of months or years in one long chunk, or iteration.

Lets just dig in to the meat of why it’s important.  Imagine you wanted to get a house built.  You line up a contractor who has experience building houses.  You tell him you want a 1200sq ft house with lots of windows and a double garage.  He asks you what layout you want, where should the windows be, do you want a deck, what colors for the interior and exterior etc.  You answer him by saying “I don’t know, I hired you because you’re good at building houses, so you just make sure it’s 1200sq ft and has lots of windows”.  Can you see where this is going?

Six months later he calls you and says the house is done.  You walk in and while the house is impressive, it’s not how you had envisioned it, and with the amount you are paying him, you want it to look how you want.  Unfortunately now that all the work is already done, it will cost a LOT more to make changes.

Software is the same way, if somebody comes and says to you “I want a system that does X” but they don’t have any details as to how it should look or work, it would be foolhardy to believe that they are going to just be happy with whatever you deliver to them.

Iterative development helps with this by allowing you to break up the project in to small iterations, the smaller the better, ideally 1 or 2 weeks.  This way you can show what you have accomplished during each iteration to the customer and see what they think, and get their feedback on what they would like changed.  Even if they customer had no idea what they wanted ahead of time, you can bet that they will after they see what you have built.  The sooner you get that feedback from them, the cheaper it will be to ensure the project turns out how they want.

One of the other big advantages of dividing work up in to short iterations is that it’s a lot easier to estimate what you can get done in 2 weeks than in 2 months.  Once you have the project divided up in those iterations it also becomes a lot easier to see if you’re falling behind or not as well.

That should give you a basic idea of some of the advantage iterative development provides.  I’ll go in to more detail in future posts of some of the other advantages.

by: Chris Dagenais

Presenting at the Prairie Developer Conference June 2nd and 3rd

February 4, 2010 Comments off

The Prairie Developer Conference is the first of it’s kind in Saskatchewan, a 2 day event covering a wide range of topics including things such as cloud technologies, agile development practices, database performance tuning, etc. 

I submitted three proposals for sessions to the conference and two of them were accepted!

  • Agile Development Practices, brief introduction and how they help your business
  • Iterative Development, How it works, Why it works, Who it helps.

I’m very excited to get the chance to present on these topics to a reasonably large group of people from around my own area, as well as raising the profile of Point2 in Regina.

By: Chris D