• 12Nov

    It’s budget season. The economy is in the tank. You know budget cuts are are on their way. How do you make sure your team and projects survive? Prove that agile increases value. That’s exactly the message Richard Leavitt and Michael Mah presented this morning. But, to get your executives to keep your team and your funding, they don’t really need to understand agile per se, they need to understand the financial value of agile. That’s what they understand and care about. The numbers. So Richard and Michael gave the numbers and explained how to talk to the C-level when trying to show the advantages of agile development practices.

    The main question: What are the documented financial returns of agile? Here are the 3 main financial impacts that your executives will understand:

    Read more »

  • 29Sep

    We all learn how to ride a bike the same way: we learn to pedal, keep our balance, and steer. And that’s it. We learn how to ride when we’re 5 years old and we’re off and riding for the rest of our lives with minimal instruction. I used this limited knowledge for years as I raced in triathlons and various cycling events. Last week I bought a new bike (an Orbea Orca for those of you who care). As part of the deal, I got a custom bike fitting and coaching session. I learned a lot during the session, mainly that I needed to learn how to “ride” a bike. I learned that my cycling posture was wasting a lot of energy and that my pedal stroke was not as efficient as it could be. I took the coach’s advice and this weekend put it into practice. And boy, was I sore. I was using my muscles in a whole new way. And guess what, I was riding faster and more efficiently. Over time, my muscles will get used to riding the right way and won’t hurt as much, and I’ll keep improving my speed and efficiency.

    OK, so what, right? I’m riding faster now…good for me. But I was thinking about how we manage projects and develop software during my morning ride today. And I realized that my experience doing these things sort of parallels my cycling experience. I learned about project management and software development very early in my career (I was older than five). I had a good mentor and he’s someone I still hold in high regard and respect. However, what I learned back then was to keep my balance, steer the project, and keep pedaling forward. But as I matured professionally, I realized that there was more to project management and software development than this. In fact, if I stopped steering the project and let our clients and developers steer, we’d achieve better results. If I stopped always pedaling forward and took a look back once in a while, we’d improve how we worked and what we delivered. As for my role as a “project manager”…I found that if I stopped trying to ride the bike and just held the seat and gave a push to those on it, I was really doing my job and enabling the riders (our teams) to ride farther and faster.
    Sometimes it hurt a little to do these things, but after a while, our teams got used to it. With time, we weren’t sore when practiced these “new” ways of working and we saw great improvements in efficiency and effectiveness. So remember, when you start implementing agile project management and development practices, it going to hurt a little, but it’ll get better over time. And when you’re starting out and going through agile adoption curve, keep this in mind: If it hurts, you’re probably doing it right.

  • 07Apr

    Many organizations require a fair bit of weekly or monthly project status reports in order to provide invoices to clients and executive level visibility into project status.  Recently, I’ve been working through the issue of project reporting on our agile projects at the request of our COO.  He has implemented a policy requesting weekly project status reports that require reporting on the iron triangle of scope, schedule and budget.  It’s not an overly complicated report and it doesn’t take much time to assemble.  However, I’m not entirely sure that it provides useful information for our customers and our executives.  It’s very easy to gloss over the facts in a line item report with very generalized reports for milestones, schedules, and forecasts reported only by a project manager.  Currently, my scope status section of the report looks something like this:

    Milestone Schedule Current Forecast Status
    Iteration 1: Foo Functionality 3/24-4/4 Complete
    Iteration 2: Goo Functionality 4/7-4/18 On target In progress

    Read more »

  • 02Apr

    With our move to our new company came a new way of working for our team.  We used to be a tight knot team, all working the same long-term 3+ year enterprise project.  Now we’re working on equally engaging projects, but they are shorter term.  Our “team” has been split into smaller teams of 3, 2 and even 1 person per project.  We’ve also been working on distributed teams with our other offices around the country as well.  As such, our velocities are for individuals, small teams and disjointed teams.  It looks like this will be the modus operandi for the foreseeable future as well: Mix-n-match teams to put the right people on the right jobs for our clients.  So, the question that has been occurring to me lately is, how do I get reliable velocities to adequately estimate bids for future work with our mix-n-match teams?

    One idea I’m toying with is trying to gauge the velocity of individual team members using Rally.  For example, I can calculate Dave’s velocity as 12 points per sprint, Mike does 10 points per sprint, and Jeff does 11 points per sprint.  If we have a project that requires Dave, Mike and Jeff together, are their velocities additive?  Can I assume that this team would have a combined velocity of 33 points per sprint?  This begs the question, is the whole greater than the sum of it’s parts?

    Read more »