In our last blog post we looked at our SCORE (Solution Centered Rapid Execution Process) and how it can be easily implemented to build EPM applications using the waterfall development method. But it wouldn’t really be a Promethean Analytics solution if we had to ask our clients to take one development method. With our main focus on providing the perfect solution for the client, it means we have no strict adherence to any particular DevOps methodology. Which means, yes, Promethean can use the Agile methodology to implement SCORE to get their EPM or BI application up and running if that’s their preference. Here’s how.
First, let’s take a brief look at the Agile methodology and how it affects software development. Agile originated several decades ago as a response to the inefficiencies larger organizations were experiencing with traditional software or application development methods. In the mid 1990s, development times began to lag as the complexity of business needs and their solutions began to increase. For example,an organization would find their business needs switching every six months yet their team was focused on developing solutions within 12 months. Because of this, at the start of the new millennium a new DevOps methodology was created, called Agile. What made it different was its focus on speedy delivery, rapid feedback, and quick iterations and implementations in order to build the application from its MVP (minimum viable product) into powerful tool for its end users.
While Agile is a heuristic approach to application development, how it is implemented is very much dependent on the preferences of a development team. One method is a Scrum, which is built on “sprints” that last anywhere from 2 weeks to a month long. These sprints generally start with a planning phase that leads to an intense period of development that follows with an acceptance or review phase, and after that, another sprint begins. Another method used is called Kanban, which translates almost literally from Japanese as “sign board”. The Kanban method, in its simplest form, is a 3 column board that simply has “Requested,” “In Progress,” and “Done.” From there, the board can take on many different nuances, stages, and additional levels of complexity, but at its heart it’s a progress board that benefits from its simplistic nature, making it easy for all layers. It’s simplicity makes progress easy to visualize and allows client input to be made at almost any stage.
Regardless of whether Scrum or Kanban is being used, Agile methodology truly embraces flexibility and ensuring a development process really meets the needs of the end user. Client input can be brought in at any time and even finalized parts of the project can be revisited for improvement or adaptation to a new business case. This seemingly endless amount of flexibility has made Agile extremely popular, with almost 70% of all Agile users using Scrum or a Scrum hybrid to meet their business needs.
Here at Promethean, we actually have no direct preference as to which development method to use. Waterfall or Agile, we’re comfortable with both. Even better, if a client chooses to take an Agile approach, our preference as to which method of Agile to use is whatever the client wants it to be! Our decades of experience means that our whole team is comfortable with Scrum, Kanban, or hybrid approaches of both. Since we always invite close collaboration with our clients, the Agile implementation approach to SCORE really takes off when we hit our sprint cycles as we constantly take feedback and iterate our solution to best fit our client.
Our Solution-Based Agile Approach begins in a similar manner as our Waterfall approach does. Our early engagement includes building a robust proposal and statement of work, which often involves early contact with all stakeholders. From there we begin to build out the project roadmap and set up the requirements for success. In-depth interviews and workshops commence with stakeholders and end users to understand the requirements and gain the necessary approvals. We begin to build our story backlog, setting up the initial major objectives (called “Epics” in Agile-speak) and the developments we need to get there (again, “Stories” in Agile-speak. Once we have gained client approval on all these essential pieces, our sprint cycle begins.
Each Promethean sprint cycle is tailored to client specifications. If sprints need to be 2-weeks, great, if they need to be a month long, that’s great too. Each cycle begins the same way: Examination of the backlog to prioritize tickets with client approval, revisiting each Epic to ensure progress is being made, and then divvying out prioritized tasks to expert Promethean team members to begin implementation. Progress is tracked with daily standups and constant communication within our team. Towards the end of each sprint we bring in the client feedback and encourage user testing, allowing us to find and fix any bugs and gain approval of each ticket by the approval.
The sprints will continue until the project ends, with enough flexibility to allow new tasks to be added to the requirements and integrating feedback to help reduce the time of each sprint. Once we’ve finalized all our sprints, development stops and begins deployment, with comprehensive testing and QA to achieve system certification. End user training begins immediately afterwards, also allowing us to improve the process along the way. When our client is satisfied with the results, we pick a “go live” date and get the champagne ready.
After launch, we make a point to keep detailed documentation of the whole development process, including a retrospective on release and how we got to this release candidate. Of course, client satisfaction is our top priority, and if there are additional business needs along the way we are happy to set up more sprints in order meet those requirements.
Learn more about SCORE here, and stay tuned for our next blog post.
Recent Comments