Free Project Management Software

Though traditional project management and Scrum have long been viewed as antithetical ways of working, that’s not quite right. It would be more accurate to say that Scrum simply responds to and refines the shortcomings of traditional management practices. Still, as Scrum and other agile methods have continued to grow in the past few years, many PMPs have begun reassessing Scrum and agile to see what aspects of those methods it can utilize. On the PMI website, they’ve just run a short interview with an individual who straddles both worlds: Jimi Fosdick, who is both a PMP and a CST (certified Scrum trainer). According to him, it’s still possible for traditional project management and Scrum and agile to coexist. Still, he’s quick to point out that there are major challenges. Of those, he cites the following as the most irksome:

“Organizational Structure: Companies aren’t usually set up to handle the way the work is done in scrum and agile–and that’s a very difficult thing to change.

“Corporate Culture: Scrum is built on the principles of self-organization and self-management. So the development team doesn’t really have a boss or a manager telling them what to do. And that’s very scary for a lot of organizations. There’s a prevailing belief–left over from the scientific management of the 1950s and 1960s–that unless you’re watching what your people are doing, they won’t complete the task at hand.

“False Assumptions: Many of the policies and progress metrics in place in organizations and the artifacts and reporting required, are often counterproductive and run contrary to scrum. Some tasks–like needing sign-off on a full requirements document before development can start–interferes with the ability to do something in an agile way.”

You can read more here: http://blogs.pmi.org/blog/voices_on_project_management/2009/12/agile-apprehensions.html

If you’ve been following the Scrum community in recent months, you know that there have been some big changes—a few somewhat controversial ones among them—at the Scrum Alliance. After a short stint without leadership, it appears the organization has found a new director in Lowell Lindstrom. According to the Scrum Alliance, Lindstrom has been an active part of the software industry for more than 25 years, playing various roles in the production and deployment of software. Additionally, he is a Certified ScrumMaster, Practitioner, and Trainer.

Still, this isn’t a permanent solution and the Alliance is in the process of recruiting a full-time managing director to secede Lindstrom. Board member Steve Fram is leading that charge, conducting a nation-wide search for the suitable candidate.

I’ll continue to update you as more details emerge…

Most software developers are all too familiar with a scenario in which their Product Owner or Project Manager explains that all of the features to be built in a product are equally important. That is, the manager wants them all and he wants them now. Of course, such demands are rarely rooted in reality and typically reflect the pressure placed on a manager from stakeholders and customers, not the true expression of priorities for what is to be built. Not only does such a request place an unreasonable demand on development teams, but it also creates a long-term risk known as technical debt. That is, when software is developed hastily—without regard for maintaining clean, workable code—the team ends up delivering a product with code so buggy and erratic that maintaining or expanding it becomes a frustrating job that can only be performed by a handful of developers.

In a recent article on Agile Journal, Chris Sterling discusses a form of technical debt called software debt, which he defines by the following criteria:

· “Technical Debt: those things that you choose not to do now and will impede future development if left undone;

· “Quality Debt: diminishing ability to verify functional and technical quality of entire system;

· “Configuration Management Debt: integration and release management become more risky, complex, and error-prone;

· “Design Debt: cost of adding average sized features is increasing to more than writing from scratch; and

· “Platform Experience Debt: availability and cost of people to work on system features are becoming limited.”

As you can see, software debt entails many of the same risks as technical debt and results in the same obstructed path toward sustainably editable code. So what’s the answer? How can organizations take steps to limit the frequency and degree to which software debt impacts development projects? In his article, Sterling sketches out some guidelines that will help developers and managers skirt design death: “Emphasize quality,” “Evolve tools and infrastructure continually,” “Share knowledge across the organization,” and more. However, these recommendations, in my mind, seem too soft and fuzzily outlined to keep teams from caving to management pressure or cutting corners.

For my money, no other agile framework is as capable of minimizing technical and software debt as Scrum. Its iterative and incremental nature provides regular opportunities to halt work and evaluate the progress made for quality and market relevance. Similarly, the framework and its regular work cycles can be used to prevent this kind of debt from accruing by simply creating repeated Product Backlog Items that address issues related to code quality. There’s a big difference between functional code and code that has been scoured for bugs and prepared for a seamless hand-off to the next developer who works on it.

I had heard that the latest release of ScrumWorks was being billed as the first enterprise-capable Scrum tool. (Since I’m unaware of any agile tool that can successfully scale without several modifications, it’s really the first enterprise-capable agile tool.) So I decided to watch a screencast to learn more. Now that I’ve seen what’s new in ScrumWorks Pro 4, I can say that it’s evident Danube is paying close attention to user feedback and working hard to resolve the impediments that have historically kept enterprises from successfully scaling.

One of the most important aspects of this release is “Epics,” which give users a powerful combination of deep functionality and tremendous flexibility that allows them to model shared components accurately, rather than conform to the limitations or idiosyncrasies of a tool. More specifically, the “Epics” feature gives organizations a way to pull back even farther and assess progress across multiple products and programs. Best of all, Danube achieved this functionality while remaining closely aligned to Scrum’s core principles. In fact, ScrumWorks Pro 4 and the “Epics” feature, in particular, were based on Scrum founder Ken Schwaber’s most recent book, The Enterprise and Scrum. If you think your development environment could benefit from such smart functionality, I highly recommend you take a look at this tool. You can read more about it here.

I always love posts like this one on InfoQ. Vikas Hazrati has collected various lists of agile practitioners’ favorite books on the topic. For anyone wanting a quick guide to learn more about agile development, this is an excellent start. Even if you’ve been practicing agile for a while, you might encounter a book you haven’t read yet. Personally, I was a big fan of Tom DeMarco’s Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, so I was glad to be reminded that I should get my hands on a copy of DeMarco and Timothy Lister’s Waltzing with Bears: Managing Risk on Software Projects…

As many of you know, velocity is a valuable agile metric that allows teams to gauge how much work they can accomplish in a single cadence. Since agile asks that teams estimate the effort required to complete a story rather than the time it will take, teams assign effort estimates to stories, i.e. abstracted valuations which can be expressed as t-shirt sizes, “headaches,” or any other measure agreed upon by the time.

Over at InfoQ, Chris Sims reports on the notion of “good velocity,” inspired by a question Buddha Buck posed to the XP list serve: For a team of about seven, doing two-week sprints, what range of velocity would be considered ‘good’? Amazingly, Buck identifies a ‘bad’ range, explaining that a velocity of eight or less probably means a team isn’t breaking its stories down into small enough chunks.

Now, if a team’s velocity is determined by estimations, using a scale agreed upon by the team doing the estimating, how can an outsider evaluate if the team’s velocity is “good” or “bad”? Certainly, if a team’s velocity increases over time, demonstrating ongoing performance improvements, that’s good. If a team simply gets worse at working together over time, reflected in a waning velocity, then that would be clearly bad. But the notion of a standard or an acceptable range is ludicrous. Velocity is useful for the teams estimating their work—they understand what a “Small” story looks like versus an “Extra-large” one. And depending on how they choose to estimate their stories, a velocity of eight might actually be a hyper-performing team.

So, to summarize, what’s actually important with velocity is whether a team’s velocity increases or decreases. There’s no standard for performance, since there’s no standard of measurement. But a team that does more every sprint should certainly be considered to be within a “good” velocity range.

It seems that agile and Scrum are just continuing to gain popularity and visibility. Now, Inc. Magazine has a success story on how one company’s agile transformation has them behaving more like a start-up, i.e. using small teams to work more collaboratively and responding more nimbly to emerging developments. According to the article, as Chicago-based Total Attorneys grew from a start-up of four to a company of more than 100, the maker of CRM software for law firms decided to implement a more formalized development strategy. They turned to waterfall. But soon, they realized that the development process had become so fragmented that coders handling different aspects of development (i.e. design versus testing) never saw one another and morale started tanking. Also, CEO Ed Scanlan explained, “We had more than a hundred employees, but we were getting a lot less done than when it was just me and three other people.”

Scanlan’s reaction was to implement agile management practices. He divided his employees into small groups of roughly five or six people per team; re-imagined the floor plan so that all employees sat together for convenient collaboration; and mandated a daily Scrum meeting, when team members can report to one another. Because the team harnessed agile’s iterative and incremental approach to development, it was, significantly, able to shorten deadlines and deliver software more rapidly.

While I like to see case studies of how companies have used agile techniques to improve their own processes, there are a number of sticking points in this story. Namely, it sounds like Total Attorneys have applied a “Frankenstein” approach to agile—they’ve pulled their favorite bits from a number of frameworks and methods and built a monster out of them. Granted, this is a populist publication that is effectively introducing readers to the concept of agile project management, so we can’t realistically expect the reporter to engage the nuances of agile the way we would here on this blog, where we’re all well-versed in Scrum, XP, and so on.

How does this article strike you? Is it another victory for agile in the media? Or is it represented in a harmful way?

Agile 2009 is getting closer and closer. I’ll be there, but if you’re still on the fence about whether you’d like to go, this may change your mind: The entire program schedule is now live on the site.

Stretched over five days, this conference is an incredibly valuable opportunity to hear some big ideas from some of the biggest names in the industry. Taking a look at the program, there’s so much good stuff, it’s almost a little overwhelming. I’ve mentioned before that I’m excited to learn more about agile metrics, so my number one, can’t-miss session of the week is Dan Rawsthorne’s presentation on the topic on Wednesday.

If you’ve ever managed a complex project, you know that the key to success is communication. When a team is connected through frequent communication—and the powerful collaboration it enables—all of its members are in sync with progress, updates, and impediments. However, in today’s fast-paced business world, it is increasingly common for team members, especially in software development, to be geographically distributed. Building software is an inherently chaotic undertaking. Without a collocated team, keeping that chaos in check can be nearly impossible.

One way to help distributed teams remain connected and navigate the chaos of development is through agile project management software. An agile tooling solution can help team members compensate for distance by creating a virtual team room, where status and impediments updates are broadcast to the entire team in real time. An agile tooling solution can offer the additional benefit of reinforcing agile values and existing practices.

My team practices Scrum and uses a free agile tool called ScrumWorks Basic, which is published by Danube Technologies. Apart from the obvious value of it being offered as freeware, my team appreciates how well it supports the Scrum values and processes we live each day at the office. Although the tool does not contain the same functionality found in the commercial version, ScrumWorks Pro, it has all the basic functionality to begin managing projects with Scrum.

If you’d like to learn more about its features or download your own free, 20-year license, head here: http://www.danube.com/scrumworks/basic

Okay, readers, here’s where you come in. Do you use free software to manage your projects? If you do, let me know tool you use and what you think.

One of the most important aspects of agile project management is the ability for teams to self-organize. But as Damon Poole writes in this post (http://agile.dzone.com/articles/the-use-self-managing-teams-ou), understanding exactly what that means can be a little difficult to say. Poole is committed to digging up some answers and to do so, he’s looking outside of agile and will report back with future posts on this topic.

From my own experience working in agile environments, the concept of self-organization has always been pretty clear (and its benefits have been just as clear). Because most agile frameworks or methodologies divide responsibilities through well-defined roles, there has never been any confusion. That is, the team is responsible for completing the work it agrees to in a given iteration and, therefore, must work together to determine how it will be completed. Poole wonders if this means that individual team members decide what tasks to tackle in addition to how and when. I think that self-organization entails all of those decisions. However, it’s important to point out that these decisions aren’t made independently by individual members of the team. It’s the team that self-organizes. Thus each member weighs in and, collectively, a consensus is reached. The benefits of this approach are obvious. It allows the team to take on more ownership of the work, thereby increasing their investment in its success. Managers, on the other hand, are relieved of their “babysitting” duties. Instead, they can focus on big picture concerns, such as release planning and prioritizing outstanding work.

How would you expand this definition of “self-organization”? Do you think Poole is making it more complicated than it really is or is he on to something? And do any of you have experience with self-organization outside of a dev team?