So, outside of the important, qualitative retrospective, what quantitative facts can we produce and track to _support_ (not intrude upon) the Agile process, analysis of velocity? In essence, why is our red line not burning down toward zero as it was previously? Some have said, appropriately, that management has a tendency to over-measure and introduce burdensome processes. Processes that are counterproductive to the Agile philosophy. However, if shops view additional project data as ’supportive’ or ‘explanatory’ of velocity and trends in velocity, the focus continues to remain on what matters — shipping software and continuous improvement.

In fact, many shops are not too far removed from being able to report quickly and capture unobtrusively key data we feel play a significant role in analyzing velocity and –ultimately–  working product. The following bubble graphs displays _some_ of these metrics that are likely at your fingertips now or available, hopefully, without an act of congress.

In posts to follow, we’ll dive into these metrics further, but the overarching thing to remember is that these metrics – taken together – are, after a fashion, leading indicators into the most dominant factor on whether software project succeed or fail: the organizational environment. Simply put: your ream’s maturity, flexibility, and collaboration dynamics.

Some of these key supporting metrics are:

• User story: analyzing for excessive churn, maturity, gaps in requirements
• Defect: analyzing for defect trends, severity, etc
• Issue: evaluating the blocking-and-tackling of things that need to be addressed for progress to continue
• Unit test: inspecting the code base and assessing the freshness, completeness, breadth and depth of unit tests
• Code complexity: assessing the code base and ensuring that it is not  unecessarily complex
• Time/effort: the least important of the bunch, but instructive at a coarse-grained level (gathered as unobtrusively to team members as possible). The ability to do this in fine-grained fashion without driving your developers and team members batty and creating unnecessary apprehension we’ll also discuss in coming posts.

As much as is feasible and appropriate, an important success factor for using _all_ of these metrics is your ability to tie them to specific features/clusters of features; for that, excellent abstraction, analytical, and organizational abilities are indispensable.

More to come  …

 UPDATES:

- More on issue metrics

Technorati Tags: agile, velocity, burn charts, agile manifesto, technology management, agile retrospective, agile reflection, continuous improvement

Technorati Tags: agile, velocity, burn charts, agile manifesto, technology management

To be sure, the visionaires behind Agile have significantly changed the way software gets built. However, Alistair appropriately and importantly references how these Agile PM approaches are founded on the work the government/military (further the government adapted these techniques from industrial manufacturing techniques at the turn of the 20th century).

The point of this post is to offer another simple dimension for burn chart tracking – business value. Understanding the business value of projects in general is an important part of any project. This is particularly true in the midst of a recession. Clearly, the Agile burn chart is very powerful and succinct in explaining how efficiently teams are achieving functionality goals on application development projects through story points; and Earned Value charts nicely explain the labor and material value of the functionality being developed through currency. It goes without saying that these are both incredibly important objectives.

However, in our experience, they both miss an important dynamic which can significantly improve project tracking, resulting negotiations, ongoing prioritization, and, more importantly, the fluidity, focus, and sense of accomplishment in business-technology interactions. This dynamic is the actual business value (and resulting priority) of the elements and features being delivered across the sprints in a project, and it is important to track and recognize this at least as often as you track story points earned.
You may be thinking: “priority is part of the sprint planning process, there’s no real need to include any special ‘priority value’ in the burn chart — its overkill.”  Our answer would be, “perhaps.” But despite the guidance of the Agile Manifesto, many project teams tend to lose connection with business priority and many business stakeholders tend to get lost in the minutiae of giving guidance on features while losing sight of which of these features are going to give them the most bang for the buck.

So, we think we have a simple solution: add a secondary measure to the Agile burn chart that captures the business value of the feature/functionality being delivered. Now, Cockburn hints at this, but we believe its a vital part of increasing communication flow and focus on business benefit. To accomplish this you simply add a secondary y-axis to the normal burn up/burn down chart. So on one y-axis, you could have story points, and on the other y-axis you would plot something more tangible to the business (in this example – estimated revenue). This could also be: customer complaints reduced, widgets manufactured, product returns averted … you get the idea.

So, you might have a table such as the one below that gives you the raw data for your burn chart.

This table would then be used to generate the following “Earn up” chart.

The ideal way to draw this graph is using one line plotted against two axes – one for story points and one for business value. However, by default, excel is not very intuitive to use in this regard. So, its likely easier to create a combination chart to represent what your team is earning on their project as we’ve done here with the bar/line combo chart.

Technorati Tags: agile pm, agile project tracking, burn charts, burn up, burn down, earn up, earned value management, agile manifesto, alistair cockburn

                                           
To paraphrase, she asked “I’ve developed my own techniques to estimate how working on multiple projects impacts a person’s productivity, what are your thoughts and references on the topic?” In essence, the topic of this question is what we — ALTERthought — call the switching gears factor. She inspired this post.

While the topic may seem tangential to the most important aspects of estimation and project management, it is, infact, one of the major reasons projects go over budget and off schedule. In the last 10-15 years, the popular notion of “multi-tasking” along with “doing more with less” have become culprits in causing teams to overload their professionals with multiple projects. This naturally impacts how effective a person is on any particular project.  For many years, we’ve represented this concept as the productivity factor and have used it as a central tennant in project planning and estimation. It is so critical in planning, that we’ve codified it as a key variable in our software planning and estimation tool:Planix.

This, that, the other
Switching gears is not the common mistake of cramming excessive work into a shortened time frame, but the realiity of asking people to perform activities on a variety of different projects. Team members of different stripes can all relate to wearing not just different hats — but different hats for different initiatives. The software developer is asked to work on a new feature for an existing application, design for a completely new application, and bug fixing for an existing application — all contemporaneously. The project manager is asked to manage one project, perform business analysis for an upcoming project, and document the proceedings of the meeting for a third, maintenance initiative. The marketing manager is asked to survey customers for a recently released application, perform user acceptance testing for one in the pipeline, and to develop requirements for another.

Cry me a river
There is a strain of the business culture that would take the paragraph above as whining and the bemoaning of someone who strives for a project management utopia. Ahem.  Where there is nobility and truth in the effectiveness of the American work ethic, there is delusion in the premise that every project is a high priority and will be completed as planned. In short, there is false optimism in thinking that we can have our cake and eat it too. It is precisely in response to realities such as the costs of multi-tasking and the rantings of the captains of “do more with less” that the Agile and eXtreme programming methodologies have increasingly gained in popularity. These approaches are fact-driven and deal with the reality of the company’s environment. Too many projects? Disparity in developer capability? Weak requirements? Overloading of team members? It all gets reflected in the concept of velocity.

The multi-tasking myth
It is true, that in modern American corporations — small and large — we all are and will continue to be asked to achieve “more with less.” What is not true is the common wisdom that simply asking for multi-tasking means people will accomplish more. Infact, social commentators, science and emerging popular coverage on multi-tasking demonstrate that multi-tasking means lost productivity – especially as the number of interruptions or activities increases. A relatively recent  Vanderbilt brain imaging study (PDF file) demonstrates that as the time between interruptions decreases, the time required for a person to recover from the context switch and become productive again increases. We argue that this finding is analogous to and a by-product of increases in the number of projects assigned to a person.  In common sense terms: As people are interrupted more, they get less done.

What does this mean for my project ?
Referring back to the original question posed by our colleague and client, a handful of people have analyzed how multiple assignments to any one individual costs an initiative and how to reflect it in project scheduling. Among the most notable is Gerald Weinberg (“Jerry”). In his classic book, Quality Software Management: Systems Thinking, Jerry proposes a rule of thumb for accounting for the context switching costs of working on multiple projects. Jeff Atwood’s blog, Coding Horror, gives a good summary of Jerry’s rule of thumb, so I won’t try to recreate it here.

Aside: for what its worth (its worth a lot) Jerry also takes a very sober – and sometimes critical view of our profession, consulting, in this book.

Shoulders of giants, math for you
Building on Jerry’s rule of thumb and the research from Vanderbilt, we propose our own rule of thumb that affords project planners an equation to quantify what working on multiple projects does to a person’s productivity.

Baseline Productivity
First, we build on our experience and existing research on productivity as an expression of productive hours worked in a week.

1. The normal work week consists of 40 hours
2. The most productive companies/people in the world are 80% productive;
3. This is usually an outcome of life and the realities of a modern company: responding to e-mails, bathroom breaks, picking up the kids early from school, sending your rare burger back to the kitchen during a 2-hour lunch, doctor’s appointments — you get the idea
4. So, what we have in world-class organizations is 32 productive hours per week (40 hours * .80)
5. This productivity factor clearly will vary by the experience level of the professional involved
6. You should adjust this productivity factor to represent the reality of your organization

That being said, this is an important departure from Jerry’s baseline assumption of 100% productivity (ie, 40 hours worked = 40 hours productive).  Its also the basis for being able to construct a simple equation for modeling what happens to productivity as projects are added to a person’s plate.

Switching Costs & the productivity factor
If the most productive organizations and people in the world acheive 80% productivity on single projects, what happens when they begin to work on multiple projects? We propose and have observed  the following: if your team members can achieve X% productivity on any single project, the  cumulative effect of adding additional projects  can be represented as a product of the productivity of the total number of projects to which they are assigned. So if x = a person’s productivity percentage on any single project and n=the total number of projects to which they are assigned, their total productivity can be reprsented by X% raised to the power of n.

Using our example of an 80% productivity factor, the equation Xⁿ would yield the following chart of productive versus context switching time for 1 – 8 projects.

Looking at it a different way, with world-class, 80% productivity, the point at which a top-notch professional begins to spend more time context switching rather than being effective is at approximately 3 projects.

A Calculator
To calculate exactly how much productive versus context switching time occurs based on the total number of projects a person is assigned, use this calculator we created in Google Docs. Feel free to save your own excel copy (File > Export > .xls).  The key variables you can change are as follow:

1. Productivity factor (eg, 70%, 80%, 90%, etc)
2. The number of simultaneous projects to which a person is assigned.
3. he total work hours for an individual in a week (we recommend you be judicious about being overly optimistic of people being able to work more than 40 hours per week)

That’s it. Now, when negotiating with business stakeholders, hopefully, you’ll be able to more effectively demonstrate and account for the costs of assigning team members to multiple projects.

Technorati Tags: productivity factor, project management, estimation, context switching, switching gears factor, Jerry Weinberg, Gerald Weinber, multiple projects, multi-tasking, myth of multi-tasking

Software estimation continues to be a daunting process. Traditional plan driven approaches are being usurped by Agile-oriented methodologies. While the Agile Manifesto and Lean concepts are an important toolkit for the day-to-day management of a project, designed to help a team tune itself to its own capabilities and productivity over the life of the project, the application development estimation process still continues to be a dark art. Project Leadership must still answer to those more senior in the organization and those leaders must still answer to the market and investors. Often times, the question they ask is, ‘When will it be done?’ Ultimately, this becomes the seminal question for organizations eager to increase revenue through the marketing of new capabilities.

In this presentation, we’ve tried to provide some glue and distill some powerful concepts which can allow teams to rapidly enter negotiation with business customers regarding functionality, schedule, and cost. This seminar is focused on helping analysts, architects, and project managers become more confident using rapid and accurate estimation and planning skills. It serves to bridge the gap between Lean/Agile approaches and the more intensive forecasting needs of organizations of various sizes.

The presentation is presented below. For more info, or to see it live contact us.

The full seminar is focused on helping analysts, architects, and project managers become more confident using rapid and accurate estimation and planning skills. The seminar serves to bridge the gap between Lean/Agile approaches and the more intensive forecasting needs of organizations of various sizes. Participants will:

1. Understand the basic structure of a business requirement
2. Learn to listen for keywords in order to help organize the suite of requirements
3. Gain an appreciation for basic use cases and user stories
4. Obtain a basic overview for the use case point methodology for software
5. Appreciate how to frame scope negotiation on a feature-by-feature
6. Appreciate the power of architecture and design in work-planning
7. Appreciate the power of what-if scenarios for estimates

Technorati Tags: Software estimation, project estimation, Joint requirements planning, use cases, user stories, agile, use case points, objectory, Gustav Karner, Barry Boehm, feature-driven development, service oriented architecture, iterative development

Now, traditionally some candidates are stumped by this question until we ask them the question a different way – that is, “can you discuss for us the philosophy behind the project management triangle?” The fundamental concept is this: a project’s main adjustable dimension are: schedule, cost, and scope (we tend to think about scope as a function of features and quality). The basic point is that one can be given the option to control any two of these dimensions, but the third dimension must be adjustable. From this starting point an interviewer can establish an incredibly rich set of questions and follow-ups in order to ascertain the experience, analytical acumen, and negotiation skills of a potential candidate.

Generally speaking, this philosophy is a sound an important academic principle.
In practice, however, 9 times out of ten, the number one “immovable” dimension for most initiatives is “schedule” with “cost” following close behind. That being the case, this is one of the key reasons that we tend to favor the Agile approach which tends to emphasize the capability of the team (leading to the effective scope acheivable) in the context of time-bound development.

There is much hullabaloo about RoR being the best thing to hit software development since the compiler (for the techies, the pun was not intended, but I’ll take it). While it may be something less revolutionary than compiler innovation, one thing is for sure RoR is currently — and promises to continue being — a Disruptive Technology.

So, Why Rails ?

From our first hand experience, these are some reasons why Rails should or could be your platform of choice.

This post is decidedly one-sided, I’ll explore why *not* to choose Rails in my next post.

There are a number of assumptions behind the reasons I am about to enumerate for choosing RoR. While we’ll save the play book for setting up a project team for other posts, I will say that a major assumption here is the quality of your team. That established, if you do assume a strong team while using development framework ‘A’ versus development framework ‘B,’ the benefits of Rails are as follows:

$$$$$ -You get stuff sooner. Its that simple. As a stakeholder, I’ve seen Rails teams turn features around in ½ the time as it would have taken them to do it using J2EE or .NET (see this post for a little comparison on development speed)

$$$ -You get more stuff sooner. Not only do you get your agreed upon set of features faster, but also you can expect to get incremental improvements and non-trivial enhancements sooner than using other platforms.

$$$ -You get to see stuff sooner. The underlying technology allows development teams to show business stakeholders features and changes in a much more expedient fashion (literally while looking over the developer’s shoulder). This makes the requirement clarification and refinement process much more real-time and iterative (read: Agile Manifesto-friendly).

$$ -You get goodies that come along for the ride. Rails is chock full of helpful technology that allows you, the business stakeholder, to present web applications that have really rich user interfaces. You’re able to present these rich interfaces to your user community without having to ask your team to undertake science projects (read: expensive) to get the equivalent functionality on other frameworks.

$$$ -It plays nicely with others. REST (pun intended) assured, with Rails as your platform choice, you’re able to integrate with other technologies. Rails is not only open source, but it strives valiantly to facilitate integration with data and other applications. These features of the framework come out-of-the box and are native to the thinking behind the development of Rails.

$$$ -Its Open. Like JBoss (J2EE Container) Rails is an open source project which means you don’t have to pay a nickel to use it. It also runs on things you can get free; like Linux.

$$$ -There is a fever. Similar to the manner in which Java ascended as a choice of web and enterprise development, Rails has zealots. The community that has sprung up around Rails is breathtaking. While this is an unscientific statement, it does seem that we are seeing the type of fervor, support, and evangelism that benefited Linus Torvalds’ Linux; and we all know, how that turned out.

Next up – The case against Rails …

Technorati Tags: software economics, Ruby on Rails, RoR, Rails productivity, software development costs, time to market,

As we continue to work with our partners, competitors, and clients, I am continually stunned by how companies quantify the business value gained from application development and integration work they perform. Typically, its an after-the-fact analysis on profitability/revenue derived from a Line of Business and its applications. On the surface and at the gross level, this makes sense.

However, in our opinion, there is a more fine-grained and informed method for making decisions around what to build.
No organization is perfect — that’s for sure; including us [&& See below]. That being said, we are of the opinion that there is a better way for companies to decide where to spend their application development budgets in close partnership with IT. In many places this negotiation and collaboration between IT and business has been unnecessarily adversarial and characterized by mistrust born from past disappointments from both sides. Business sins include: Feature creep, ill-formed requirements, un-responsive stakeholders, constantly shifting priorities. IT sins include: cost overruns, 80 hour work-weeks, stop-start work efforts, no sense of accomplishment or finality. And its not just the project sponsor and development teams that deal with the fallout. Whether companies “fly the flag” and live by the agile manifesto or are more traditional in their processes, CSR teams, marketing teams, and other operational groups operating in fits-and-starts to support a technology deployment that is ‘a few weeks away’ are still common in the landscape.

This does not have to continue to be the case. There are no silver bullets for the werewolf because, frankly, that’s why consulting companies like ours exist. However, we do think there is a key to making this process more collaborative, informed, fast, and ultimately valuable to the business. Agile Methodology [INSERT APPROACH OF THE DAY] aside, companies still have to decide on what they want to spend time and money. And, the faster that business and IT can enter conversations about the cost and projected return of features that are going to be built the better. Okay, this sounds great, but how does one implement it?
Here is one recipe:

• Ingredient 1: Get high-level requirements quickly and efficiently — for the vast majority of application development efforts, you can and should be able get to a body of requirements that can be used for budgeting and ROI purposes in a few hours … Yes, really — in a handful of meetings and, ultimately, a few hours.

• Ingredient 2: Use a flexible and repeatable framework for estimation that allows you to model ‘what-if’ scenarios in collaboration with business stakeholders quickly and effectively. Moreover, use a framework that allows you to do this on a feature-by-feature basis. In our experience, this is crucial. Why? because Line of Business owners think about the work in terms of trade-offs and options that allow them to drive more money to the top and bottom line. Do these sound familiar: What if I add more people? I don’t really need that feature, what if we remove it? What if the team works 50 hours a week? What if I make that feature less complex?

[&& We were/are/will not be perfect. That's one of the reasons we developed a tool, Planix, to make Ingredient 2 easier to accomplish. This is a shameless self-promotion and yes, there is a free version]

• Ingredient 3: Encourage the business to provide the expected “X” — revenue, profit, widgets, karma points, clams, etc. — that is expected to be generated by the features estimated in (2). Encouragement is key, but at some point, the executives, IT, and the business must insist that projected X be rationalized and estimated in order to justify a capital budget to build the next shiny new application.

• Ingredient 4: Divide Ingredient 3 by Ingredient 2 to determine what your return is going to be from this application/IT investment

• Ingredient 5: Discuss, negotiate, repeat Ingredients 1 through 4 until you have a set of features that business and IT believe are important

Sounds like a lot doesn’t it? It can be a lot in terms of calendar time without the right sponsorship; that is for sure. For our part, we’ve seen the process take 3 months for a 2000 hour, 3 person, 50 feature effort. We’ve also seen it take 5 days for a 21,000 hour, 10-person, 600 feature effort and everything in between.

The important thing, in our opinion, is changing the dialogue … instead of only answering the question “what were the costs to build my application and what did my Line of Business bring in,”we should be collaborating on the question “what features bring the most business value; what will it cost me to gain this value?”

Technorati Tags: estimation, budgeting, ROI, project management, user stories, use cases, agile, ROI