Agile Project Management Through the Looking Glass - Lemberg Solutions
6 minutes

Agile Project Management Through the Looking Glass

In IT industry, as in any other business segment, a lot of work related to the creation of a new product is being left behind the scenes. So let us shed light on some of it — project management.

I believe everyone has an idea who is a project manager: you see these guys with red eyes and nervous moves every day in the office. We are something like live communicators between the team and the client. We are those who fight for total happiness: so that everyone would not just work and check results, but also share part of the joy on the way. A Project manager is a person responsible for the successful progress and delivery of the project (and also the one who is hated by all other involved parties, usually). But that is pretty general information and my idea for this article is to provide some details that might be helpful and interesting.

Project management - CTA - Lemberg Solutions
Over the past 3 years, I used to use Agile methodologies for the projects I was responsible for, a scrum in particular. So the following information is based on this experience.

Sprint 0

Work on the project starts long before the actual development begins. When sales managers are done with their part and all necessary legal issues are solved, the phase which we call “Sprint 0” is launched. If we set the reference to a classic project management model and 5 stages described in PM book, the two first stages — Conception & Initiation and Definitions & Planning — are referring to the activities that are supposed to be covered during Sprint 0. The “Todo” list for this described phase may be shortened or extended depending on the peculiarities of a certain project, here you can find an example, which is basically a compilation from several projects:

  • Analysis of client’s requirements
  • Defining of the methodology that will be used
  • Resource planning, determination of the timeline and communication plan
  • Analysis of the market, for the purpose of creating a portrait of an end user
  • Writing user stories, forming the backlog
  • Prototyping and UI creation, feature design
  • Refinement of user stories and break down into development tasks
If you are new to project management, check our Client's Handbook on Managing Your Remote Product Development Team.

How does the magic happen?

It should be noted that 2 activities from the list above are connected with a moment when the development team joins the game. These guys usually give input for designers, so that the concept isn’t just beautiful, but also compatible with a technical part and not too complicated in terms of implementation. But let’s get closer to the applied part: we usually have several teams that work on the project. In a way, they compete a bit from time to time, but this results in a constructive discussion that helps to polish-up the product at each iteration, until the delivery point.

Ready team

These are professionals who are involved in the so-called ‘Sprint zero’. They conduct an analysis of the market, create user portraits, provide solutions and concepts, create architecture, think of feature design, work on prototyping, create the UI. Also work related to the gathering of primary acceptance criteria, as well as the writing of user stories, is done by them.

Here is one nice practice, which we use for feature design — the Slice & Dice session. It is a meeting of architects where they “slice” a huge part of functionality into smaller features (breaking epics into user stories, if to use the Jira language) and “serve” those in the form of a task with a pretty clear description.

Done team

These guys work like restless ants on the actual development, in other words — code writing. They do the analysis part though: they go deeper into details in order to define the exact implementation steps and to write down how to test instructions for QA engineers.

Also, they perform code reviews to make sure that everything written is in accordance to high standards; as well, they write automated tests, which help to keep the structure solid and can be ran further during the testing process.

The Development process is divided into sprints, each from 2 to 4 weeks in length. Here is the list of activities, which we perform during each sprint:

  • Sprint planning (where the development team and the product owner sit together to define the sprint goal and to decide which part of the project scope we should work on; also the acceptance criteria, implementation steps and estimations for each task are reviewed here)
  • Development
  • Refinement sessions (breakdown of user stories into smaller tasks, primary estimation)
  • Internal testing (provided by in-team QA engineers)
  • User acceptance testing (a check made on the client’s end)
  • Sprint review (meeting performed to check whether we reached the goal for the sprint and to demonstrate the work results)
  • Sprint retrospective (internal meeting with the team, performed with the purpose of monitoring the flow of the sprint and understanding what can be improved in future sprints)

QA team

The team of guardians who don’t let the bug pass undiscovered. They run automated tests, proceed with manual tests (like pressing all reachable buttons both with fingers and noses at the same time). Also, they perform cross-browser and cross-platform testing for corresponding types of project. And of course, they do accessibility tests to make sure that people with disabilities can also use the product.

UAT team

User acceptance testing is significant and necessary since on this stage we can make sure that the product is good (in terms of code quality), looks nice, etc. Yet, only feedback from end users will definitely show if it is desirable and wanted.

In order not to miss any necessary steps, we wrote the definition of done – the list of requirements for each user story, work on which can’t be completed before all these stages are passed. Here is an example of the definition of done:

  • Code Complete and pull request passed the build
  • Code reviewed
  • Internal testing passed
  • Automated tests are written and executed
  • Accessibility checked
  • UAT passed
  • Code Documentation in How To Test

Once every task from the backlog has successfully passed the above-mentioned list, we are ready to show the final version of the product to the world. It is time for the release (and keep in mind a good suggestion: never ever set it for Friday). Sure thing, that’s not the end: there will be further support and maintenance, as there is no finish line when it comes to perfection.

Now, I hope, you know a bit more about project managers, the process of product creation and some useful tips that I was happy to share here with you. However, you can still discover much more once you’ve become a part of this magic.

Project manager - CTA - Lemberg Solutions
Article Contents: