Learn how LiveAction enables SD-WAN Visibility in this featured White Paper Read Now
Skip to Main Content

7 Agile Frameworks for Developers and Engineers

In our recent whitepaper NetOps, DevOps, SecOps, AIOps…who does what and why? We look at these groups’ different areas of focus, priorities, and workflows.

In that white paper, the words “Agile” and “CI/CD” come up often to describe the priorities and practices that define DevOps. Once NetOps and other hybrid Ops were created, they followed suit, adopting the same methodologies.

What is Agile?

Agile is a delivery method that DevOps and NetOps alike can use to better organize their projects and work.

Traditionally, DevOps uses CI/CD/ CD continuous integration, continuous deployment, and continuous delivery to integrate development and operations. It focuses on the lifecycle of software or applications from development to maintenance and emphasizes automation, programmable processes, and how to maximize efficiency.

Many DevOps, NetOps, and SecOps groups also opt to use Agile as their delivery method to better organize their projects and work.

This post considers the merits and use cases of seven agile frameworks and looks at where each can be most successful.

Scrum

Scrum is a structured agile approach that utilizes sprints within fixed-length, ex: 2 weeks. The sprints pull from a backlog of product requests created by the product owner, and can also pull in or center around user stories.

Once the items are pulled in, the sprint begins. When a story is moved to “DONE” there are points awarded to the team. A scrum board is used to list the tasks selected for a sprint and to show their current status. The focus with scrum is on the team and what they are working on.

Scrum is filled with ceremonies, interesting language, and roles, the key roles are:

  • Scrum master – who fulfills the role of a project manager. This individual manages the sprint and guides the team. The Scrum Master can also determine if the team members are carrying enough points and if the team, in general, is meeting “point” objectives for deliverables.
  • Product owner- each task has a product owner associated. This is the person who created the request for the feature or improvement and represents the client or the company
  • Team members – these are the devs who work on accomplishing each of the tasks pulled into the sprint.

Scrums consist of 4 meeting types, including “daily stand-up”, a “weekly sprint review”, and a “retrospective “meeting upon the end of the sprint window. There is also a “sprint-planning” meeting before a sprint begins.

PROS

Scrum allows for visibility into all stages of a project. If you are dealing with lots of variables, uncertainty and frequently changing requirements the structure of scrum helps capture changes and pivot quickly.

CONS

There are A LOT of meetings – at least one every day.

WHO

Scrum works great for small cohesive teams that need to sustainably develop long-term and complex projects.

Kanban

Kanban is less ceremonial than Scrum and leaves a lot up to the team. Kan and ban are Japanese and translate into “signal card.” It uses a visual board to optimize flow and reduce bottlenecks. The focus is not really on the team members but on the continuous”flow” process and the result for the client.

The saying that encompasses the kanban philosophy is “stop starting – start finishing.” The goal is to cut down on the work-in-progress (WIP) time in the middle.

The visual board goes from left to right, backlog to completion, and can be subdivided by “swimlanes” horizontally for the most important to least in each column.

Here’s a simple example of a kanban board:

The board keeps projects moving fluidly with defined statuses and ownership for different steps. There are no set deadlines, the focus is on the flow of the board and continuous improvement.

These 4 standards accompany most kanban boards:

  • visualized workflow – the workflow should be easy to follow across the board
  • column limits – each column is limited to a predetermined # of tasks (except the completed column), once a task moves to the right, another can come over from the left
  • defined statuses – there should be a shared understanding of what each status means. For example, the team must decide what minimum criteria must be met for a task to be considered “DONE”.
  • an avenue for feedback: whether in forms or meetings, feedback is an important part of improving processes

PROS

fewer meetings than scrum, easy to supervise, less overhead than other frameworks, and very accessible. Can clearly see the status of the work in progress, can reprioritize as you go

Flexibility – you can add on whatever your team needs, for example, many kanban teams will pull in the MoSCoW approach for their swimlanes on the board – breaking them into Must have, Should have, Could have, and Won’t have ( which are kicked back into the backlog with a note or closed)

CONS

Does not necessarily track against company objectives, is not great for iterations, difficult to introduce a timeline or predict release dates without formalized sprints

WHO

For teams that see a high volume of requests that vary in scope, kanban offers an efficient workflow. It can also have success with larger teams, where other more structured frameworks fail. Often larger teams struggle to adopt change, but kanban is flexible enough to combine with existing methods and is easy to implement.

DSDM

DSDM also called the Dynamic System Development Method is one of the most controlled and structured agile frameworks. For DSDM to work, significant team involvement is required. There are many rules and lots of roles. Stakeholders are also usually involved throughout the entire process.

DSDM is focused on the business case of projects. The philosophy driving DSDM is that any project must align with the company’s strategic goals.

DSDM is highly managed and considers the full project lifecycle. Before undertaking a project, significant work must be completed in these three areas:

  • Pre-project: this work involves setting goals and defining the project vision
  • Feasibility: this work determines whether the project goals are possible and realistic
  • Foundations: this work agrees upon the methods that will be used and define the desired project results

Once complete, the project moves into exploration, engineering and deployment. Here’s a visual representation of the project phases:

There are 3 areas of focus for DSDM

  1. Business
  2. Solutions
  3. Advisors

Business

Business is an area of focus that looks at product vision, direction, and viability. The roles that fall under business include:

  • Visionary – has the vision and supervises the project from a high level considering company objectives
  • Solution tester – tests the product against the technical requirements

Solutions

These roles are responsible for creating a solution aligned with the requirements

  • Developer – develops the code and any prototypes for testing
  • Project manager – day-to-day project management
  • Technical coordinator – responsible for the technical quality of the project
  • Team lead – focuses on collaboration between team members and effective communication
  • Scribe – documents the decisions, requirements, and signed agreements and feedback from deliverables

Advisors

Advisor roles are people who provide feedback that supports the development process

  • Project champion/executive sponsor – who is funding the project
  • Advisor user – a user who contributes advice to the project development
  • Ambassador user – delivers client feedback on the project based on the user experience

PROS

Supports iteration development and rapid results, easy to follow the progress of projects across the organization, and business objectives are kept centered in DSDM work

CONS

The amount of structure can feel restrictive and does not encourage dev creativity

WHO

Teams that need to produce deliverables that require a tight scope and have deadlines should consider this method. DSDM can be costly to implement and has significant overhead which can exclude smaller organizations from using this framework.

Crystal

Crystal is by far the most flexible agile framework. It focuses on the people surrounding the projects and places importance on how they prefer to work and their comfort. This approach encourages collaboration and communications and is adaptive to changing requirements. It’s considered lightweight – meaning it does not require lots of documentation/reporting.

The primary theory driving Crystal is that every project has different needs and therefore the approach, strategies, and methods should also be different.

The Crystal framework uses the term “increment” instead of “release.” It considers these 4 factors in each increment date commit.

Comfort (C), Discretionary Money (D), Essential Money (E), and Life of the project (L)

For example, to determine if an increment can be completed by a certain date, the team will consider how many hours (C) each dev is willing to work on this project a week, how much money is committed to the project (D), how much money the project will cost to complete (E) and let the math determine if that deadline is attainable or not.

The crystal approach uses different practices depending on the size of the project. As the team size increases, the color gets darker, going from clear to blue.

Crystal properties

  • Teamwork
  • Communication
  • Simplicity
  • Reflection
    • Responsiveness and reporting
    • Reason for every action
    • Ease to Reverse and Reconstruct
  • Frequent Adjustments
  • Improvements

PROS

This approach lets team members work in the way that is most effective for them

Crystal encourages team communication and accountability and facilitates a transparent project flow. It can adapt well to changing requirements because of its built-in flexibility

CONS

Can be a victim of scope creep

Lack of documentation and reporting can make it confusing for people outside the team to see project status and movement.

WHO

Experienced and independent development teams who prickle at micromanagement

Extreme Programming (XP)

XP centers on application delivery to clients and involves the client throughout the development work. Unlike scrum, its iterations (or sprints) are only 1 week. It has a few additional regulations than the scrum framework, although many of these principles have since been adopted into other frameworks.

XP created the terms” “story points,” “continuous integration” and the concept of “test-driven development” (TDD). They also originated the concept of “paired programming.”

The TDD approach tests first before deployment and is more cautious than other frameworks. This has given the XP framework a reputation for releasing higher-quality products.

The continuous integration approach allows for constant application updates and improvements once available instead of saving improvements and patches for large releases.

An additional feature of XP is Pair Programming where two developers alternate writing code and observing. This practice reduces error and increases collaboration and creativity in development.

PRO

Paired development reduces errors, releasing software at small intervals with continuous testing results in superior software quality

CON

XP was designed for active software engineers, not project managers, and can be an intimidating process to people who are not actively developing code. Mandatory client participation can be frustrating and result in changing requirements. The continuous delivery and automated testing infrastructure integral to XP can also be expensive to implement. Overall, the largest complaint is that XP is just too difficult to implement.

WHO

This framework is ideal for customers with evolving requirements and focuses on short sprints and frequent releases and checkpoints to keep the product aligned with customer needs the entire way through.

Lean Development

Lean Development or Lean was created by Toyota as a manufacturing methodology.

The point of Lean is to be efficient, and fast, and to get rid of any wasteful processes or steps that do not add value.

Lean Framework focuses on eliminating waste and delivering quickly. An illustration of the 7 lean principles:

In action, you can expect a team using Lean to follow continuous integration principles, have several small batches of releases, incorporate customer feedback throughout, and focus on automated testing.

PROS

speeds up the time in which project deliverables are ready, reduces costs of the project

CONS

Team cohesiveness and discipline are critical for success, software requirement specifications (SRS) are allowed to evolve throughout the project, but that carries the risk of losing sight of original business objectives

WHO

Lean is best for small teams with small projects that need to be done in short time frames. Larger projects are not well suited for Lean.

Feature Driven Development – FDD

This framework is a gradual approach to developing software. This process follows 5 steps and begins with a product concept made up of a list of features. Once all of the features are listed and selected and prioritized, a plan is developed on how to best create the product.

The six key roles in an FDD framework include

  1. the project manager – the point person on the project
  2. the chief architect – responsible for technical design
  3. the development manager – coordinates between teams
  4. chief programmer – in charge of / leads other developers
  5. class owner – someone who develops and tests a specific feature
  6. domain expert – understands user requirements

The framework is driven from a feature perspective with the purpose of delivering working software repeatedly and rapidly. The development is planned and structured around the features required for the product.

Here’s what the process looks like:

PRO

Easy to track and report on, good for large-scale projects, simple to use with just 5 basic steps, communication mostly happens in written material so many fewer meetings

CON

Puts a lot of responsibility on a primary senior developer to be a coordinator, lead designer, etc. May not consider wider business goals or the value the project has to the end-user.

WHO

Needs at a group of at least 6 (the number of roles) and works best with autonomous senior developers who prefer fewer meetings and more independent work.

 

Conclusion

Selecting the right agile framework for your team size, project size, and objectives involves careful consideration and weighing of several variables. The one thing required to make any project framework successful is the ubiquitous ability to communicate and collaborate seamlessly wherever your team members may be. Visibility into network operations at all times is key to keeping the network under your wings and out of the way in your conference calls and daily standups.

About LiveAction

LiveAction provides complete visibility for network security and performance from a single dashboard so you can have confidence that the network is securely meeting business objectives while you work on moving your projects into the DONE status.

Talk to us about your goals today!