Tag Archives: agile

Uncategorized

Project Management Tools Review

Introduction (or, what is it all about?)

I’ve been trying to figure out a good solution for the project management needs I’m facing.  There are literally hundreds of tools intended to help developers make better software, and dozens of methods and philosophies (where only a few really prevail in the mainstream).  My team leans agile, but we need some better tools to manage ourselves.  I’ve been re-reading a lot of stuff on agile methodology and spending some time thinking through the current state of our discipline (as it applies to our team in particular).

Questions I’ve been pondering are:

  • What are we doing now?  I mean everything, not just what works or what doesn’t.  What is the total sum of how we practice software development?
  • What things should we stop doing?
  • What things should we start doing?

One of the things I came across in my reading is The Future of Agile Software Development.  Dubakov makes some interesting points and I’m not sure I necessarily agree with all of it (there is some good back-and-forth in the comments section), but I think his thinking about the focus points of good software development are reflective of the collective wisdom that inform the current state of the art in software development: do right things, do them right, and do them  fast.  I think this is the goal of modern Agile methodologies, and I’m a bit more optimistic than Dubakov that they can help us get there.  However, his outlook is a good reminder that part of the Agile philosophy is to have the self-awareness to back off and refocus on the core goals (do right things right and fast).

Software Development Focal Point (original content at targetprocess.com)

 

As I think about that focal point, I also reconsider the various stakeholders and their perspectives.

Developers as craftsmen

We take satisfaction in our work for its own sake because that’s how we’re wired.  We’re makers.  What really makes for a good weekend is to know that the last 5 days were spent making something, and that it was good.  We are made in the image of God by God, who delights in his own handiwork.  He graciously gave us the same attribute, and it manifests itself in a spectacular kaleidoscope of human talents and creative works.  His desire is that we delight in him while experiencing joy in our derivative creations.  This delight is made possible by Jesus Christ, who in his death absorbed the wrath of God over the corruption of the world (and proved it in his resurrection), and by faith we are enabled to delight in him in this way, to his own glory.  By his grace, those who don’t believe these things still take pleasure in their work, even if there’s no particular spiritual meaning  in it for them.  That’s why Monday is my favorite day of the week, not the reverse: I come to work with anticipation of the joy to be had in doing good work.

As developers, we want to make perfect software.  We want it to be bug-free.  We want the code to be elegant, flexible, loosely coupled, well-documented, clever, consistent.  We want it to be optimally efficient in time and memory (“performant” is not a word, and even if it were, it’s a horrible, imprecise word).

We also want to work in smoothly operating teams.  We don’t want there to be discord over minor issues.  We want to be managed well (and my definition of “good management” whether by a team lead like myself or by a project manager or whomever is “makes our jobs easier”).  We want to have a sense of purpose, and we want to feel organized.  We want to receive confirmation when our work is good, and when it’s not, we want to know how, why, and the best way to fix it.  We want to be continuously growing in our skills, both in depth and breadth.

Clients

For the purpose of this thought process, I consider “client” to mean “the one paying to have the project done”.  The one who has been persuaded of the strategic value — great or small — of the project.  They are running a business.  Perhaps a large business, or even multiple businesses.  If the company is large enough, it may be multiple businesses under a single corporate umbrella.  Whatever the particular structure of the “business”, someone decided that the project was worth doing.  But why?

They think that ultimately, the sum total value of the project (it’s activities, processes, and deliverables) are worth more to the business than if the project was not executed.  Much of the time, this is a simple calculation: how much money do they have to spend, what’s the business need, and what are the various options for satisfying it?  We would do well to always be mindful that our project wasn’t the only option.

Business owners

I think of clients and “business owners” separately, although in some cases they may be the exact same individual or individuals.  Either way, there is overlap in these two perspectives.  The business owner is something of a corollary to the developers.  They want the project to succeed, but they want it to succeed on their terms.  Business owners are the most impacted by the problem at hand, and have the clearest ideas about what the solution should look like.  They aren’t (usually) particularly technical, and a lot of the time don’t really have any sense of the possibilities, but they know what they want their daily work to look like and produce.  The point of the project is to make manifest the most important demands of that vision within the resource constraints of the client.  That is value.

Software firm management

Lastly, there is the management of the firm responsible for executing the project.  Their goal is mirror to the goal of the client: provide a solution to the problem at an even lower cost than demanded by the clients resource constraints.  Much of the responsibility for planning a successful project falls here.  Up front, the management has to decide whether a potential project is worth doing.  There are all kinds of considerations that go into that.  Part of it is evaluating the client to understand if he has the resources to commit, if he can describe his problem well, or if he even understands his own problem.  Management has to keep a close eye on the cost of the value provided to the client, and forecast somehow whether or not enough value can be provided at a low enough cost to both keep the client happy and make a profit.

What do we need from our tools?

This leaves us with some complex needs and desires.  The stakeholders have competing visions.  Sometimes we even have directly competing visions.  Developers, if asked when something will be done, would often prefer to retort, “when it’s done.”  Obviously, this won’t do.  But we still need to get it done and do our best to satisfy all four of the visions simultaneously.

The tools have a tall order to fill, to be sure.  In order to even begin to understand what we need from the tools, we’ve got to regurgitate these visions into some concrete features (hey….kinda sounds like what we do for a living!).  Let’s just break it down vision-by-vision (and some features will be common to more than one vision).

At a high level, the developer vision is best supported by an agile methodology (no surprise there, because the agile philosophy was formed by developers).  It isn’t perfect, but it’s the best we’ve come up with so far.  So what does that mean for our tool(s)?

  • We need the tool to help us capture the needs of the business owner.  Right?  We want to do the right things.  The business owner is the one that has to tell us what those things are.  The predominant agile methodologies refer to these as “user stories”, or perhaps “features”.
  • We need the tool to help us know what we’re working on right now.  Agile development is iterative.  The short work cycles that actually produce value are called iterations, sprints, or what have you, but we have to be able to break the work into manageable chunks, and put a date on it.
    • Part of the what is knowing which user stories we’re working on right now.
    • Another part of the what is understanding what each user story entails; understanding to some degree the complexity involved.
  • We need to know when we’re supposed to finish what we’re currently doing.  Developers make choices moment-by-moment about what to do or not do, and we need to have a finish line so we can make choices that are in the best interests of the project.  This allows us to make predictions — however imprecise or inaccurate — about what can be done in the given time (otherwise known as “estimates”).
  • We need the abstract artifacts of the project, like user stories, estimates, and deadlines to be linked with the actual work product (i.e., code) so that everyone has accurate insight into the state of the project at any point in time.  This linking needs to be as automated as possible, because the more friction there is in putting data into the tool, the less good data you’re going to get.  You can take that to the bank: if developers get frustrated with the tedium of the tools, you’re going to find that we will consciously or unconsciously avoid working with the tools.  That is bad for everyone.  The lower friction there is (and automation means essentially zero friction), the better.
    • Code really should be linked through the SCM tool, so when changes are committed, developers can enter in annotations that link the code with the project management artifacts as a part of their normal workflow.
    • I’ll get to “release management” in the next bullet, but it’s worth mentioning that unit testing is really important, and the tools should support them in whatever ways possible.  Test results should automatically result in bug reports to the tool, for example.  Test results should be reportable in the tool as a way to demonstrate progress or problem areas.

The client perspective has exactly one question that must be answered: “Am I getting enough for what I’m paying?”  For the client, the whole enchilada is the value proposition.  The tool must expose the value of the project.  To that end:

  • The tool has to allow the client to see what’s been done, and how much time and money was spent to achieve it.
    • The tool has to facilitate the collection of metrics that matter (lines of code are not one of them!).  Hours are a critical metric, but you’ve got to also be able to slice up hours into buckets of time the correspond to the bits of work that were done (completed, or partially completed user stories).
    • The tool has to give you a way to record the complexity of a user story.  This can be a non-hours measurement; in fact, it’s probably best if it’s not.
  • The tool has to give the client some insight (or help us to give the client the required insight) into what’s left, and how much time and money it will take to achieve it.
    • This needs to be done, to the extent possible, using measures that the client will understand.  Hours of labor and a billing rate are a universal metric for every client.  The tool needs to help us help the client make informed decisions about what things will cost in these terms so that various scenarios can be considered.  The best way to do this is to succeed at #1 just above.  A correct interpretation of  past data is the best insight into future value propositions.

Ever project has overruns, mistakes, and failures along the way.  Some worse than others, but no project goes perfectly according to plan (if it did, you wouldn’t be in software, you’d be in manufacturing).  When those things occur, the second bullet above becomes incredibly important.  It’s all that matters to the client.

The business owner needs the tool to help them articulate their vision for the solution.

  • BOs need the tool to help them capture user stories.
  • BOs need user stories to be coherent, and to have context that helps both us and them understand their interrelated-ness
  • BOs (and clients) need the tool to help them priorities the stories so that correct decisions can be made jointly with the client about what features or stories will provide the most value to the business.  This is satisfied by good sprint planning features.  There has to be an easy way to understand quickly what parts of the BOs vision are done, can be done, can be tested, should be done, etc.  This is similar to the second client bullet, but with a different emphasis.  This is also thought of as backlog management.  A sort of story card board is what most agilists would call for here.
  • BOs need a way to report variances from their own understanding of their vision (e.g., bugs), and those variances have to be worked with in a similar way to the rest of the work items.  Their fixes have to be adjudicated according to business value, evaluated for complexity, planned for along with other development work.

The management needs the tool for essentially the same reasons as the client, but perhaps with some additional reporting not visible to the client.

  • What’s the cost basis of the project?
  • Similarly, what’s the expected duration and margin?
  • Who are the best performers?

So there’s the rub(ric).  The bullets above may not seem as concrete as you might like them to be, but I want to leave room for interpretation and vision from the toolmakers (also note that this isn’t really a review of SCM tools or testing tools).  The tools I plan to review:

As I review each tool, I’ll post a link and a date here on this page.  Tools not shown here either I didn’t know about or could easily eliminate from consideration because of bad reviews or obvious lack of important features.