Effective Project Management in Agile Environments
One thing I have learnt the years spent managing projects is that there is not just one way to manage a software implementation. Every project brings its own flavors of people, attitude, organization structure, operational and financial feasibility. However, it must be said that Agile implementation does work, and it works because it introduces 2 very important things… accountability and timeliness. When you do things in short sprints, you want to see something tangible and therefore everyone involved is expected to be committed. Traditional development methodologies do not account for the fact that business and rules governing business these days are changing rapidly. Therefore, if you did things in sequence where you gather all requirements, design, develop and demo to the end user as part of user acceptance, there is a likely hood that the requirements have already changed and what is being shown is no longer relevant. These are known things already. There is an important advantage with using a traditional approach like Waterfall and that is “Structure”. The purpose of this article is to provide example of what we have done on Agile projects to help with structure. We combined a few principles of waterfall with agile to provide the right balance on complex implementations.
Let’s break is down… with every project, there are 3 to 4 steps to always need when managing a software project i.e. Discovery, Design, Development and Testing.
Discovery is the first phase of an implementation methodology. The objective here is to get a clear understanding of the project scope & detailed product deliverable. The outputs from this phase include:
Project Charter: a guiding document that should be held to test the confirm compliance with scope
RACI Chart: a document that identifies the primary stakeholders and what each role/person is responsible for
Project Schedule: now that the scope is confirmed, a schedule that makes sense to track. Key to not over complicate this by making it too detailed and/or long. Remember, you must manage this through the life of the project. So simple is better!
Detailed Requirements: a unambiguous narrative statement that explains the functionality that must be covered with the implementation that the business stakeholders can review and understand. Ideally, this must be by module so that that document does not turn to be very large.
Design phase focuses on defining work that will be performed to deliver the required functionality. This phase includes multiple project definition activities. The key is to not make this a documentation hell but document visually, important aspects of the system using MS Visio or similar software. The outputs from this phase include (obviously these will vary depending on the specifics for the project):
User Stories or Backlog items: where the detailed requirements are decomposed into lines items/functional
Business Architecture Diagram: end user perspective of what the different modules will cover in terms of business functionality
Detailed Data Flow/Cross Functional Flowchart: a step-wise depiction of flow and transition points based on decisions taken using the proposed system
Technical Solution Architecture Diagram: diagrammatic flow of events in a system. For example, if you are using Angular within .NET core framework, the solution architecture will show the communication between the Angular modules and the Web API calls.
Application Architecture Diagram: technical breakdown of the application into logical layers
Database Architecture Diagram: a high-level conceptual mapping of the relationship between entities involved.
Security Architecture Diagram: depiction of identity management for the application
Deployment Architecture Diagram: depiction of how proposed production environment for the application in the cloud or on premise or a combination
Operations Architecture Diagram: depiction of the deployment or release management process from the developers to the different environments using a continuous integration/continuous deployment model
Project Bill of Materials (BOM): a spreadsheet containing the technical design specifications in the form of server spec, firewall rules, reverse proxy settings
Low-Fidelity Wireframes: to provide a structure for the main pages in the application
UI/UX Style Guide: a document to specify theme, colors, fonts, UI component settings etc.
The idea is to do Discovery and Design in sequence and regardless of the project size, these two activities must not take more than 2 months to complete. In-fact, by the end of the first month or as soon as you have the requirements detailed in narrative format, the framework level development must begin. This will focus on building common components that are needed to build sprint specific functionality once you begin the Development phase and need to execute development using sprint cycles. The idea is to build the accelerator for development in month 2 along with the architecture documentation.
Development phase is the process of actualizing the stories or backlog items into functionality. This will be the longest phase in most hybrid implementations. It will also be the most important phase. Work in this phase will include extending the framework to meet the specific requirements of the project. The idea is to approach development using multiple iterations. Iterations will be highly recursive phase of the project where you need to actively collaborate with the client resources to ensure the functionality meets the project goals. The outputs from this phase include:
Sprint Planning
Functional Modules
Unit Testing Results
Key point here is to plan the length of the iteration carefully. Too short may not give you time to development something of value and too long may not provide the advantages of agile implementation. Remember, the premise of any agile implementation is… it is better to be roughly right than to be precisely wrong!
In my opinion, a 2-week sprint provides the right balance. Week 1 is for development followed by week 2 for testing. Begin the sprint on a Monday and end on Friday. For long weekends, begin on Tuesday and still end on Friday or Begin on Monday and end of Thursday. Demo for the completed sprint will be on Monday following the end of the sprint. This gives the right balance for the dev team where they are not forced to cut corners to meets the objectives of the sprint demo. Following the sprint demo, the completed functionality can move through the UAT process for 1 week and any defects resulting from the UAT must be logged during this time. The dev team must be empowered to assess if they would like to take any of these defects as work items for the next sprint. This will ensure there is continuous improvements as the development progresses. Depending on the volume of UAT defects, the development team can assess if they need to pause the sprint and address the defects before moving to the next sprint.
Suggested approach to maintaining a balance between development and defect resolution