The Agile Tribe

It is not ALWAYS the developer's fault …..

on February 8, 2011

Author: Peter Sellers


…. that your software doesn’t work!

I’m not saying it’s never the developers fault. What I am saying is this – it is not just the developers who contribute to the success or failure of your software.

  • How can this be the case?
  • Who contributes to the success or failure of your software?
  • What can be done to improve the chances that your software will be a success?

Product/Business owners….Let’s discuss it!

This is the first of three discussions around the roles and responsibilities of the Product/Business Owner in the Agile software development life-cycle. In this first discussion I will look at the roles and responsibilities of the team members at the project level. In subsequent discussions I will look at their roles and responsibilities in the iteration and the story delivery life-cycle.

How can this be the case?During the project concept phase developers have no roles or responsibilities at all. It is not the developers who decide if your project is feasible. A technical lead/architect will be involved in the high-level design, but the decision on proceeding with the project does not rest on them.

The developers are responsible for engineering and writing the software that you ask for. How can it not be their fault?

The initiate phase sees the granulation of concept level work. Developers along with other team members participate in workshops at this phase. The developers play a role in helping to break down features into stories and refining the solution design among other things. Their role in these workshops is the same as every other team member present – to refine the concept. Developers may carry out technical ‘spikes’ around technical risks to help determine estimates and time frames, but for the most part they are merely members of a team identifying, prioritizing, estimating and planning at this stage.

Development is carried out by developers at the develop phase of the project. No prizes for getting that one right. Is this when it becomes their fault? Well, once again they are not the only members of the team involved in this phase. They are part of a team charged with building functionality that adds business value, and they need support from other team members to do this. The whole team should be involved in planning sessions, stand-ups, retrospectives and showcases during short iterative periods of development.

Developers play a large role in engineering functionality at this stage. It is there responsibility to develop code that meets acceptance criteria established by the whole team. This same code is tested manually by test analysts and demonstrated to you before being considered complete. That means everyone in the team has agreed what the developer should build, it has been tested and has been accepted by yourself.

Development is not carried out in isolation, the whole team is responsible for ensuring its quality, not just the developers.

Finally there is the deploy phase. Here the developers have a role to play in handover to the production support team. They will also be involved during creation of the back out strategy, data recovery and stress testing.

The developers role at this phase is largely supportive. Once more, this phase relies on team efforts – not just the developers.

Who contributes to the success or failure of your software?

If the developers are not the only ones responsible, then who else is? Who else contributes to the success or failure of your software?Typically the BA (Business Analyst), SME (Subject Matter Expert) and a technical lead/architect will take part in workshops during the concept phase of your project. These team members are responsible for formulating the desired outcomes, identifying features as well as preparing some high-level design and estimates. Their role is to determine if the initiative is worth doing.

As well as the BA, SME and a technical lead/architect, the developers and test analysts will all be involved at the project initiation phase. Every one of these team members has a role to play in adding detail to and refining the conceptual phase outcomes. Each team member is responsible for utilizing their unique expertise to elicit stories, prioritize, design, estimate and plan during a series of workshops.

So who else contributes during the develop phase? Strange as it may sound the BA, SME, test analysts and a technical lead/architect have just as much to contribute during this phase as previous phases.

Infrastructure also become involved at this phase – as a focus starts to be put on deployment and production support.

Each team member attends planning and story elaboration sessions, stand-ups, retrospectives and showcases. Each has a responsibility to contribute their skills, even during the feature development cycle (which we will discuss further at a later date).

Test Analysts have a responsibility to test features as they are developed. You are responsible for agreeing that the acceptance criteria is met during a demonstration/showcase. You have a role to play in the quality of your software during the development phase.

During the deploy phase the SME, Test Analysts and production support teams all have roles to play. The main objectives of this phase are to move to a production environment, whilst ensuring a good handover to the production support team.

Handover to the production support team occurs with support from developers. Final user acceptance testing occurs at this time. Data Recovery, stress and load testing will be carried out by Test Analysts during this phase.

What can be done to improve the chances that your software will be a success?

So if there are so many people contributing to the softwares success, what can be done to improve the chances of success?

Use the project concept phase to determine if it makes business sense. Ensure the business benefits exist to make the project worthwhile. Establishing SMART (Specific, Measurable, Attainable, Relevant, Time-Bound) goals and completing value sliders at this stage will enable you to measure project success. Tying features to business benefits helps prioritize implementation. Ensure diligent risk analysis is carried out too.

Even at this conceptual stage there is a serious chance of impacting project success. Don’t take it for granted. Use it to your advantage.

At the initiate phase of the project involve the whole development team. Ensure identified features are broken down in to stories. Map the stories to the business processes to ensure nothing is missing. At this stage prioritize the stories based on MOSCOW (Must have, Should have, Could have, Won’t have). Prioritize on business value not effort or complexity. Also, carry out risk analysis on the stories and plan to deal with high risk ones in early iterations.

During the initiate phase prepare the test strategy – the what, when and how of testing. Estimation plays a big role at this phase. Estimation workshops carried out now help you produce effective plans. The estimates, plans, risk analysis and prioritizing all have an impact on the projects chances of success. Utilizing the teams combined skills improves your chances of success – even before development has begun.

At the development phase, ensure developers use ATDD (Acceptance Test Driven Development)/TDD (Test Driven Development) methodologies. The ATDD/TDD methodologies combined lead to leaner code, written when needed, that meets acceptance criteria. Developers doing this, will improve your chances of success.

Around the development cycle in this phase ensure iteration planning and story elaboration involving the whole team take place. Create a shared level of understanding about goals and stories throughout the whole team. Don’t neglect the retrospective, and the chance it provides to review, action and implement changes to help the team succeed.

The aim of the develop phase is to produce working software at the end of each short iteration. Hold a showcase, highlighting the new features. The showcase also enables your team to get early feedback on developed features prior to release.

The deploy phase needs to be started well in advance to be successful. Engage the production support team early. This will help to make the handover smoother. Carry out data recovery and stress testing during the deliver phase, providing the team time to identify problems and fix any issues.

As this phase often involves tasks that take a lot of time, plan to do as many of the tasks as possible during the deliver phase. Addressing these tasks early offers the best chance of a successful deploy phase.

Build Quality In

As we have seen quality is the responsibility of every team member in an agile team, not just the developers. Every team member has a role to play in building quality in.

Are you ready yet to admit…it’s not ALWAYS the developers fault?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s