The Agile Executive

Making Agile Work

Archive for the ‘Agile Tools’ Category

Apropos is Going Places

with one comment

Pictured above is a screen shot from the forthcoming Rally implementation of Apropos – the end-to-end Kanban system unveiled by Erik Huddleston, Stephen Chin, Walter Bodwell and me in the Lean Software and Systems conference last April.

Pictured below is Stephen Chin presenting the forthcoming product in the recent JavaOne conference:

The commercial version by Rally builds on the four pillars of the original implementation of Apropos at Inovis and the subsequent open source version:

  • Stakeholder Based Investment Themes
  • Business Case Management
  • Upstream and Downstream WIP Limits
  • Dynamic Allocations

These four pillars enable Apropos users to dynamically adjust their plans as needed in accord with the realities of end-to-end execution. Agile portfolio planning and actual execution truly run alongside each other as depicted in the following figure:

Adjustments to allocations can take place in either in the plan or in execution. Here are two typical examples of stakeholders’ dialogs:

  • In planning: “In response to the quick growth of the sales funnel, we decide to increase the % of time allotted to tactical sales opportunities from 35% of the total R&D budget to 40%.”
  • In execution: “The introduction of product Pj will be delayed by three months due to lack of qualified professional services resources. During this period, the affected R&D resources will be reassigned to help with multi-tenant aspects of a SaaS version of product Pk.”

Recommendations: Consider using the open source version of Apropos for a small-scale pilot as part of your 2011 planning/budget cycle. If the pilot proves a good fit with your needs,  switch over to the commercial version in the 2012 planning/budget cycle.

____________________________________________________________________________________________________

Considering end-to-end Agile/Kanban roll-out? Let me know if you would like assistance in planning and implementing a roll-out which focuses on continuous value delivery. Click Services for details.

____________________________________________________________________________________________________

Making code reviews not suck

leave a comment »

Not all Agile teams practice strong code reviews, but one of the original Agile practices (sort of long forgotten, it seems) of paired programming was all about code review. As such, I thought I’d cross-post these two videos going over what one RedMonk client, SmartBear, does to help make code reviews suck less. –Coté

Yesterday SmartBear released version 6.0 of CodeCollaborator, the popular code reviewing tool. They’ve added in numerous features, of course, with highlights like handling asset as an item to review (like a Word doc), enhancements to the Eclipse plugin, and integration with VisualStudio. Check out the 6.0 feature list for more details.

I discussed the new features with them in the below interview and then got a quick demo:

New features interview

You can download the video directly as well.

Also, a full transcript of the video:

Michael Coté: Well, hello everybody! Here we are in lovely Austin, Texas, at what we have dubbed the SmartBear studio. This is Michael Coté, of course, of RedMonk. And today I am joined by a guest to go over a new release that SmartBear has out. You want to introduce yourself?

Gregg Sporar: Thank you, Michael. Yes, my name is Gregg Sporar. I have a face made for radio, but yet we are going to record this on video.

Actually, that was the great thing about doing the podcast, because it’s a podcast and it’s just my voice.

Michael Coté:[the podcast] on code reviewing.

Gregg Sporar: But then, you took this giant picture of me and put that on the blog, and I am thinking, dude, more of a Gravatar. We don’t need — here, we are. We are talking about Code Collaborator v6.0.

Michael Coté: That’s right. Just to give us like a really quick introduction, like what does CodeCollaborator do for people who don’t know off the top of their head?

Gregg Sporar: CodeCollaborator’s sole goal in life is to automate the grunt work parts of the peer code review process. So the collecting of the files and making them available on a central location. Coordinating the communication between the review participants and tracking what everybody says and where defects are found and that kind of thing, and then reporting the statistics at the end.

Michael Coté: What release number is this one?

Gregg Sporar: We are talking about version 6.0.

Michael Coté: So in 6.0, so tell us what the new features are? What’s going to get people excited about this release?

Gregg Sporar: There are several things. Let’s back up for just a second to version 5.0 last year, when we added support for reviewing materials other than just source files. The reason for that was, because a lot of our customers, you are dealing with a software development team, but there are other people on the periphery as well, that might want to be involved in the review. If you’re building embedded software, it might be that the firmware guys or the hardware design guy, he wants to be involved and he wants to see his schematic in that.

Michael Coté: Right.

Gregg Sporar: Then we also had just regular software development teams coming to us saying, well, this is great, but I would like to add the design document to the review and look at it and reference it from within the same tool.

So last year we added support for PDF files, for example, and for image files, for JPEGs, and PNGs, and GIFs, and that kind of thing.

Michael Coté: And that allows you to add in all the commentary and the usual meta information on a piece of code?

Gregg Sporar: Exactly! So whenever I would show the PDF feature to people, they would say, well, that’s great, but I would really like to do this with a Word document.

Michael Cote:: Sure.

Gregg Sporar: So there is a plug-in that Microsoft makes available to create a PDF off of a Word document, but people don’t want to do that. They just want to take their document and put it in place. So that’s one of the key features in 6.0.

The way we actually implemented that is kind of interesting. We built a Windows printer driver, because, again, at the end of the day, we just need to be able to render something and paginate it and put it into the tool. The best way to do that really in that environment is a printer driver. So it’s not just Word, it’s not just Microsoft Office apps, it’s any Windows app that can render paginated output.

Other major features. A significant enhancement to our Eclipse plug-in, which we have had for a few years now. In the past it was limited to just being able to show you or actually just being able to create a review or add materials to a review, and now we have actually brought the entire review experience directly into the IDE.

Another thing that we have gotten a lot of request for is for Visual Studio. Not everybody uses Eclipse, believe it or not. So what we have done is just sort of an initial entrée into the Visual Studio world, we have essentially got functionality equivalent to what we had in our old Eclipse plug-in.

So again, I don’t have that ability to bring the review experience in, like I have done now and with the guys that built for our Eclipse plug-in, but it’s a start. It gets you partway there.

Again, to let you stay within your working context, to at least be able to create the review or add materials to that.

Then there are what I call Red Meat features. Not RedMonk, Red Meat. This is the real type stuff, because these are features that you don’t have to be an Eclipse user or Visual Studio user, this is something that’s going to affect everybody.

This is, for example, one of the things that a lot of people have asked for, for a long time, the ability to delete a comment after you put it in to the tool. We are not actually going to allow you to delete, we are going to allow you to redact the comment.

Michael Cote:: Right.

Gregg Sporar: I will show that to you during the demo. The reason for that is, we can’t really completely remove it, because it would break the IM type paradigm for our real-time track capability. I mean, think about it, if you were IMing with somebody —

Michael Cote:: And it just disappeared.

Gregg Sporar: And it just disappeared while you were reading it, that would kind of freak you out. That breaks that paradigm.

Michael Cote:: It’s kind of like that email recall feature, which is a little strange in its own right.

Gregg Sporar: Which is a little strange in its own right. Then the other issue of course is, we have a lot of customers who, auditability, traceability, that kind of thing, is really important. Nothing can ever be deleted.

Michael Coté: Sure.

Gregg Sporar: So we are going to allow you to redact a comment. We have changed the way that we display defects within the file comparison window. We have added, again, some of these usability type features that affect everybody.

We have made some enhancements to our ClearCase Integration. We have also put in some pretty important enhancements to our integration at the other end of the spectrum to Git and Mercurial.

Michael Coté: And how many version control systems do you guys work with now?

Gregg Sporar: 16.

Michael Coté: 16? That’s pretty nice.

Gregg Sporar: That’s a rather large number.

Michael Coté: That’s probably more than most people could name off.

Gregg Sporar: So a fun drinking game is to get a couple of beers in me and then try to get me to list the 16 in reverse alphabetical order, because I can do it in alphabetical order, but reverse alphabetical order is a little more difficult.

One last [thing], maybe, to mention really quickly. We did, and this is again something that you can’t appreciate unless you are an existing user of the product, we have significantly enhanced some of our reporting capabilities. That’s kind of that third pillar of what it is we do.

For the customizable reports, where the user can build their own query, we have added some additional fields that they can now filter on and select and that kind of thing.

Then we put a lot of effort into adding what we call user-oriented reports. So we have always had review-oriented reports and defect-oriented reports, that again, primary key is information about the review overall or primary key is, tell me about the defects that were found, but now we have added a third category, which is, tell me what I have been doing.

Michael Coté: I always think of that as self-micromanagement. Sort of optimize your own self.

Gregg Sporar: So one of the features, it is the ability for me to come in after the fact into the tool and find out, well, what reviews did I work on during the last week? I had a guy at a customer site explain to me this feature, because when he is doing his weekly status report, he knows he typically spends about 10-20% of his time during a week doing code review. Well, he wants to know, what reviews he did.

Michael Coté: Yeah.

Gregg Sporar: So again, user-oriented reporting.

Michael Coté: Well, great! Well, let’s check out a demo of those features and see what we get to see.

Demo

You can download the video directly as well.

There’s also a nice wrap-up of posts detailing features on the Smartbear blog.

Written by Coté

September 15, 2010 at 8:56 am

This is Not a “Me Too” Product

leave a comment »

I had the distinct pleasure to discuss AgileEVM over dinner yesterday with its two “fathers” – Chris Sterling and Brent Barton. I was much impressed by the originality of the concept, the clear differentiation of the product and the laser focus on Earned Value Management (EVM) aspects.

Governance of the software development process is a topic that has been much discussed in various Cutter publications – see for example recent Cutter blog posts by Stephen AndrioleRobert Charette, Jim Highsmith, Vince Kellen, Masa Maeda, Michael Mah and me. Chris and Brent add a layer of EVM – both in terms of theoretical foundations and actual tool – to our spectrum of thoughts on governance. IMHO AgileEVM has the potential to induce a disruption in the way companies go about the business of governing software.

AgileEVM is particularly intriguing as a {product + professional services} combo. Chris and Brent are well-known as awesome Agile consultants. The opportunity to pick their brains twice – once through the product, a second time through a related consulting engagement with them – is most attractive.

The two “pages” below give a sense of the power of the product. Even better, simply download the product through the AgileEVM website.

Grab Chris or Brent for a 1-1 demo if you are at Agile 2010 this week. You will not be disappointed…

Using 3σ Control Limits in Software Engineering

with 2 comments



Source: Wikipedia; Control Chart

The  July/August 2010 issue of IEEE Software features an article entitled “Monitoring Software Quality Evolution for Defects” by Hongyu Zhang and Sunghun Kim. The article is of interest to the software developer/tester/manager in quite a few ways. In particular, the authors report on their successful use of 3σ control limits in c-charts used to plot defects in software projects.

To put things in perspective, consider my recent assessment of the results accomplished by Quick Solutions (QSI) in two of their projects:

One to one-and-a-half standard deviation better than the mean might not seem like much to six-sigma black belts. However, in the context of typical results we see in the software industry the QSI results are outstanding.  I have not done the exact math whether those results are superior to 95%, 97% or 98% of software projects in Michael Mah‘s QSMA database as the very exact figure almost does not matter when you achieve this level of excellence.

A complementary perspective is provided by Capers Jones in Estimating Software Costs: Bringing Realism to Estimating:

Another way of looking at six-sigma in a software context would be to achieve a defect-removal efficiency level of about 99.9999 percent. Since the average defect-removal efficiency level in the United States is only about 85 percent, and less than one project in 1000 has ever topped 98 percent,  it can be seen that actual six-sigma results are beyond the current state of the art.

The setting of control limits is, of course, quite a different thing from the actual defect-removal efficiency numbers reported by Jones for the US and the very low number of defects reported by Mah for QSI. Having said that, driving a continuous improvement process through using 3σ control limits is the best recipe toward eventually reaching six-sigma results. For example, one could drive the development process by using Cyclomatic complexity per Java class as the quality characteristic in the figure at the top of this post. In this figure, a Cyclomatic complexity reading higher than 10.860 (the Upper Control Limit) will indicate a need to “stop the line” and attend to reducing complexity before resuming work on functions and features.

Coming on the heels of the impressive results reported by David Joyce on the use of statistical process control (SPC) techniques by the BBC, the article by Zhang and Kim is another encouraging report on the successful application of manufacturing techniques to software (and to knowledge work in general). I am not at liberty to quote from this just published IEEE article, but here is the abstract:

Quality control charts, especially c-charts, can help monitor software quality evolution for defects over time. c-charts of the Eclipse and Gnome systems showed that for systems experiencing active maintenance and updates, quality evolution is complicated and dynamic. The authors identify six quality evolution patterns and describe their implications. Quality assurance teams can use c-charts and patterns to monitor quality evolution and prioritize their efforts.

Apropos has been Open Sourced

leave a comment »

Erik HuddlestonWalter BodwellStephen Chin and I unveiled Apropos – the Agile Project Portfolio Scheduler – a month ago in the LSSC10 conference in Atlanta, GA. The system is now available as open source. Click here to go to the home page of the project and download the software. It will enable you to:

  • Synergies R&D with downstream organizations such as Operations, Professional Services, and Sales
  • Increase delivery value through organization-wide alignment of priorities
  • Achieve continuous improvement by whole process feedback loops
  • Gain realtime visibility into delivery status and potential blockages

The core concept of Apropos – multiple parallel feedback loops – is  demonstrated by the following process control diagram:

Figure 1: Process Control View of Apropos

Enjoy Apropos, benefit from it and please give us feedback!

How to Initiate a DevOps Project

with 4 comments

17th/21st Lancers c. 1922-1929 "THE FIGHTING SPIRIT!" by sunnybrook100 - One Million Views!.

Source: 17th/21st Lancers c. 1922-1929 “THE FIGHTING SPIRIT!”

Agile consultants on a development project often start by helping the team construct a backlog. The task is sufficiently concrete to get all stakeholders (product management, project management, development, test, any others) on a collaborative track through the creation of a key artifact. The backlog establishes a base line for the tasks to be carried out in the project.

For a DevOps project, start by establishing the technical debt of the software to be released to operations. By so doing you build the foundations for collaboration between development and operations through shared data. In the DevOps context, the technical debt data form the basis for the creation and grooming of  a unified backlog which includes various user stories from operations.

Apply the same approach when you are fortunate to be able to include folks from operations in the Agile team from the very beginning. You start with zero technical debt, but you track it on an ongoing basis and include the corresponding “fix-it” stories in the backlog as you accrue the debt. Running technical debt analytics on the source code every two weeks is a good practice to follow.

As the head of development, you might not be comfortable sharing technical debt data. This being the case, you are not ready for DevOps.

How to Construct a Great Information Radiator

with one comment

The information radiator above is used by Panic, a Portland, OR software company. It shows the following items:

  • E-Mail Queue — number of messages / number of days.
  • Project Status — sorry for the heavy censorship — you know how it is!
  • Important Countdowns
  • Revenue — comparing yesterday to the day before, not so insightful (yet).
  • Live Tri-Met Bus Arrivals — when it’s time to go home!
  • The Panic Calendar
  • Employee Twitter Messages
  • Any @Panic Twitter Messages — i.e., be nice! They go on our screen!

Click here for detailed description, including an easy to follow “Implementation Notes” section. The writer provides the following perspective on the effort to construct the board:

From start to finish, this was about a three-week project.

And no, it didn’t slow down development on [insert the app you want the most here]. Check the board!

Written by israelgat

March 15, 2010 at 5:00 am

Posted in Agile Tools, How-to

Tagged with ,

Technical Debt on Your Balance Sheet

with 17 comments

Colleague Jonathon Golden introduced me to a new plug in to Sonar. The plug in calculates the cost to fix the technical debt accrued in a product. For example, you might find an accrued technical debt amounting to $1M in a 500KLOC application. Obviously, you will need to spend $2 per each line of code to “pay back” your debt.

The expression of technical debt in monetary terms is intriguing. Unlike financial debt, there is no credit limit on technical debt. Hence, unless a team is proficient at refactoring on an ongoing basis, technical debt tends to grow over time as the underlying software decays. Beyond a certain level of debt, no good option is available. The code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else. Under such circumstances, most/all of the development team gets sucked into maintaining the software instead of developing new features and functions.

Monetizing technical debt can have two far reaching implications, as follows:

  • A credit limit on technical debt can be established.  For example, when the technical debt reaches a certain level (say 25 cents per line of code), new functionality is put on hold. The team applies itself to aggressive refactoring to reduce the debt to an acceptable level.
  • For companies who capitalize software, technical debt could become a line item on the balance sheet. It will simply be listed as a liability.

From a customer perspective, the monetized technical debt on the balance sheet of a software vendor is a proxy for the technical risk involved in licensing software from this vendor. Such monetization could be easily extended to report technical debt per product family. With such reporting in place, the technical risk associated with licensing a specific product can be assessed.

Software vendors might frown at the requirement to monetize technical debt. I would contend that such a reporting requirement is absolutely consistent with the spirit of the Agile Manifesto:

Customer collaboration over contract negotiations

In other words, if you are reluctant to list your monetized technical debt you can’t really claim you practice Agile.

Written by israelgat

September 29, 2009 at 8:18 pm

A Note on “The Tool is the Method”

with one comment

The post The Tool is the Method generated a lively discussion. Whether you agree or disagree with the post, you are likely to find the experience reported by Rod McLaren in Jira, Greenhopper, Lighthouse: tools vs practice in Scrum of interest. Here is an excerpt from Rod’s post:

Our biggest problem with Jira/Greenhopper was that it isn’t as well-aligned to our developing practice of scrum as we needed it to be. The tool got in the way of our learning the practice, and started behaviourally skewing our view of scrum (‘The chosen tool becomes a factor of the first order in determining not “only” how Agile (or any other software method) will be practiced, but what mindset will evolve in the course of the rollout’). We were trying to fit scrum to the tool we had, and were talking more about how to use the tool well than we were about whether the sprint was going well.

I don’t know that the debate tool v. method could or should be resolved here. Absent resolution, the perspective on the subject Annie Shum expressed in Tools, Behavior, Culture is quite a good one to keep in mind:

In thinking about tools in the context of impacting large scale cultural changes, one can’t help but immediately think about the computer/digital computing.  By all definitions, a computer is a tool – in fact, I would venture to characterize a computer as a “universal tool” that can, in theory, perform almost any task.  Moreover, I can’t think of any other tool that can surpass the computer and digital computing as the most disruptive transformation agents of our society and cultural shifts in the 21st Century.

Written by israelgat

August 5, 2009 at 6:55 pm