Category: project management

Agile Project Management Questions Answered

November 16, 2009 by Kelly Waters

I was asked recently to answer 5 questions about agile project management for a feature on PM Boulevard. I thought you might appreciate seeing them here too...

1. How has the Agile practice evolved over the last two years?

I don’t personally think that agile practices have particularly changed in the last two years, however there is clearly a stronger emphasis on some elements more than others now.

Scrum certainly seems to have crossed into the mainstream since I started my blog. Even though it was less than 3 years ago, Scrum still felt quite new and innovative in the UK at that time. I work in the web development sector and now every company I meet seems to be doing Scrum.

Another change is the interest in agile from the project management community. This seems significant as people start to think more about how best to apply agile on larger projects. Looking at Google Trends, which shows search volumes over time, the graph below shows that search demand for ‘agile project management’ started relatively late in terms of agile adoption, and interest is still growing strongly now.

The Secret To Delivering On Time

August 19, 2009 by Kelly Waters

Hi, I'm Kelly Waters, author of the popular blog, All About Agile. I've agreed with Artem to guest over here at ASD and be a regular contributor - this is my first post...

I've been doing agile development for quite a few years now, and seen many benefits. But one of the most remarkable things of all, is how so many teams can quickly get good at predicting what they can deliver, and deliver on time, even if they were hopeless at estimating before!

Why Project Managers Like Documentation

November 21, 2008 by mcottmeyer

Most software project managers have very little power in an organization. They are on the hook for delivery, but have very little control over the actual resources required to get the job done. Project managers have to broker agreements, hold people accountable, and get people to do things that they are not otherwise incented to do.

Fixed Constraints and Up Front Design

Requirements documents are created early, and often with little input from the delivery team. Budgets are set and timelines negotiated, prior to the project team even being engaged.

In other words… project managers are in a pretty bad spot. They are trying to manage in a situation where the triple constraints are all set for them, they have little direct control over resources, and the resources they have are matrixed across several projects with competing priorities and differing agendas.

How to Do Many Projects (Part 4): Resource Planning

November 4, 2008 by JurgenAppelo

In three earlier blog posts I talked about multi-functional teams, matrix management and maintenance. In my maintenance article I argued that maintenance work on an application should done by the developers who were responsible for building it. However, I also pointed out that this introduces some additional resource planning problems...
When software developers are responsible for multiple projects, you always end up with complications in resource planning. This is not just the case when you let developers perform maintenance on previous projects. Similar problems arise when they are required to do some other activities, like spending time on consultancy or estimations for projects that haven't yet been signed into contracts. Likewise, many developers need regular training, or they like to do some quality/infrastructure stuff for the organisation itself. Therefore, maintenance work on old projects is a challenge, but it's just one of many types of work that can take people's attention away from their current projects. This requires a professional approach to resource planning...

Finding a Partner to Trust - Writing an Agile RFP to Outsource a SW Development Projects

October 22, 2008 by Peter Stevens

My customer wanted to find an external partner to develop their new software product and develop using Scrum. So we needed to evaluate the potential partners, but how? The classical approach is to define the application “exactly”, then ask some potential vendors if they can do it and how much it will cost (and then haggle over the price). This is not very Scrum like, but it represents a starting point which is well understood by customers and vendors alike. What is different about an Agile RFP?

How to Do Many Projects (Part 3): Maintenance

October 21, 2008 by JurgenAppelo

In two earlier blog posts I described how we have organized the software development efforts in our company. I wrote about cross-functional teams and matrix management.

This time, I'd like to talk about software maintenance.

I have recognized two lines of thought regarding maintenance:

1. Software maintenance should be separated from new software development. This means that, when a software development team considers a project finished, it is handed over to a maintenance team.
2. There's no clear difference between software maintenance and software development. A team should perform both new development and maintenance.

Personally, I lean towards option 2. And these are my reasons:

Finding a Partner to Trust - Using Scrum to Create an Agile RFP

October 15, 2008 by Peter Stevens

I just finished helping a customer write an RFP (Request for Proposal) for a software development project. The customer has had some expensive experiences with waterfall style projects, and Scrum had been the key to getting those projects back on course. So it seemed logical to plan Scrum from the beginning. But how do you write an agile, Scrum-Compatible RFP? How do you select a company to implement an agile project? We started with Scrum.

Part 1 in the Agile RFP Series;

1. Using Scrum to Create an Agile RFP
2. Contents of the Agile RFP
3. Selecting an Agile Outsourcing Partner

Google was remarkably unhelpful with this problem. The top links all pointed to a paper and presentation from 2003 about combining Use Cases and User Stories in the RFP process. A request to the ScrumDevelopment Group produced no responses. So we were on our own.

How to Do Many Projects with Matrix Management (Part 2)

October 14, 2008 by JurgenAppelo

In How to Do Many Projects (Part 1) I explained that it is good to have multi-functional teams, where each team includes a project manager. Here is part 2, which is about the merits of matrix management...

Functional Managers
As in every other organization, in our company each employee has a (functional) manager. I prefer management to be arranged along functional lines. Therefore, a project manager has a manager who knows a lot about project management. A front-end developer has a manager who is herself fluent in CSS and HTML. And our software developers have development managers who are proficient at building code, delivering solutions and making nerdy jokes that no ordinary person understands.

I believe it is imperative that managers understand the work their employees do. There's little reason for software developers to work with a manager who cannot distinguish a bit from a byte. (I have blogged earlier about how to select a fine technical manager.) Similarly, project managers should be led by someone who understands agile principles, Scrum practices, and how to turn Notepad into a planning tool.

Important: a manager does not have to be better than the sum of his subordinates. It is only natural for his senior employees to exceed the manager's knowledge and expertise at some point, because management requires other (soft) skills, some of which the seniors might be lacking. However, the manager should be good enough to earn trust and respect, and to be able to coach and lead.

Scream Free Project Management

October 10, 2008 by mcottmeyer

A few weeks ago I had the opportunity to read a book by Hal Edward Runkel called Scream Free Parenting. The title is a little misleading because the book is not really about screaming and the lessons Hal teaches go beyond just parenting. The book is about controlling your anxiety so you can build healthy relationships.

The key idea of the book is that anxiety is at the root of much our conflict. Think about it… we want better behavior from our kids, we are not getting it, and not getting that desired behavior stresses us out. When we yell at our children, we are really saying "I want to be calm, you are not allowing me to be calm, I demand you change your behavior so I can be calm".

Prioritizing the Product Backlog

October 8, 2008 by Peter Stevens

Any project plan is a mixture of what the product owner wants and what the team can actually deliver. The product owner naturally wants more than the team can deliver, so s/he has to prioritize in order to get something useful in the desired timeframe.

Once you have a prioritized product backlog, you have the prerequisites for calling the first Sprint Planning Meeting. How do you convert an unordered list of features into a prioritized product backlog which you can give the team to implement? What should you do first?

I'm not sure that there is a correct answer to this question. It will depend on your product, your company and your situation. Let's take a look at some widely used strategies for prioritizing the product backlog

• Minimum Marketable Feature Set - the first pass to narrow the list of stories
• Business Value First - Focus on High Value Functions
• Bang For the Buck - Go for easy wins
• Technical Risk First - Do the hard things first
• Defer Risk - Do the hard things later (or never)
• Vote - Ask your users