Top 5 reasons why you should go Kanban

Kanban in the Japanese word that stands for “visual sign” that can improve the flow of work process. Kanban is used in Agile way of working as a tool to visualize tasks.
It’s a board, traditionally a whiteboard but nowadays digital, which consists of cards where you can add your ideas, tasks and issues that need to be worked on. You can change the status of the cards by moving them between columns as the work progresses.
To put it in simple words it is a visual management system that helps you to keep track of circulating tasks. You may be aware of Kanban and congratulations if you are using it!

Our top 5 reasons on why you should go Kanban.

1. Agile – not just a secret for the tech industry
Agile management principles are now being adopted and implemented across industries, all over the world. The principles are as simple as likable: The empowered, learning team is the core. Involve customers and stakeholders in the process and do not wait until it is finished. The people doing the work should be the ones planning it.

Kanban has emerged as the tool of choice for agile teams as it visualizes workflows and is powered by sheer transparency.

2. Be smart, even if your workplace is stupid
The expectations on you are clear: be productive, smart, reliable and a likable colleague. The market puts increasing pressure on organizations when it comes to higher productivity and a competitive edge. Visual management can be the cure for many employees, project managers and teams. The beauty of Kanban is that it can be used to visualize practically any type of work item.

They make it possible for people to focus on the right tasks by self-organization. The board simply makes it easier for us to prioritize, which is crucial when it comes to efficiency. And even more crucial for engagement and team spirit.

3. Working together is better
True and effective engagement amongst internal or external stakeholders is very hard to dictate. There is a growing interest in how people behave in different situations and what influences our actions, from behavioral economics to CBT. For managers it is of great interest to unlock the engagement that turns your employees from drones to missionaries. The key is to access the link between formal workflows and informal information.
Kanban method is made up of 7 important principles:
4. Control through transparency
One concept of the Kanban methodology is especially attractive: By being open, you gain control. Management, regardless of industry, is the act of optimizing resources and getting people together to accomplish goals while using available resources in possible best way.

With Kanban boards, your team becomes empowered. It increases the level of self-organization to get the job done. As the level of involvement raise, so does the level of engagement.

5. You’re tech savvy enough
Nowadays, with the ease of smart devices, most of us qualify to be appointed power users of social technology, from social media to mobile technologies. The threshold to allow technology to help us manage work and life is lower than ever. You just need to accept that there are more effective workspaces these days for your own and shared tasks, and look beyond Outlook, Excel and Linkedin.
Drop Us a Line
Curious to know  how Steerco can support and help you implement agile and using Kanban? Please contact us for more information.

    [anr_nocaptcha g-recaptcha-response]

    Read More

    How Agile evolved, and is DevSecOps the next step?

    The precise meaning of the term and scope of DevOps remains a source of debate, but at a high level DevOps is the integration of the development process with operational activities, hence the name DevOps. Instead of IT operations and software development teams being siloed off from each other, DevOps breaks down the traditional boundaries that existed between them in order to achieve continuous integration and continuous delivery (CI/CD) of quality software features.


    Just as with Agile, building the correct DevOps culture within your organization is absolutely critical, however Agile and DevOps are not mutually exclusive. While Agile and DevOps share common goals, they have not always agreed on how to achieve those goals. DevOps differs in many respects from Agile, but, at its best, DevOps applies Agile methodologies, along with lean manufacturing principles, to speed up software deployment.


    One area of particular tension between Agile and DevOps is that the latter relies heavily on tools; in particular, when it comes to the automation of testing and deployment processes. But DevOps can overcome the resistance of Agile developers to tool usage simply by applying Agile principles themselves.


    The challenge is to have the Agile development teams trust in the automation efforts of DevOps, while at the same time encouraging the DevOps team to consider the business goals of deployment rather than pursuing speed of deployment for its own sake. With constant communication between the Agile team and DevOps team (another Agile principle), development can achieve a degree of comfort with DevOps tasks and processes. This means that testing and deployment automation can proceed quickly often with little to no handover at the end of a project, resulting in a decreased time to market.

    The Next Evolution: DevSecOps
    As businesses continue to integrate and expand to cloud-based services, security issues become more and more complex. One area in which Agile is lacking is with integrating security into the heart of the development process. Unfortunately in many Agile environments, application security is often something that is only looked at after development is completed rather than being a core part of the process. Enter the next iteration of DevOps: DevSecOps


    DevSecOps is focused around five basic principles

    • Customer focused mindset
    • Scale, scale, scale!
    • Objective criteria
    • Proactive hunting
    • Continuous detection and response
    With the recent changes to GDPR law, more and more businesses are being forced to take security seriously and place these requirements much higher in the project delivery. There is a big risk to organizations if they do not embrace security at the centre of their development, as the fallout of an incident could really affect not only the reputation of the business but also the financial penalties have the potential to be extremely damaging:


    “There are two tiers of administrative fines that can be levied as penalties for non-compliance:

    1. Up to €10 million, or 2% annual global turnover – whichever is higher.
    2. Up to €20 million, or 4% annual global turnover – whichever is higher.”

    While DevSecOps and Agile may also disagree about the priority of tools, security must become an integral part of any development project. This is why Agile, DevOps and DevSecOps must all work together to ensure not only rapid deployment but secure deployment. Agile and DevOps were both important evolutions of the software development process, but DevSecOps is the next evolutionary step. In our upcoming articles, we will discuss techniques that help you secure the support from senior management to implement DevSecOps.

    Read More

    The role of the Manager in Agile Projects

    We know that Scrum teams are a fundamental building block of the Agile way of working. They are where the core work gets done to deliver the remit of the Product Owner. One of the main founding principles behind the Scrum team, is that they are self-organizing teams. However, this does not mean that there is no need for managers in the organization.

    What is needed is the right behaviours and manager role in Agile in the right place, at the right time.

    How does a Manager’s role differ in vertical vs horizontal management?
    Managing in an organization that is fundamentally based on self-organization is not easy. This is particularly true if the managers have learnt their trade in a more traditional top-down command and control hierarchy and are used to waterfall planning. Waterfall teams follow the vertical structure of the organization. Scheduling and performance management is often “top down,” meaning that managers set the pace and the schedule.

    In an Agile environment, however, the team is self-organizing. It sets its own schedule based on priorities from the product owner and the available capacity and velocity of the team. The team follows the horizontal flow of the work down the value stream.

    Command vs influence approaches of leadership
    Managers and leaders have a number of critical roles in organizations deploying an agile approach. These include setting product and service directions, making resourcing decisions, integrating across teams, and helping team members with their continuous professional development. However, where traditional management relies on top-down direct and a ‘command’ approach, management in an Agile environment relies much more on influence and trust. A command culture will hinder a team’s ability to develop self-organizing skills, which are at the heart of the value Agile brings to an organization.

    Moving away from managing by control can be difficult for some managers, and learning to trust and influence can take time. However, the change in behaviour lets the manager delegate decisions to the team, freeing them to concentrate on the longer-term issues and strategy, as well as allowing them to focus on eliminating organizational barriers obstacles to the success of the Scrum teams, this in turn helps the team be more productive.

    Common pitfalls
    With the role of Scrum masters and Development managers clear, with senior leaders driving the vision and strategic direction of the organization or unit, and with self-organizing scrum teams doing the core work to deliver the remit set by their Product Owner role, what is left to do?

    In reality, not a great deal! The manager role in Agile is to ‘stay in their lane’ and help make efficiency and productivity a reality, maximizing the teams’ ability to deliver value. Agile managers do this through anticipating what their teams are going to need.

    In practice, problems arise for three fundamental reasons:

    • The managers step beyond their role boundary and start doing work that belongs to another role, often the work of the scrum team.
    • Scrum masters don’t give enough time and attention to their glue/co-ordination role across teams.  In larger projects with more than one product stream the Product Owners don’t give enough time and attention to their glue/co-ordination role across product streams.
    • Under pressure, managers revert to traditional top down waterfall behaviours.

    Putting in effort upfront to determine what work goes into which role boundary, and then using this framework to design the managers’ jobs in relation to the work of the scrum teams will pay dividends as implementation begins.

    In our next post we will build on the Agile management theme further by taking a look at how executives can use agile frameworks to manage their portfolios.

    Read More