Kanban

An Agile Hybrid Approach – What to Consider

Posted on by

an-agile-hybrid-approach-what-to-considerMany practitioners and project managers look toward creating an agile hybrid approach by doing a mish-mash of waterfall with agile methodologies. However, what we are going to look at are the different agile methodologies and the ones that are actually compatible with each other. It must be said, that for any team about to proceed with tailoring different agile components, it is something that should be done with expert practitioners who understand the pros and cons of adding more than one methodology into practice. It is advisable that a solid team of expert agile coaches and scrum masters are present on such a team so that the evolution and benefits can be implemented effectively and safely for the entire team.

Agile Frameworks Compatible in Creating a Hybrid Framework

1- Scrum

Most members of an agile team know agile by way of the Scrum framework, but what most have yet to see is that although it presents a solid framework for complex projects, it could use the help of other methodologies. What we can take from Scrum however, is the concept of building backlogs with work items that get listed in priority. The second automatic component is the importance of a Product Owner who actually owns that list and ensures that they represent what the stakeholders will expect. This is done through prioritization of the backlog for the rest of the team so that a potentially deliverable product is completed and accepted by the stakeholders by the end of each sprint.

2- Extreme Programming (XP)

From this methodology we can gather the best practices for the development team including Refactoring, Test Driven Development (TDD), continuous integration (CI) and collective ownership. What we tend to see in these practices are the concept of work process that is conducive to the flow and efficiency of the work being done.

3- Agile Modeling (AM)

This methodology is usually considered an effective addition to most of the other agile methodologies. It has mainly two components: Modeling and Documentation. The Modeling component encourages best practices such as Just Barely Good Enough (JBGE), Architecture Envisioning, Lookahead modeling, Active Stakeholder participation, and Model Storming among others. The Documentation aspect covers the necessity of documenting continuously (not to be understood as documenting excessively), document late, executable specifications, and single-source information.

4- Unified Process (UP)

Over the years the Unified Process has taken on many forms, mainly the Rational Unified Process (RUP) from which it derived directly and sometimes is mentioned interchangeably. However, other examples include OpenUP, and Agile Unified Process (AUP). What needs to be considered is that UP is not just a process but an actual framework. What makes it useful is that it’s highly customizable with characteristics covering an iterative and incremental development process, architecture centricity and risk focus. From this framework we get 4 phases that are used for creating a project, namely in the following order: Inception, Elaboration, Construction, and Transition. Much of what is used in the Disciplined Agile Delivery (DAD) framework has adopted this but DAD has also added to this.

5- Kanban

From the realm of Lean practices, we get Kanban. This method framework builds on the concept of Just-In-Time (JIT) at its base, but it has many tools that derive from it, one of them being the Kanban Board. The Lean aspect comes with the concept of limiting work in progress to prevent waste. Along with that comes the concept of visualization of progress. With the use of Kanban, the level of product quality becomes optimal since all areas of waste (Transport, Inventory, Motion, Waiting, Over production, Over processing, Defects, Skills) are removed. Along with that, the high level of visibility of progress that the development team is something that is of utmost importance. As most who have practiced Agile will see, the aspect of visibility is a very important characteristic to creating and maintaining team synergy.

There are certainly other methodologies that can be put in the mix, but it must be considered that tailoring an agile hybrid approach is an art, not a science. That is to say, if key components are added from one project to the next, it will likely not create the same results for every project. There are many other factors that come into play, and would not simply be a matter of methodologies used, but also the variation of players involved, that is certain to change the project landscape at any moment’s notice.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

 

How to Manage Epics as an Agile Tool in Planning

Posted on by

how-to-manage-epics-as-an-agile-tool-in-planningAs part of a large project, you may have a complex product to develop. Whether for intangible (software, games) or tangible (hardware, electronics), there is a need to structure your backlog by level of complexity and size. Although we typically do not go so far as creating Epics in all agile instances, they can prove to be a handy agile tool if created and used in an organized fashion.

The idea behind Epics are to create a sense of commonality between multiple user stories. It is important at this stage to be sure your agile team members are not using the terms for Epics interchangeably with other terms that could drive confusion in day-to-day communication. But along with this defined approach, all team roles (product owners, business analysts, scrum masters, developers, etc) should think of Epics structures and how they will be used going forward. Here we look at Epic examples in hierarchies for Features, Themes or Requirements.

Features in Epic Hierarchies

One way to look at an Epic is to identify it as the high-level feature. As an example we are referring to the physical features of a landing page on a website. It would have a header, footer, content, images, media, etc. With that you can further breakdown the characteristics with user stories, and then tasks to look like the following:

Epic(Feature) —> User Story —> Task(s)
Example: Header —> As user, I would be able to use a search bar to search the site content… —> Investigate Search Bar functionality

Themes in Epic Hierarchies

Epic —> Theme —> User Story —> Task(s)
Example: Landing Page —> Page Structure —-> As a user, I would see 3 columns… —> Create left column, Create right column, Create center column

Requirements in Epic Hierarchies

If you were developing a series of websites for instance, you would need to repeat a set of requirements for each website. In this case you would likely re-use the requirements as you start each website, and then vary those features. The following example would facilitate re-use of the requirements from one website to the next.

Epic(Requirement) —> Feature —> User Story —> Task(s)
Example: Website Landing Page —> Website Page Navigation —> As a user, I will be able to navigate to all site pages from the landing page… —> Create Navigation Bar

There is no definite way to use Epics, these are simply examples. The variations can be infinite and can vary from team to team, project to project, or product to product. But as we know that Epics are typically large user stories, and represent a level above the user story. One thing that needs to remain stable is that the agile team must agree to structure that makes sense for them.

Using Epics to Stay Organized

Using Epics as an agile tool to organize the stories, can enable easier overview of the different product components (features/requirements/themes). As the sprint backlog can list tasks to be developed by multiple agile working teams on different features at the same time, the overview of each Epic can help the Product Owner prioritize stories and interlinking dependencies with each other.

Another useful setup that helps in the structuring of swimlanes for your Sprint/Kankan boards is to have them created according to your Epics. This makes the horizontal divisions clear on the common groupings. It also adds another dimension to manage on your board, but it certainly would be helpful in larger sized projects.

The most important part in creating structures, is to keep it simple. If there is too much team discussion and confusion where everyone is lost in managing the structure, it means that it’s not simple or clear enough. Of course, if all else fails, keep in mind that Epics are not essential. If your team doesn’t see a need for them to exist in your agile product management scheme, just leave them out, as they might not be required due to your project not being as large or complex as originally thought.

[Image courtesy of Danilo Rizzuti at FreeDigitalPhotos.net]

How to Define Your Kanban Workflow Management

Posted on by

Whether or not your workflow management tools include a kanban board with a workflow process via an actual (low-tech) office wall or having a (high-tech) virtual agile software board, you want to avoid having too much WIP (work in progress). If there is too much WIP, you may create too much waste or risk in the form of lagging partially completed work, or excessive waiting. Furthermore, excessive WIP will also cause blockages to be obscured and hidden.

Here’s an example of a comprehensive status workflow automation from beginning to end:

New –> Open –> In Progress –> Code Review –> Code Committed –> QA Ready –> QA In Progress –> QA Passed [or] QA Failed –> UAT Ready –> UAT In Progress –> UAT Passed [or] UAT Failed –> Closed/Done

A more simplified (and recommended) view of this workflow process would look like this:

To Do –> In Progress –> Done

how-to-define-your-kanban-workflow-management/In either workflow solution, it is in everyone’s best interest to place WIP limits. Before your sprint would start, you should be able to determine based on the story points and team size what the typical limits should be as per the agile team roles and team members. These can then be calculated and factored to represent the overall WIP limits for your board to prevent too much clutter. However as you can guess, the comprehensive example above or any type similar to it, would be the most difficult one to set limits to, since the stories would be scattered everywhere across multiple statuses.

Like any complex procedure, it is best to break it down into smaller parts. A simplified board should be used as your dashboard view to get a consistently general view of progress.  Once you’ve scaled down your board as much as possible the WIP limits will become easier to manage. A notable mention is the status “Blocked” which can be shown with a more specific indication of which workflow the block occurrence came from, i.e. Blocked in Dev, Blocked in QA, or Blocked in UAT. This will further allow for a quick response to the blockages.

The example given above assumes workflow management processes are happening simultaneously, but it would certainly be more appropriate to create some workflows in later sprints or specific milestone date if you knew, for example, that UAT was coming at a much later time. The key is to keep it simple.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]