Table of Content
While Enterprise-scale agile adoption continues to grow, the practices that define it are often misinterpreted. A recent Gartner report points out that many application delivery leaders erroneously equate “doing agile” with “being agile.” The two are easily confused. As a result, business application leaders often assume that by integrating Atlassian JIRA Agile project management tool into their development process, or simply using burndown charts or user stories, they introduce ‘agility.’
This article discusses the true nature of agility. The difference between adopting the agile culture or agile tools is like the difference between holding a medical degree or a stethoscope. Understanding this can make or break your agile transition. If you are an enterprise IT leader with agile on your 2018 agenda, we recommend reading this article to learn more.
The Difference Between Doing and Being
The report goes on to discourage leadership from religiously following a sprint-based methodology like Scrum, warning that It can ultimately hinder an organization’s overall agility.
Agile is a culture and a ‘mindset’ so to speak. Scrum is a formalized process. The original premise behind Scrum was to accelerate product delivery. However, leaner, less structured initiatives such as DevOps and continuous delivery are more focused on value. These initiatives introduce a holistic approach to application delivery. It encompasses all aspects of the organization such as business users, integration and testing. Not just software development.
————
You might also like our blog
From DevOps to Agile to Enterprise Agile Delivery
————
Agile Methodology: Scrum Vs Kanban
What is Scrum?
Scrum is a well-defined process framework for agile project management. It involves cross-functional teams working in iterations. Scrum teams include two unique roles. The Scrum Master oversees method enforcement. The Product Owner oversees product definitions and represents customers’ interest.
Scrum teams meet regularly for iteration planning, daily status updates, and sprint reviews. This can easily distract teams and have them spend more time reporting what they do instead of executing. Still, the benefits of Scrum are generally perceived as major time saving on specifications and fewer handovers due to cross-functional teams. Finally, Scrum offers more flexibility in roadmap planning due to short sprints.
What is Kanban ?
The Kanban methodology is a less structured one than Scrum. It is not a process framework as such, but more like a set of guiding principles to agile project management. Kanban principles can be applied to any process. In Kanban, you organize your work on a Kanban board. Columns represent states. Every work item passes through different states from left to right. Work items are pulled along through the in progress, testing, ready for release, and released columns.
Unlike Scrum, Kanban has a set criterion to define capacity. A Work-in-Progress Limit (WIP Limit) is applied to make progress bottlenecks highly visible. The WIP limit defines how many work items can be in a certain state at any given point in time. If a state reaches its predefined WIP limit, no new work can enter that state. The whole team must help clear the filled-up state first. This encourages team members to be multidisciplinary.
The table below recaps key differences:
Scrum |
Kanban | |
| Process | Formalized | Loosely outlined |
| Milestones | Per Sprint (one-month long or so iteration) | Continuous improvement |
| Daily Meetings | Iteration planning, status updates, sprint reviews | Unnecessary |
| Capacity | Per Sprint (guesstimate) | Pre-defined WIP Limit |
| Multidisciplinary | Teams | Team-members |
| Dedicated roles | Scrum Master, Product Owner | Project manager |
| Bottlenecks | Invisible | Visible |
What Does It Mean to ‘Be Agile’?
Agile organizations are better positioned to deal with rapidly evolving market demands.
The principles of agile software development are laid out in the Agile Manifesto. It emphasizes the value of teamwork, trust and open communication over that of tools, procedures, and methodologies.
While all agile methodologies allow minimal dependency on requirements and specifications, some methods are more conducive to creating an agile-inclined organizational culture. Such methods;
- encourage multidisciplinary learning and continuous adaptation.
- offer job mobility, avoiding fixed job roles and career paths.
- track metrics of value rather than time and execution.
- incentivize individual excellence instead of team excellence.
Why Doing Agile Is Easier Than Being Agile?
Processes are easier to define and control than people and culture. It often seems easier to measure execution and milestones rather than value. Scrum, although commonly associated with agility and speed is very much constrained to the cadence of the sprint.
Application leaders introducing Scrum for the first time can indeed use it as a change agent towards a new code of agile conduct. Ideally, as teams commit to sprint goals, team members would take on more responsibility. They would raise code quality, increase speed and become altogether more motivated to get better and faster to deliver what they promised.
Scratch the surface of Scrum, however, and you will find the very traditional milestone-time-to-market paradigm underneath.
Shifting the focus away from the delivery of specific features and on to continuous improvement requires a less structured methodology such as Kanban as well as a clear directive from leadership and the right Enterprise Agile Delivery tools.
————
You might also like our blog
Agile Versus Waterfall: How to Select the Right Tool for the Job?
————
How to Change Your Organizational Culture
Application leaders in DevOps organizations should lead by example. They should demonstrate a willingness to become trailblazers, for example by introducing new agile planning tools and technologies. Panaya Release Dynamix [RDx] is an intelligent continuous delivery tool. It provides real-time insights into pipeline risk and quality and automatically generates corrective actions.
Leaders should also discourage negative or retributive responses such as ‘I did not realize this component was ready to test’ or ‘the business requirement wasn’t clearly defined’. Tools like Panaya RDx, let all stakeholders see everything, with visibility and real-time monitoring. The collaborative platform also helps you sync everyone across business, testing, development and delivery teams with connected activities and workflows that focus on the same objective.
Finally, application and program leadership should be flexible in adjusting requirements based on changing conditions. Panaya RDx lets you factor in real-time insights and gain multidimensional views into impact and risk, for data-based decision making.
Selecting the Best Fit Agile Planning Tool
As a rule of thumbs, Gartner recommends selecting a tool that supports the agile principles instead of fixed methodologies. Opt for a tool like Panaya RDx that enables Value Stream Management, caters to multiple stakeholders, with built-in visibility and collaboration.