Project Management for Software Development Teams

software-teams

Managing all types of projects, incl. software development, can be handled in various ways. There are plenty of methods and theory out there to dig into, to hopefully find the best possible solution for your project. The best one is very much a matter of the nature of your project, as well as you and your team's subjective opinion and thoughts going into the workflow. 

Below, we've gathered some of the most popular methods designed solely for software projects. If you're more interested in universal project management methods, we have a similar article on those here.

 

Agile Software Development Methods

Extreme Programming (XP)

Extreme Programming is a software development methodology, which is intended to improve quality and responsiveness to changing requirements. XP is continuously running in a planning / feedback loop to ensure the most value is delivered.

XP encourages a set of five values; communication, simplicity, feedback, courage and respect. Communicate the progress to everybody, keep the builds simple to ease maintenance and support down the line, run continuous feedback sessions on the completed work, having the courage to act on things that ruffle your mind and accept and adapt to feedback from others, and last but not least respect everyone on the team, their opinion and work together to find the best possible solutions.

As you can see from the illustration below, the method advocates short development cycles for frequent releases of your software. This is in link with increased productivity and possible frequent changes of requirements, while limiting potential issues to a minimum by releasing in manageable chunks.

XP encourages a set of 13 practices

  • Sit Together
    Communication is one of the core five values of the XP process, and thus sitting together, or at least having a very close relationship with your peers, is highly valued. Often conversations start out of nowhere, you overhear conversations among your colleagues, and spontaneous groups are build.
  • Whole Team
    A harmonious cross-functional team means a more intelligent and productive team. When you lead a more diverse team, there's always somebody knowing something about what you're trying to accomplish or fix.
  • Informative Workspace
    An informative, visual and transparent workspace fosters a more inspired team, a more creative team coming up with better ideas. Keeping the progress on the team's goal visual on the walls, and make sure everybody is involved and in-tune.
  • Energized Work
    Nobody can work and be productive 24/7. You need an energized and motivated team. A team that not just works hard, but also goes home and plays hard. Having a set schedule, going home on time, spending time with family and friends, eating healthy, doing some outside activities, and getting the sleep your mind and body needs. Think of yourself, and think of your teammates.
  • Pair Programming
    Doing programming in pairs is encouraged to create code and builds of higher quality and fewer reiterations. One is leading the code writing, while another is leading the design and how everything fit together.
  • Stories
    Use stories to explain the features and tasks that need to be developed. This can function as a reminder to a previous conversation, and also keep you on-track of what you're actually trying to accomplish. Like, what problem should it solve?
  • Weekly Cycle
    A weekly iteration cycle beginning with a meeting on the first day of the week. The schedule of the meeting is firstly, how's the progress on the project, secondly, which stories does the client want prioritized, and thirdly, how are we going to deliver those stories? At the end of the cycle the work is presented to the customer, and feedback is gathered to adjust and stay on-track.
  • Quarterly Cycle
    Every quarter, a meeting is held together with the client. Upcoming stories are defined and prioritized. This helps you ship maximum value, while the customer can work with their stakeholders based on a reliable roadmap.
  • Slack
    Having a few slack stories included in the cyles as well. A few stories that are not as important to ship within schedule. This works as a buffer that can be postponed if work piles up, or be an extra snack to grab if there's time left.
  • Ten-Minute Build
    A habit of automatically running and testing builds of maximum 10 minutes is encouraged. The purpose is to limit the risk of major errors, which might occur if the code compilation happens less often. Frequent testing limits the risk.
  • Continuous Integration
    This one goes hand-in-hand with the previous one. Integrating your code several times during the day, keeps your build, test and release up-to-date. This should ease deployment.
  • Test-First Programming
    XP takes the approach of beginning with writing the unit test of the features you're going to build, run the test, make it fail, and finally write code that simply makes it pass the test.
  • Incremental Design
    Keeping design flexible, and doing the designing as new requirements are coming in, or new adjustments are made. This avoids the risk of designing for something that is not going into the final release anyways.

500px-Extreme_Programming.pngThe Extreme Programming process

 

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method is another software development method with a special focus on limiting budgets, hitting deadlines, and increased user involvement and top-management commitment.

DSDM moves through three main phases; the pre-project phase, the project life-cycle phase, and the post-project phase. Additionally, a life-cycle phase is subdivided into five phases; feasibility study, business study, functional model iteration, design and build iteration, and implementation.

Focus areas of DSDM

  • focus on business needs
    All decisions must be based on the business case, and lead your business and projects toward their respective goals.
  • deliver on time
    Prioritize work to hit the deadlines with the important tasks.
  • collaborate
    Active and passionate collaboration promotes idea generation. Encouraging a single team culture rather than a split one.
  • never compromise quality
    Level of quality based on the initial defined business case.
  • incremental building
    DSDM encourages getting a perspective on the problem you're trying to solve, and keeping the details open for iterations.
  • iterative development
    Running iterative development, frequent demonstrations and reviews of the completed work.
  • clear and continuous communication
    An environment that encourages informal communication between all colleagues and levels of the organization. This ensures that ideas flow, and problems get discovered early on. The Scrum approach of running quick daily stand-up meetings updating everybody on the progress.
  • demonstration of control
    Monitoring the status of the project and comparing it to the business case. Also, making sure everybody is in-tune with the progress is paramount, preferably through visual means.

490px-DSDM_Atern_Project_Phases.png

The DSDM process

 

Adaptive Project Framework (APF)

Adaptive Project Framework is specifically constructed for software development. The problem it was made to solve is the constant change of requirements when dealing with software and clients at the same time.

The key component of the APF process is to split work into several cycles. These cycles are prioritized based on the work breakdown defined in cooperation with the client itself. This ensures that you always take on the most important tasks, and manage to build the cycles which are of highest value to the customer and end-user.

The APF process moves through 5 phases. The process begins with the definition of scope, where you in cooperation with the client define the Project Overview Statement, you prioritize the work and requirements to match what brings most value to your client, which finally leads to the Work Breakdown Statement, i.e. cycles to build.

Next step is your first cycle. Cycles are the chunks of work you're planning to do. First up is to plan the upcoming cycle. Which tasks need to get done? Third step, you begin the actual work. Schedule the cycle, assign people to tasks, and ensure everything will be delivered on time. Build the cycle, and continuously monitor and adjust the build.

Just before ending the current cycle you reach the Client Checkpoint. The point of this step is to ensure a sufficient quality of build before the cycle is delivered to the client. This step also highly encourages you to include the client in testing of the finished work to ensure proper value has been delivered.

If there are more cycles in your project, you move back to step 2, and continue with the next build cycle.

When all cycles are completed, you move to the fifth step, the Project Review. The purpose of this step is to review the project on a general level. The completed work is reviewed as a whole, and if the delivered product is sufficient, the project can be closed.

Adaptive Project Framework.svg

The Adaptive Project Framework process

Crystal

Crystal is one of the most simple methodologies, meaning that it advocates a more lightweight process rather than a strict step-by-step approach. Crystal is really a family or group of methods, incl. Crystal Clear, Crystal Orange, Crystal Yellow, Crystal Diamond, Crystal Sapphire, and various others. All adjusted to fit different kinds of projects. The first three often used in more simple projects, and the last two for projects with higher risks.

The Crystal methods have 6 areas of attention. People, interaction, community, skills, talents, and communication. Crystal purposefully puts these six factors above the process itself. Simply, it suggests that those are the foundation of the project, and should thus be the foundation of the method used as well.

No matter the subset of Crystal methodology, there are seven commonalities between all of them.

  • Frequent delivery
  • Reflective improvement
  • Close communication
  • Personal safety
  • Focus
  • Easy access to expert users
  • Technical environment with automated tests, configuration management, and frequent integration

 

Feature-Driven Development (FDD)

FDD is another agile and sorta lightweight method for managing software development. The process is driven by features prioritized in cooperation with the client. Again, the FDD methodology promotes a stable and continuous shipment of builds.

The process consists of 5 phases. The process is kinda split in two. The first two phases are on the version level, while the last three are on the feature level. Meaning, you run through the first two one time per release, while running through the last three for every new feature being developed.

Process of FDD

  • Develop overall model
    First, the overall scope of the project is leveled out. What is going to be build? Why is it going to be build? What context and value does it deliver? The feature set is discussed and reviewed by the group.
  • Build feature list
    Based on the gathered information from the initial phase, the final list of features is now defined. The list is prioritized by importance and value created, seen from the client's perspective. The features are then categorized and divided into subjects and areas of interest.

    Generally, features should max. have a build length of 14 days, else it needs to be broken down into several tasks.
  • Plan by feature
    The first feature specific phase begins. The development plan is produced, and each feature (or feature set) is divided between groups of developers to be the new owner of the continued development.
  • Design by feature
    Next step is to define and design each task. What needs to be done? How should it work? Why does it provide value for the customer? Assign tasks to developers with the right set of skills, and make sure they're available for the job.
  • Build by feature
    The feature is built, then going through a unit testing and code inspection, and finally released to the main build.

 

Projects in Controlled Environments (PRINCE2)

The PRINCE2 method is definitely one of the most comprehensive methods out there. It consists of 7 principles, 7 themes and 7 processes.

PRINCE2 focuses on continued business justification based on a proper business case, learning from experience, specifically defined roles and responsibilities, breaking work into stages, management by exception, defined product requirements, and finally tailoring the processes to your business environment.

There are three overall bodies in the PRINCE2 method; the project board, the project manager, and the project team. The project board is only concerned about the top-level tasks and the overall business case. The project manager speaks for itself, they're managing the project, reporting the current status to the project board, taking care of potential problems, etc. Finally, the team manager, if appointed, works as the communication channel between the project manager and the project team.

7 themes of PRINCE2 on how to run achieveable and profitable projects

  • Business Case, directly linked to the 'continued business justification' principle
    Make sure the actual business case makes sense. Valuable? Achievable? If at any point this is not the case; make changes to the project, or shut it down altogether.
  • Organization, directly linked to the 'defined roles and responsibilities' principle
    The project manager should always be sure of all team members' place in the organization. What are their responsibilities and competencies?
  • Quality, directly linked to the 'focusing on products' principle
    Define the concept of 'quality' at the beginning of the project. Quality can be very abstract and subjective, and is thus paramount to define as part of the planning process.
  • Plans
    Plans on how the defined goals of the projects are being achieved. This theme focuses on the product, time, costs, quality and the benefits.
  • Risks
    Proactively identifying, assessing and controlling unknowns. A risk management report is developed, essentially a log of all the risks categorized as opportunities or threats.
  • Changes
    This theme is in place to manage new requirements, features and issues coming in. Basically, everybody needs to be on the same page. Everything needs to be settled before execution can begin.
  • Progress
    Tracking progress is essential for keeping a project on-track. Progress is where you make sure everything is going according to plan, and if not, take proper actions towards fixing it.

The PRINCE2 process is moving through 7 phases

  1. Starting Up a Project
    This is basically the business case of the project. What is being build? Who should build it? What are the problems we're trying to solve? What is the concept of 'quality' for this project? What value are we seeking to deliver?
  2. Initiating a Project
    How do we solve the problem this project was created to solve? This phase focuses on defining the scope, quality, time, costs, benefits and risks of the project.
  3. Directing a Project
    This is an ongoing phase. Initiation of the project, defining stage boundaries, third-party guidance, and project closure.
  4. Controlling a Stage
    Here is where the Work Breakdown Structure is defined. The stages are setup, and agreed upon by the project managers.

    Project managers are continuously reporting the current status to the project board, and assisting in solving problems as they arise. Team managers are arranging daily work, and acting as the channel between individual team members and the project manager.
  5. Managing Product Delivery
    This phase is all about accepting, executing and delivering the stages as defined earlier.
  6. Managing Stage Boundaries
    The next stage is planned. Update the project plan, and / or business case if necessary. Finish the current stage and move to the next, or develop an exception plan if necessary.
  7. Closing a Project
    The project is completed. If needed, any final reviews are prepared. Finally, delivery of the product to the customer.

 

Rational Unified Process (RUP)

The Rational Unified Process is a software development method developed by IBM. The process is a two-dimensional process broken into 6 activities, with an additional 3 supporting activities running vertically, and 4 phases symbolizing time running horizontally. Additionally, RUP promotes a list of 6 best practices for better management.

Best Practices of RUP

  • Develop software iteratively
    Supporting continuous change of requirements by having a more frequent release cycle that always ranks the tasks with the highest risk first. Effectively avoiding growing pains in the future. Feedback from the end-user is encouraged to improve and discuss the next steps.
  • Manage requirements
    Track, organize and document requirements and decisions made along the way. Making sure there's a reference to ensure better design and implementation that matches the end-user's expectations.
  • Component-based architecture
    RUP promotes a component-based development process. Meaning, instead of developing full-scale right away, it supports building components that together lead to deployment of the full-fledged feature. Also, building components rather than full features allow for using this component across features and parts of your system.
  • Visually modelled software
    Using the Unified Modeling Language helps in designing and communicating the structure and behavior of your system. Each building block is linked, and shows exactly how it fits into the puzzle.
  • Verification of software quality
    Quality assessment in terms of reliability, functionality and performance of application and architecture service.
  • Control changes to software
    Controlling, tracking and monitoring for continuous successful iterative development.

 

Process of 6 activities

  1. Test
    Test the feature on a continuous basis.
  2. Analysis and design
    What value should it create for the end-user? How do we solve the problem best possible?
  3. Business modelling
    What problem do we need to solve?
  4. Requirements
    What is required to solve this problem?
  5. Implementation
    Build the designed feature.
  6. Deployment
    Release the finished build.

Development-iterative.png

The RUP process

Supporting disciplines

The following disciplines are in place to simply keep the project on-track. Make sure everything moves according to plan, and with as few as possible issues along the way.

  • Configuration and change management
    This discipline is in place to ensure documentation of changes happening to the software over time, and who made the changes. Basically, it is tracking new changes and iterations of the deliverables. Making it significantly easier to return to the right stage and person if anything goes wrong.
  • Project management
    Planning, implementing, monitoring and controlling the deployment of software.
  • Environment
    Setting up the environment around the development; tools, processes, etc.

The 4 phases of RUP

  1. Inception
    The first phase of RUP is to define and setup the business case of the project. Which problems are we going to solve to consider the project a success? Who are the involved parties, and how should it affect them? How is it going to be used? Are there any risks in implementing this? Which resources do we need, which roles, which competencies, and are they available?

    Based on all of this information, a timeline of milestones is constructed to have a high-level roadmap ready.
  2. Elaboration
    The problem to be solved is analyzed more thoroughly, while still keeping a wide perspective on the system you're going to build. The perspective is paramount to avoid moving down the wrong path. With this perspective in mind, the project is planned out. If there are any high-risk tasks in play, take a look at these from the beginning.
  3. Construction
    This is where the actual development begins. Development, integration and testing. Steps are taken to optimize the workflow along the way. At the end of this phase, the product should be ready to ship.
  4. Transition
    The transition phase is there to gather feedback from the end-user. Develop missing features, fix bugs, and adapt the product to the findings.

 

Final words

There are of course more options out there, but the ones mentioned above are some of the most popular, and are all widely recognized by software development companies, big and small.

Again, if you're more interested in universal project management methods - we have an article on that here as well.

 


Like what you read? Here are some other articles you might also enjoy:

Subscribe to the Forecast Newsletter

Get a monthly roundup of productivity tips & hacks delivered straight to your inbox