Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula - Part 2

Back in May 2010, I posted an article entitled Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula, which has been one of the most popular articles on this blog.

Amongst the feedback received there were many requests asking me to provide more details on how to devise the numbers to apply on the formula. This article expands on the topic by explaining my way of coming up with the numbers for the optimistic, pessimistic and realistic components of the Pert Weighted Average formula.

As explained here, the I use the following formula to estimate the duration to develop each user story that make up an iteration: (Optimistic + (4 * Realistic) + Pessimistic) / 6 .

How to apply the formula

Optimistic - I ask each developer to provide me with an estimation of how long it will take to complete each story they will work on. This is the number that I use for the optimistic component.

To estimate the other components of the formula I use a combination of grading user stories by size and complexity as outlined in the first article. However it is not as simple as that.

I don't see estimation as an exact science and therefore blindly applying a formula will not work under all circumstances. However, the formula does provide me with a consistent estimation procedure that has worked for at least 10 years now.

Another variable that I use in estimating the development effort is my team's velocity. I have a detailed record of the team's velocity recorded against functionality deployed to production. This helps me to compare actual duration of completed user stories against the effort that was originally estimated and use it as a basis to estimate the effort to develop stories that are similar in size and complexity ratings.

So here is how I devise the numbers for the rest of the formula.

Realistic - I search TFS (Team Foundation Server) for completed stories with similar size and complexity ratings and take the actual time that it took to develop it as the realistic component of the formula. 

Pessimistic - It is hard to estimate what a pessimistic duration would be because of many different variables that come into play such as risks associated with the particular piece of functionality, complexity, developer  experience and many other variables. I have met some development managers that double the duration estimated as the realistic and use it as the pessimistic. I don't blindly assign a number to it, I try to take everything into consideration in order to come up with an estimation that makes sense.

I don't think that there is a formula that you can blindly take to estimate software development effort. It is not as simple as that as there are many components that come into play in effort estimation, project management and software development.

What makes a good software developer?

Today at work I started to do some performance reviews. As I prepared the review papers  I started thinking about what makes me rate one developer higher than another.

So the question really is, what makes a good software developer? There are certainly many answers to this question and viewpoints will vary greatly. I don't think there is a definitive answer as the definition of "good" will change depending o what you are trying to achieve.

The following sections provide a high level summary of my thoughts on this very interesting topic.

Technical Skills

Technical skills are definitely very important, however I think that it is overrated. Attitude is far more important than technical skills. More on that later.

Possessing well developed technical skills enables developers to complete their tasks faster and therefore it has the potential to make them more efficient. In the past 2 or 3 years I have introduced new technologies in my current organization. Those projects didn't come without challenges, there were some rough days and times of low productivity. The developers with more advanced technical skills were able to understand those technologies and become more productive faster than the others. The real good developers became mentors to the other ones, without making them feel bad.

Attitude

Attitude is by far one of the most important skills a developer can have.

We all have different strengths and weaknesses, we can't all be technical geniuses or specialists in every single area of software development. When a developer faces a technical challenge and "hits the wall", no matter how good he/she is technically, attitude will determine the outcome. A good attitude and the ability to stick with it until the issue is resolved is key in this situation.

What I find particularly annoying is a developer that lacks these skills and as soon as there is an issue he/she immediately starts to ask the other developers without even researching the web or the team's wiki. Having said that, when facing technical challenges, there is a line when one needs to decide to stop researching and ask for help. I don't like to see developers stuck and not ask for help. Once research is done and a solution is not found, there is nothing wrong with putting your hand up and asking for help.

Business Knowledge

Business knowledge is also very important to enable a developer to work productively. Whether you work for an internal IT team or for a development house, having good domain knowledge enables developers to better participate in design meetings and to decide what delivers real value.

The time has past when developers sit in the corner and writes code according to the specs without asking questions or participating in solution architecture and other related tasks. We are all doing agile these days and moving to self-managed teams. Against what many people believe, implementing agile and self management is actually very hard. In order to have self managed teams you need developers that understand the business and are able to have meaningful discussions without project stakeholders. Without domain knowledge this is practically impossible.

Furthermore, well developed business knowledge enables developers to question the completeness and accuracy of user stories, either before or during development.

Lack of business logic is actually very dangerous because the developer does not actually know what it is that is being developed and what value it delivers to the business.

I would say that domain knowledge and attitude are some of the most important skills a good developer needs to have.

Openness for discussion

There are many different ways to address a particular technical issue or to develop a new function item. In my team we have daily stand up meetings and longer design/review meetings depending on what is going on.

Every so often we hold meetings to discuss the architecture and/or the best technical solution for a particular issue or functional item. During these meetings we discuss what the is the best solution and we move on to implement it without wasting too much time. I find very entertaining to see the developers argue to have their opinions or solution implemented. My own entertainment aside, these discussions are very important for the ultimate quality of our work because nobody knows everything, it is when we all sit around and workshop ideas that the best solutions are implemented.

I need to be careful and manage these meetings very well. Once we agree on a solution I quickly move on to the next topic or I end the meeting. The overall process works well, it has increased team cohesion and even the quietest developer starts to participate which is a bonus to everyone.

It is a win-win situation for me.

Appetite for new knowledge

IT is always changing. New technologies are often released to the market, new frameworks and methodologies are reviewed and update. It never stops. In order to keep up with it, developers need to be curious and have a appetite for new knowledge. You never really graduate from uni if you work in IT.

I could keep on going and identifying many other skills like knowing your tool set and many others, however I will stop here because I think that, in broad terms, I have touched on what really makes a good software developer.

I find really amazing that after a quick search on the web, most of the articles on this topic highlight technical knowledge, the need for good tools, knowledge on how to use those tools and other related technical skills. Although these skills are very important, they do not make great developers.

When I interview new developers I often ask if they know a particular technology or tool that is not listed in their resume. If they say that they know I probe a little further and may even ask why it is not on the resume, depending on the circumstances. The good ones, those who often get the job, say that whilst they don't have experience working with this specific technology, they can learn quickly and become productive in a reasonable period of time. If I can find evidenced of it in the resume and I confirm during reference checks, that will be the developer that gets the job.

In conclusion, I don't think that there is a definitive list for what makes good software developers as it varies depending on the circumstances. In broad terms, I find that attitude, openness to discussion and business knowledge are some of the skills that will give developers the edge they need to succeed in their careers.

The Decline and Fall of Traditional IT

IT (Information Technology) as we know it came to a fork in the road several years ago. The traditional IT department used to deliver technology with a service component. Now we provide service with a technology component.

What does this really mean? Let me provide several examples of the transition from information technology to information services:

• The IT department used to deliver technology projects. Now the department delivers project management services. These services include IT functionality, but not exclusively.

• IT departments used to build a complex infrastructure of networks and servers and workstations. Now the department delivers an enterprise architecture articulating how everything fits together.

• Staff members in IT were the back office geeks. Now the department trumpets service-orientation with world-class help desks and sophisticated escalation processes.

• Security was a deny first, enable later process. Now the department defines security by corporate policies. These policies follow national and regional privacy laws, enable multi-layered authentication for a variety of roles, and facilitate freedom of information legislation.

• IT departments used to hand-craft software to meet every nuance of an organization's processes. Now the department staff are master negotiators working with a sea of vendors to deliver information services written by a vast array of industry subject matter experts who have never set foot inside the organization.

These are the facts crafting our new reality. The implications for the future of IT are undeniable. The decline and fall of traditional IT is complete. Organization do not need, nor do they want, a traditional information technology department. What they crave is a world-class information service organization.

~

Digital Strategy & Execution - The "What Sandwich"

I try to use analogies that help stakeholders get their heads around some of the abstract concepts floating around in a marketing environment. Strategy and its proper relationship to Execution is one of them.

This is not a post on the elusive definition of strategy. Nor an attempt to define the difference between Strategy (with a big "S") vs. strategy (with a small "s") or Strategery or any of the other silliness that surrounds this term.

I like to think of the relationship between Strategy and Execution as a "What Sandwich" or, more specifically, a sandwich comprised of "What" needs to be built, that lives between 2 slices of "How" objectives will be achieved and "How" the features and functions will be executed.. The sandwich is made like this:

I'll leave the deeper question of "Why" for another time or other minds.

Chaos Theory for IT

I made a career shift several years ago from financial services to higher education. Being in IT leadership, I wasn’t concerned with making the change. From my point of view I was simply doing a similar job, just different industries. What I discovered was a fascinating cultural shift from a centralized top-down environment to a distributed consensus-based world.

Moving from organizations with enforced technology standards to a one-size-fits-none world was an interesting transition. Personal computing tools in a corporate environment were locked down and well controlled. In a higher education environment, particularly universities, funding comes from many sources and technology decisions can sometimes be made in many places.

I could debate the relative merits of technology in these different worlds, but the most fascinating difference is the decision-making process. Utilitarian efficiency experts may argue that top down is the obvious preferred approach. Decisions get made and everyone simply follows through. Logical.

But do the best decisions get made in this model? The university world provides an interesting counter-example. Major decisions are made with extensive socialization of the underlying issues. Building consensus in this world is like pulling back an elastic band or a slingshot. The more effort you put into developing consensus (or pulling back the elastic), the more buy-in, understanding, and acceptance you have to the solution. When you launch your initiative and let go of the elastic, everything goes faster.

My lesson from implementing large IT projects in this model: invest the time in developing consensus and you will see the return. It is worth the time and effort to build consensus first, because you have everyone’s support later. The time upfront is saved by reducing grief and re-work during the implementation.

The process of consensus-building starts with engaging the key thought leaders across the organization. The next step is to make it interesting for them. What do they want from it? Once you get their input, use it. Apply their comments in a meaningful way. Consensus doesn’t mean everyone gets to make the decision. But it does mean that everyone at least has the opportunity to contribute.

Ultimately, consensus is about relationship building. Whether you work in a top-down hierarchy, a centralized bureaucracy, or a distributed chaoscracy, the one consistent factor is your ability to create confidence in the decisions made and the path forward.

~

IT and the Holy Grail

I can't help but notice how many IT leaders, myself included, list "strategic planning" on their resume and their LinkedIn profile and any other personal profile. It makes me wonder if strategic planning is the holy grail of IT. Any single topic with so much attention begs the question: do we put too much faith in our ability to plan?

To answer the question, let's borrow a trick from mathematics and think about strategic planning by working backwards from the end state. Consider where you are today and how well a plan from five years ago could have predicted your current predicament. Could you have planned out an enterprise IT strategy that accommodated Google Apps and Bring Your Own Device and ubiquitous Apples and staff with multiple IP addresses? And could you have predicted the need to balance all of this with ever growing privacy legislation? What about the decline and fall of outsourcing (witness General Motors turfing HP/EDS)? If these events were unpredictable half a decade ago, why do you think you can plan out the next five years?

Over the past few years I have had the wonderful opportunity to read several IT strategic plans as well as write a few. They are all remarkably similar. With my eyes closed I can tell you the titles of the first three sections: Mission, Vision, and Values. Creativity doesn't seem to be considered a valuable asset in strategic IT planning. Yet without creativity, how can we imagine the future? 

The process to write these plans is fun to watch. Sometimes these strategies are built in a conscious fashion using a formal planning approach; sometimes these strategies emerge through convulsive reactions to change in the world around us. Some groups start with an enterprise architecture; some groups start with a crisis. No matter what the motivation, everyone has a plan. You may develop it elegantly, or you may stumble into it wretchedly, but it is human nature to crave a plan for the future.

The problem is that the accuracy of your plan five years from now has a plus/minus of 100%. In other words, the rounding error for any IT strategic plan is roughly equal to the entire contents of the plan.

So how do we reconcile the need to plan with the inability to plan well? Military strategy sometimes comes in handy. Think about the brilliant Canadian victory at Vimy Ridge in 1917. After years of trench warfare stalemate, a technique of rolling bombardment was introduced. The shells landed just-in-time and just-in-front of the advancing infantry, thereby preventing the enemy from emerging from their bunkers in time to mount a credible defense. 

Maybe we need rolling strategic plans. Instead of trying to predict an accurately future IT state, set some basic objectives (invade Germany and capture the Kaiser) for the long term. Then figure out what you need to do in the shorter term to work towards those goals (capture the next trench). Then revisit and adjust the long term view every year. 

So, five years ago, an IT plan could have easily said, "investigate web-based productivity tools." A year later it may have said "assess vendor product roadmaps for web based productivity tools." The next year may have said, "compare cloud-based tools for productivity services from Microsoft and Google and what are the performance issues." Finally, the next year the plan may have said, "evaluate Google Apps service from Apple and Android devices and determine the impact of privacy legislation on their usage." 

Narrowing the scope from broad strategy to practical implementation is the ultimate measure of success for any strategic plan. The real holy grail of strategic planning is accomplishing real work. It isn't about the plan. It's about what the planning process enables you to accomplish.

~

How do you measure an IT department?

As part of a consulting engagement my client wanted to know how well their IT department compared to similar IT departments in the same industry. I began by collecting data comparing the customer's IT department to peer organizations in the same industry. I knew before I started that there may be some apples to oranges comparisons. What surprised me was that I was comparing apples to flying saucers. I discovered the real issue is determining how to define an IT department before making any quality judgements.

In this particular study I looked at organizations within the same somewhat regulated industry. Organizations with similar revenue and customer volume had IT departments that varied in size by over 200%. So what was really going on here? First, it was clear to me that everybody has a different names for the same thing. Second, there are no obvious rules about boundaries. Let's look at both dimensions sequentially.

Names can be deceptive. For example, within IT there is often an infrastructure group. Assuming that includes server support, does it also include network support? If that includes network support, does it also include the phone system? If it includes the phone system, it probably includes the automated call response software and support staff. If you include these staff, do you include the telephone operators? If the operators are included, then do you include the call centre and business help line staff? Now we have an organization that reaches directly from the external customer to the back-end server.

I know this example may be extreme. But where do you draw the line? Let's think about boundaries. Does IT end at the pure technology of servers and network gear? Or does it go further? Think about applications development. IT usually includes the programmers, but not always. What about the analysts that work with both the business and the programmers to develop the requirements? Sometimes they are called business analysts, sometimes systems analysts. They do the same work, but the systems analysts typically reside in IT and the business analysts do not.

Defining IT by roles performed simply doesn't do the trick. As I reviewed the organizations in the study, there seemed to be no consistency. One IT department ran the printing operations for the whole organization. Another included web content development. Contrary to intuition, you cannot define an IT organization by the functions it runs.These seemingly arbitrary distinctions depended on history, available skills, and ultimately, political machinations.

Names are nearly meaningless and boundaries fluctuate continually making comparisons challenging. But the rules creating IT boundaries are remarkably consistent across all organizations. The ability for IT to influence these changes is negotiating power.  The degree of negotiating power accumulated by IT defines its boundaries. Building negotiating power comes from cumulative value-building. Every transaction between IT and a customer creates or destroys the clients' perception of IT's value. If IT provides great service, clients are more willing to work with IT. As a result, they become more willing to support IT in political bargaining when the organizational boundaries are inevitably revised over time.

Back to the original question - how do you measure an IT department? I would propose that you define the worth of your IT department by its return on service (ROS). If clients feel they get great service, the long term reward to IT is greater scope - a higher ROS. Conversely, bad service creates negative ROS and a shrinking IT department. A good IT department is one that is growing because it is providing an optimal return on service to clients. The last full measure of an IT department is its return on service.

~