Friday, March 13, 2015

Six Things That Make Scrum Great

I wrote a post about how there are many things I don’t like about scrum.  But I do like scrum in general. There are parts that I may not like about it, but nothing is ever going to be perfect. I’ve seen a few different approaches to scrum, and it has evolved since I first started doing it seven years ago.

Scrum is a framework intended to help prioritize tasks and improve teamwork. Through communication, better estimations, and feedback, the process of completing tasks is supposed to move quicker as time goes on. Scrum is used primarily in the software development world, but I’ve had it applied in the accounting and marketing departments. There are also stories of many other projects that are not software based that have had scrum applied.

Scrum is easy to understand

Even if you’re not familiar with the scrum process, or you’re new to it, you can contribute and understand what is going on. With a little bit of training, you can understand the roles and expectations everyone involved. Take a look at a chart, the task board, or attend a stand-up and you can get a good idea of what is going on.

Break downs

By going through the planning of a story, I believe you’re actually starting your work! I’ve always been a big fan of planning. In college, I had to account for nearly every minute of my time a week in advance so I could make sure I knew what I could accomplish. When you task out a story, you’re breaking the story down. You’re making a plan, and the team can say, “You’re on the right track!”
I like seeing things organized in a way that I can categorize them. The smaller the compartment, the easier it is for me to understand and accomplish. It helps prevent me from getting overwhelmed which I have done so often in the past.

Task Boards

Physical task boards are the best! When I’ve seen the task board at its most effectiveness was when each person had their own color post-it and had to get up and physically move the post it to the done column. There is something in your mind that makes you feel good when you physically can move something. However, now I always work on a team where we need a virtual task board. On the surface, it serves the same purpose but I don’t find it as satisfying.

The task board allows anyone walking by to silently take a glance and answer the question of “What is the status?” I hate that question. The task board will tell anyone exactly where developers are at and you don’t need to interrupt.

Stand Ups

I can get caught up in my own world. I can get so focused on a story that I lose sight of what the rest of the team is working on or struggling with. When I am operating at my best, my headphones are on, and I will forget that I’m around others. This means I don’t interact with anyone. I prefer it this way.

Stand ups force me to look at people, gather around the task board and listen to everyone speak. They can ask me a question, or I can help them out if I see something going on. The best part is that it is limited to 15 minutes! Of course something can come up that isn’t stand up appropriate and we would talk right after.


I like looking at projections. I like knowing, “On February 28th, we should be done with our project. It becomes a competition for me because I want to then say, “Ok, let’s see if I can finish by the 21st.” It becomes an interesting game for me. This creates an internal challenge.

Projections also allow management to plan around the development team. I have yet to see a better way of setting up projections in software development.  If the product owner wants tax calculators to be done by April 15th, set the priorities, do some averages, draw some lines and you should be done.

You even have projections in just an individual sprint. “Can I earn myself an extra day of training by finishing early? Let’s try.” Projections tell you when there are problems, or when things are going well. As long as your team is honest, and thorough with their estimations, there can be a lot of great things to be done with the projections one can generate from the scrum process.

Faster Turn around

When you can deliver part of the software, you should deliver it. You’re going to get reports of inefficiencies, or bugs in this process sooner. The sooner you get feedback, the easier it is to make adjustments. From a development standpoint, this is ideal. There is nothing more frustrating than finding out that you built features based on a misunderstanding.

Clients are also happier because they get to see their product sooner. They’re spending resources and they finally get to see what they’re spending money and time on. Compare that to waterfall, where there is a big bill and they don’t see anything for a long period of time. Usually waterfall involves a dispute at the end as well.

My favorite parts of scrum involve transparency. The organization is there for everybody to contribute to and observe. There are bunch of great things about scrum. These are just a few of my favorite things that I like to take advantage of.

Friday, February 27, 2015

Scrum is great, but...

I like scrum. The ability to shift direction of the product relatively quickly is valuable. I think there is a lot of merit to the idea of a product that is shipped regularly. Perhaps the biggest advantage of scrum is the early feedback. Nothing is worse than getting something, and realizing it isn’t exactly how you wanted it to be.

In the past few months I’ve spent a lot of time looking and analyzing the scrum process, gone through some formal training, talked to a couple of experts and come up with my own opinions. Some do show the weaknesses in scrum, and some may be just flat out disagreements with the scrum process.

All team members are not equal. 

Scrum is built on the idea that all team members are passionate about the project, and respect each other. A cross functional team is a great idea where we can help each other out when appropriate. But that’s not always the case. The truth is I’m not a BA expert. Can I do it? Sure, but I’m significantly less efficient at those tasks than I am when I’m coding. Not everyone has experience doing QA. At my place of work, I don’t even have the tools installed on my machine for design. So there’s a role/specialization in development that says not all team members are equal, and they shouldn’t be!

Additionally, team members have different levels of dedication. A disgruntled, jaded employee is going to have a different level of dedication than the new guy looking to make an impact. Their goals at the company are different. Some want to ship software, some want to improve their skill, and some want to just collect a paycheck. The idea is to hire motivated employees, but let’s be real – you cannot keep everyone happy, motivated, and having the same goal.

Self-Organizing is great but… 

Scrum is supposed to allow teams to self-organize. However, it treads a dangerous line in a lot of areas. It is our nature that when five people get together to work towards a goal, that someone acts in some sort of leadership role – even if it is an unofficial one. This is the self-organization. But that conflicts with the all team members are equal. By placing leadership on a team member, that’s no longer equality. Additionally, you tend to let people who are more aggressive and outspoken dominate the conversation, potentially not knowing about the project.

For example, I once was working on a complex engine for an application that I worked on. Three developers huddled around the whiteboard and talked about potential issues that could come about. Two of us were working together, and making good progress. The third was not. The third developer was new to the organization and didn’t have knowledge of the business rules. However, because he had the type of personality to dominate the conversation it stopped progress. He should have been asking why instead of dictating. Fresh views are great, but the personality can be a problem.

Third Parties 

I always seem to work on projects that have heavy third party integration. Any time you work with a third party, you inherit their headaches times ten. You cannot do anything about them, you can only prepare for them.

For example, I had once developed a feature on an application based on insurance risks and rates. The rates would come from a third party. Before actual coding had started, the contracts were written and agreed upon. The third party told me that the service I would need to call would be available in three weeks. I had mocked up a service that I could control and develop against. Not the most efficient way of developing, but it works. Once I finished up my side of the development, I really needed to test with the third party, who was now multiple weeks late. Like any waterfall project, when one module is late, it pushes the next module to be late. This delayed the release. Eventually they finished with a completely different contract that we agreed upon. You can try to protect yourself from third parties, but I find that they always find a way to disrupt your schedule.

Bugs have no real plan 

Scrum seems to be ideal for a new project that is starting from scratch. You don’t have to worry about legacy code, being pulled into other projects, or bugs. Let’s face it – every developer who isn’t Larry Gasik has bugs in their code. I have yet to see anyone implement a smooth plan allowing for when things come up. I’ve seen different approaches to handling bugs, and I don’t like any of them. Reduced capacity makes planning look bad and encourages lazy developers. Swapping stories in a sprint destroys morale and timelines.

Shared Resources

Smaller organizations allow people to wear multiple hats. This can be both beneficial and detrimental. In large organizations there are almost always too many hats. This is a major problem. Depending on the project, a scrum team may not need a full time DBA, a UX expert, a front end coder, etc. These types of resources then get shared among the organization. When this happens, you’re adding another hurdle for the development team to complete their job. This goes back to a scrum team relying upon third parties. When these things happen, your projections can change based on that third party. When that third party has their own sprint or schedule, it becomes difficult to interact with them and get things done in a timely fashion.

Scrum is great but…

It is a framework. It is not intended to be followed by the book. Modify it to be what works for your needs. I’ve never had a full time product owner. I feel like I’m going to find a unicorn before I locate a full time product owner. On a project with only three people, I’ve had to be the scrum master and developer, and when that happened, it was more successful than just complaining.

Too often I am seeing scrum being hailed as a silver bullet, and that any time scrum isn’t working for a project, it is because the process isn’t being followed. The scrum framework is built upon ideals when in reality you may not have the set up that scrum thrives in.

Sunday, May 18, 2014

Mythical Man-Month Chapters 1-5

I started reading The Mythical Man-Month by Fredrick Brooks– a near 40 year old book about software development teams and timelines. The underlying idea is that you cannot just throw workers at a project and expect results. I heard about this book a while ago, but I couldn’t ever track it down at a library, nor could I find someone who would let me borrow it and to be honest, I didn’t want to pay for it. Just recently I found someone who would loan it to me. The book is old, and there are some parts in it that help show its age, but the underlying concepts are there and go into more thought than I’ve ever had about them.

While I’m only a few chapters in, as a developer, it has been quite depressing for me. There’s a section where it talks about the productivity of developers, and brought their salary into play. The developer who makes twice as much as the other is not twice as productive. The developer at twice the salary may be ten times as productive!

It is an interesting time for me to go through this book. I’ve been at my current workplace for just over a year, and I’ve been with my project since its beginning. I’ve seen developers come and go on the project. Team leads, and project managers moved around. At one point, we had 11 workers on the project full time, and in less than a week the team will have six. The number fluctuates, and the team looks very different than when we first started.

For the most part, the team has worked well together. I believe that is because of each individual’s ego is inline. Mythical Man-Month compares development teams to surgical teams. Each person in a surgical team has a specific task. One person may be deciding how to split away something, another person may be splitting that into smaller more manageable tasks. Another could be actually doing those tasks. Then there are the individuals who are helping support those actually building, such as secretaries, and managers who will be gathering information from your client. This works because everyone knows their role, and follows it.

So why did the beginning of Mythical Man-Month depress me? Because I’m seeing the concepts in the book come into play and be accurate. Developers are optimists, and they’re horrible at estimating. The money wasted on bringing new people on board only to see them go has costs go through the roof without positive impacts on the team. Furthermore, I am now thinking about if I am as good of a team member as I had thought, my place on the team, and what I’ve been doing to improve it.

It also depresses me a bit because of the approach to software design, and how ends up in the end user’s hands. For example, our product owner will request some report. The team will gather information on said report, by asking questions, doing some database research and basic proposals. Everyone will agree that this report is important and it needs to be generated a certain way. While in the middle of actually building it, suddenly the requirements will change. For me that is extremely depressing. I feel that it shows a lack of planning and respect for the developers’ time. Mythical Man-Month touches on a related topic when it goes into talking about focus and effort. A feature that may be used once a quarter can take a long time to build. What if those efforts went into something used every day? I’ve seen problems like this throughout my career, and it makes me stop and wonder about where my energy should be placed.

Thursday, May 15, 2014

Scrum: A Breathtakingly Brief and Agile Introduction

I’ve been on a handful of scrum teams. I understand scrum and I like scrum. I’m not going to go into the strengths of scrum, or the negative points (unless painfully obvious in the book) of scrum. I’ve done other agile types of development, but scrum seems to be the strongest for the corporate world in my opinion.  With that said, I’ve never been on any team that fully follows scrum. There’s always subtle variations to it that the team needs. The basic ideas are the same though.

The book is short, and you can read it in a half hour. I think it is a great introduction to scrum, and some of the basic goals from all points of view. I would recommend this to anyone who has not been doing scrum, or wants to know more about it. If you’ve done it on a couple of teams, there will be nothing new for you.

The book starts out talking about the types of team members. There are three – the Product Owner, Scrum Master and Team Member. The one I found interesting and I think needs to be addressed is the Team Member. Team Members need to be cross functional in my opinion. The book talks about specialization but later retracts it a bit.

  • “People who do the work are the highest authorities on how it should be done.” This to me brings to light one of the biggest downfalls of scrum, and that is poor architecture is often a result of scrum. When a developer has a misunderstanding of the ultimate goal, or different point of view, this can lead to poor decisions with architecture. You also must remember that not all developers are strong in the architecture area
  • Doing my job vs. Doing the Job – The ultimate statement of being cross functional. It doesn’t mean you have to be an expert in all areas of technology of the product, but you need to be able to do it.

This goes back to my cross functional team members. I believe that scrum is under the fundamental understanding that nearly everything is able to be completed by any team member. Sure there may be a few things that are an exception, and not everyone will be on the same level, but everyone needs to act on the best interest of the team.

The book brings up burn down charts. Burn down charts are awful any time the scope changes. For example, if my product owner comes to me and adds 6 hours of work to the sprint, and I complete 8 hours of work the same day, according to the burn down, it looks like I only did two hours of work. Additionally, you show me a release burn down where there isn’t a story added. When a story is removed (say it is no longer necessary) it looks as if the team did a great job! I much prefer the idea of a burn up chart.

Meetings vs. Ceremonies – I forgot about the “ceremonies” title. At first, a major selling point of scrum and agile was less meetings. I was sick of having meetings every other day to discuss status on work. Those meetings were an hour or longer. With scrum you have more frequent, but shorter meetings. Probably a wash in reality.

Sprint Planning – I’ve never done scrum with a full time product owner. Having a dedicated resource to be a product owner is expensive. As a result, I’m reminded that I’ve never done sprint planning as efficiently as it could go. The book divides sprint planning into two parts that I don’t necessarily agree with, but I understand what they were going for.

  • Part 1 (What will we do.) – The product owner decides what stories will be considered for the sprint. To me, this is pointless. The point of the prioritized backlog is the indicator of what should be done. This step only exists because product owners do not keep the backlog up to date.
  • Part 2 (How we will do it.) – The team breaks up these stories and tasks them out. The product owner is available for questions on how to do this. I’ve never had a product owner regularly available during sprint planning. As a result, I believe developers need to groom the stories early to help understand the stories. This will not occur during any “sprint ceremony”, but needs to be a regular occurrence. This will also help understand the end goal of the system. The problem with my preference is that it does take a lot of time.

These are based on my experiences and opinions of scrum. Like I said earlier, every scrum team has their own obstacles that won’t work in the textbook definition of scrum. Scrum is about small teams. And if you don’t have a small cross functional team that can be trusted, you’re in for trouble down the road.

Monday, April 1, 2013

Async and Parallel Programming in .NET 4

I spent some time recently on some of the latest features of .Net. One area I overlooked a while back was Async and parallel programming. I've done mostly web development and it hasn't always been beneficial to me. Lately I've expanded my talents, and this has come into play.

Essentially the Task Parallel Library (TPL) helps add parallelism to your application without having to worry too much about your thread pool or exceptions. You have to worry about these things, but the TPL has really helped out in the simplification of these areas. This is important because as technology advances, our applications need to be more snappy. For example, on the Windows Store applications, you may have multiple threads happening, but you cannot lose responsiveness to your application. Microsoft will reject your application if it does not respond.

Tasks are the fundamental building block. I think of tasks as function that will consume a large number of CPU cycles or require information from a third party. If we had a single threaded application, we'll be forced to wait for these functions to complete. However, we can create a task that will start up another thread and we can go on our doing other things.

As always with multi threading, there is additional complexity versus having a single threaded application. The TPL helps handle these issues. Each task will have a status, a result, and an exception that can be checked for processing. How variables are passed into tasks will impact your results. The order of execution can also be impacted because of multiple threads running at the same time. The TPL helps you handle it all.

I'm going to spend some time focusing on a few different areas of the TPL and show how they may be able to help you out in development.

Friday, February 22, 2013

Securing Information In Your Database - Introduction

As a security precaution, it is important to not save any sort of sensitive information in clear text in your database. This can be information such as an email address, a social security number, answers to secret questions – or anything that would be considered sensitive data for the user.

For most people, it is surprising how a little bit of information can lead to malicious attacks. They use the same account names, emails, passwords, and secret questions for all of their accounts, so if you get one, you probably have them all.

I’ve seen an unfortunate amount of sensitive information stored in clear text from applications I have worked on. When I ask why it is done this way, no one has an answer. The response is always “it is just always the way it has been.” I don’t find this to be an acceptable answer as when you do your initial design, you know it needs to be done.

My next few posts will talk about encryption, hashing, and security in general. 

Sunday, July 1, 2012

Pro jQuery - Chapter 4 (JavaScript Primer)

It took me forever to go through this chapter. It was incredibly slow, and nothing too interesting. If you're reading a book on jQuery. jQuery has its bases in JavaScript, so a key foundation for it is JavaScript. Plus a lot of it was so long, with many examples that I went through on principal that it just got me really uninspired. I am glad to have finished it.

So it uses a lot of console logging, and created objects for its own demonstrations. It went into how you'd add a method onto a function, which is very different from how you would in c#. It was actually very good at explaining how to determine if an object has a property, explaining the differences between null and undefined. I spent a good portion of my time on this since it is a little different from c#.

The book did touch on array methods, but didn't go into depth. I'm glad about this because as I said earlier, it was longer than it needed to be.

So they had to put this chapter in for sure, but I feel that it was still a little long. It isn't really going to be of any assistance if you have a problem. You're going to need to go to another JavaScript reference and look at it there.

I am excited though because I see the next part is called "Working with jQuery".