Impleface Design Pattern – When Stupid Meets Hardworking

In my opinion the worst qualities for the software developer is when the stupidity and hard work are combined together. Anyone who worked in software development organization for a long enough time can tell many stories about some coworkers who possessed both of these traits. For the most time they results in awful code being produced in gigantic quantities. However, sometimes this results in something that you will remember for a long time. Because it will make you laugh until you will start crying. So here it is – the new design pattern called Impleface when the interface and its implementation are coupled in a way you have never seen before.

public interface Implementable {

public static final Implementable DEFAULT_IMPLEMENTATION = new Implementation(new Long(1), "DEFAULT_IMPLEMENTATION");

Long getId();

String getName();

public class Implementation extends Implementable {

private Long id;
 private String name;

 public Implemeentation(final Long id, final String name) { = id; = name;

public Long getId() {
 return id;

public void setId(Long id) { = id;

Free Project Management Templates

I just came across this interesting web site that offers free downloadable templates for various project management documents, including project charter, work break down structure (WBS), statement of work, etc. All of these documents are developed by PMP certified project managers and can be very helpful for your organization.

Why People Hate Meetings – How To Make Meetings More Effective

I have been lately going to a number of meetings that made me think about why people don’t like meetings. Meetings became something like a plague in the corporate world; people make jokes about them; everybody hates going to meetings, but yet nobody seem to do anything about it. So I decided to put together a few simple tips that could possibly make meetings a little less frustrating for people.

1. Clearly State the Purpose

Too many times I have been invited to the meetings for the projects that have already been going on for quite some time and every time I had this feeling that I was watching a movie starting from the middle. I did not understand what was discussed; I did not understand the goal of the conversation; and what was even more upsetting:  I did not know what was expected of me in this meeting. I am sure many people could relay to that. So my suggestion to the people who organize meetings: clearly define the goal of the meeting and if you invite someone who is new to the project or the subject that will be discussed then provide some additional background information.

For example:

The purpose of this meeting is to review the latest project plan and identify the potential concerns from sales and marketing.

This will help people prepare for your meeting, and potentially identify and invite additional people who could provide critical information that will be important for your decision making later.

2. Clearly Define the Desired Outcome

In other words you need to specify how you will judge if the meeting was successful. This will help everyone to focus on the objective and will save you a lot of time in the meeting.

For example:

The ideal outcome of this meeting is the list of risks that we will need to manage during the project.

This gives everyone who is invited a pretty good idea of what needs to be accomplished in the meeting and helps avoid confusion and minimize the time spent in the meeting talking about other things.

3. Provide Plan of Action

Some people call it meeting agenda but I prefer to call it a meeting plan. The reason for that is that agenda implies rigid order and specific sequence of discuss topics with timeline. In many cases the meeting organizer simply cannot know all of these things or quite honestly it may not make sense to time box the items on the list. Instead I prefer to state in the plain human language how we are going to go about accomplishing the meeting goal (see item #2 on the list above).

For example:

In order to identify the risks we all will take a bunch of 3×5 cards and on each card we will write one potential issues that we could foresee on this project along with the probability of the problem occurring, the approximate time line when it could occur, and the expected impact. Then all of the cards will be reviewed by the group, to remove the duplicates, and will be given to the project manager to add to the risk management plan.

In this example we would set clear expectations for what will happen in the meeting and what is expected from the attendees.

4. Meetings Are For Gathering Ideas or Sharing Information

Many people expect to make the vital decision in the meeting and sometimes it does work, but more often than not, the final decision will be made outside of the meeting. Especially, when the stakes are high.  This is happening because meetings are not good for decision making. They are good for gathering ideas, brainstorming, or sharing the information. So before you call a meeting, please, think about what you can accomplish and if the meeting is the right way of doing it.

Business Analyst Training At University Of Wisconsin Executive Education

I just finished Defining and Managing Business Requirements class at University Of Wisconsin Executive Education which is a part of Business Analyst certification.

As a part of the class we covered a number of different activities that a good business analyst should be taking as well as some of the techniques that they could utilize the be more efficient. The class covered:

  • Creating  problem statement
  • Performing stakeholders analysis
  • Performing SWOT and gap analysis
  • Performing process analysis and issue investigations
  • Interviewing potential customers and end users
  • Writing unambiguous, complete, cohesive, consistent, feasible, testable and verifiable requirements
  • Organizing requirements and creating responsibility and requirements matrix
  • Prioritizing requirements based on objective and quantifiable criteria

Overall the class was very interesting, we had an excellent instructor who is practicing business analyst with extensive practical experience. She able to keep everyone excited and engaged and provided a lot of additional useful information.

As I was sitting in the class I decided that I wanted to capture my thoughts and ideas as well as some of the things we covered in the form of a Business Analysis Framework.  In the future I hope to have enough time to write about specific components of the training but for now it is just a template that I put together as an Excel workbook that you can download from my site.

Delivering The Value For The Clients – This Is What Agile Is All About

Agile is not about a specific way of writing the code or running the team meetings. It is really all about dealing with complexity and uncertainly, driving the ROI for the clients and allowing them to make the decisions that can possibly alter the course of the project if there is a business need for it.

Too often people get fixated on certain attributes of agile like daily stand up meetings, or pair development, or writing user stories on 3×5 cards and forget the real purpose of it. Common people, wake up! This is only the attributes that may or may not work in your environment. Focus on the big picture, concentrate your energy on delivering value to your clients, help them shorten the time to market for new features. This is what agile is about.

User Stories – Why Making Software Requirements More Granular Can Be a Good Idea

Picture of Dilbert talking about writing user stories for Agile project

The point of doing User Stories is to make requirements more granular.

One of the core agile practices is writing requirements in the form of user stories. This approach to requirement gathering exists in pretty much any flavor of agile software development process.

Challenges with Estimating

In order to really understand the rationale behind creating user stories we first need to understand the process of estimating the duration and effort for software development work (or any work to that extent).

Every time someone is asked how long or how hard it would be to implement a certain feature or a set of features they are facing two-dimensional uncertainty. The first thing they need to figure out is what exactly they need to do (or how it should work) and the second how they will be doing it (the technology and inner mechanics of the project). The bigger the task the more difficult it would be to give an accurate estimate and the greater the chance we will miss something.

Here is an example: someone asked you to estimate how long it would take to build a new web site for insurance company where people will be able to purchase insurance policies on-line. How long do you think it will take you? And what is the level of confidence you have in your estimate?  Would you feel comfortable committing to this timeline?

Now, imagine that you were asked to estimate how long it would take to build a new web page on which the user will be able to enter their personal information and home address, and that should result in the system creating a new profile for this user and redirecting the user to their profile home page. Would you be more comfortable estimating this or the entire web site? Would you be more confident in your estimate for this feature?

User Stories vs. Traditional Requirements

This is where the user stories come into play. Instead of defining a gigantic set of requirements that is likely to change half way through the project anyway the requirements are defined in a form of user centric stories:

As a new user I should be able to register new account by clicking on Register button on home page and then I should be taken to the New Account Registration page where I can enter my first name, last name, home address, and email. After successful registration I should be taken to the My Account page and the new account should be created.

Compare this to the more traditional form of capturing the requirements:

 R1. System should allow for the new user registration

R2. Registration should start with clicking on Register button on the home page

R3. During the registration process the new customers should provide:

  1. 1.      First name
  2. 2.      Last name
  3. 3.      Home address
  4. 4.      Email address

R4. After registration the customers should be redirected to My Account page.

 Which one is easier to visualize? How about estimating?

Tracking Progress

 There is, however, another important aspect that often gets overlooked. More granular requirements are easier to track. Imagine that you have a 20 page long document that contains the complete set of requirements for your system. Some of them are implemented, some of them are still being worked one, and some of them have not even been looked at. How would you estimate your progress on this project?

 If you had the requirements defined as user stories and each story would be estimated separately then it would simply become a matter of doing the math. You can easily calculate the total amount of work (either in hours or points) minus the completed work.

 If you kept the user stories small enough and did an OK job estimating them then figuring out when you will be done becomes a fairly trivial process. You know how long it takes to complete one story (again either in hours or points), you should know your team capabilities. Put it together, and you will get the rate at which you can be completing your requirements.

 For example: you have 30 user stories ranging from 8 to 24 hours of work each. For simplicity we will not talk about duration vs. effort at this time. All of them together come to 1000 hours of work. You have 6 developers on your team; therefore your total daily work capacity is 6 x 8 = 48 hours. Assuming that they only can stay focused on your project about 80% of the time while spending the rest of their time on some administrative work (time entry and other corporate stuff) you will have your team capacity at 38.4 hours a day. Divide your 1000 hours by 38.4 and you will arrive at 26 work days.  This would be about 5 work weeks.

In this example 1000 hours would be called your back log and 38 hours a day would be called your projected burn down rate. You can even create a nice looking burn down chart.

Picture of Agile Burn Down Chart

Burn Down Chart halps you predict the actual project completion date.

 In reality things can be a little different and more often than not the expected performance will differ from the real life productivity. After the first few days (weeks) you can establish your real burn down rate – the number of hours it really take to complete the projected (estimated) unit of work.  After that you can recalculate your project plan and come up with more accurate reality-based dates.

Points vs. Hours

 The approach above works well with abstract developer working in vacuum. In real life different developers have different productivity. This is the reality. To address this problem the user stories can be estimated in some relative units of complexity (points). It is not really important what one point would equate to as to make sure that all stories that estimated with two points have about the same amount of work and are about twice as more complicated as stories that have only been estimated with one point.

 For example, let’s assume that one point is about 8 hours of work. In that case if we look at the example above we have our total backlog at 125 points (after combining all of the points assigned to all of the user stories).

 We can again estimate our project burn down rate to approximately 4 points a day (38.4 divided by 8) or 20 points a week. This will give an estimated completion time of 6 weeks.

 Is this accurate? It is just as accurate as estimating in hours. You never know how quickly you will be able to move until you start. After we finish first two couple of weeks we can correct the estimated burn down rate. Let’s say we found out that in the week one we only completed 16 points worth of work and week 2 we were able to finish 18 points. This would help us establish reality-based burn down rate. Let’s say we decided that we will use 18 point from now on (first week was really tough because it was a brand new project so we don’t want to use that data).  Then our new project timeline is going to extend to 7 weeks.

 Of course, it is not 100% accurate. A lot of things can still go wrong: you may discover a complicated problem, clients can change their mind, new legislature can be passed by Congress and impact your industry, etc. However, it is much more accurate that the traditional way of estimating the project based on traditionally defined requirements.

Agile Software Development Demystified – Part 1

Agile practices as a software development methodology have been getting increasingly popular in the last few years.  This can be partially attributed to the success of some of the projects that used agile and partially to continuous word-of-mouth advertisement from many agile evangelists who spread the good news across the software development community.

Unfortunately many people are still not very clear what agile is fundamentally about.

Image Dilbert on Agile

Agile methodology means being better prepared to react to customer demans

Agile Fundamentals

There are a few commonly accepted best practices that can be viewed as core agile development practices. Let’s review them.

Frequent delivery

This is by far the most important and the most frequently overlooked aspect of agile development process. The whole idea of being agile is based on ability to deliver value to the customer frequently. This allows the clients to start using new functionality as soon as it is available and generate revenue from new features. This is what directly impacts time to market for any software product. This is what drives ROI of any development project. This is what makes the difference between being the market leader and the follower, the profits and loses.

Iterative development

In order to accomplish frequent delivery to the end client the entire development process should be organized around relatively short cycles (or iterations).  Each cycle can be viewed as a mini development project with its own unique deliverables, fixed scope, and a clearly defined due date.  The end result of each iteration should be a new feature deployed in production environment thus generating value to the client.

Continuous planning

The only way to support this delivery model and frequent releases to production is to have continuous project planning process when only a high level project plan (more of a road map) is created at the beginning of the project and more details are defined for each iteration before the iteration begins.

Constant feedback from the client

Frequent delivery enables the clients provide timely feedback to developers and allows developers take corrective measures to make sure the project is organically evolves using evidence based feedback form the clients. For example, the product manager could have incorrectly assessed the need of certain features in the product therefore putting higher priority on certain functionality. After these features have been deployed the feedback from the clients clearly indicated that the need in these features was incorrectly established and different set of features would be more useful at this time. Agile delivery model would welcome this feedback and allow for a quick change in direction by re-prioritizing features that are stored in the project back log which in turn will allow quickly react to the new client requirements.

Reliance on automation

If the clients can change their mind about the order in which project is being worked on and have the right to re-prioritize the work for developers then developers should be prepared for this.  The best way to prepare for this kind of requests is to minimize the amount of non-value adding activities, such as testing, maintenance, physical deployment of new functionality, etc. Anything that does not directly lead to increase in ROI should be a candidate for automation.

Let’s look at testing process.  Every time you deploy a new feature you need to regression test the entire application.  This takes time and resources. And the worst thing about it is that the value of the delivered product does not increase if you need to run full regression test once or five times. There is however, a huge cost increase associated with “excessive testing”.  This is why testing should be considered as the primary candidate for automation.

The next step would be to implement continuous integration environment where building of the application that is under development is automated and integrated with automated testing process, and also provides some sort of quality reporting at the end.

This will greatly reduce the cost of new features and result in better resource utilization.