devopsy.kinsta.cloud

Tag: kanban

  • Pushing Beyond Agility: The Kanban Maturity Model

    Pushing Beyond Agility: The Kanban Maturity Model

    Kanban is not a novel idea. It is a well-practiced and known method for organizations to increase productivity and efficiency, reduce the lead time of processes and improve delivery flow. However, historically Kanban has been frequently misunderstood.  Many people think that Kanban is just a whiteboard with stickies in columns of to-do, doing, and done. Or just a visual representation of a board in their agile tool. This resulted in many organizations missing out on the full potential of Kanban.

    The Kanban Maturity Model (KMM) is challenging this idea by defining certain steps for growing the maturity of the organizations that use the Kanban Method. The KMM collects and summarizes a decade of experience applying Kanban across diverse industries, in businesses of all sizes. By codifying these experiences, it addresses two common problems experienced in Kanban and agile implementations: overreaching and plateauing. We see overreaching when organizations or teams learn about some interesting practices and try to take them on before they are ready for them. While the practices have shown to be valuable in evolved environments, when taken on too early they can backfire. Plateauing happens when improvement levels off as the original problem that initiated the change initiative is abated. While there have been some improvements, there is potential for significantly more improvement. The KMM addresses this by identifying a road map and coaching tools for taking teams or an organization to the next level of improvement.

    As defined by Teodora Bozheva, Kanban trainer and consultant, and co-author of the “Kanban Maturity Model” with David J. Anderson, “The Kanban Maturity Model provides guidance for developing cultural values and management practices that enable enterprise agility, better customer satisfaction and business outcomes. It is an organizational maturity model that helps organizations evolve their agility and resilience.”

    The KMM maps Kanban practices as well as cultural values against seven organizational maturity levels. At first sight, the KMM may look complex. However, by advancing through the different stages, organizations are helped in a variety of ways with a road map to achieve their improvement goals.  For example, it can help relieve staff from overburdening, make processes more predictable and sustain a balanced workflow. In addition, businesses can deliver faster to market, align around a shared purpose and strengthen organizational values.

    When used in conjunction with software technologies such as Kanbanize, a Kanban automation solution for Agile Project Management, the model helps users fully optimize the workflow across all business functions and bolster the full intent of Kanban. Kanban software solutions and the KMM are stronger together. When companies simply invest only in Kanban automation solutions, they lack the required guidance and resources to fully maximize such tools. Similarly, without the automation of processes, insights and metrics provided by Kanban software technologies, deeper organizational maturity on the KMM scale is difficult to achieve.

    KMM: Understanding the Maturity Levels

    Transitioning from individual gain to the long-term company goals, each level represents a different step in the organizational journey toward agility with Kanban. The seven levels are arranged based on the company focus, main values, how stable the business is and what benefits it receives from Kanban. It is important to understand that each level of the model includes transition and consolidation practices. The transition practices are key to getting past the plateau and helping move from one level to the next,  causing the company to reflect on what can be improved in the process. The consolidation practices are then pulled to achieve the outcomes that the maturity level describes.

    Level 0 – Oblivious

    If your organization is not aware of the need for a structured work process, you are at maturity Level 0. Most organizations at this stage do not have a systematic approach to organizing the way they work and have a difficult time applying Kanban on a team level. At this stage, organizations typically visualize work on a personal level using either a physical or online Kanban board.

    Level 1 – Team Focused

    At maturity Level 1, team members already have built the habit of using Kanban on an individual level. After individuals start to recognize the advantages of simple workflow visualization, it is time to transmit the benefits of Kanban from an individual to a team level.

    An indication that an organization has initiated the transition toward using Kanban at the team level is that the work from the personal Kanban boards is moved to a shared team Kanban board using per-person swim lanes. This way, team members will easily recognize their own tasks, but at the same time, have an overview of what others are doing.

    An important step at this stage is to define and visualize initial policies. These are norms or rules that the whole team agrees to follow for the sake of normal functioning and improving work processes.

    Level 2 – Customer-Driven

    So far, your team should have an understanding that using Kanban helps to boost collaboration and bring transparency to the work process. The next step is recognizing the workflow. In other words, the team starts to understand what and how things are done and realize the need for a defined work process. The goal is for workers to understand what is expected of them and what they can expect of their colleagues with a shared vision of what finished product should look like.

    However, at this stage, while the process, policy usage and decision frameworks are consistent, there is still inconsistency of the desired outcome.

    Level 3 – Fit-for-Purpose

    By the time a company reaches maturity Level 3, they get a deeper understanding and better definition of their processes, workflow, policies and decision frameworks. It is important that the whole team agrees on all of them and understands how they help them achieve better results.

    As you start to outgrow maturity Level 2 and begin the transition from a customer-driven to a “fit-for-purpose” process, an organization becomes better at meeting customer expectations in a sustainable manner, as well as balancing upstream and downstream flow. The steps for maturity should be dedicated to complete alignment of the organizational requirements and processes needed to consistently meet customer expectations with predictability, a fast and balanced workflow, actionable metrics and shorter lead time.

    Level 4 – Risk Hedged

    Maturity Level 4 introduces risk-hedging practices, data-driven decision-making frameworks and use of predictive models. At this level, organizations embrace a model-driven management approach to strategic planning that anticipates risks, forecasts outcomes and results in consistent economics. All these improve overall business economics and robustness against unforeseen events and exceptional circumstances.

    Level 5 – Market Leader

    At maturity Level 5, not only have design, implementation and service delivery become routinely “fit-for-purpose,” the business is now entirely “fit-for-purpose” from a shareholder and end user perspective. The focus of this level is now on continually optimizing the workflow for efficiency and improved economic outcomes without sacrificing quality, increasing margins, minimizing costs and optimizing the value of work done.

    Level 6 – Built for Survival

    The deepest stage, maturity Level 6, is when a business can be established as “built to last.”

    The business is capable of questioning and assessing:

    • Is the way we do things still competitive?
    • Are new technologies, processes, methods or means becoming available that we should be investigating or adopting?
    • Do we offer the right products and services? and if not, how should we change?
    • Are we serving the right markets? Do we have the capability to serve our chosen markets adequately?
    • Who are we as a company? Is our current identity relevant and appropriate, or do we need to reinvent ourselves?

    These questions are strategic concerns, and the answers can help establish capabilities and services that align with the broader company strategy and bottom-line.

    A Road Map for Business Resiliency

    Over the past few years more and more people have learned, understood and applied the Kanban Method correctly and demonstrated significantly improved results. Knowledge work of all forms, from operations to project management to product innovation, the use cases and impact of Kanban across industries and business functions are extensive but sometimes underutilized. The KMM provides a greatly detailed map on how to take your company from a shallow practice that helps sort out individual needs to a fully functional business model. When adopted in conjunction with Kanban automation software, the KMM enables organizations to evolve and improve processes, business outcomes and customer expectations, and drive business resiliency and robustness.

  • Enterprise Kanban Implementation: Where to Start and How to Scale Across an Organization

    Enterprise Kanban Implementation: Where to Start and How to Scale Across an Organization

    The Evolution of Kanban 

    At its core, Kanban is a management method designed to improve customer satisfaction by creating fast and reliable workflows capable of delivering products and services of superior quality.

    Kanban originated in the automotive industry of Japan and was originally developed as a method for improving manufacturing efficiency at Toyota. However, at the beginning of the 21st Century, key players within the software industry realized that Kanban could be used to positively change the ways in which products and services were delivered.

    The result is astonishing. In less than a decade, Kanban has become the most popular tool for software development and IT teams, surpassing the Scrum framework, which has been the de-facto standard until recently. According to the State of Scrum survey, 60% of Scrum teams utilize the Kanban method, which is a testament to the benefit it brings.

    Kanban left the realm of the automotive industry and conquered the IT world, but now, with an increased focus on flow and by harnessing advances in computing technology, it is about to expand its reach to the entire business. Leaders all over the world have realized that Kanban has the most flexible architecture that allows it to scale across the enterprise in a natural and human-centric way. More and more companies are embracing the Kanban “start with what you do now” principle and are on their way to true business agility. But, how do you go about that exactly?

    A Bit of Expectations Management

    Managing an enterprise Kanban implementation starts with expectation management. Senior leaders that sign off on multi-million dollar budgets for agile transformations should be informed that business agility is a strategic choice and not a one-off project. No company in the world has ever managed to become agile overnight. There’s no shortcut to that, nor is there a recipe to follow.

    Even if your company is doing well, unless you push hard to improve, sooner or later your competitors will catch up. So, in terms of expectations, people should know that there is no “we’re done” state. The constant, never-ending process called continuous improvement is what makes you resilient in the long run.

    If there’s one area where Kanban really shines, it is continuous process improvement, which will almost always lead to qualitative and quantitative overall improvements. Applying Kanban to a process will typically drive up to 2000% improvement—and that’s not a typo. Scale that on a company level and let the numbers speak for themselves.

    Start with What You Do Now

    Once an organization has made the decision to implement Kanban, it can be tempting to jump quickly into building the system itself without conducting a thorough analysis of enterprise operations and processes. As a first step, it is vital that organizations assess their current situation to understand where concrete improvements can and need to be made. This includes aspects such as:

    • Processes: Is production stable and predictable? Answering no to this question doesn’t mean you can’t properly create and scale Kanban in your organization, but it does mean that you need to put some extra buffer and flexibility into your planning. 
    • Involvement and Investment: This is where the notion of scale is important. A company-wide Kanban would be immensely more effective than local implementations, but it will require involvement from senior leadership and a significant budget. It is often a good idea to start small, learn fast and then go full speed.

    Kanban’s flexibility allows it to be overlaid onto existing workflows, systems and processes without disrupting what is already successfully being done. It will, naturally, highlight issues that need to be addressed and help to assess and plan changes so their implementation is as non-disruptive as possible.

    Kanban’s versatility allows it to be introduced incrementally, and sympathetically, to all types of organizations without fear of over-commitment or culture shock. This makes Kanban easy to implement in any type of organization as there is no need to make sweeping changes right from the start.

    If you are starting on a smaller scale with a goal of growth, once the Kanban mentality is put in practice and successfully functioning, it is important to set goals for future scale—six months, one year and three years down the road. If you conduct a pilot where Kanban is embraced and productive, don’t lose time and momentum waiting to deploy it across the rest of your business or enterprise. 

    Training

    Training is an aspect of Kanban implementation that is often overlooked. It is important for the team designing and implementing the system to consider every level of user across the organization. What seems logical, obvious and understandable in the context of a planning meeting may not prove to be so on the shop floor.

    While a well-designed Kanban system may appear visual and obvious, end users who don’t understand the theory behind it, will not always trust it. This is especially true for mature employees who are accustomed to doing things a certain way based on learned habits. When introducing Kanban, put yourself in the shoes of someone who does not know anything about it and may not initially embrace the idea of change. As straightforward as Kanban should be, if the end-user is not on board, it won’t work.

    Training resources such as Kanban University offer certified Kanban courses and a global network of resources for organizations to help onboard employees and users at every level, build awareness and assure quality in Kanban implementations. Upfront and ongoing investment in such training teaches organizations how to fully maximize the value of Kanban, and train them to understand and visualize systems of work to continually improve and deliver effective results. 

    Past the Team Kanban Phase

    If you do Kanban right, many tough questions will have to be answered, including, “How do you connect the high-level strategy with the goals on a team level?” and “How do you bridge the gap between planning and execution?” The good news is that Kanban has an answer for these questions, too.

    Kanban integrates naturally with strategy deployment frameworks such as Hoshin Kanri or OKR. All you have to do is use Kanban across every level of the organization. Practice shows that companies would typically use three flight levels. The lowest level is the team level, where work gets done. The second is the coordination level, and the third is the strategic level. All levels are connected to one-another, so that strategic initiatives (level 3) are broken down into projects (level 2), which are then broken into work items for the teams to work on (level 1).

    When you “Kanbanize” all three levels and connect them into a single whole, then you get an extremely powerful management tool with the following benefits:

    • All work is visible, starting from the very top to the very bottom.
    • Impediments across all levels are explicit.
    • There is bidirectional feedback loop between all flight levels.
    • The senior leaders can quickly change the course of the whole company.
    • Much more accurate and reliable status reports that are based on real data.
    • Through the usage of proper Kanban tools, the data gathered on the team level can be used for forecasting on the project level. This helps leaders take informed decisions.

    Driving Enterprise Agility with Kanban

    The demands of businesses, customers and markets will always change. And in response, businesses must be able to quickly pivot and adapt to meet shifts in expectations and requirements. Successfully implementing Kanban across an enterprise requires a deep understanding of the theory that stands behind it and upfront investment to determine the best approach to make it work within the context of unique organizational challenges and objectives. When implemented and designed appropriately–with buy in and support at every level–Kanban enables enterprises to be agile amidst change, continually improve vital processes and the ability to scale to meet the demands that tomorrow can bring at a moment’s notice.

  • Syncfusion Releases Essential Studio 2020 Volume 1

    Latest version brings new Kanban, Progress Bar, and Card controls to comprehensive Blazor suite

    Research Triangle Park, N.C., April 09, 2020—Syncfusion, Inc. announced today the release of Essential Studio 2020 Volume 1. The highlights of this release include new Kanban, Progress Bar, and Card controls in preview for the Blazor suite and the move of 11 other Blazor controls from preview to final release. The Essential JS 2 suites also gain three new components, and the Xamarin platforms receive a plethora of new features to improve existing controls.

    “Our developer community continues to be very enthusiastic about our growing Blazor suite and this latest release responds to that demand by offering some of the most requested Blazor controls, such as the kanban board,” said Daniel Jebaraj, CEO of Syncfusion. “Our commitment to offering quarterly product updates allows us to deliver the latest and most requested features to our growing community.”

    Syncfusion’s native Blazor components library contains over 65 high-performance, lightweight, modular, and responsive UI controls in a single package. Updates in Volume 1 include:

    • Kanban—allows users to visually organize and prioritize work, and manage workflow transparency.
    • Progress Bar—allows users to visualize the changing status of an extended operation, such as a download, file transfer, or installation.
    • Card—offers a flexible and extensible content container with multiple variants and options like headers, footers, media, content, and actions.

    Syncfusion’s Essential JS 2 suites receive new Kanban, Progress Bar, and Dropdown Tree components in this release. A few other release highlights for the web platforms include:

    • Resource view support for the Gantt Chart control (JavaScript, React, Vue).
    • Infinite scrolling support in DataGrid and batch editing support in TreeGrid (ASP.NET MVC, Angular).
    • Web layout support for Word Processor (React, Vue).
    • Native template support for HTML shapes in Diagram (ASP.NET Core).

    Syncfusion also continues its dedication to the Xamarin platform with new features such as trend line support for the Charts control. Xamarin.Forms now comes with WPF support for the DataGrid control, while Xamarin.Android and Xamarin iOS are enhanced with a current time indicator in the Scheduler control and row- and column-span support for fields in the DataForm control.

    These are just a few of the new controls and features in Essential Studio 2020 Volume 1. Explore the entire list on the What’s New page. Existing customers can download the new version of Essential Studio by signing into their accounts. Those interested in trying Essential Studio can download a free 30-day trial. Syncfusion Essential Studio is a software product offering 1,600+ components and frameworks that can be used in Visual Studio and Visual Studio Code for developing stunning applications.

    About Syncfusion, Inc.

    Syncfusion is the enterprise technology partner of choice for software development, delivering a broad range of web, mobile, and desktop controls coupled with a service-oriented approach throughout the entire application lifecycle. Syncfusion has established itself as the trusted partner worldwide for use in mission-critical applications. Founded in 2001 and headquartered in Research Triangle Park, N.C., Syncfusion has more than 22,000 customers, including large financial institutions, Fortune 100 companies, and global IT consultancies.

     

  • The 5 Core Principles of Lean Management

    The 5 Core Principles of Lean Management

    Lean project management is rooted in cost-saving manufacturing methodologies. The ultimate goal of lean methodology is to reduce waste. Companies in all industries have adopted lean principles into their own processes, but lean is most suited toward physical manufacturing, engineering and related industries.

    Regardless of your company’s size or the activities of your organization, lean project management principles can be extraordinarily helpful in optimizing your everyday operations.

    Below are the five core principles that guide lean thinking for project managers.

    Identify Value

    Defining the value of a given product is crucial. Before beginning any manufacturing project, or any project for that matter, the amount of value a finished product will generate must be assessed accurately. How much customers expect from a given product must also be ironed out.

    Value questions that lean teams will ask:

    • What do customers want?
    • How will they benefit from our product?
    • How much are they willing to pay for the benefits of our product?

    Lean teams can, for example, estimate how much customers are willing to pay based on related data points, then set costs low enough to reach an agreeable price. The goal is to eliminate all waste in every process. Any area where value is not added—or worse, cost is exceeding value—must be addressed early on using lean management principles.

    Map the Value Stream

    The value is the end goal of the project. Once you’ve established value as a definite endpoint, you can begin mapping the way to get there (or value stream). Every single process and every single step involved in getting to the end product is part of the value stream. From gathering the materials needed for production to coordinating efforts with PR, every related process is represented in the value stream.

    Kanban is one of the most popular ways to map value streams. Tasks are broken down and are posted in a “just-in-time” fashion. That way, each task is taken one at a time and only done when it is absolutely necessary to complete.

    Using Kanban flowcharts and other diagrams, managers can set up visual aids for value streams, mapping every single step onto a single page. By mapping the flow of activities, lean project managers can easily identify waste and inefficiencies with the process, allowing them to ameliorate these issues swiftly.

    Create Flow

    By mapping the value stream, project managers can spot waste. Any tasks that are done too early, too late or too often creates waste. By analyzing the map and removing waste, lean project managers can create the optimal flow of activities.

    Lean project managers check for possible bottlenecks and delays. If there are any inefficiencies present, tasks may have to be reordered. Sometimes, project managers may even decide to append value-adding tasks to improve processes.

    Ideally, every step should flow into the other, beginning at the factory (or organization) and arriving smoothly as an end product to the customer.

    Employ a Pull Approach

    Many organizations use a push approach, stockpiling supplies in anticipation of demand. Lean organizations, however, employ a pull approach, wherein production increases as demand increases. Customers can “pull” directly from the manufacturer, getting what they need in an on-demand fashion.

    The pull approach requires extremely accurate market research and exceptionally efficient dissemination of information within the organization. Also, all processes must be streamlined; otherwise, it will take too long to ramp up production to meet demand.

    Seek Perfection

    At its core, lean management is about continuous improvement. Lean management requires a thoughtful approach to every action. Optimization must be part of the corporate culture itself. Every member of the organization must be working toward removing waste, adding value and delivering quality. There is always room for improvement in lean organizations.

    Conclusion

    Lean organizations are removing waste. Lean project managers ensure that activities within the organization flow properly, without interruption, delays or bottlenecks.

    Identifying value means finding out what your product will do and how much customers will pay for it. Value streams are then mapped, following every step in production. Project managers ensure that tasks flow and processes run smoothly. Market data is collected during development and these data points drive production. The most important principle that guides lean thinking is to seek perfection. The lean management philosophy demands a dedication to continual improvement.

    — Ellie Martin

  • Kanban for Operations and Traffic Court

    Kanban for Operations and Traffic Court

    Howard stepped off the elevator and into the lobby. His eyes were puffy and felt like someone had scrubbed them with sand paper. Looking around the office, he made a beeline for the coffee machine. It was one of those fancy jobs where you use a touch screen to select all the different flavors, textures and aromas. Howard thought they all came out tasting like boiled socks. As the last few drops of black sludge dripped into the mug, Lisa peeked her head around the side of the machine.

    “Getting ready for stand up?” Lisa asked, eyeing Howard’s coffee.

    “Getting ready for life.” Howard grumbled as he headed towards the stairs. “You coming?”

    “To stand up, yes. To life, not until I have some of this delicious coffee-flavored oatmeal. See you upstairs.” Lisa said, putting a cup into the machine and starting to make her first of 30 mandatory selections.

    Howard strolled into the Operations area, starting to feel a little more human with some coffee in him. Looking around, he spotted Paul hunched over his keyboard, typing furiously. His desk was in its standard form of disarray. Empty Diet Coke cans covered the desk, with a few crumpled in the middle like fallen soldiers on a battlefield, the other cans standing around the crumpled ones in mock solemnity. The keyboard was one of those mechanical DAS keyboards with the blue keys, so it made clicking noises as Paul’s fingers danced across them.

    “Good morning Paul.” Howard said as he lumbered to a stop beside Paul. Paul raised one hand in a warding off gesture.

    “Can’t have any more interruptions or I’ll never get this done. See you in five minutes at the stand up.” Paul said without looking up. With that, his hand flew back to the keyboard to join the other, like a juggler taking in another bowling pin and seamlessly integrating it with the ones he is already juggling.

    Howard nodded and shuffled off to large Kanban board on the wall of the Operations bay. It was a large screen projecting the digital board onto the wall via a small Raspberry Pi. Howard was quite proud of this board. It had taken some time to convince the team that they could use Kanban in such an interrupt-driven world as Product Operations. The team went through several iterations before coming to the current board on the wall and even now they were willing to make changes.

    All new tickets for the team funneled into the backlog column on the left side of the board. These were automatically marked as untriaged. The team would review these tickets in the morning stand up and then prioritize them as a team. This excluded emergency tickets which were closely inspected. Emergency tickets would enter directly into the Expedited Lane of the board, and the team would swarm them until completed. Those tickets were almost exclusively the domain of outages and customer impacting events. New tickets filtered in through either email or the BOT in the Operations Slack room.

    The team began gathering around the board to review and prioritize the tickets in the backlog. Howard noticed that there were a few tickets in the active column that he didn’t recognize. He made a mental note to ask the team about this after they “walked the board.” The team took turns reading the new tickets in the backlog, and they discussed the work effort, blockers, dependencies and perceived priority of each. The tickets were then rearranged to be in order of priority with highest on top. Next they worked from left to right, with each person explaining the tickets they were responsible for.

    “I noticed that there are a couple tickets in here that were not there yesterday and were not covered in the triage. How did that happen?” Howard asked before everyone drifted back to their desks.

    Chris Fallon, known simply as Snark to everyone else, spoke up. “Those are the ‘important people’ tickets, boss. They are the ones we get from the constant ‘drive-bys’. You know, when an exec or a sales person steps into your cube and tells you that this is going to be the next big thing that makes millions.”

    “Wait a minute.” Howard said, turning to look at Snark. “I thought we all agreed that we would only take tickets in via the backlog, unless it’s an emergency.”

    Snark laughed, “Yeah, well, they seem to think their poor planning and ineptitude is somehow synonymous with being my emergency.”

    Howard took a deep breath and said, “OK, we can’t do this or it undermines the process. When this happens, it’s like the person standing over your desk is saying their time is more valuable than yours. That is simply not true. Let’s take the guidelines we all agreed upon for expedited tickets and print them out. We will put them up on the wall and the next time someone comes up with a ‘favor to ask’ point them to the rules. If they still don’t let up on you, point them to me. We have to be fair, though.”

    Howard thought for a long moment and said, “OK, here is what we will do. We will hold daily traffic court for anyone that puts in a ticket. This is completely optional, of course, but if the person feels like it is an emergency, and yet doesn’t meet the qualifications, they can come to the stand up the next morning and plead their case. If it seems like the need is real, the team can agree to put that item above all the other items to be next pulled into the Kanban process. This doesn’t mean we swarm it like an outage, but they do get to the top of the pile. Thoughts?”

    Everyone silent for a moment, and then the agreed. Everyone but Snark, who continued to look up at the ceiling, apparently deep in thought. At last he lowered his eyes to the group and said, “This will work, IF you get the right people on board first AND you support all of us in sticking to the rules.”

    Howard nodded and said, “I already have a mental list of the people we will need on board. I’ll get that taken care of today. Can you write this up and get it up next to the Kanban board?”

    “I’m on it.” Snark said, and turned with the rest of the team to leave.

    The concept of the traffic court ended up paying dividends in ways Howard hadn’t counted on. It turned out that, much like regular traffic tickets, people didn’t want to invest their time to come in and argue the case with the court. Instead, they decided to take the easier route of just paying the fine. This was their opportunity cost; time over money was the same as time over prioritization. There were cases where people would show up and win or lose their case. In the end, Howard and the Operations team began to understand who was just wanting to jump line and who had a genuine need. It was no surprise that each type tended to be repeat offenders. Over time, the ones exhibiting negative recidivism, began to learn that their behaviors were time-consuming and not being validated. Their behavior didn’t change but how they actively interacted with the team did and thus the outcome was still the one Howard’s team wanted.

    — Pauly Comtois

  • 5 Team Skills That Make DevOps a Success

    5 Team Skills That Make DevOps a Success

    When starting their DevOps journey, your team will discover it needs to develop some new skills. Most likely the team is good at typing code and solving issues, but what about the soft skills?

    Many teams have to learn how to deal with issues themselves—as self-supporting teams, there is no longer a manager who will help them out and tell them what to do.

    During the Phoenix Project DevOps business simulation, the majority of teams discover collaboration and communication are skills they lack. I am often surprised how few people can really facilitate standups, retrospectives, Andon-sessions and other communication methods.

    Here are the five team skills that participants recognize as core skills they learn (or could learn) during the simulation.

    The Standup

    The standup is a very powerful way to share knowledge about certain issues. The team will stand together for a short time and discuss an issue that blocks the flow, needs clarification or needs to be high priority. So, who should initiate this standup and who should lead it? I’ve noticed a lot of participants find it very difficult to manage this standup initally, but after a few times the team discovers the key elements of a successful standup:

    • Chose a facilitator. Someone who is leading this session. It doesn’t matter who (it doesn’t have to be a manager).
    • Share the focus: What are we going to talk about?
    • Keep it short (time is ticking).
    • Make sure we all understand the outcome.
    • The importance of listening and engagement.

    Facilitating a Retrospective Session

    DevOps is also about continuous learning and experimenting. One of the important steps in this process is retrospective. This activity explores the past round of work and reviews what went OK and what needs to be improved. Again, during the simulations I discovered that not many participants know how to execute this activity. After being shown the right example, the team often can perform this activity themselves. This is what teams learned during the simulation:

    • Someone from the team must facilitate this process.
    • Make sure the improvement is supported and understood by the whole team.
    • Test the improvement before to applying it.
    • Record the discoveries—this becomes part of the visual management system and part of the team backlog of improvement needs.
    • This team skill is one of the skills that more than one team member should be able to execute.

    Managing the KanBan

    During a project, teams sometimes will have standup moments to discuss the work visualized on their KanBan. Work will move from backlog to doing and done, and new priorities will change the order of work. During the simulation participants will take the lead in this process, but some don’t find this easy. After the sessions they discover:

    • Use standups to discuss the changes on the KanBan, make sure the team is fully involved when moving notes around.
    • Challenge participants to share their thoughts. Saying “yes” doesn’t always mean “yes.”
    • Errors are made, but that doesn’t mean somebody has failed and should be punished. Keep the session safe and open.
    • The KanBan is a form of visual management system (VMS). The VMS is not the goal—it is an instrument and must help the team to visualize flow, limit work in progress, drive productivity through an awareness of what people are working on and continuously improve the process.
    • Make sure at the end of the session, all participants know what’s agreed.

    Managing an ‘Andon’ Session

    ‘Andon’ is a very powerful instrument to explore a situation that stopped the flow. As soon as the flow stops, someone “pulls the rope” and the team “swarms around” to investigate the error and try to continue the flow as quickly as possible. This session should be led by a team member; it doesn’t matter who. During this session, the team discovers the following learning:

    • Make sure the session is short and focused on fixing this blockage and restarting the flow.
    • Make sure we are not blaming each other; it should be about exploring what stopped the flow, fixing it and agreeing how to prevent it from happening again.
    • Make sure the whole teams swarms around and participates.
    • Create a safe environment.

    Collaboration

    Doing the work is not always easy. Sometimes we don’t know what to do. Sometimes we need help, and sometimes we are not happy with the actions of a team member. This is what collaboration is all about.

    One of the first aspects of collaboration is helping each other. But, this is not always effective. Sometimes it’s even disruptive or we just take some work from somebody else if we think he is too busy. Here’s what participants learned about collaboration during the simulation:

    • We have to avoid “compensational behavior.” This is about taking other people’s work with the intention to help the other. Sometimes this person doesn’t know you took the work and he or she does it again, creating unnecessary double work.
    • Collaboration is about shared goals and shared processes. We should all know what we are doing and how.
    • It’s also about clear roles and responsibilities. If you know what your colleague is doing, you know what you have to do. And the other way around.
    • You must have an open team culture in which it is also safe to say you don’t know and to ask for help.
    • Collaboration is fun, and it gives energy if we as a team achieves something.

    Conclusion

    I have visited many global DevOps conferences in the previous years and have listened to numerous speakers declaring, “It’s all about people.” And they were right. Unfortunately, the audience often did not get many useful answers.

    A high-performing collaborative team needs team players who know how to deal with the collaboration and communication issues themselves without needing management intervention.

    Teams will have to go through the stages made famous by Bruce Wayne Tuckman (Forming, Storming, Norming, Performing and Adjourning) to become an effective, collaborative team.

    Continuous learning is a key success factor and a critical competency for any DevOps team. Why not start this learning journey in a safe and challenging environment?

    A simulation such as the Phoenix Project is a very powerful instrument to teach teams how to collaborate and become high-performing. The environment is safe and feels like the real work environment. Participating in this simulation with an actual team allows you to capture and agree on actions to takeaway. Outcomes can easily be transferred to day-to-day work.

    I wish you a lot of soft skills.

    About the Author / Jan Schilt

    Jan Schilt is owner of GamingWorks. His background is Human Resource Development (MSc). Within GamingWorks he is responsible for Business Simulation design, Facilitation and Train the Trainer. He is also an expert in developing learning activities related to organizational change. He builds all the simulations and has delivered more than 300 workshops worldwide.

     

     

     

  • Why Is There No DevOps Manifesto?

    Why Is There No DevOps Manifesto?

    Let’s start with a brief story:

    There’s a scene in a movie called “A Few Good Men” in which a lawyer is questioning a cadet. The lawyer directs the cadet to turn to the page in the thick Marine Code Manual that explains where to find the canteen. And the cadet replies, it isn’t in there.

    And the lawyer says, “Well, you eat, don’t you?”

    And the cadet says, “Yes, sir, three times a day!”

    The meals for everyone aren’t served by the book because the canteen isn’t included.

    This isn’t a history for the term DevOps or of the many people who’ve led, presented, written and interviewed about the DevOps movement. I’ve got a footnote below with some pointers for that. This is simpler than that: It’s why today there is no DevOps Manifesto and why I don’t think there will ever be.

    Now, I think I understand the desire for a DevOps Manifesto. I’ve met a lot of folks, company executives and analysts, who still dis DevOps a bit because it lacks a certified definition, an official manual or a definitive statement. Basically, a manifesto; you know, a canonical thing you can put on a shelf.

    Manifestos can be nice. They lay down the vision, the intent, the mission. They can appeal to a wide range of people, from revolutionaries to functionaries to dignitaries. It isn’t for sparking conversations so much as for orderly setting down of intent. A manifesto can bake in the meaning and content of something.

    A manifesto has that “rule of law” book feeling to them. Manifestos also have provenance and pedigree—some group of some renown sat down to discuss some topic for some specific resolutions and wrote the sum of it up. Manifesto wording can be checked to ensure real-world compliance.

    You can almost slap a copy of a Manifesto on a table to settle an argument about the manifesto’s topic. And assuming the words were crafted carefully enough, it will be the end of discussion. And that’s exactly the problem with a manifesto with respect to DevOps.

    I say: That’s not what DevOps is about.

    DevOps begins with stopping the nightmare scenario pitting Ops against Dev—or any other part of the organization. But it comes so much further. It’s for a new age of computing at webscale, using tools, teamwork and techniques to get to better, happier, more engaged outcomes for customers. Some of it is so new we are still figuring out words for it.

    The DevOps movement isn’t slowing down, either. Analysis of the Google results page shows it:

    DevOps searches over time Sep2015

    In all of this time, no one of any significance in the community has attempted to create a “manifesto for DevOps.” I’d say the Godfather of DevOps himself, Patrick Debois, was super insightful on how he went about ensuring no official manifesto could get written. (I’m not going to review the lessons learned from “The Agile Manifesto,” although good lessons were learned from the things created in the wake of having an Agile Manifesto.)

    If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.

    As Andrew Clay Shafer (@littleidea) said recently, DevOps is about optimizing for people. With the pace of IT and tech ever accelerating, no manual or manifesto could keep up. Which reminds me of one of my favorite quotes:

    Companies die because their managers focus on the economic activity of producing goods and services and they forget that their organization’s true nature is that of a community of humans.

    — Arie De Geus

    One thing you should know for sure about DevOps: The community likes to enhance, educate, enliven, inform and energize people. Basically, everyone is wide open to embracing anything that helps out because webscale is hard. So yeah, DevOps now aligns with “microservices” because microservices can further the DevOps cause. Just like kanban, Docker containers, automated configuration and InfoSec. And anything that enables Dev and Ops to deliver more, better, faster to customers. It’s about serving the customers.

    Meanwhile, if you’re looking for more, you’ll usually find a bunch of folks … figuratively speaking … over in the kitchen at the canteen, serving up awesome and working hard on doing it better and faster.

    And everyone interested is welcome to sit down and enjoy what’s served.

    Seriously. Join in. You do not need a manifesto to.

    P.S.  It was with deep hesitation that I wrote this. There are simply so many awesome people who’ve made all this happen and I am not one of them. Literally the finest collection of technologists—and in many cases, human beings—I have the honor to know who make this community what it is.

    You should check out, in no particular order:

    • The amazing (and amazingly modest) Patrick Debois
    • The writings and teachings of Mark Burgess (one of the most under-recognized geniuses I have encountered)
    • The CALMS write-ups by John Willis (@botchagalupe) and Damon Edwards (@damonedwards)
    • Damon’s five-minute video on DevOps history
    • John’s frank exploration of the issue of burn-out in IT (and that is directly related to why we are having DevOps conversations)
    • Mary Poppendeick’s lean development work
    • John Allspaw and John Hammond’s 2009 Velocity keynote that sorta kicked this whole thing off
    • Ben Rockwood’s (@benr) comprehensive LISA11 keynote
    • The many videos of Andrew Clay Shafer (@littleidea) and his brilliant guidance. Sometimes with katana and sometimes with gattling gun.
    • Jez Humble’s books (particularly “Continuous Delivery” and “Lean Enterprise”)

    And works from folks including:

    • Jeff Sussna (@jeffsussna)
    • James Turnbull (@kartar)
    • Adam Jacob
    • John Vincent (@lusis)
    • Bridget Kromhout
    • Adrian Cockcroft
    • Gareth Rushgrove
    • Kris Buytaert
    • J. Paul Reed
    • Ernest Mueller
    • James Wickett
    • Ines Sombra
    • Karthik Gaekwad

    I mean, this is a global phenomenon, were you expecting a short list? This isn’t even complete!

    Oh, and the VisibleOps guru Gene Kim, who came and showed us all a way to really blow the doors off the DevOps news.

    These people are helping all of us do better Dev, better Ops, better IT, better business so that you can have better customers. It’s amazing. It really is. And it’s wonderful.

    Also, if you get a chance to spend time at a DevOps Days anywhere, you should.

  • 4 Ways DevOps Teams Create Value.

    4 Ways DevOps Teams Create Value.

    Sven Malvik – I’ve written thousand of lines of code based on lies, lies I hoped were the truth. The truth is that we make false assumptions. Assumptions that kill our business. I’ve built software that was too expensive, I’ve built software nobody wanted, and I’ve built software that never saw the light. If you are like any other developer you probably have lied too. But it doesn’t matter. What matters is the application we haven’t built yet and that we will build based on the truth. We need the truth to create value and to survive. This article will show you 4 ways of how DevOps teams create value.

    (more…)

  • Think you’ve established Kanban? Why you might only be halfway there

    Think you’ve established Kanban? Why you might only be halfway there

    As a Lean Coach working in IT I often hear development teams refer proudly to their scrumboards as an example of Kanban. To which I say, ‘that’s a great start… but it’s really only just the start’.

    Let’s start with what a scrumboard is, and does. A scrumboard is a visual display of work, showing the progression of user stories in development. As you see some stories moving through the phases of development, and others getting stuck, you huddle to figure out how to get them unstuck. Now you’re using your visual display for visual management, which is a great Lean solution.

    Change management boards, like the one used in The Pheonix Project, are another good example of visual management. The physical display of changes, shown by release date and system, is a great way to get a handle on the amount of change and risk you’re throwing into live production. When you start moving them around to limit the risk, again, you’re using visual management.

    The word ‘kanban’ roughly translates as ‘signboard’, and a scrumboard really is a good start. But it’s only half the story. Until you limit the number of stickies on your change management plan, or the number of story cards on your scrumboard, you’re really only half way to kanban nirvana.

    True kanban requires you to limit the amount of work in progress and to establish the pull of work. In a manufacturing plant, a kanban card is attached to each unit in production. When a completed unit is, say, taken off the shelf by a customer, the card is sent back into the production line to signal that there is now an empty slot on that shelf which needs replenishing. Limiting the kanban cards sets a constraint around the amount of work in progress – and this limit should reflect the capacity of the process. In the same way, you can limit the number of story cards, boxes on your scrumboard or spaces in your change management plan. When a scrumteam complete a story that frees up a slot for them to pull the next story into their workload: the visual display should reflect this by showing each team’s capacity. In addition to visual management, you can create rules around work in progress, requiring each scrumteam to limit their intake so they have no more than, say, two workpackages in progress at a time.

    This is all well and good, but what do you do when demand from the business requires a greater capacity? Historically you’d have thrown that extra demand into the mix, asking your teams to do more with the the same amount of resource, maybe pushing back a release date to accommodate the extra work.

    Kanban requires you to create additional capacity in the system to allow for the additional demand either by:

    • rebalancing the load, for example switching some resources from a work package that is ahead of schedule
    • removing or deprioritizing other work and putting work on hold
    • increasing resources by bringing in new team members

    All of these actions will generate some churn, so it’s going to be worth a tough conversation with your customer first. ‘Are you sure you want me to disrupt the current sprint, or the next release, to squeeze this in? How about we pick it up next week, when we’ll have some new capacity?’ By limiting your work in progress, you’ll be speeding up the flow of development into production, so you can make that ‘next week’ promise with increasing confidence.

    So the next time you walk over to that scrumboard, why not take the next step, and limit the work in progress to truly establish kanban.

  • In Support of DevOps: Kanban vs. Scrum

    In Support of DevOps: Kanban vs. Scrum

    The Kanban software development methodology is getting a lot of attention as of late, particularly for its ability to enable DevOps. Some organizations are even going so far as to move from Scrum to Kanban to improve efficiencies. We use Scrum at OutSystems, since we’re doing feature development that requires stakeholder feedback. The sprint lock and end-of-sprint demos to stakeholders are invaluable to us. But I was curious to see how the two methodologies differ and how Kanban may further enable an organization’s move to DevOps. Here’s what I found.

    There are two key differences between Scrum and Kanban: the rules and the workflow.

    The Rules

    Both software development methodologies provide rules for how work is performed. If your organization uses Scrum, then you know that it is quite prescriptive. Agile Advice lists 23 mandatory and 12 optional rules for implementing Scrum. These include, for example:

    • A product owner creates and manages a product backlog
    • Teams are cross functional
    • Interruptions are prohibited during sprints
    • Work is time boxed
    • Scrum meetings are held daily
    • A burn-down chart is used to measure progress

    Taken together, these rules create a fairly rigid box in which teams must operate in order to be successful with Scrum. As I see it, this presents two big challenges. First, few organizations actually follow all of the rules, leading to what is called ScrumBut – We practice Scrum, but… ScrumBut means a company ignores specific Scrum rules for internal reasons, leading to a suboptimal use of the framework.

    Second, at the core of Scrum is the time box. Time boxes are good for providing distraction-free time for developers to deliver the product, and define regular milestones for stakeholders to evaluate and steer the project. But, from a DevOps point of view, these artificial delivery checkpoints break the flow. Coordinating dependencies between sprints and ensuring their successful move to production becomes a big challenge.

    Kanban, on the other hand, is less restrictive. Its rules are as follows:

    • Visualize the workflow
    • Limit work in progress

     With only two rules, Kanban is an open and flexible methodology that can be easily adapted to any environment. (Some companies are using it across the entire organization – from manufacturing to marketing.) You can add rules as needed, borrowing from Scrum, if you so wish.

    The focus on the flow instead of time boxes makes Kanban an attractive choice to use with DevOps. Deploying work items becomes just another step in the process, and with its emphasis on optimizing the whole delivery rather than just the development process, Kanban and DevOps seem like a match made in heaven. With the contrast in rules understood, let’s look at the workflow.

    The Workflow

    In addition to rules, the workflow differs in Kanban vs. Scrum. This is a direct consequence of the rule sets. In Scrum, you decide beforehand what features will be completed in the next sprint. The sprint is then locked, the work is done over the course of a couple weeks (the usual sprint duration), and the queue is empty at the end of the sprint. Locking the sprint ensures the team has the necessary time to work on a problem without being interrupted with other apparently “urgent” requirements, while the feedback sessions at the end of the sprints ensure stakeholders approve the delivered work and steer the project as the business changes.

    In Kanban, you do not have the time constraints of a sprint, and the focus is on making sure the work keeps flowing with no known defects moving downstream. However, limits are placed on the size of the queues. This means that a maximum number of features or issues can be worked on at a given time, allowing the team to focus on delivering those work items with high quality. Making the flow visible creates a sense of urgency to keep things moving along. Note that Kanban was born in manufacturing, and its big focus is on productivity and efficiency. Kanban has to be extended in order to incorporate fundamental aspects of software success, such as stakeholder participation.

    Enter DevOps

    Organizations that adopt DevOps are looking to increase efficiencies, deploy features more frequently and be more responsive to business demands. You can see, then, how each methodology addresses various aspects of DevOps to greater and lesser degrees. Choosing one over the other isn’t cut and dried. Here’s what I advise:

    If your team is responsible for feature development, which requires stakeholder feedback, and developers need to focus, Scrum is probably a better fit. The sprint lock and end-of-sprint demos to stakeholders can be invaluable.

    If your team is responsible for maintenance and tends to be more reactive, then consider Kanban. There is no need to lock your backlog and you have more flexibility to respond to customer input.

    Ultimately, every team is different. You know where your team excels and where it needs extra guidance. I suggest you borrow from both methodologies to give your team just what it needs to achieve DevOps’ goals.

    About the Author

    Rodrigo CoutinhoRodrigo Coutinho is Principal Software Engineer, OutSystems. A member of the founder’s team at OutSystems, Rodrigo has a passion for web development, great products, and geeky stuff. He spends his time designing future versions of OutSystems Platform and dreaming about the cool future of the web.