I’ve already touched on the importance of agile development in previous posts in this series: agile development for custom web and mobile applications; why agile development makes sense for your business and why scoping is pointless for agile development projects. In this post, I’d like to touch on the question: what does an agile development project look like, as well as the importance of the relationship between the project manager (commonly known as a Sensei) and the product owner.

What do the people involved in an agile development project look like?

Before I break down the way we work on agile projects, let me explain what the various members involved in an agile development project look like.

Product owner

This is often the person behind the idea, solution or problem-solving campaign. He/she knows everything about the company and/or system and can easily identify the problem that needs solving. They also act as the main contact point when discussing a project and what needs to be done. They take the information provided by various stakeholders and use their discretion to place it into a project.

Stakeholders

Stakeholders are often people that are part of the problem that the product owner is trying to solve. They could be the people working in an archaic way or they could be the owner of the company that is throwing money away because their systems are wasting valuable resources. They often provide insight into what problems exist and provide this to the product owner who can then look at the bigger picture and see what will give the project results early on.

Sensei

In every project there is a project manager. In agile development, they’re known as the Sensei (often related to master). In this case, i is the person that directs the development team and guides them in building the requirements and user stories provided by the product owner.

Development or innovation team

These are the people that actually produce the work. They work as hard as possible on getting user stories into complete status as quickly as possible. This team is generally very clever and often needs the Sensei to translate or clarify (communicate) certain technical information back to the product owner.

How do all the members fit in and what does an agile development project look like?

All the people involved are crucial to the success of a project. They all need to give 100% to the project to get 100% out of it. There are a number of steps involved in making this happen.

1) User story session

This is a very high-level overview of a piece of functionality that will solve a single problem. User stories follow a very consistent format that answers who, what and why. An example of this would be:

As a potential client of Flicker Leap,
I want to read an article about agile development project management,
So that I can understand how an agile development project works.

The more specific a user story, the better. More importantly, the why is by far the most important piece of information for the development team as it gives them insight into how to build the project.

2) Clarification

Often, the why has not been unearthed enough or the technical details need a bit more clarification. This might be done in a session or via a quick chat over an instant messaging tool, email thread, project management tool or video conferencing tool.

3) Discovery

The development team spend time looking at the requirements of a user story and start assigning the amount of effort required to deliver it. Sometimes this requires some clarification, but often discovery allows for effort to be assigned so that the product owner can start managing priorities.

4) Managing priorities

At Flicker Leap, we do the Kanban methodology within the agile framework. In Scrum, you would choose the user stories that fit into your sprint size (the effort you have in a period) and lock them into that sprint. In Kanban, the product owner sets the priority of the user stories from top to bottom and the developers will then start working on the most important user stories first.

When a user story moves into progress, it generally never moves back out into the backlog and only moves forward to completion. This means the product owner only works on the backlog and changes priorities there. An important note here is that some user stories are assumed to be done before another user story is. This often means that the first user story had all the complex functionality that would be used in the second user story. If you change any priority, you need to check with the Sensei if any user story effort changes.

5) Quality assurance (QA) and staging deployment

When a developer completes a feature, they then pass this onto the QA board for the QA team to assure quality. Once they’re happy they move this along to the deployment board, which should start rolling the feature out to a staging site automatically for the product owner’s and stakeholder’s approval.

6) Production deployment

Once a feature has been given the approval and potentially gone back into progress with changes. The feature is then pushed into production (often with a whole lot of features) allowing stakeholders to benefit from the hard work of everyone.

Conclusion

This process and “order” allows for a very transparent workflow that everyone is aware of and can see. A Kanban team will often have Kanban boards, which show where a feature is in the agile process. The transparency allows for everyone to form a closer partnership, which often leads to the success of projects mainly due to accountability from every single party.

Has this helped you answer the question: what does an agile development project look like? Let’s discuss agile further over a cup of coffee. Book an appointment with Flicker Leap today.