Introduction

Any IT product, application or software development effort is made up of stakeholders who are invested in the success of the product. These stakeholders typical comprise customers or users, executives, development team comprising architects, product owners, analysts, Ux/ UI developers, software developers, testers, etc.

In conventional waterfall projects, the teams above form strict structures and protocols for delivery of the desired work. Waterfall stresses on strict Finish to Start approach where end of a stage is prerequisite for subsequent stages to start. In Agile approach, the same structures are loosely defined and followed, while protocols are generally flexible and come with only ‘recommended’ status. Further, Agile is typically defined by iterative, small pieces of functionality delivered rapidly and in close collaboration with the customers and / or end users. Agile doesn’t follow Finish to start approach rather stressing on parallel tracks of work which can be finished separately or together.

In Agile projects, Product owner or product manager is responsible for maintaining the details of what is being built. The amount of work to be done in a project is recorded in what’s knows as a product backlog. Product backlog is a list of features and user stories required to complete the work in a typical Agile development. It is the product owner’s responsibility to work with Development team to organize the product backlog in to a list of prioritized features and user stories which dev teams then use to pull sprint backlog and deliver useful, working increments iteratively. Product backlogs features and user stories are continually revised, updated and modified as project proceeds along and as more clarity is achieved through a collaborative approach.

Image Credit: Internet

Scrum vs Kanban

Scrum and Kanban are two of the most popular approaches. Both the approaches have lot in common, yet both have points of divergence as well. Many experts consider Kanban as the methodology closest to the spirit of Agile principles. It is often contended that while Scrum does contain vital benefits, like continuous feedback loop and the ability for teams to self-organize independently, these benefits are effectively absorbed by the self-arrangement features of Kanban.

In Scrum and Kanban both, the focus is on efficiencies and transparency. Both the approaches are Agile and Lean, and favor using clear, most obstruction free path. Scrum and Kanban both target to deliver usable software early, efficiently and as seamlessly as possible, through breaking features into easily manageable pieces of work. Further, both Scrum and Kanban feature self-organizing, learning teams which evolve with time.

Scrum teams work in a series of sprints. Each Sprint is characterized by certain ceremonies and artifacts. Scrum team typically means the product owner, development team and scrum master. In many cases, depending upon the composition of the team, testers, Business Analysts and in few cases, devops personnel, are considered part of development team. Before each sprint, there is a sprint kickoff meeting, which is attended by scrum master, product owner and the development team. The development teams consult with the product owner to discuss the items on the backlog to identify and prioritize the work they can deliver at the end of the sprint. The selected items become the sprint backlog. And the sprint backlog becomes the sole focus of the development team for the next two weeks. This sprint backlog is held sacrosanct and as far as possible no new items are allowed unless under exigent circumstances. There are occasions when dev team is not able to complete all the prioritized work in the sprint. In such cases the incomplete items are transferred back to the product backlog at the end of the sprint to be taken up during subsequent sprint or re-prioritized for future. During the sprint, which is typically 2 – 4 weeks in duration, daily stand up call is organized by the Scrum Master where each development team member is invited to cover three things – what was done yesterday, what will be done today and any blockers / risks / issues. It is the Scrum Master’s responsibility to record all blockers / risks / issues and seek resolution to clear development team’s path. Scrum Master is also responsible to maintain the decorum by ensuring daily stand up meeting takes place daily, that most members participate and speak up and the duration of meeting doesn’t exceed 15 minutes.

At the end of the Sprint, Sprint Review (or Sprint demo or showcase of new functionality) meeting and Sprint Retrospective are held to present what the team has delivered and what are the lessons learnt respectively to ensure that next sprint is more efficient than the last. It is generally a good practice to document these sessions, especially where customer sign-offs need to be obtained.

Image Credit: Internet

In Kanban, there are no defined Sprints and there is no defined ‘prioritized backlog’ required to build an increment of working software at the end of iteration. The development team works in a continuous manner, as per its capacity. As the dev team works on the prioritized product backlog directly, there is no separate sprint backlog. Dev team keeps pulling items from the prioritized backlog as soon as one item is finished or any capacity becomes available. The capacity of dev team in each phase determines the number of user stories or features it can pull to work upon. During each phase of development, i.e. build (coding), testing, and marking items as done, movement of backlog items frees up capacity in the preceding phase. As capacity is freed up in one phase, pressure is on the preceding phase to move work up. This ‘pull mechanism’ exerted by each subsequent phase on the previous phase results in movement of work through phases.

Kanban has no time-boxed iterations or sprints, and as such doesn’t place a hard limit for each iterative delivery or increment of working software or any improvements that are being targeted as goal. Kanban teams generally work as per the workflow, which are defined as goals. The team expects to make continual improvements in an evolutionary manner as the teams get more mature.

Image Credit: Internet

In each Kanban board, there are specified columns. Under each column is a limited set of colored notes that signify the tasks assigned to the given column as per the workflow. As studies have noted, 80% of information is gathered visually, which makes the Kanban board a powerful tool for noticing and remembering the things that must be done.

Further, under Kanban, no set roles are defined. Practically speaking, it makes sense for someone to serve as a product owner, project manager or supervisor, especially for medium to large projects which are more complex, but the roles may also theoretically evolve with the needs of the project and the environment. A Kanban team is not required to be cross-functional since Kanban workflow is intended to be used by any and all teams involved in the project. Therefore, a team of specialists and a separate team of generalists may be working on different aspects of the same Kanban project from the same board at the same time, all in order to pursue the defined goals.

Unlike Scrum, where the focus is to produce an increment of working software, in Kanban, teams strive to achieve goals (complete workflow states) and reduce the amount of time to complete the entire process. A reduction in the average timecycle may be one of the indicators of success.

Under Scrum, work in progress is limited in each iteration. The team has committed to the number of tasks or user stories and has adapted that scope as sprint backlog. This is the scope that the team is ready to accomplish during the Sprint. All the items can theoretically move to the Work-in-progress section simultaneously. In Kanban however, the limit for each stage of the workflow is defined and noted on the Kanban board clearly. Kanban limits work in progress per workflow state to this number, which is nothing but the capacity of the project teams working on the Kanban board. For example, if there are 5 developers, and each developer has committed to 1 user story or task, then number 5 is denoted on the Kanban board to indicate the maximum capacity available in that phase. Consequentially, there shouldn’t be more than 5 items in the particular phase.

Under Scrum, only the development team can edit the sprint backlog once it has been committed. In Kanban, the Kanban board may be edited by a Product Owner. According to Essential Kanban Condensed Guide, Kanban has evolutionary defined two “hats” that the team members can wear: Service Request Manager and Service Delivery Manager. The “hat” of Service Request Manager is an alternative to the Product Owner. In Kanban, there is also a culture of slack resources, or free flowing resources who can don generalized or specialized hat to help resolve bottlenecks, as and when needed. For example if a resource has completed his / her tasks, s/he is free to move to help another team member on a task which is in blocked state or on critical path. Equally well, the free resource can choose to take up a fresh task or user story from the backlog queue.

In some Kanban teams, there is an additional section on the Kanban board, an Urgency section, which is typically represented as a swim lane. This section may be used for an unpredicted urgent task from the Backlog or a bottleneck task from the board. In such an event, the urgent or bottleneck task is moved to Urgency swim lane where it becomes the first priority for the team.

Image Credit: Internet

Conclusion

Scrum and Kanban are often used interchangeably or thought to be two sides of the same coin. As both approaches are used to drive efficiency and utilize product backlog and common terms, the different nature doesn’t become apparent to a layman. In reality however, there are significant differences between these two methodologies. An often raised complaint about Scrum is the length of its time-boxed sprints and the rigidity through which time-boxed iterations are imposed, which are considered too long when employed with startups. The main criticism stems from the fact that lengthy, rigid sprints lead to infrequent releases, which can cause work teams to drag their feet or become accustomed to slow pace when responding to the needs of customers. Similarly, in case of undersized sprints, where the scope of work for each release is large, the larger features need to be broken in to smaller iterations, which are unlikely to deliver full value to a customer and might end up confusing the customers and end users. The set time-boxed lengths of Scrum were designed to offer consistency, and may not always be useful in a world where technological innovations move at a faster rate than before. Kanban tackles problems raised in Scrum with a different scheduling protocol where instead of operating with time-boxed sprints, Kanban restricts the number of things that a collective can focus on during any particular time span. Hence, the benefits of Kanban are twofold: Organizations can get more response from the marketplace, and they’re able to adjust to the demands of that input with greater agility. In that sense, Kanban is often considered the most close to Agile spirit.

Understanding these differences is key to choosing the path that will work best in a given environment.

When working on an Agile project, there is continuous discussion about development processes and timely, iterative delivery to customers. For the most part, Testing is construed, without much thought, to be an ‘included’ part of Agile Development process, just as design and requirements analysis are. Yet the domain of software testing is often ignored, or at the least not paid an equal attention.

There are multiple approaches or frameworks within Agile like SCRUM, Scaled Scrum, Kanban, XP and others. As the complexity of software development processes is increasing continuously, the software testing processes also need to evolve and mature to keep up with the development approaches. Agile testing is a relatively newer approach which focuses on testing smarter rather than investing considerable efforts, all the while delivering high-quality results.

The testers and developers are required to put in higher level of collaboration in Agile Testing. Agile testing is all about seamless integration between development and testing processes; the testers provide corrective feedback to the development team during the development cycle, while the development team reduces probability of high number of defects. Agile testing is a continuous process rather than being sequential. The testing begins at the start of the project and there is ongoing integration between testing and development.  The common objective of agile development and testing is to achieve higher quality product, free of defects and errors.

Agile Testing explained: What IS NOT Agile Testing?

Agile methods have been growing in popularity since the first formal adaptations in late 1990s to early 2000s. Agile has its own fan clubs and is fragmented in to practice areas, from simple, single team based Agile Scrum to complex models like SAFe Agile. Besides the more popular Agile methods, there are relatively lesser known yet equally effective methods like Crystal, DSDM and Feature Driven methodology.  Regardless of the method, all Agile methodologies share much of the same philosophy and features – regular feedback loops, speed, flexibility, and above all, regular communication and interactions between stakeholders, whose roles have been clearly defined and limited in all Agile methodologies.

Image Source: Clarion Technologies

Traditional testing practices have taken their lead from the Waterfall model of software development, where requirements gathering, software design, and implementation follow a deliberate and often lengthy path. Waterfall methodology has fallen out of favor recently, as Agile is becoming increasingly popular. Despite the tide of time in favor of Agile methods, waterfall testing still exists and in many cases is seen as flourishing. The ‘waterfall testing’ in an Agile implementation is particularly like an island in the middle of water which steadfastly holds its own.

The lack of Agile testing strategy is particularly characterized by two kind of practices. First, reliance on testing as an end point to development. Many development teams still consider testing as a conclusion to development stage. This promotes the view that testing must test the entire user story or feature or MBI or increment produced in its entirety. Secondly, testing at the end of development cycle is seen as merely a rubber stamp activity. Development teams often give impression that they have coded what needs to be coded and testing is merely a formality.

Today as seen in many Agile implementations, development may have moved to Agile however ‘testing at the end of development cycle’ continues to exist in its previous avatar, clearly meaning that Testing has lagged. This kind of hybrid Agile is being followed everywhere, where development stages include everything from high level design to business analysis to client collaboration, only excluding testing. Reasons can be many, perhaps out of convenience and / or ignorance, or perhaps due to simplicity.  Perhaps the people did not understand the difference between Agile testing and Waterfall testing, hence just carried over many of the same documents and processes as used in Waterfall. In most cases, testing is simply seen as a control point, or check-gate, rather than treating it as it should be, a value addition activity.

Agile Testing explained: What IS Agile Testing?

So what is Agile testing again? For some reason, people often treat Agile testing as a black box, not knowing what to expect. Agile testing is not a ready made approach, or a set of pre-defined test cases, or pre-determined set of processes. What Agile testing is, like all other Agile processes, an adaptive approach depending on the project and the functionalities being delivered.

There is inbuilt uncertainty in an Agile project. When an Agile project starts, what the final shape of product or what will the system look like, is not known. Agile projects begin with requirements which continue to change till the time product meets acceptance.  As a project moves forward, the risk profile of the project changes. At the beginning of a project, the risk profile is higher and as the project moves forward the risk profile grows conservative as there is more at stake during later stages. As the team learns to work together, the team and project dynamics change over time. The timescales change over time; WIP inventory and backlog continues to change over time. Similarly, Agile testing approach also must undergo a change to meet the changing, adaptive requirements of the Agile project. Whatever is the approach being adapted for development processes, testing should follow the same approach.

Image Source: Medium

The below are some rules that may be followed to define Agile Testing approach for the project or the function:

• An iterative approach to test software or product being built to aid meeting project goals
• Less focus on framework and rigid structure; higher focus on adapting to project requirements
• Risk profile -: Agile testing process must adapt to changing project risk profile. Test cases need to build in the amount of risk as per the risk profile at different stages of the project.
• # Defects -: Amount of testing work can change over time as the knowledge of developers increases with time. This may require changes to the testing approach.
• Systems architecture -: may change over time as project moves along. Testing team needs to build or import capabilities to meet this changing profile.
• Timescales -: The timescales themselves change over time. During certain stages in a project, a feature may span multiple sprints, while in other stages there may be multiple features delivered in a single sprint.
• Extra reporting -: another aspect of testing is the usual practice of publishing reports, test plans, templates, processes, etc. The reporting output must adapt to the project and its environment. If the project is unique, documentation may be more than other projects.
• Documentation -: By nature, testing is a process heavily reliant on documentation. This doesn’t mean however that documentation should be a rigid requirement. Changing documentation approach to adapt to project is a facet of Agile testing. For example, if the team uses JIRA or any other tools, then testing process needs to adapt to the same. If the team is using github to upload the test cases, then that’s the approach testing should follow.
• Communication -: there is greater responsibility to use variable communication as demanded by the project environment.

Agile test strategy Is a critical input for not only running effective Agile development processes but it provides excellent support to organization’s DevOps initiative, and the benefits of Agile testing extend beyond the immediate benefits of continuous testing. And continuous testing is vital to improving product quality.

As compared to testing at the end of finishing development, Agile development stresses on early and frequent testing of finished and unfinished code changes. In the world of Agile, testing needs to happen early and often. So, instead of waiting for development to be finished before testing begins, testing happens continuously as components or tasks on a particular user story or feature are completed.

Agile Testing Methodologies

Image Source: Infobeans

Test-Driven Development (TDD) − Test-Driven Development (TDD) is based on coding guided by tests. The word “test” in Test Driven Development may be misleading. The primary goal of Test-Driven Development is to make the code clearer, simple and bug-free. Test-Driven Development starts with designing and developing tests for every small functionality of an application. In TDD approach, first, the test is developed which specifies and validates the intended function of the code being written.

Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven Development (ATDD) is based on regular communications between end users or customers, developers and testers and driven by pre-defined Acceptance Criteria and Acceptance Test Cases. The thought behind Acceptance-test-driven-development is that user or customer perception of the system or product is just as important as its functionalities, so this perception is ideal to drive performance in order to help increase chances of adoption. To give this idea life, ATDD collects input from end users / customers, uses those input points to develop acceptance criteria, translates that criteria into manual and / or automated acceptance tests and then writes code against those tests. Like TDD and BDD, ATDD is a test-first methodology, not a requirements driven process. Acceptance-test-driven-development generally goes a step further than the regular Test-driven-development or Behavior-driven-development approaches, as it directly goes to the source or – end users and / or customers, to understand the rationale behind the product and how it will be used.

Behavior-Driven Development (BDD) − Behavior-Driven Development (BDD) testing is based on the expected behavior of the software envisaged by the project team. BDD approach is based on same principles as Test Driven Development approach, but instead of unit tests, it calls for testing at higher level, usually at business level. Instead of starting with a technical-facing unit test as in the case of Test driven development, BDD starts with an initial requirement based on end user or customer behavior and calls for tests that are “human readable” and can even replace some requirements documentation. This requirement is based on behaviors that the product should exhibit, creating an airtight guide for engineers to use as they develop tests.

Exploratory Testing -: Exploratory testing gives the testing team and testers an ownership over the code to test it in an organized, yet chaotic way. In exploratory testing, testers are not following documented test steps, but rather exploring the vulnerabilities in the software in imaginable and clever ways to try to break it. Testers document defects as usual, but detailed documentation of what and how the application was tested may not be always provided.

Exploratory testing doesn’t follow a set script or test cases. Rather, it’s about developing the most intuitive tests based on each unique functionality of the software. Because of its unconventional approach, exploratory testing often mimics how users or end customers will interact with the software in real world.

Session Based Testing – Session based testing is a step further than exploratory testing. Session based testing develops on the exploratory testing approach by providing more structure. As exploratory testing is completely unscripted, it relies heavily on the skills and experience of the testing team and testers involved, which is not the best fit always. Session based testing provides structure and accountability by developing a charter for testing and running testing in time-boxed intervals. Additionally, testers are required to report on the testing that took place during each session.

Conclusion

The test process is not a separate process that can be outsourced or left alone, it is merged with the development processes. The true benefits of Agile testing are revealed when it is used as part of Agile development and accorded an equal importance. The sooner testing team and testers get involved, better it is for the project. Ideally, testers should be part of the overall scheme of things from day one, simply because giving testers a seat at the table from the start provides a higher level of insight into requirements and goals, encourages collaboration and helps hammer home the need to conduct frequent, continuous testing.

Introduction

A mindset, or state of mind, is a set of beliefs, thoughts, biases, assumptions and values held by an individual or a group of individuals that leads the individual or the group respectively towards the choices they make. The Humans are most comfortable in choosing paths or making decisions that confirm with their beliefs, assumptions, biases and values. The existing mindset is made up of all these and rewards itself through positive reinforcement by guiding the individual or the group, in case of shared mindset, towards the path of least struggle. In other words, towards the path that is in conformance with the existing set of beliefs, thoughts, biases, assumptions and values. Simply put, it is a way of thinking about things and making decisions that those in a group share to the point that it becomes a way of life.

Flowing from the above definition, an Agile mindset can be defined as set of beliefs, thoughts, biases, assumptions and values that guide individuals and group members to make each decision to support an Agile way of working, or Agile work environment. Agile work environment at a broad level is made up of focus on collaboration, team work, flexibility to change, respect, communication, client-partnership, continuous feedback loop, learning cycle and fearlessness towards failures.

Lets not be fooled by the simplicity of the above terms. It is easier to define mindset and then attach Agile to it, or better still, define Agile terms around what should be done, or the ideal way.  In real world however, most people and teams practicing Agile struggle to understand or explain to others what constitutes an Agile mindset. Most of the times people hide behind thinly veiled excuses like, ‘Oh, I get it, but cannot explain it to others.’

Drivers of Agile mindset

The Agile mindset is the environment within which agile teams have their brightest chance to flourish. It is not laid out anywhere. It isn’t a prerequisite for an agile adoption, nor is it a standard which can be adapted for a functional agile team. This mindset is simply the best foundation on which Agile teams can propel themselves to success.

Specifically, an agile mindset is powered by 3 primary measures. First, an agile mindset always encourages early adaptation of Agile principles. Second step is continuous reinforcement and retention, while the third step is measuring metrics and driving compliance in day to day working environment and fine tuning approach as necessary. These three practices – adaptation, continuous reinforcement and retention and measurement of metrics are the key in any organization’s Agile journey.

Many enterprises begin their Agile journey with noble intentions. They want to improve their product offering to customers, improve their go-to-market or turnaround times, bring in internal efficiencies, reduce time between deployments, or all of these. However it’s quite common for many of Agile adapters to discover that they are not fully prepared for the Agile journey. This could happen due to one or combination of many factors. They may discover that employees do not fully understand Agile and any efforts to have them adapt Agile have not been fully successful. Or that the internal environment is not conducive for Agile way of working. This would primarily happen if one or more of key stakeholders or top level management is not a believer of benefits of Agile. In most cases however Agile adaptions fail because the organization tries to do too much in too little time. One of the great failure points of Agile is that Agile is not a magic wand. One cannot hope to implement few Agile practices or principles and expect overnight improvement. And when the improvements don’t come about, blame it on Agile. Agile is not a magic cure for years of inefficiencies or layers of bureaucracy in the organization or half-hearted efforts at implementation. Above all, Agile requires discipline and effort to commit to Agile principles and stay committed even in the face of less than expected benefits. In order to reap true benefits of Agile, it takes sustained and repeated training, high management focus, reinforcements and continuous practice of Agile principles. Remember: Agile is only as good as the people implementing it. So if you notice Agile is failing in your organization, guess what! Chances are something else is failing too.

Adaption of Agile methods is perhaps the easiest step. All it takes is starting implementation of Agile principles and the practices as per the chosen method. However, this is an inherent weak point as the adaptation needs to be accompanied with strong commitment as any halfhearted attempt will lead to disappointment.

The second most important aspect is continuous reinforcement and retention of Agile principles. Adapting agile in a Big Bang manner or as a quiet change is not worth much if not followed up with regular reinforcements through trainings, refreshers, communications and word of mouth messages. The Agile principles and practices need to be driven deep down to the deepest layers through untiring, unrelenting efforts by professionals like Agile coaches and leaders. Agile roles need to be strengthened and given enough autonomy to run things on the ground. Agile coaches must drive and ensure adherence to all Agile practices and ceremonies as per the chosen method. Above all, Agile must be made a part of, promoted and practiced as a ‘way of working’ and not as a special endeavor or initiative.

Whatever is the chosen method of Agile implementation– Scrum, scaled scrum, kanban, Lean or any other, the Agile coaches need to take the mantle of driving Agile principles. Constant reiterating is just one part of the journey. Teams and individuals must be constantly evaluated on their individual compliance with Agile principles and ceremonies depending on the chosen method. Individuals and teams lagging behind must be coached on the benefits of Agile and helped in order to bring them up to expectations. Remember: Agile adaptation is a disciplined team effort and reinforcement at individual and team level is necessary to enforce rigor.

And this brings us to the third part, specifically around measurement of metrics. Maintenance and adherence to product backlog, prioritizing sprint backlog, tracking efforts burned down and remaining during sprints, user stories closed and accepted by customer, are some of the metrics.

1. Sprint burn-down -: The sprint burn-down chart visualizes how many story points have been completed during the sprint and how many remain, and helps forecast if the sprint scope will be completed on time.

2. Lead time -: Lead time measures the total time from the moment a story enters the system (in the backlog), until it is completed as part of a sprint, or released to customers. It measures the total time for a requirement to be realized and start earning value – the speed of your value chain.

3. Agile velocity-: Velocity measures how many story points were completed by a team, on average, over the past few sprints. It can be used to predict the team’s output in the upcoming sprints.

4. Code coverage -: Code coverage measures the percentage of your code which is covered by unit tests. It can be measured by the number of methods, statements, branches or conditions which are executed as part of a unit test suite.

5. Cumulative flow -: Cumulative flow is a kanban metric which shows the status of tasks – in a sprint, a release or across software teams. It can visualize bottlenecks in the process – a disproportionately large number of tasks in any of the workflow stages indicates a problem. For example, a big “bubble” in the chart in a verification or testing stage indicates this stage has insufficient resources.

Image credit : Microtools

6. Failed deployments -: Measures the number of deployments (either to test, production environments, or both). Can help understand how solid environments are and whether teams are really building potentially shippable software.

Conclusion

Perhaps, what makes Agile difficult for lot of managers to grasp is that it’s not just a technology, methodology or process that gets implemented within an enterprise’s current culture and assumptions. The Agile way of running an organization seeks to fundamentally redefine the very concept of an enterprise which has prevailed for the last one hundred years.

Instead of an enterprise being conceived as an efficient, profitable steady-state machine aimed at exploiting its environment and existing business model and the industry its part of, the Agile organization is a growing, learning, adapting living organism that is in constant flux to exploit new opportunities and add new value for customers.

Introduction

Agile and Lean are some of the most commonly used terms in SDLC lifecycle. Often these terms are used interchangeably or as complimentary to each other. There are similarities as well as points of divergence between these approaches, and it takes years of practical hands on work to sort out the nuances.

Agile software development framework refers to 12 principles and 4 values that were put forth in Agile Manifesto which became the basis for an alternate method of software development to replace the waterfall methodology. Agile was primarily a reaction by the software community of engineers and sponsors who wanted to see faster progress and cut any bureaucracy, red tapism or flab in the system. The existing heavy-lifting style of waterfall development caused as many troubles as it resolved through delivery of the software systems.  Disconnected teams, uninterested project sponsors, disappointed customers, cost and time overrun, and a software system in disarray and out of sync with customers’ needs were quite often the remnants of a waterfall implementation.

Agile gained traction as a better answer for delivering software while Lean was adapted and refined on product success in conventional manufacturing. Design thinking is a relatively abstract approach for exploring problems and solutions with customer in mind.

In any business or services enterprise, blindly committing any model, framework, or methodology seldom delivers a positive result, let alone the desired result. Different LOBs or departments may have their own unique problems which go against the grain of ‘one solution fit all approach’. The need is to marry available choices with the needs of an organization in a way that each option selected returns the best possible ROI with acceptable levels of risk.

The intersection of Agile way, Lean manufacturing and Design thinking presents an interesting combination of techniques to progressively achieve improvements in software delivery. An unbiased examination of all three techniques in detail, potential and scalability reveals interesting areas of coupling, while there also exist enough reasons to adapt adequate cautions.

“Be stubborn on the vision, but flexible on the details.”

—Jeff Bezos

Agile, Lean and Design Thinking examined

Agile is our ticket to scalable, collaborative and customer-centric software development; Lean is the framework for achieving efficiencies and applying learning to achieve process improvements, and Design Thinking is an innovative approach to attacking problems through iterative exploration and application of learnings.

Design thinking is a way of getting to the solution of a problem through continuously questioning the previous outcomes. Design thinking often advocates going where the rules don’t exist and where precedents are unknown. Design thinking is more to do with learning ability than following a set path. A cook conjures up new dishes and a designer comes up with a new dress line in much the similar fashion. It’s through thinking about the user of the product and coming up with attributes  that would deliver the most value that designers come up with the most effective design elements.

Design Thinking often focuses on the subtleties of how deep look in to problems can lead to ingenious solutions. Abstract attributes like experimentation, dealing with ambiguities, empathetic learning and above all, a designer’s ability to make meaning out of otherwise ignorable facts, hold special place in Design Thinking. Simply put, Design Thinking is a study in to how problems are framed and analyzed and how an empathetic approach of looking at problems from customers’ or users’ point of view can often bring out subtle hints towards solutions. Design Thinking challenges assumptions, encourages innovative ideas, prototyping and experimentation, and defining users’ needs and pain points. Much of the Design Thinking process is similar to Agile, insofar as iterations, late changes, customer centricity and flexibility are concerned.

The heart of Agile way, irrespective of the chosen Agile method is to react to change. Agile is a dynamic approach to delivering software of value to the customer where the customers and engineers became collaborators to produce the software. Agile is highly effective in uncertainty and is the perfect answer to many professionals and designers’ worst nightmare of not being able to change the product design during later stages of development. Scaling Agile is a critical part of Agile implementation helping organizations address changing requirements without raising everything to ground.

Lean approach developed in the manufacturing world primarily as a cost saving tool. Based on cold, hardcore scientific methods of reducing waste through processes, rules, procedures and value addition, Lean was primarily control oriented. While Agile and Design Thinking advocate flexibility, less reliance on processes and empathetic learning, Lean often runs in opposite direction. One of the major drawbacks of Lean is that conventionally it often ends at process optimization, waste, and quality, and misses so much of what the Lean mindset offers potentially. However, Lean deals with uncertainty and advocates an adaptive approach, changing according to results of experimentation and learning. Lean framework also advocates empowering those closest to the work to decide the best approach of doing work under strict supervision and control. Hence, there are ample synergies between the Agile and Lean approaches.

The lean startup methodology was invented in Silicon Valley in the 90s, powered by the dot com boom but the conventional Lean has its roots in Toyota’s production system. Toyota’s lean manufacturing system was used to build things efficiently, yet it doesn’t tell what should be built.

Using Hybrid mix of Agile, Lean and Design Thinking

Many projects can and do fail despite best intentions. According to various studies, anywhere between 30-50% of IT projects fail to achieve their objectives. A study by IDC points out that 30-35 percent of IT projects still fail. Other research puts the figure upwards of 50 percent. Regardless of the study, the main reason consistently cited for the failure of software development projects to deliver their intended outcomes is misalignment with user and business needs.

Agile, Lean and Design Thinking place high focus on close collaboration with users and people closest to the work being done. While Design Thinking focuses on finding the right problem through empathetic approach and listening to the users, Agile places emphasis on collaboration and feedback loop, while Lean advocates placing power in the hands of those doing the work. Just like design thinking, a key tenet of effective agile application, irrespective of the Agile framework chosen, is to seek frequent inputs from end users and incorporate the feedback in iterations to achieve the right outcomes. Doing this during early stages of projects includes establishing project goals, defining business increments, writing user stories and / or features, establishing success criteria through definition of done and creating product backlogs from which iteration backlogs follow. Throughout the development process, the inputs through feedback process manifests form a crucial part of delivering the ‘right’ product .

While design thinking and agile can be applied separately, benefits’ realization can be higher if the two approaches are applied together, creating an environment where both approaches benefit off each other. This environment fosters a ‘customer/user first’ attitude and equips employees with means and methods to focus on user-centricity and rapid iteration as a means of reaching optimal outcomes. Design thinking brings a strong user focus while agile is an excellent way to deliver product incrementally, ensuring customer / user needs are kept at top and center throughout entire design and development phases.

For teams looking to leverage agile and design thinking for the first time, here are few recommendations to keep in mind:

• Fail early, fail often – No idea is a bad idea. During the brainstorming sessions or ideation phases, any criticism of any idea is simply not permissible. Each team member is free to put up their idea on the board so long as it’s a fair representation of users / customers’ needs. A critical part of Design Thinking is to come up with prototypes and working models, which are often very poor adaptation of users / customers’ needs however serve as a vital link.  The prototypes are shown to users / customers to get feedback and incorporate learnings. Poor prototypes have perhaps taught design teams more than any other source. The goal is to understand the needs of the users / customers empathetically.
• Low hanging fruits – By starting small and focusing on high-value, yet low-risk opportunities, confidence and experience both grow in applying principals of using design thinking and agile together. Then, as the capability matures, teams can take on more challenging initiatives.
• Create cross-functional teams – This is perhaps one of the easiest yet so-often-delivered-wrong concepts. By allowing team to leverage cross-functional viewpoints, for example, a developer may have critical feedback on UI, team leaders can tap in to experience from various domains. This not only fosters required creativity, but also creates a healthy understanding of each other’s challenges within the team. As far as possible, the team must be physically collocated with end users / customers to promote frequent collaboration.
• Balance design and development – Agile teams are often groomed to go in to an iteration mode, basically an all-guns-blazing mindset. And that’s not wrong. Typically, Agile teams learn and implement on the fly. Agile teams are often instructed to “just start coding”, fixing problems as they come along and gathering user / customer feedback along the way. Care needs to be taken while mixing Agile and Design Thinking as this may create tensions about how much time to spend on resolving problems before starting development. The team must understand that this isn’t a pure-play Agile implementation, or a pure-play Design phase which can take ages. The team must understand the value of the empathy, definition, and ideation phases, and that Design Thinking is not leveraged only at the front, rather it can crop up during any phase. In fact, the team must be prepared and encouraged to get back to the beginning at any point during project to uncover new user insights and / or reframe the problem, and then continue development with a renewed sense of “why”.

Conclusion

At a simplistic level, Design Thinking can essentially be described as a process that leverages divergent thinking (to generate ideas and get out of the box solutions), followed by convergent, team thinking to select solutions to pursue, all the while getting user / customer feedback. Design thinking is a mindset towards solving problems from human needs perspective rather than from a business perspective.

Agile is an umbrella approach encompassing variety of IT product development and business methodologies that has at its core deep, unwavering commitment to principles of highly collaborative, multi-functional, self-organizing teams. Agile isn’t limited to software or IT systems, but goes beyond that.  Agile’s minimal approach and focus upon working product or software as a measure of progress is in stark contrast with heavy lifting ways and upfront documentation before each stage of waterfall development.

Waterfall is called so because of the sequential, orderly tasks and downward flowing approach, where everything is supposed to be smooth, and one thing leads to the other. In real life, its rarely so.

Agile methods, of which Scrum is the most popular, bring in to calling flexibility, speed, and willingness to get things done. Many experts believe that Since agile was introduced in the development of software applications, both the overall quality and speed of delivery have significantly improved. It’s the quick gratification virtues of the Agile methods that have made the methods dear to many professionals in various industries.

However, Agile methodologies are focused primarily on developers and the iterative nature. The concept of Agile grew out of programmers’ attempts to resolve most common project management issues and pain points experienced during big software development projects. Unsurprisingly then, the Agile Manifesto (primary document delineating Agile principles) did not include the UX perspective, nor did it account for the time, resources, and research that UX professionals need in order to create trend-defining, excellent designs. For the much part, UX was taken to be part of development, as Design effort.

Customer Centricity, cannot and must not be equated with customer collaboration. Most people make this basic error, partly due to the fact that both terms contain the word customer, and partly due to the belief that involving customers in the development process takes care of all their needs and makes them delighted customers. The truth of the matter is that Customer Centricity is a far wider term which requires placing customers’ requirements at the center of all activities; while collaboration is just a tool available to implement the vision of Customer Centricity.

Image Source: SAP

Agile and UX: curving away from each other!

Agile is a mindset or approach about radical transparency and knowledge of the fact that the development team doesn’t know all the answers, or even most of the answers, at the beginning of a project.

An UX workflow outlines all the steps within the UX process, from UX research and gathering user feedback or behavior driven insights to defining design specifications, to low-fidelity wireframing and high-fidelity prototyping, UI / UX design, and performing customer or end-user usability testing prior to development.

Image Source: DIlbert

There is a tendency within Agile project teams to get ahead of the curve. At times, the developers run ahead of where overall team and the customer are in terms of discussion / elaborations / prototyping on requirements and how the final product will look and feel and subsequent sign offs. Perhaps the development team knows exactly what they’re making functionally, hence they feel comfortable, at times even overconfident, especially when re-writing a product that is already live (new technologies rather than a refactor). The customer may perhaps be expecting fine grained behaviors and focus on aesthetics, look and feel part, while unbeknownst to customers/ end users, the developers are trying to concurrently work on future functionalities of the system in order to get done as much as quickly as possible. Often this happens with the implicit knowledge of everyone on development team, with Business Analysts (and the Scrum master or PM) feeding back-end developers concise & defect-free stories to code. Developers hope to stay ahead of the curve in this manner, often working in a factory-manner, producing lines of code hoping that the customers’ expectations remain the same. And while by doing this, development teams may succeed, especially if the measure of customers’ success is through produced lines of code, where they often fail is meeting the more human expectations.

In fact, in projects where the Design teams are involved, the rigid way in which Agile is often implemented in medium to large organizations and / or projects (typically, projects driven using Scrum or similar methods) makes things even more challenging. Two-week iterations force tunnel vision on the design team, who are often tasked with making backlog items ready for development often at the cost of due thought process. The team runs risk of getting so focused by a particular feature or the user story that they may ignore the broader, often intangible product and design implications, such as integration, omnichannel consistency, or user-interface architecture.

Needless to say, such development efforts often go against the grain of Agile itself, as one of the core cornerstones of Agile development is feedback from customer and collaboration, which can be often sacrificed in the name of delivering incremental pieces of software, or iterations.

Image Source: Internet

Agile and UX: integrating towards and in to each other!

However, this sad state is not unmanageable. Over the years, many UX professionals who work in an Agile environment have developed their own ways of not only surviving, but thriving in this mad-paced, Agile environment. Once again, there is no set protocol or playbook here — most of the remedies that UX professionals employ are broad-based, strategic, and organizational factors in the fervent hope of marrying UX with Agile, keeping intact the benefits of both while coming together to make a better product.

Image Source: Adobe Stock

• Management buy-in and understanding the value of UX -: Organizations which are further along on UX curve inherently understand the value UX-focus brings especially to product development process. Focus on UX not only provides a competitive edge, but also is a key differentiator in the Go-to-Market strategy. This is yet another way of describing UX maturity, a concept long argued as the key to product success, and consequently, business success. Decision makers in such organizations realize that UX is not just an afterthought, or an extra coat of paint; rather it’s the careful and customer or end user-centered approach to product strategy, features, structure, interactions, content, and aesthetics. Project managers in these organizations and leadership don’t just ask UX designers to rush through features and user workflows, or merely rubber-stamp features that have already been decided upon by the rest of the team, instead, they expect the UX team to be involved from the very start and pay attention to nuances and subtleties in order to produce something which customers and / or end-users will cherish. Managers and leadership in such organizations embraces uncertainty and detaches its focus from merely quantitative measurement and understands that a “UX” approach means always hypothesizing, testing, and iterating on product design ideas. The focus is on qualitative methods to gather behavior-driven insights. The rich insights that UX teams need for their work and to make decisions often require time consuming and “putting-your-ear-to-the-ground” methods. On the other hand, organizations that are biased toward quantitative data as being the most important or most persuasive evidence for decision making often integrate Agile and UX poorly.

• UX People are critical Leaders -: While having managers and stakeholders that understand and support UX is extremely important, the reverse is also true: UX people that succeed in Agile environments exhibit leadership qualities. They point out assumptions about user behavior that could prove disastrous if wrong. They make time to reach out to colleagues to help explain UX process and principles, and why they produce better products. They bring their coworkers to usability tests to build empathy and observe users struggling. They fight for getting time to do user research, and to design something right. UX pros that thrive in Agile push the team back towards the bigger picture, and the context in which humans will actually use these products that are being built.

• Agile Process is natural fit for UX -: The original idea of Agile was to act as a flexible framework which can be used as a guidance, or a set of guiding principles to aid teams to develop quickly and effectively, where customers and end-users are as much a part of the process as developers are, where change and reacting to change is welcomed, and where speed and agility trumps the need to follow set protocols. By integrating Agile and UX, all of these principles are promoted. Customers’ or end-users’ feedback invokes behavior driven insights which are crucial to UX work, while readiness for change drives developers changing their approach in the face of radical decisions by the UX team.

• Agile development doesn’t limit user experience -: Users don’t interact only with small parts of a product’s design in isolation, they use many or all features of the product to accomplish larger goals. What good is one piece which works fabulously well, and is well thought out, while the overall application is a poor implementation? All pieces of a product design must work together seamlessly and harmoniously to provide a “beyond-good” user experience. In fact, in an omnichannel world, users expect their journeys to transition and perform seamlessly across multiple channels, even when developed by different teams.

• Rigidity drives away innovation-: UX works well when the Agile process isn’t strictly and mindlessly implemented. If an organization has rigid Agile-process guidelines that admonish UX teams for following due dilligence, and rewards UX professionals who merely rubber-stamp designs, it becomes very tough for UX people to become anything more than pixel-pushers. UX professionals who succeed in Agile work in environments that care more about responding gracefully to change than about how long a standup meeting can last. Once again, nuances and rules of Agile should be implemented in the spirit of producing a better product. Teams who incorporate UX well will figure out how to manage features and user stories so that UX has some time to get ahead of production and create validated, researched, and thoughtful designs.

• Learn when to accept UX debt-: UX teams, when working within an agile approach or workflow, need to compromise on the ideal or the best solution to get something built quickly, especially if that something delivers some, if not the most, value.  UX can’t be an impregnable fortress in the sea of Agile. Iterations in agile are planned to create a steady development velocity and UX design must keep up with this pace. Setting time limits for each of the team’s UX activities will help ensure that the team’s goals are realized on time, ideas are not overworked and the bad ones are thrown away early. UX teams must learn to limit the fidelity of design that is handed off to developers. This starts with the wireframing and prototyping phase of the UX design process. As an important lesson – UX teams must not waste time on details that could be worked out further down the line. It is essential to produce not the perfect design, but just the workable design, so that the same is communicated quickly and effectively to the developers.

• UX Professionals and Developers are on the same side-: Effective Agile teams communicate well and share a common understanding of the project’s goals (both large and small). Developers and UX professionals act in spirit of producing a truly better product. UX professionals step beyond pixel-pushing and decoration only, while developers are ready to make radical changes, often at the cost of abandoning their tested approaches and coming out of their comfort zones. UX professionals feel equally invested in the success of the product and take ownership for development issues. Often, such an ideal state of affairs is only achieved after working together and developing respect for each other’s work, something which is simply not possible in short runs.

• Its simply better ROI -: While many non-UX-minded project teams see UX as time consuming, UX-minded teams see the extra time used upfront as a factor which produces returns several orders of magnitude over the initial investment.

Collaboration is key for Agile-UX teams to deliver great software. If design and development teams do not keep an open-door policy, misunderstandings will grow and issues won’t be identified until it’s too late. Teams used to work a certain way, for example designers working head down for long stretches of time, while developers cranking away lines of code  often have to make comprises on quality or risk producing worthless code.

Image Source: Methodsandtools

Conclusion

It’s certainly difficult to make Agile and UX work together as two wheels of the same cart where one wheel is simply not enough to pull forward even an empty cart. Typical Agile processes tend to be biased against anything which is not measurable, and don’t take into account the time, resources, and efforts UX professionals need in order to deliver behavior driven attributes and user-centered products. Aside from its success in IT applications and software development, the agile processes are becoming popular in legal, marketing and other enterprise industries. At the same time, many are realizing the important and critical need to integrate iterative workflow into the user experience process. And despite issues, Agile UX teams agree that Agile and UX both help make a better product and deliver a better user experience.

Introduction

For any team and in any team setting, the role of a coach assumes centerstage in addressing the grooming, training and teaching requirements. The coach must possess skills about the primary reason of assembly of team, and must possess deep understanding of the nuances of the game. An effective coach knows how to groom the talent available and make the best within the given constraints. A successful coach understands not only the game, and how to win the game, but also the reasons why teams fail. That last part is often the sole difference between a coach able to inspire the team to higher successes and others. Beyond the training and teaching ability, the most significant trait a coach must possess is how to ignite the hunger for learning and subsequently winning in the team.

Agile values and principles are a tectonic shift from downward flowing command and control management practices to collaborative, team centric environments. To nurture an organization through this shift towards becoming Agile requires someone with depth of agile experience, knowledge of human behavior and strong influencing skills.

With the above in mind, let’s see what’s an Agile coach. An Agile coach is someone who is tasked with teaching and training the teams within an organization on Agile methods and the Agile way in order to spread the benefits of Agile. The purpose is to make sure the organization and individual teams excel in delivering better value to its customers and stakeholders by gaining efficiencies in how everyone in the organization works. The organization aims at gaining an edge through increased inner efficiencies, better ROI and lower costs. An Agile coach, by grooming the teams, training and teaching the values of Agile and inspiring team to relentlessly implement the chosen Agile methods, plays a valuable part in this endeavor.

What makes an Agile coach

So what skills an Agile coach must possess? In order to fulfill the above objectives, an Agile coach is someone who is an expert in theory and practice of Agile values. An Agile coach is someone who is willing and able to communicate freely to be able to teach others. An Agile coach is also someone who is able to take an outsiders view, is an Agile promoter within the organization, has the ability to mediate in case of shared responsibilities between projects, and guide large teams towards Agile methods. Above all, an Agile coach is someone with ability to work with multiple teams, projects and portfolio owners to drive Agile adaption and implement improvement efforts.

In addition, each organization may have its own preference of what skills it considers more important. Organization have diverse needs and may come up with their own specific desirable traits.

Image Source: Internet

1. Technical coaches: Agile coaches who are hired as technical coaches are primarily tasked with working closely with developers and typically have experience with coding and integration, since those are necessary skills when working with the dev teams.
2. Process/management coaches: Agile coaches working as Process or management consultants / coaches focus more on working with leadership and portfolio owners to educate agile teams and to oversee successful adoption of the agile method across teams. These Agile coaches play a significant role in monitoring adherence to Agile practices as per the chosen Agile methodology.
3. Non-directive coaches: Non-directive coaches offer selective, need-based, individualized support for people or organizations looking to solve specific agile-related problems. They are generally brought on for very short time periods with specific mandate.

Organizations choose their flavor of Agile coaching based on requirements, size of portfolios and / or projects, client demands, current state of Agile adaption and future desired state, as well as budget and other constraints.

Image Source: Internet

Responsibilities of an Agile Coach

An Agile Coach is typically a shared resource with multiple responsibilities on their agenda. Resolving roadblocks at an enterprise level or between projects, to coaching Scrum Masters and Agile teams, to custodian of portfolio level dependencies, risks and anything that may derail achievement of planned goals are the prime focus area. Most Agile coaches also track Agile metrics at team level and hygiene factors.

The roles played by an Agile coach vary from being a reflective observer: “You do it, I will just watch and tell you what to do”, to being a passive or an active partner: “I will show you once and then you can do it” or “We will do it together”.

Image Source: Credit Thinkstock

Organizational Responsibilities

1. Become the facilitator for the organizational culture change necessary for sustained agile implementation and success.
2. Helping the organization or Business Unit implement the chosen Agile methodology by working closely with teams and resources on the ground
3. Presenting data points, reports and extracts to leadership to support implementation of chosen Agile methodology
4. Becoming the bridge between leadership and Agile teams to enable communication and sharing of expectations, plans and goals.
5. Integrate related methodologies within the company to have an unified approach

Technical

1. Act as interlocutor to ensure right stakeholders are identified and issues are addressed with the right stakeholders
2. Leveraging previous experience to teach the basics to bring people up to speed with an agile way of working; organize and lead trainings at ground level and periodic refreshers
3. Guide scrum masters towards Agile implementation and coach on areas of weakness

Trains / Portfolio / Projects

1. Work with portfolio and project leaders to develop standards and requirements for the agile process implementation
2. Come up with plans and improvement measurement metrics and methodologies. For example, tracking of user stories, sprint burndown rate, etc.
3. Work with Product owners to monitor movement of items through backlog
4. Work with Product owners / project leaders / scrum masters to identify dependencies and risks and coordinate work towards resolution to ensure minimal impact
5. Organize discussions and track progress on removal of roadblocks
6. Help Scrum masters and projects to achieve goals together
7. Track team level Agile implementation and metrics
8. Bring all Agile teams under the same umbrella
9. Ensure transparency and fairness while dealing with teams and resources

Conclusion

Over the years as sports have become more competitive, sporting teams have realized that one coach for all aspects of the game is not enough. For example in Cricket, teams employ separate coaches for bowling, batting and fielding. In football, teams employ goalkeeping coaches, striking coaches, defensive coaches and more. Similarly, many large organizations today employ multiple Agile coaches with varying and diverse skill-sets, experience and backgrounds so as to derive maximum benefit and ROI.

Adaption of Agile methods can have more than just tangible benefits. The benefits of Agile are not limited to the organization only. As an organization pursues it’s endeavors on the path of Agile journey, it contributes to its ecosystem and to the field of Agile teachings. By playing an instrumental role in an organization’s Agile journey, an Agile coach can have a lasting impact beyond their expected role.

Agile Is Not Incomplete or No Documentation — Agile Means “Right” Documentation.

Introduction

Agile methods have been growing in popularity since the first formal adaptations in late 1990s to early 2000s. Agile has its own fan clubs and is fragmented in to practice areas, from simple, single team based Agile Scrum to complex models like SAFe Agile. Besides the more popular Agile methods, there are relatively lesser known yet equally effective methods like Crystal, DSDM and Feature Driven methodology.  Regardless of the method, all Agile methodologies share much of the same philosophy and features – regular feedback loops, speed, flexibility, and above all, regular communication and interactions between stakeholders, whose roles have been clearly defined and limited in all Agile methodologies.

As the focus has grown on speed, flexibility and continuous delivery, many Agile practitioners have come to regard Agile framework as highly flexible, evolving structure without rigid guidelines, rules, or methods. Agile teams have at times contended that documentation assumes lesser priority in Agile methods while some consider maintaining documentation a matter of convenience. Along with varying viewpoints, people have come up with their own adaptations of Agile practices and guidelines, merrily choosing one while ignoring other.

Why is documentation important?

All software systems are complex products developed and delivered through a series of steps and / or processes. Irrespective of the method used or the skillset involved, each software begins with an idea and translates into a product, prototype, document or piece of code to be used for the next project.  Whether a product, document, prototype, or working software, the artifact created in one step becomes the input to the next step.

The Agile Manifesto states as one of its core principals, “Working software over comprehensive documentation”, hence many people assume that Agile means little to no documentation. Nothing can be farther from the truth. In reality however, it is often a fallacy; and nothing more than a common misconception of those inexperienced with agile. Thinking that a project can be delivered more quickly and easily by avoiding documentation is often akin to not doing enough testing in order to save time.

Image Source: Mastering Business Analysis

Documentation serves an important purpose. In particular, project teams want to capture high-level information in documentation but not details, which is largely fine as long as documentation requirements are met. You will still need to capture important information permanently, and sometimes regulations require certain levels of documentation (yet another requirement)

1. Documentation is integral -: Documentation is as much a part of the system as the source code. In addition to working software, Agile teams need to minimally deliver user manuals, support documentation, operations documentation, and system overview documentation.
2. Initial stages and recording agreements -: Documentation plays very important part in recording understanding of everyone on the project team with regard to the overall scope of work and their individual wok areas and the points of integration. Documentation pertaining to requirements and recording definition of done, recording understanding of solution and design documents are integral part of project documentation. Without this documentation, most of the project work can come at risk and re-work can become the least of project team’s headaches.

3. Inputs to next work effort -: Building high-quality working software which meets the needs of the stakeholders is important, yet its equally important to ensure that the software can be maintained and enhanced throughout its useful life. Documentation helps regular operation and support functions and without adequate documentation there are higher chances of wasted work efforts and re-work.

4. Not all projects are created equal -: Projects vary in degree of complexity and time taken to complete. Complex projects demand more concise, well-detailed documentation than simpler projects. Similarly, working on new systems or new requirements means more documentation is needed as there is little pre-existing knowledge or resources to fall back upon. Working on complex and unknown systems means more documentation as interactions will need to be understood by the team.

5. Maintain transparency and communicate better -: documentation helps teams communicate better as well as maintain transparency in to the team’s activities. It’s a fool’s world to think that project teams exist and act in isolation. In varying degrees, whatever happens on a project team, impacts other teams around.

6. Ideas and tasks cannot just be all in people’s heads -: stuff that’s not documented is sometimes lost as soon as the project is over, and definitely lost over an extended period of time. Documentation however survives as long as it is considered relevant and maintained.

Image Source Scott W. Ambler

Agile Documentation

Unlike waterfall project management, where the focus is on clearly defined documentation, and documentation is a project phase unto itself, Agile views documentation effort as only what is bare minimum essential to the project.

Agile encourages “just enough” documentation as may be required for the project to meet the expectations of customers and stakeholders.  Among other things, the level of documentation needed for a particular project depends on newness of system and requirements, maturity of project teams, complexity and scale of the project, future needs, etc.

The documentation on an Agile project can be in the form of white boards or brain maps; or sticky notes or writing on flip-up chart papers. Pictures, rather than lengthy documents can be the flavor of the day. Similarly, videos can be created of project team members explaining requirements or detailing solution or just how any part of the solution would work. Agile does not believe or recommend in documentation just because some stakeholder feels that each and every detail of the project must be captured in writing to retain knowledge for future. The aim of Agile is release increments better and faster. “Just enough” documentation fits in the overall picture of efficiency.

While some information will always need to be captured in written form or documented clearly, there are techniques that may be used to reduce amount of writing, but will still give the customers and stakeholders what they want. One way to reduce the amount of writing is to create diagrams through brainstorming using a whiteboard and capturing those as images saved by individually or as part of a document.

Image 3: Source Internet

Agile – Documentation and changing requirements

The standard waterfall requirements documentation doesn’t hold much water in Agile world. First and foremost, for any medium to large project, obtaining stable requirements upfront is impossible. The business needs and customer preferences themselves change over time, and in many cases business  and customers aren’t even aware of what they want till they see a final working version of the product. In many cases customers realize they specified wrong requirements only when they see the final version of the product. The other problem with requirements identification is understanding the intent, or the unsaid needs of the customer. Perfectly well written, and word-by-word noted requirements turn out to be well short of the customers’ expectations because the team did not understand the unspoken requirements.

Image 4: Source Internet

The product backlog, where the requirement came from, and how it will be accepted by the customer (acceptance criteria or definition of done) are all various documentation that are essential and central to the success of the project. It cannot be optional, it cannot happen “whenever convenient.” It is a part of the development and acceptance process.

Documentation in and of itself doesn’t hold much value unless it is paired with an effective communication method. The focus in Agile world is, and should be, rightly on conversations first, and documentation later. In the above cases where traditional documentation of requirements will fail miserably, communicating frequently and holding conversations about product features regularly so that the customer and project team can build the product together holds the key to product acceptance.  The simple idea is to come to an agreement point at the end of discussion about each feature or story point (where features are broken in to story points) and documenting the same. Once again, remember! Conversation and agreement first, documentation later. The agreement between customer and business and project team centers on what is the acceptance criteria (definition, roles, acceptance tests), which is later documented and forms part of Agile project documentation. This final output, after the discussions are done and the dust is settled, is the key towards a successful project as without this final step, of documenting what’s agreed, months of work and planning can flow down the drain.

Acceptance criteria & acceptance test form the core of Agile requirements. These documented agreements – Acceptance criteria and acceptance tests – cut the ambiguity around the requirement as defined by the customer, thereby improving the chances that dev team/s build the right thing, that stakeholders will be happy with. Further, it affords developers some flexibility in how they implement or develop the requirements, as long as the final product meets the criteria/tests documented in previous steps.

Image 1: Credit SkepticalAgile

In addition, acceptance tests and acceptance criteria bring about an important change within the customer organization. In many cases there are more than one or two stakeholders. Entire customer teams from cross-functional areas can participate in requirement discussions and its very common to find divergent viewpoints among the same team. Discussing and documenting acceptance criteria lends a seriousness to the entire exercise and forces the entire customer team to come to shared understanding, which simply would not exist without documentation. Divergence among stakeholders is the single biggest pain point while working with medium to large projects and Agile documentation can very well nip the problem in the bud.

At implementation level, these criteria and tests become the common language between project team, developers and the stakeholders. Acceptance criteria and tests established earlier become the basis for discussing changes in requirements, as well as how progress is tracked. Of course the acceptance criteria and thereby the defined acceptance tests can themselves change if requirements change or even otherwise following the same original course of conversation and communication followed by agreement and documentation. Furthermore, these acceptance tests can be automated, using Acceptance Test Driven Development (ATDD) tools commonly available today.

Post the requirements’ documentation, another sticking point with many is the topic of Technical documentation. Technical documentation is meant to be a description of the software as it exists including all the changes to the original version thus far as on the date of recording. The purpose of technical documentation is to allow continuity, i.e. to allow a system to be maintained by future developers, long after the original team has left or as long as the system is deemed to be useful. In reality, however, technical documentation, such as UML diagrams, may not be very helpful in solving day-to-day development problems, and are often found to be out-of-sync with the actual behavior of the system.

At the core of Agile technical documentation is documentation through tests, in what is normally referred to as Test Driven Development. When the development team starts work on a story or feature, the testers and developers come together first to define and automate the acceptance tests. This helps on more than one front. First, this helps the team maintain their focus as they implement the acceptance criteria agreed earlier, by including only those factors that contribute towards meeting acceptance criteria and rejecting those that don’t. Second, this helps the team gain a common purpose and work towards the same goal in the most time efficient manner as the inconsistencies are resolved upfront. Thirdly, this acts as a final level of check to identify any tasks which can derail the entire project. Test driven development’s core feature is to only include the tests which are appreciated by the stakeholders, and which amply demonstrate the product features and acceptance of those features, rather than including mundane or repetitive tests.

Lastly, project teams’ maturity, whether it’s a new team or has worked on several projects in the past together, is an important consideration on the amount of documentation needed. It is extremely important to document, starting from requirements to acceptance tests, however the level of documentation needs to be managed at project level.

Image Source Dilbert

Conclusion

While it is true to a large extent that Agile methods advocate doing away with rigid guidelines, documentation and maintaining artifacts is not a rigid requirement to begin with.  Lets keep in mind, agile is first of all a set of values, not a settled and strict, rigid framework. All Agile practitioners should be confident on how to adjust these values to their environment. Remember that every company has its own pace, characteristics and values.

All Agile documentation must follow the same rule – it is not that agile eschews documentation, so much as it eschews up-front documentation.

Introduction

What does scaling Scrum mean? Scaling Scrum is a challenge that many enterprises face due to multitude of factors – growing complexity of the projects, changing needs of the organization, increase ROI, need to justify investment, or simply to appear to be following a truly Agile method. Whatever the motivation or the reason behind trying to scale Scrum, enterprises quickly discover along their journeys that scaling Scrum is actually quite different from initial implementation of Scrum. And, realize that it is quite difficult indeed. While the initial implementation of Scrum would be fairly simple and not demand much, the implementation of Scaled Scrum is anything but simple.

A single instance of Scrum implementation has a straightforward path – 1 scrum team that takes work from the product backlog, performs the necessary sprints in accordance with Sprint cadence to create an usable increment of product at the end of Sprint, adds unfinished or newly discovered tasks back to Product backlog as Technical debt and moves on along the same cycle.

Scaled Scrum, on the outside is exactly the same. Selected user stories from a product backlog provide the scope of work for a Sprint, where the goal is to produce an usable increment. The difference lies within. Within the Sprint/s however, the product owner or the project owner has chosen to implement multiple scrum teams, using any number of different compositions or structures.

All of the basic cadence of Scrum – the values, artifacts, roles, and meetings of Scrum apply, whether Scrum implementation is singular in nature or scaled up. These principles remain inviolate for the purposes of controlling risk, increasing predictability, generating creativity and productivity, and creating transparency.

Image Credit: K&C

Scrum – What to expect!

Scaling Scrum is a hands-on, get-dirty down on the floor, all-hands-on-deck, sleeves rolled up model where team members figure out one instance and nuances out of other instances of scaling Scrum that might work for their projects, releases, initiatives, or organizations.

As more Scrum teams come together to work on a Product Backlog, the number of people, their interactions, inter-working dynamics, complexities, and non-linear events increase. The situation is like too many vegetables simmering in a pot – you can guess but never accurately estimate how many flavors are one too many. For similar reasons, the relationship between productivity/creativity and the number of Scrum Teams is not clear. Product Owners employing multiple Scrum Teams need to carefully weigh the benefits and costs.

Techniques for organizing and selecting Product Backlog items, resolving dependencies and integrating work, and creating “done” increments are evaluated. Since every development situation is different (domain, people, technology), every set of techniques is unique and often has to change with time.

Scrum is designed to work best in an environment which fosters complex adaptive systems which exhibit intelligent goal seeking behavior. Scrum is designed to support an object-oriented component architecture.

A.      Early Implementations

One of the first implementations of Scaling Scrum  was studied in IDX systems (later known as GE Healthcare) in 1996 – 2000 period.

• Managers self-organized company into teams
• Managers became team leaders
• Directors ran Scrum of Scrums
• VPs became leaders of sites with multiple Scrum of Scrums
• Grew to over 600 developers
• Virtual architecture teams
• UX team and Integration team
• External experts verified that production doubled company-wide

Source: Scaling the business by scruminc.

Using Scrum at scale is another term coined at Microsoft following their extensive experience with Scrum here and here. At the same time, virtually all other top product and software application companies have realized the huge benefits of doing Scaled Scrum.

B.      Team Structure and reporting

The first step to scaling is to form teams focused on features in order to maximize the user experience and speed of iterating on working software.

• Every team has a product owner assigned and a professional Agile Coach who drive process improvement across the company working directly with senior management team.
• A very important factor to account for is location of the teams. Team co-location is crucial, however not always practical. If distributed teams cannot be avoided, extra steps need to be taken to induce the feeling of co-location by measures like periodic get-togethers, reliable and prompt communications, etc.
• Teams need to have clear autonomy and Scrum master must work with the team to remove impediments. Scrum master assigned to the team gets measured on process improvement and timely removal of impediments.
• Regular communications and meet-ups between the teams and are crucial to disseminate information and provide autonomy as well as relevance to teams. Cross dependencies can also be resolved better and faster this way.
• Cross functional teams are comprised to provide feedback to the community of practice they belong to. Communities of practice are generally the organization of resources according to their skillsets. For example, all Java resources may belong to the ‘Java practice’ in an organization, if the organization has such a setup, from where they are assigned to different projects. While in a project, resources report to project management as well as their respective community of practice.

Image Credit: Knowledgehut

Scrum – Frameworks

All SAFe scaling frameworks share some common patterns: Scrum implementations at team level, multiple teams sharing same product backlog, planning done as collaborative exercise across teams, and the general principles of pull and self-organization.

Scrum teams can be organized in many different ways, contingent on the framework used. There are number of frameworks that are available out there today. In this article we provide a brief on most of these frameworks for scaling Agile – LeSS, SAFe, and Scrum@Scale, DAD (Disciplined Agile Delivery) and Nexus

All Scaling Scrum frameworks start with cross-functional, self-organizing Scrum teams. The teams dissect and slice requirements into the smallest possible measurable tasks and increments that can be developed independently. Teams are expected to focus on self-learning, technical and process excellence such as doing continuous integration and automated regression testing to ensure that new code pushes don’t break any existing functionality. At the end of every sprint the teams should have a potentially deployable product, called an ‘usable increment’. The frameworks also encourage the use of Lean principles to optimize flow.

A.      LeSS (Large Scale Scrum)

LeSS is a framework for Scaling Scrum that comes from two practitioners – Craig Larman and Bas Vodde, based on their work in the financial and telecommunication industries.

LeSS is defined by approach of minimalistic nature in supervision as well as use of processes, i.e. use as little processes to get multiple Scrum teams to work with each other well enough. LeSS consists of a hand full of rules, and also has guides and examples for how to customize these rules as the organization grows.

Perhaps in some ways LeSS is a larger reflection of how an ideal Scrum implementation is supposed to work.  LeSS recommends that there be multiple Scrum teams with the same product owner and shared product backlog be maintained to promote consistency and predictability. Scrum teams should be long-term, cross-functional teams. Sprints should be synchronized to represent a product-level sprint leading to one usable integrated product increment at the end of the sprint.

A LeSS Scrum Master typically encounters complex large-scale problems and s/he needs to resist the urge to resolve them with equally complex solutions. Instead, the scrum master should leverage the spirit of Scrum and find simple ways to empower people to resolve their impediments. This approach leads to large-scale, yet simple, solutions.

Image Source: Less.works

LeSS is characterized by a single product owner with one product backlog, and several teams, each with its own sprint backlog. The Product owner is the owner of the complete product backlog and typically there are no divisions of the product backlog, unless using a methodology like LeSS Huge.

LeSS is the purest version of Scrum with only notable difference coming during the planning stage. As compared to Scrum which notes that there be 2 planning meetings for each scrum, LeSS recommends that the first sprint planning meeting be the joint meeting where user stories for product level usable increment is finalized (finalizing a product level Sprint Backlog), while the second part of the planning meeting is used by each team to produce their own specific Sprint Backlog.

B.      SAFe

In the words of Dean Leffingwell, SAFe® is a freely revealed knowledge base of proven, integrated patterns for implementing Lean-Agile development. It provides comprehensive guidance for work at the Portfolio, Large Solution, Program, and Team Levels.

SAFe approach gained prominence post 2012 and has had 4 major updates since its initial release in 2011.  Currently, the available approach is SAFe 4.6 launched in October 2018.

SAFe approach is a quintessential reorganization of the work with the aim of maximizing the speed of product or service delivery from initial idea to release and from customer feedback to enhancements and improvements. SAFe approach is based on organizing work in to value streams based on the repetitive nature of work performed. Each value stream has got its own organization of release team, called The Release Train. This ‘Release Train’ generally comprises multiple Scrum teams working together to deliver a component of ‘usable increment’ of the product. The ‘usable increments’ from all the Release Trains and Value streams then is combined to become a product increment.

SAFe methodology is further available in 4 different configurations dependent on the needs and size of the organization. The 4 different configurations vary considerably in terms of complexity and inter-play of components as well as the focus areas. These are:

1. Essental SAFe
2. Portfolio SAFe
3. Large Solution SAFe
4. Full SAFe

C.      Scrum@scale

Scrum@scale looks to tackle the problem of Scaling Scrum through questioning the ways of working and analyzing various choices to find the right approach to suit the context.

Scrum@scale is defined as follows:

Scrum@Scale (n): A framework within which networks of Scrum teams operating consistently with the Scrum Guide can address complex adaptive problems, while creatively delivering products of the highest possible value.

Scrum@scale imbibes all the principles of Scrum methodology – light structure, minimum bureaucracy and process controls, simple to understand however difficult to practice, needing regular and sustained cadence.

Scrum@scale contains two interlinked cycles: the Scrum Master cycle and the Product Owner cycle. These 2 cycles work in an interwoven way to provide a powerful framework to coordinate the efforts of multiple teams along a single, desired path.

Source: Scrum@scale guide

A set of the teams that operate within the project or have a need to coordinate comprise a “Scrum of Scrums”. The Scrum of Scrums is a “team of teams,” which hold a Scaled Daily Scrum (SDS) event with a representative from each team (usually the team’s Scrum Master, although any person or number of people may attend). The SDS exists to coordinate teams and remove impediments to delivering value.

The Scrum of Scrum must include all capabilities needed for product release at the level of Scrum of Scrums. That means that the Scrum of scrums should have the capability to look at the small goals and impediments while looking at the big picture all the time – to the point where it becomes ingrained in the team’s DNA.

Scrum of Srcums is at the heart of Scaling Scrum approach as laid out in Scrum@scale. The Scrum of Scrums team works independently as a release team and must be able to deliver value to its customers. To achieve this effectively, Scrum of Scrums has its own artifacts, roles and events – Scrum of Scrums daily standup, Scrum of Scrums retrospective, Scrum of Scrums review, etc where participants from all the Scrum teams attend, led by Scrum of Scrums master.

Scrum@scale also lays down the concept of Executive Action Team which is a super-body of Scrum of Scrums of Scrums operating within the organization. The purpose of establishing this super-body is to create an Organization level backlog of Agile initiatives (prioritized list of various initiatives) and aid in resolving the organization level impediments that hamper the achievement of these objectives.

Scrum@scale essentially views the entire organization as a super scrum team, something of the sort of a Scrum Master organization, transposing the agile operating system from project / program / product level to organization level.

D.      Disciplined Agile Delivery (DAD)

DAD or disciplined Agile Delivery is characterized as is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), and Unified Process (UP), amongst other methods.  DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users.

E.       Nexus

According to the definition available at Scrum.org Nexus is an exoskeleton that extends Scrum to guide multiple Scrum teams on how they need to work together to deliver working software in every Sprint. It shows the journey these teams take as they come together, how they share work between teams, and how they manage and minimize dependencies.

To start a Nexus, organizations should first:

• Identify the teams in their Nexus
• Form an initial Nexus Integration Team
• Have a single Product Backlog
• Have a definition of “Done”
• Identify a Sprint cadence

Just like Scrum@scale, the Nexus approach has its own terminologies, artifacts and resources. Nexus Daily Scrum, Nexus Retrospective, Nexus Review, Nexus Integration team, Nexus Sprint Backlog, Nexus Sprint Planning.

A representation of Agile Map

Conclusion: Scaling Scrum is a challenge!

As team sizes grow, organizations grow and their needs become more complex, bigger and more complex impediments arise along the road. The role of Scaling Scrum is to provide a framework to continually identify and remove dependencies created by increased complexity.

Scaling Scrum, like implementing Agile Scrum methodology is a matter of choice. Many organizations have reaped tremendous benefit and even more continue to do so. However, the primary integration point of Scaled Scrum is within the culture of an organization. The complexity of an organization’s hierarchy and culture defines the kind of products and applications it produces. In the words of programmer Melvin Conway:

“organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”

— M. Conway

An easy example of this can be seen through the website of a company, where it is often noted that the complexity, content and structure of the website depends on the demands of the internal teams rather than the needs of the users.

The Second challenge to successful implementation of Scaled Scrum comes from communications. As software projects grow in size and complexity, so do the teams of engineers that develop and maintain them. Brooks, in his seminal work, “The Mythical Man Month” discussed coordination as one of the key problems of running a software project with many developers. The coordination effort required to help each member of a team stay in sync and keep a project on schedule is enormous.

Early indicators of software quality are beneficial for software engineers and managers in determining the reliability of the system, estimating and prioritizing work items, focusing on areas that require more testing, inspections and in general identifying “problem-spots” to manage for unanticipated situations. Often such estimates are obtained from measures like code churn, code complexity, code coverage, code dependencies, etc. But most analysis often ignore one of the most influential factors in software development, specifically “people and organizational structure.” Read this paper for more information on the study conducted at Microsoft to analyze the above: Empirical software engineering at Microsoft Research

Generally speaking, LeSS is considered a good starting point for organizations who are relatively inexperienced in their Scrum adaptation. LeSS scales up with minimum addition of processes and leads to significant gain. On the other hand, implementation of an approach like SAFe demands a high organization maturity and experience of implementing Scrum. Implementing SAFe is generally for full scale Agile organizations and requires high degree of commitment and focus. Scrum@scale is a good approach for organizations with several scrum teams in place which want to focus on finding things and areas to improve.

In the end, choosing a methodology depends on the context and the situation, with the most important principle – ‘improving how to work together’.

Originally Published May 12, 2018

Introduction

Jeff Sutherland and Ken Schwaber conceived the scrum process in the early 1990s. The term ‘Scrum’ was originally borrowed from rugby and referred to ‘team of individuals working toward a common goal’. The pair codified scrum in 1995 in order to present it at an object-oriented conference in Austin, Texas (during the OOPSLA 1995 conference) and published it in the form of a paper titled “SCRUM Software Development Process.” However, the development of Scrum is not so clear as needed to credit just one or two individuals.

Many publications and experts credit Hirotaka Takeuchi and Ikujiro Nonaka, two acknowledged management thinkers, as the proponents of first concepts related to Scrum. A paper published in the January 1986 issue of Harvard Business Review by the duo gave detailed principles of Scrum. Jeff Sutherland and Jeff McKenna drew on the inspiration of this 1986 article and developed it further. The first full implementation of Scrum occurred in 1993 when Jeff Sutherland along with John Scumniotales and Jeff McKenna implemented Scrum at the Easel Corporation.

Image Credit: Internet

Scrum was initially based on the notion that development of new, complex products, can be best achieved when small and self-organizing teams are given objectives rather than specific assignments. The team had the freedom (self-directing teams) to determine the best way of meeting those objectives. Scrum also defined time-boxed iterative development cycles whose goal was to deliver one or more features in each release, thereby delivering incrementally working software version with each release. Today, most teams that claim to practice an agile methodology mean that they’re using scrum.

The original Scrum definitions, purpose and uses are best found at Scrumguides.org

The best explanation of what Scrum is, in the words of Jeff Sutherland and Ken Schwaber is as follows:

Jeff Sutherland believes that Scrum is a framework with a set of best practices learned over fifty years. Ken agrees as well with this and gives a good analogy of comparing Scrum with playing chess: The word “framework” means that much is not specified and must be devised by those using the framework. I equate Scrum to the game of chess. You can read the official rulebook for chess. The moves, players, sequences, scoring, etc. are all specified. Learn them. Then you can play chess.

Image Credit: Internet

Core Practices in Scrum

There are core principles in Scrum that are widely discussed about and known. Based on these principles, there are multiple practices that are acceptable within Scrum, which teams may adapt based on their needs and requirements.

• Work is organized in short cycles, typically 2 weeks:
• The management takes backseat and doesn’t interrupt the Development team during a work cycle. Any interactions are through product owner.
• Role of Product Owner as the custodian of Product Backlog
• Product Backlog is the document where all requirements are recorded
• Product Backlog refers to all the work that remains to be done on the project
• The team reports to the client and product manager for work done
• Estimates are drawn up by the team
• The team decides how much work (how many story points, features, etc from the product backlog) it can do in an iteration.
• The team decides how to do the work in the iteration.
• The team measures its own performance.
• Define work goals before each cycle starts.
• Break down work in to small use cases, user stories.
• Systematically remove impediments.

The above are not exhaustive rules, but best practices modeled on Scrum rules which teams are free to adapt.

Growth of Scrum and its default usage with Agile

Scrum is now the default agile software development methodology. This management framework, which is “simple to understand but difficult to master”, is used by 66% of all agile companies.

VersionOne’s 2016 State of Agile Development survey puts the number of teams currently following a pure Scrum approach for their agile implementation at 58%. Furthermore, this number increases to 75% if you include hybrid approaches such as those which combine Scrum with another agile approach such as Kanban to create Scrumban.

Image Credit: VersionOne’s State of Agile Development survey

Why is Scrum so unpopular?

Before the Agile fad made it a lasting and widely-used process, many organizations used the term “Scrum” for what someone would commonly call a “Code Red” or a “War Room emergency”. If there was an uncontrollably fast spinning out-of-hand situation, or an unexpected failure, or rapidly-evolving problem, the management or the department leadership would call together their best people and form a cross-cutting team. This cross cutting team’s only mandate would be to resolve the problem as quickly as possible.

Of course, the team would have a leader for namesake, in other words as there is no clear manager as the team didn’t evolve but was rather plugged together, a leader would be ‘assigned’. This person is sometimes called Scrum master and his / her authority is limited to ‘removing impediments’ and ensuring that team members ‘meet’ daily. The management would not want him to be an official “people manager” (since he needs to be as impartial as possible). Since the crisis is short-term, the team members’ career goals and aspirations are put on hold. It’s considered a “sprint” because people are expected to work as fast as they can to solve the problem, and because they’ll be allowed to go back to their regular respective functions or teams once it’s over. The team members, many of them highly qualified engineers and thinkers pitch in whole-heartedly as they feel doing so is the best interests of the organization. The focus is on the mission and the mission only.

Image Credit: Internet

However as time wears on, and ‘Sprints’ progress, the never ending nature of ‘emergencies’ become clear. That these çode-red’ situations are now imbibed in to the organization’s DNA becomes clear when project after project falls in to the same framework.

Once a firm sees the dramatic benefits of small client-driven iterations in one area, it becomes natural to ask: Why not do all work in this fashion? The bigger question to ask is : Can all work be done in similar manner?  Can code-red situations exist forever or become the de-facto working style? What impacts does it have on the humans involved in the value chain? After all, an organization’s most important asset are its resources. So what about their perspective? Are these resources happy to work in an environment where they need to justify every hour of their day producing predictable results like a machine? Or is it not important at all to take their viewpoint and their idiosyncrasies in to consideration? More often than not, in the race to become Agile and implement Scrum, such questions get relegated to sidelines.

Image Credit: Internet

Here is a look at some of the reasons Developer communities and professionals in project management have ceased to be a fan of Scrum:

1. Use of Story Points -: The use of story points appears to be one of the defining features of Scrum. Each user story is given a certain count of story points, and a team is confronted with the number of points it has “achieved” at the end of a sprint. Some teams also follow their daily progress in terms of story points with a burndown chart that is consulted every day at stand-up. However, with teams working to gather points the focus gets shifted to completing tasks instead of delivering good software. The questions that seem to come under focus is how many stories are complete, and not the more important questions of how has the code base improved? Did it become more modular, simpler, habitable?
2. Barrage of meetings -: Scrum recommends the following type of meetings
   1. Planning meetings -: Planning always seems to be a regressive activity. Little attention is paid to the accuracy of estimates which may seem a pointless exercise after certain time. This is one area where teams can learn the most, because incorrect estimates point to misunderstanding of the code base and domain, but decent review of estimates is rarely, if ever done.
   2. Retrospective -: very little value add is achieved, as in Scrum, the retro is explicitly supposed to be about the Scrum process itself, not about the codebase, the technology stack or development patterns.
   3. Daily standup -: While sounding noble, I have seen more than one example where daily stand up meetings become more of a ritual than anything else. People talking in to voids, while others keep doing their stuff dreading their chance to speak, at the end of which same standard sentences get repeated.
   4. Scrum meetings aka Show and tell -: Points are awarded often for whether the particular feature works or not, irrespective of how much thought process went in to the work. Often there is extra work needed to set up the demo which doesn’t get counted in any estimates.

3. Scrum as Management Tool -: Scrum is seen by many as a Management tool rather than a Development process. When the management imposes process and demands one-sided transparency of all the workers, people feel watched. They get the sense that they’re being stalked and will be labelled “low performers” as soon as their week-by-week, individual fluctuations go the wrong way. So they become resentful.
4. Sprint, Sprint, Sprint -: Sprint is an iteration in which work is done; where usually selected user stories at the start of the Sprint are developed and released at the end of the sprint. Work to be done in the Sprint is selected before the start of the Sprint from product backlog. Once Sprint starts, the work cannot be changed, scope added or deleted unless in agreement with product owner and the team. The team retains the call to agree to scope changes during the sprint. However, this very idea of not deviating from planned work is like an anathema, as software development cannot be always predictable. Each project is different; new ways of solving even older problems can be found, and its entirely possible that team may discover new problems or new things about existing problem at hand which may require a course correction. These discoveries may affect not only the estimate but alter the entire path team is taking to resolve that problem. Hence assuming a linear trajectory for the project path in the sprint becomes really tough handoff between just getting the work done vs quality of work.
5. Oversimplification of Development processes -: the development process at the very least, is as much about humans as it is about work on hand. Its easier to assume that team would organize itself and the dependencies between work picked up by two or more than 2 individual team members get managed without any conflicts or creating further dependencies. Further, how should work be re-arranged when new discoveries are made?
6. Scrum inhibits deep thinking and innovation -: In Scrum, the gods of story points per sprint reign supreme. For anything that doesn’t bring in points, one needs to get permission of the product owner or scrum master or someone who has a say over them. Refactoring, reading code, researching a topic in detail are all seen as “not working on actual story points, which is what you are paid to do”. Specialization is frowned upon. Deep thinking, problem solving, research, are all considered wasteful activities when the same hours can be spent to code 2 more story points. Whatever technology one helps develop or is introduced to, s/he is not allowed to become an expert at it, because it is finishing a story that brings the points, not becoming an expert at it. These are all manifestations of the control mania of Scrum. Management uses Scrum to micromanage teams and individuals which leads to resentment and feeling of loss of autonomy
7. Unreasonable expectations -: Management unwilling to give the teams time to evolve around Scrum with the expectations of immediate results tied as a noose around the neck of team members. Team members are expected to move from story to story, from project to project with little time to develop expertise or finding that one area that truly interests an engineer.
8. Creating customer value -: Every feature and user story has to provide some kind of customer value or result in some benefit to customer. In reality though, there is a world of software beyond immediately recognizable value or benefit for the customer. Many software systems are complicated, integrated pieces of art which are working together as a cohesive unit, even when there are tens of things wrong that could break the code or stop the functionality. This is especially true in case of platform services which feature some kind of integration with Legacy systems. To keep the show going, there is behind the scenes work required to make the platform more reliable or resolve that one bug that has been carried on as technical debt, or tweaking some back end feature to display results faster. Does
9. Customer interaction -: Continuous interaction with customers is good but only to an extent. Not all team members are customer management experts, in fact very few technical people know much about managing expectations and are quite often not great communicators. This is not a negative, as its not a skill requirement for a great coder to be great communicator, however for someone dealing with clients and customers, good communication is must. Plus, when do you really draw a line between endless customer changes and delivering a final product.
10. Unnecessary cutoff from the world -: Submarine development (coding underwater for extended periods of time, surfacing only occasionally) is bad. Endless chasing of one feature list after other leads to burnout and lower morale.
11. Looking at the wrong details -: An aggressive focus on individual performance where it stifles creativity and detailed planning is often detrimental both to the individual and the team. When faced with such situations, people just try to finish the tasks to meet the sprint goals. The efficacy of those goals to meet customer expectations as well as quality takes a back seat.
12. Communication -: Each team member is supposed to articulate 3 things in the daily standups. It is a known fact that not all team members are equal communicators. Team members have varying communication skills – so how does everyone get an equal chance of being heard? And more importantly how do each team members’ point of view get voiced?
13. Lack of respect for team members’ seniority levels -: Respecting someone’s experience and skills is very different to creating hierarchy layers. Individual team member’s skill and experience can be rewarded in other ways than creating and awarding lofty titles. More often than not, such individuals with excellent skill, experience and track record of solid engineering background settle for autonomy to do their thing, getting involved in thought provoking research oriented work, higher end transactions, chance to lead client meetings, chance to train junior employees, etc. Basically anything which takes them away from daily grind and rewards them for their years of hard, superlative work. Scrum, on the other hand is often used as an excuse for lack of concern for people’s career objectives in work allocation. Imagine an engineer with 10 years’ worth of experience and an enviable track record, asked to code the same the same requirement as an engineer with an year’s experience. At any rate, that’s not a pretty scenario.

Image Credit: Internet

Is Scrum completely useless?

Most experts are not against every idea and practice in Scrum. For example, the principles of the whole team taking responsibility for the code base, or always having an integrated, working master are really noteworthy and something that all teams in all project settings can benefit from.

Software is research; its as much discovery and going along the unknown path as it is about following standardized, laid down paths. It’s a matter of discovering the solution, not rummaging through it.

Image Credit: Internet

Scrum, as many practitioners will tell you is far from useless. In fact, its simplicity makes it very popular among industry practitioners from all backgrounds. There are lots of other techniques that you can use with Scrum – user stories, continuous integration, burn-down charts, burn-up charts, estimation of tasks in hours, complexity points, etc. But none of these are mandated.

Image Credit: Slideshare

Conclusion

A lot of Scrum that is seen today is more along the lines of “This is a buzzword, I read a blog post and watched one of those YouTube videos…let’s go!” without understanding of the principles or how to implement those.

As one senior developer put it once: firms and teams are much better off and will have much higher chances of success if they attempt to answer these two questions honestly:

• Whats the team’s process from feature request to feature delivery?
• Why did the team choose that method?

Many in the development community particularly many old heads feel It’s time for this culture of terminal neglect of experience, low autonomy, and aggressive management intervention to pass over to something more adept at the growing needs. These folks feel that Scrum and Agile aren’t just bad ideas – they’re more dangerous than that, as an entire generation of new engineers and professionals using these techniques are getting their horizons restricted, having to absorb limiting methods such as Scrum and Agile. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and “user stories” are how things have always been done.

Image Credit: Dzone Agile

Agile and Scrum rose in prominence post 2001, when the growing requirement of immediate results just couldn’t be met through conventional waterfall project management techniques. Before that the software development field had persisted with same old conventional techniques for 3 or 4 decades.  Perhaps, just perhaps, the time for rollover to new methods has been shortened from 3 or 4 decades to 2 decades. Perhaps, Scrum has now become the new ‘old’ method of doing things.  Perhaps, its time already for newer methods to replace conventional Scrum.