This document covers basic insight to applying several combinations in agile and waterfall methodologies within DevOps. Continuous attention to technical excellence and good design enhances agility. Ninth agile principle
Water-Scrum – what?
Over years of experience we have learned there is not only one perfect way of managing projects. Waterfall depends too much on outdated requirements, and goes too long between development efforts and user acceptance. While Agile is too fast paced for most end users or clients. It is alsotoo rigid to allow for changing requirements and inconsistent user feedback. By gathering feedback from project teams, and clients we have been able to come up with a blended approach to working with technology projects, especially Microsoft Dynamics 365.
Our Scrummish Waterfall breaks up the Water and Fall portion of that method and inserts Scrum in the middle to handle operations and delivery methods.
Water – The initial gathering of requirements typically performed during Statement of Work (SOW). However, this is a rarely accurate once initial discovery of a project is performed. So we maintain water as the initial discovery waterfall phase of a project before moving to a full agile method.
Scrum – From this discovery the project team and users prioritize requirements and identify dependencies. Then the requirements are transformed into user stories (see User Stories) and these are placed into a backlog. From this large list of items to be completed, the project team determines a more accurate estimate of effort to complete all items. That large timeline is broken down into manageable sections called iterations or sprints. For instance, three months of effort may be broken down into six sprints consisting of two weeks each. At this point we are breaking up project delivery into functional groupings by using agile sprints. The project team will meet daily for quick, short, non-detailed stand up meetings to cover what was done, work in progress (WIP), and blockers.
Fall – Once the iteration is complete, the project team will review the result of all the efforts to determine if we met requirements. The benefit comes from using the sprints and cards within each sprint tied to user stories. This clarifies where requirements fell off the list, who made the decisions, and where was the project team effective or inefficient during the project.
A Framework, Not a Methodology
We want to implement tools that allow project teams structure with flexibility, and that is why we chose a framework rather than a methodology. A framework allows for each project team to have their own interpretation of how the tools will be implemented. The tools used are a Kanban board, Iterations, Sprints, Functional Developers, Technical Developers, End- Users, Project Managers, and Project Sponsors or leadership teams. This document will cover mere suggestions for how a project can be managed in a more fluid manner, while still providing structure for reporting progress, risks, and change control.
What is Kanban?
“Kanban is a popular framework used by software teams practicing agile software development. It is enormously prominent among today’s agile software teams, but the Kanban methodology of work dates back more than 50 years.
In the late 1940s Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves. Supermarkets stock just enough product to meet consumer demand, a practice that optimizes the flow between the supermarket and the consumer. Because inventory levels match consumption patterns, the supermarket gains significant efficiency in inventory management by decreasing the amount of excess stock it must hold at any given team. Meanwhile, the supermarket can still ensure that the given product a consumer needs is always in stock.”
While Toyota implemented this with physical cards called kanban, this framework is timeless and applies to any industry. This is where DevOps comes in as the virtual board that holds the cards for each sprint. These digital project management tools are the visual aspect of an agile project, while allowing us to group iterations relevant to project segments of a waterfall project.
Thus we review and work within a Kanban Board.
Terminology
Below is a list of terms commonly used in these type of projects. Keep in mind these are recommendations for what the term can represent. DevOps allows capabilities to re-label most of these for each project.
Items
Any record of action to be taken within the project. An item can be a requirement, feature, risk, epic, task, change request, or other.
Epic
A large effort that will span multiple iterations. Provides tracking tasks and efforts across iterations or sprints.
Iteration
A long time period pre-determined for the project that contains items to be completed within that time period.
Sprint
A short time period pre-determined for the project that is within another iteration. A sprint contains items that will be completed by the end of the sprint. If items are not completed they are carried over to the following Sprint or dropped from scope. The product should be kept in a potentially deliverable state at all times. At the end of the sprint, the team reviews a demonstration of the deliverable product and plan next steps.
User Stories
This is simply describing the tone or formatting of a name for an item. Typical of requirements to be expressed as user stories. The structure follows: SOMEONE will be able to do or not do SOMETHING when accessing SYSTEM/FORM/NETWORK. This helps all project team members keep the priority on the user experience. This also provides clarity to the user who expressed the requirement.
Requirement
A request from client for functionality or technical capabilities.
Feature
A request for specific user experience or process that should come across.
Task
Lowest level item, represents actual work to be completed. Typically roles up to another item.
Risk
A scenario, event, or resource that is trending negatively or could indicate impact to the project causing undesirable outcomes.
Change Request
A change to scope, existing functionality, existing requirements, system or network that will impact the project.
Backlog
A backlog is a list of all of the item types just reviewed in the previous section. Theitems can have relationships that show Parent to Child, or dependencies or just a connection. Everything starts in the backlog. Each sprint is built from the backlog. Any new items are created in the backlog and then moved to a sprint.
- Product backlog contains all items for the product being implemented.
- Sprint backlog contains all the items assigned to a given sprint.
Work in Progress (WIP)
Any tasks being actively worked on during a sprint.
Blockers
Something that is preventing the completion of work. Must be resolved to move forward with task.
Estimate of Effort
This is an estimated plan based on our understanding of processes and functionality at a 10,000 ft. view (Epic level). At this time we have not:
- Gathered all user stories
-
- Their detailed task requirements
- Performed relative sizing
- Applied MoSCoW to requirements for prioritization
- Must Have
- Shoud have
- Could Have
- Won’t Have this time
- Aligned resource availability, holidays, etc.
These bulleted items are started with meetings during Sprint 0, and they will continue until the team has agreed they have covered the details.
There is an approach to capture all of the detailed requirements in an extended Sprint 0 (4+ weeks… or whatever you need to get the job done). However, it may be best to hold these meetings while also working on building tasks in order to show a tangible product of what was being captured for requirements. Either way, take into consideration that Dynamics is a rapid deployment platform that can be configured relatively quick, and the goal is to keep a full Product Backlog that you can apply to your Sprint Backlog. Otherwise, you have resources looking for work after the 1st week into a given sprint cycle.
Change is Constant
The plan is subject to change once you start capturing task level details – DO NOT allow anyone to hold you to this plan prior to completing user story/requirements gathering meetings! It’s important as the PM to be clear about this expectation. The idea of this methodology is to allow us to quickly pivot when new information arises, without incurring major technical debt. Also, while considering the black hole around potential integration and migration details.
Team Effort
Our approach works because we develop it together. Agile frameworks are just that…
The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self–management, and the flexibility to adapt to emerging business realities.
Try not to follow this in lockstep. Work on this as a mixed team (when appropriate), client and vendor working side by side. The overall goal is that we get buy-in from all levels of the project (project team and executive sponsor levels). The best results come from engaging the client as a whole, not just functional or technical. The team approach combines business minded users or functional consultants with technical developers. This promotes collaboration, communication, flexibility and most of all plain old functioning software.
A Modern Architect
The concept of a software architect came from a young field looking for relevance to an established business world. The metaphor to a structural architect is not ideal and having been taken so literal has caused problems within software development teams. The traditional architect works with buildings made of concrete, once the foundation is laid, their work is completed, and the structure of the building will not change. Software is almost completely opposite of this where once the foundation is laid, the design has just begun and will continue to change until it is no longer useful.
The building metaphor has outlived its usefulness… If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach…
The secret is that it is grown, not built …
Harlan Mills proposed that any software system should be grown by incremental development… Nothing in the past decade has so radically changed my own practice, or its effectiveness…
Therefore, with this framework the architect, as a technical leader, is not as hands-off as before. The architect provides technical expertise in the form of mentorship and hands-on engagement with development. The design of the project comes from looking at the requirements as a whole, at the time they are being implemented, not as they were during “discovery”. For example, the design of an integration should be grown, nurtured, and revealed during the process, and like a garden weeded at times.
“Design is pulled from demand rather than speculatively pushed .”
Digital Gardener
As for “Digital Gardener,” that idea comes from a blog I read a while ago . It brought up the idea that our job titles are misnomers and misguide us in our efforts. When computers came of age in the 70s and 80s, the job titles copied what we knew, which was the construction business, with engineers, analysts, architects, etc. However, as we have grown the comparison to construction does not fit anymore. Our buildings do not stand in one place with the internal structure forever. They are ever changing, always moving, and even the core structure must be flexible to handle and adapt to change.
Therefore, we must change how we design and develop solutions. We should set boundaries, and plan for growth, anticipating changing landscapes, yet always protecting from issues or weeds, not just bugs. In this setting we become Master Gardeners who don’t set firm foundations but build for the ground for gardens to grow, they don’t control weather, so they regularly plan for the unknown. We should be better at tending and managing change as a constant rather than a disruption. That is why I want to be called a Digital Gardener rather than an Architect.
