Posts Tagged ‘project management’

« Older Posts   

Questioning Testing

A fictional dialogue is presented below to explore and question the traditional role of the I.T. quality assurance department. The characters are: Bess: Manager of a line of business. Asa: Manager of the I.T. quality assurance (QA) department. The scenario is that Bess has asked I.T. to provide some software to monitor and drive improvements […]

Staffing Software Development Teams

Recently I had a few discussions relating to the staffing of software development teams, and I was dismayed to learn that some managers viewed this as merely getting the right number of FTE (full-time equivalents) placed onto each team. In this flawed traditional command-and-control viewpoint, people are nothing more than interchangeable resources, and teams are […]

Balancing Order and Chaos with Process

Whether it is software development projects or I.T. operations, many larger organizations seem enamored with process as the solution to their problems. The default reaction to negative outcomes or variances between people in performing activities is to add more process. Process provides an ordered structure for keeping such chaos at bay. This reflects an underlying […]

Industry Adoption of Agile

Agile methods have seen a surge of adoption within I.T. in the last few years. Agile is clearly not a fad or limited to early adopters – it has entered the mainstream and is here to stay. For those of you not yet using Agile, I wanted to provide statistics and recommendations from widely-recognized industry […]

Meeting Milestones via Swarming and Reserves

No matter what method of software development a team uses, there will be times when the team struggles to meet planned milestones. The milestone could be completing committed stories for an iteration or reaching the feature-complete point in a release. The struggle to meet the milestone might be caused by any number of factors like […]

Alternatives to Formal Traceability

In my prior post The Trouble with Traceability I discussed the problems with doing requirements traceability, especially formal traceability using approaches like a requirements traceability matrix (RTM). Despite the flaws with traceability the underlying objective is sound: ensure that everything the customer or user requires is correctly delivered. So how can we achieve this objective? […]

Connecting with Calgary

I recently had the opportunity to travel to Calgary, Alberta to visit the CGI office there and hang out with several of the development teams. These teams have extensive experience with larger-scale agile development including both XP and Scrum and have a good reputation for having a great development culture that excels at mentoring and […]

Stop Staring at the Spreadsheet

As a scrum master or technical lead do you find yourself frittering away your time staring at the spreadsheet (or other tool) you use to track progress of the team? Do you keep studying the velocity and burndown or keep tweaking the numbers or formulas? I have heard of this becoming a chronic problem for […]

Drawbacks of Formal Audits

In heavily-regulated or bureaucratic environments formal audits are a common occurrence. Such audits typically consist of an auditor external to the team or organization who analyzes historical evidence of the work done to find non-conformities with respect to the documented process being audited. To those with a bureaucratic mindset process and audits are the answer […]

Contribution as a Function of Difficulty

In my prior article on capability for software developers I identified four measures for assessing a developer’s capability. Three of these measures are closely related: the ability to work independent, the amount of assistance provided to team members, and the level of difficulty of tasks that can be handled independently. In this article I examine […]

Predictability and Planning for Done

There is an interesting relationship between having predictable estimates for project management and using a thorough definition of done. Achieving the full definition of done for a feature or release (often called being done-done) is surprisingly difficult. You may have heard the anecdotal rule of thumb that it takes 80% of the time to achieve […]

Using Feature Done Checklists

I have written previously about the importance of having a definition of done that the team understands and adheres to. At the level of features (use cases, user stories, etc.) a comprehensive definition of done will often consist of a number of items, some involving non-developer roles such as tester, business analyst, and architect. Tracking […]

Problems with Typical Definitions of Project Success

My previous article discussed the importance of defining success as it relates to software projects and products. Now I want to look at some typical definitions of success and identify problems or short-comings with these definitions. From this analysis I aim to point the way towards a better definition of what success entails. Typical Definitions […]

The Importance of Defining Success

Can you define what makes a successful software development project or product? Do you know the criteria by which your current assignment will be judged a success? Does everyone associated with the project or product share the same definition? Defining what it means to be successful may seem obvious or trivial, but I expect that […]

Comparing Agile and Traditional Project Management

I just attended a great presentation about Agile project management by Mike Cottmeyer at Agile Edmonton’s monthly meeting. What stood out for me were two comparisons Mike made between Agile project management and traditional approaches (e.g. waterfall project, PMI/PMP). Dealing with Uncertainty Mike characterized traditional approaches as trying to manage out uncertainty in the effort […]

Cyclic Incremental Growth in Software Systems

I recently read an interesting research paper titled Metrics and Laws of Software Evolution – The Nineties View by Lehman et al in the 1997 proceedings of the Software Metrics Symposium that discusses eight laws of software evolution. One set of graphs within the paper jumped out at me: they show the incremental growth of two systems over a series of releases. The graphs shared a common pattern: releases with higher than average incremental growth tended to alternate with one or more releases with lower than average growth. What are the implications of this commonly observed behavior for developing and using software? How can we use this pattern to our advantage? Read on to see my answers to these questions.

Why is Estimating so Difficult?

Working as a software developer offers many challenges ranging from tracking down an elusive defect in third-party software to trying to determine what a client really wants. Perhaps the most difficult challenge, however, is succeeding as an oracle who can accurately divine the future – more commonly referred to as creating an estimate. A layperson […]

Release When Ready

There are several strategies for producing software releases. One approach is to release by schedule – the software ships on a fixed date defined well in advance. Another method is to release based on budget – the work stops once the money available is exhausted. I believe, however, that the best strategy in general is […]

Producing Good Software is Hard

This is a public service announcement to all project managers, business analysts, others working in the I.T. industry, and the general public: producing good software is hard. The next time you wonder why the software you are using crashed, or why your software development project is behind schedule, or why your software doesn’t meet the […]

ICE Conference Highlights

I recently attended two seminars at the ICE 2006 Technology Conference in Edmonton thanks to my employer CGI. I enjoyed both presentations and regret not attending more. I was able to pull some useful tips and ideas from each seminar that resonated with me. The first session was Lessons for Risk Management Taken from the […]

« Older Posts