Skip to content

Why solution architecture and what are Agile, Scrum and Kanban?

Why it is now essential to have appropriate solution architecture frameworks at work?

In current ever expanding IT environments, organisations have experienced number of challenges to their IT programs, including cost overruns, re-starts, and delayed implementations of the projects. There might be various factors contributing to those challenges but it is a big challenge to govern those projects without a viable and mature Solution Architecture (SA), so research has shown that Solution Architecture is critical to the success of an IT program.

Most organizational executives are still in shadows and couldn’t figure out how and where Solution Architecture fits in the technology projects. It is important to clarify this vagueness.

By definition “Solution architecture is a practice of designing, describing, and managing the solution engineering in relation to specific business problems” according to AltexSoft

But to be more specific, Solution Architecture captures and communicates the “big-picture” vision of these project/programs to key business and technical stakeholders, facilitates integration of the contracting, infrastructure, and systems engineering activities and fosters collaboration between technical and business stakeholders.

Well let’s explain this in simple mode…

In mid 90’s when we were young programmers & analysts, we used to gather requirements, plan and produce system analysis documentation which took around more than 70% of the project timeline. Designing and coding software was mostly 10% of the overall duration. And in addition to those changes in requirements from the clients was a big headache of the project teams that had to undo whole process again. This created a lot of confusion and traction between business and development teams resulting in mismanagement of the project and most likely failure of the projects. On top of this there was a big question in the business world that “How to translate business requirements to technicians?” The first people to look at are project managers and analysts that worked on analysis stages who spoke a language completely different from the one engineer spoke. Normally programmers were people who like solving tech problems not business problems which created a gap between planning and coding even deeper.

This created a need for someone who would take the technology leadership, of a high-level view on the problem, and suggest a solution expressed in a language accessible to technicians. Since today most development teams use iterative and agile methods like Scrum and Kanban that solve the problems of long planning process involved during waterfall periods. But to bridge the gaps between requirements and technology, it was essential to address the second problem – communication difference and thus this practice was dubbed as Solution Architecture represented by a Solution Architect that can interact with highly efficient and dynamic technical teams mostly daily to articulate customer needs and feedbacks. Initially there were simply Enterprise architects and Software architects but later in mid 2000s the role of Solution Architect emerged between a wide enterprise perspective and a narrow tech perspective.

Mostly in organizations there is lack of a mature and viable solution architecture that can be due to several challenges including:

  • Solution architecture is not well defined, and is neither standardized nor used consistently across IT programs.
  • Solution Architecture best practices have not been fully incorporated into organisation’s processes and guidance.
  • Solution Architecture is not integrated with agile development approach.

It’s important for organizations in 21st century to be more adaptive towards technological changes. To compete in current technological advancements the need to integrate a mature and viable solution architecture should be the no 1 priority for every organisation moving forward towards future.

Let’s now get to understand what are all these terminologies like Agile, Scrum and Kanban are:

Agile

 

 

Agile is popular nowadays most things that are marketed as Agile misses the actual point of what Agile actually is?

Everything is Agile, Agile methods, Agile development, some will say it is a methodology of developing a software and even there are Agile products nowadays.

The actual meaning of Agile found in the Agile Manifesto. This manifesto clearly roots out that Agile is not a – methodology, specific way of developing software, framework or process.

Agile actually is a set of values and principles and most of it has to o with following different practices, using various methodologies, and even developing a specific tools. Agile team is only agile if they are following the Agile set of principles and values that the team has setup in the first place. So basically Agile is really a collection of beliefs that teams can use for making decisions about how to do the work of developing software. Agile manifesto stresses on valuing on the things like:

  • Individual and interactions over processes and tools,
  • Working software over comprehensive documentation,
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

In addition to these values Agile manifesto has set out 12 principles that support the values that gives the ability to make a good decision in a particular situation. These principles are:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

So basically the practices of a team by following the Agile principles and values make the teams more robust and resilient. These practices that teams use can change frequently will depends on the question they might ask “Why they are using certain practices?” for example a team might start with SCRUM and later find that KANBAN is a better fit for delivering value to their customers.

Thus practices might change from time to time depending on the requirements, but by making decisions following Agile principles and values are mostly important that make any team or a person Agile.

SCRUM

Now let’s see what actually Scrum is:

According to Scrum.org “Scrum is a simple framework for effective team collaboration on complex projects” and it simply adds “Scrum is not a methodology because it is flexible”.  To understand scrum we must start with its three major pillars:

  1. Transparency
  2. Inspection
  3. Adaptation

And Scrum’s 3 primary components are:

  1. Roles
  2. Events and
  3. Artifacts

1. Roles

Scrum defines specific roles:

Product owner: 

Responsible for defining and sequencing the work that is to be done.

Scrum Master:

Responsible for keeping things organized and helps remove impediments that could slow down the development team. This person will make sure the project is moving smoothly and that every member of the team has the tools they need to get their job done. Sets up meetings, monitors the work being done and facilitates release planning. It’s a lot like a project manager but with a modern fancier name Scrum Master.

A Development Team :

This team does the work, this could be developing software or other types of work

2. Events

Then Scrum defines a number of events:

Sprint:

A sprint is time-boxed fixed length iteration, typically 2 weeks in length, but no more than 4 weeks. Whatever the length of iteration is chosen, the team sticks with it – it doesn’t vary from iteration to iteration. The whole team collaboratively defines a scope of work to achieve a goal or business objective that is valuable to the product owner and then makes their best effort to complete that body of work during the sprint. They may succeed or fail to complete all the work, but the Sprit rhythm remains same either way. Unfinished work can be assigned to the next sprint if it is still valuable to the product owner. In some teams the sprint may be referred to as an “increment”

Sprint Iteration Planning:

It is where the team defines the work and the goal they want to achieve in the upcoming Sprint. This is a collaborative effort and involves the whole team having discussions about what a valuable return on investment has and what is possible to actually accomplish within the bounds of the Sprint.

Daily Face to face meetings (Daily Scrum):

Teams following agile principles will adapt this because it helps keep everyone focused on the agile principle of face-to-face communication. Normally these meetings are timed to 15 or 30 minutes max. In some cases team speak up one by one explaining about the tasks they did yesterday and plans for today and point out any obstacles/opportunities they may have encountered.

Sprint Review:

This is a collaborative meeting to show what was accomplished during the sprint and get feedback on the work shown to stakeholders. For example with software development, this includes some type of demo with the goal to provide true transparency (one of the pillars of Scrum) on what has been done. As people inspect what was accomplished they provide feedback that can be used to adapt the way work is done in the next sprint to provide the best return on investment possible.

Sprint Retrospective:

This is the meeting where team gets a chance to reflect on how things have gone and how they can be improved. This event is based on Inspection and Adaption pillars of Scrum.  For Agile teams, this event is one of the ways teams follow the principle that says they should reflect on how to become more effective and adjust accordingly.

3. Artifacts

Final component of Scrum are the Artifacts. These artifacts are:

Product Backlog:

It is the list of things that the product owner wants or thinks they may want. In software, this usually is an ordered list of features with the things Product Owner sees as producing greater return on investment are at the top of the lists. These list are also called user story for eg: As a (role) customer, I want to login to system (feature) so that I want to save my documents privately (benefit). The collection of all these user stories is called the product backlog. The product backlog is the source for the Sprint Backlog.

Sprint Backlog:

It is the set of items that have been selected for the Sprint. The Sprint backlog is populated at Sprint Planning and it helps keep the team focused on just what is needed for the current sprint without the added noise of everything in the full product backlog. The Sprint Backlog provides a great deal of transparency in understanding the progress being made toward the current sprint goal.

One of the most important things to remember about sprints is that the goal of each sprint is to get a subset of the product backlog to a ship-ready state. The late finish of the sprint is a great indicator that the project is not on schedule and something needs to be done. Therefore it is extremely important to monitor the progress of each sprint with a Burndown Chart. It is one of the best visibility tools to ensure a project is progressing smoothly. This provides a day-by-day measure of the amount of work that remains in a given sprint or release. The burndown chart provides empirical proof that the project is on track or if it’s going to be late. 

Increment:

It is the thing that is actually delivered. For example, it might be a new release of software with all the new features that were completed in the Sprint. This increment should be something that is potentially be shippable or deployable. This means it needs to fully meet the definition of done with all the proper testing and cleanup that would be necessary to start getting a return on investment from it.

If we combine these altogether and simplest way to think of Scrum is as two loops. The outer loop is the two-week iteration with the planning, review or demo and retrospective occurring on a rhythm of every two weeks, each iteration is inspected and the next one is adapted to try to make it just a little bit better. Within this two week loops is a 24 hour loop that starts with daily Scrum meeting and is also focused on providing transparency so the work done tomorrow is adapted to make improvements based on what we’ve learned today.

Now let’s dive into Kanban

KANBAN

So what really KANBAN is?

It is a lean scheduling system developed in Japan by Toyota Motors and is a popular framework to implement agile principles. A Kanban system utilizes visual cues that tells us what to produce, how much to produce and when to produce it. Its typically like a menu where there is an item, quantity and price and the customer selects the items and how many of them in the menu which they like to be served on entrée (first), mains (second) and desserts (third).

Kanban systems usually start with a board and visual cards that represent items in the product backlog containing the user stories. The product backlogs and user stories are similar to that we explained in the Scrum methodology. On the columns you can move the user story cards that represent their current step in the workflow ranging from “New task” to “Completed task”. 

The steps in between are completely depends on the range of project complexities, but it is better to keep it simple and efficient.  The visual nature of the board makes it easier to visualize what’s in progress, what is going to be started next and what features are completed. To ensure the items are completed in steady pace Kanban imposes limits on the number of items that can live in the workflow step at any given time for example: in-progress column might hold only 4 items at one time (these are also called WIP limits), team cannot start the new task until in-progress task is moved to the right. This will help to visualize the bottle neck if the no of new task is keep increasing and next column is empty but things are not moving in the middle then there must be something wrong with some of the tasks in progress. Then the team can immediately work together to get things sorted to keep the pace of the work moving and delivering products to customers.

Well there you go if you understand then things become much simpler .. now we know Why solution architecture and what are Agile, Scrum and Kanban ? right? 

Leave a Reply

Your email address will not be published. Required fields are marked *