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

Our client is a Fortune 200 company for who we began an enterprise initiative on May 30, 2007. Thanks to our tool Planix and our friends and their framework, 6th Sense Analytics, we’ve been capturing projected and actual effort on this project.

For the work (user stories) completed to date (8 weeks/40%) of the project, the actual productivity of Grails is outperforming our estimate for J2EE, Java/Spring, and, yes, Rails. Qualitatively, it can also be argued that we’re also performing integration in an Grails/Java environment that may pose challenges for a Rails/Ruby/Integrated environment.

As is the case with most of our clientele, we agree not to publicly disclose the specifics of who they are/the nature of their project. So, we will be a bit limited in the amount of context we can provide. However, this occasional series of posts is largely a quantitative examination, so we look forward to sharing with you the data from our findings as the project progresses.

Why Do this ?

There is a lot of ongoing debate regarding the “speed of development” in various technologies; we simply wanted to add some data to that conversation and elevate beyond a developer/team’s “gut feel” about why a particular technology is more productive.

Why Groovy/Grails ?

We began this project on May 30, 2007. Prior to its start, we proposed and obtained approval to utilize Groovy on Grails from the client’s Architecture Team. Our reason for championing the use of Grails arose from a handful of factors. Chief among these factors, in no particular order, were:

(a) Our company history and charter to continually examine promising emerging technologies for the benefit of our clients
(b) The potential level-of-effort productivity boosts promised by a couple of Grails prototypes we completed
(c) The flexibility of Java-based technologies in tackling what we thought would prove to be a relatively complex systems integration initiative
(d) Java-based/EE technologies are the client’s preferred platforms; their teams and processes are organized around Java. We needed a technology that could help maximize the value of existing application investments while offering RAD capabilities

Why Should I Believe your estimates for the Other Technologies?

This is a fair point, but we’re pretty confident that the estimates are faithful and accurate to the respective platforms. We estimated the effort using our estimation and planning tool, Planix (written in Rails). We’ve used this tool for 5 years in various forms and have lived by its accuracy. The tool does embody a fair bit of our own methdologies; however, if you’re looking for objectivity, you should know that many of its principles are adopted from the giant, Gustav Karner, of the objectory whose work is adapted from *the* giant in software economics, Barry Boehm. A quick Google search will turn up plenty of studies on the proven accuracy of the Karner Use Case Point approach for a project. What we’ve done throughout our history is to benchmark the productivity of a variety of technologies to give businesses trade-off options when it comes to cost and schedule.

What are the Takeaways ?

Grails is the latest in our effort to benchmark technologies and their respective productivity; to date, Grails is showing itself to be slightly more productive than using Rails – to the tune of about 5.8%. As others have observed, we do believe Grails to be a “formidable challenger” to Rails .. and we’re gathering data to back up our claim. Yes, premature precision will get us in trouble and the sample size is characterized by 1 project that is 40% complete, but … well, you get the picture.

Stay tuned for more productivity analysis as well as technical analysis on the resulting code base.

Technorati Tags: Rails, Ruby, Ruby on Rails, Grails, Groovy, Groovy on Grails, Grails Productivity, Rails Productivity, Software economics, Barry Boehm, Gustav Karner

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,

Obligatory Caveat: While we’ve not built the same application in a variety of langugages to assess the potential savings, we have normalized by analyzing applications of similar complexity with comparable team competencies (using Planix as our steward).

To cut to the chase, in general the economics and adaptability of a Rails-based application versus other applications look something like this –

A medium complexity application with approximately 20 medium-to-high complexity features (use cases or user stories)*

* We are speaking of applications where a ‘pure’ Rails approach is applicable; where other non-Ruby on Rails technologies are not required ro realize the solution.

Pretty impressive, eh? We believe so as well, but — again — just because you can develop faster, does not mean you should. In my next post, we’ll discuss more of the pros and cons of using RoR as your platform of choice.

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