Artifacts and components – how do they improve Scrum?
Introduction: “Same same but different, but still the same”
Years of accumulated insight and self-observations have led us to the point of being certain and bold enough to implement custom improvements to well-known frameworks of choice. Since the earliest versions of WISE were released, it has evolved into much more than just a process of “know-how”. It evolved into a specific type of approach, a process that developed a culture of high ownership and teaching users to become aware of the various aspects of organic work involved in software development.
WISE is a result of our growth-driven culture and custom-made improvements aimed at raising the value of digital products by only implementing features that can benefit the business and its end-users. WISE is not a new framework, it’s an established set of good practices. Even though it started as merely a plugin (an extension to an existing framework), the changes it offers nowadays to make a world of difference in terms of productivity, performance growth, and the overall well-being of the clients, their products, and even the software engineers working on the project. We can proudly state that WISE is a cornerstone of LEOCODE’s approach.
The main part: What SCRUM does not have.
WISE is a product-building catalog of artifacts based on a multilevel analysis of implementation. This analysis is present throughout, even during the early stages of software development. Its purpose is to create a product that meets its stated requirements representing the measurable market value and answering the clients’ business needs.
The process utilises the traditional way of building an application. All of the features built in the process come from the stated business requirements as well as market and user research.
The core of WISE is implementing only the features that provide real value for the end-user and business owner. The first question we ask is “What value does the product provider have and which problem does it solve?” – Only then do we start working on the technical aspects of developing the required features.
Is it a real improvement?:
Scrum is far from perfect as its agility is often questionable at best. Sooner or later, improvements had to be made. Enter LEOCODE to finally bring you the long-awaited update.
I personally think of SCRUM as a blunt tool, a framework created for the sake of systemization, communication and continuity itself. It’s a framework for solving tasks that come strictly from above. There is no space for initiative coming from the bottom that can break the glass ceiling and reach the decisive person on top. Scrum is a pre-defined process containing a set of fixed roles and rituals that remain unchanged throughout its implementation.
Scrum values following a plan over responding to change.
WISE is more of a smart tool. It is self-aware and constantly adapting a set of practices that can be implemented into any framework. However, in this article, we will focus strictly on its relation to SCRUM as WISE is SCRUM turned agile.
WISE components/SCRUM tweaks:
Measuring and evaluation of the effects of own work
When implementing a task, developers are obliged to monitor features by gathering data such as usability, overall popularity etc. This information can be delivered to the client afterward, but it’s not a fixed rule. The components and events offered by WISE are well known in all types of agile approaches but it is important to state that we only use the ones that are strictly necessary and potentially beneficial for the project. Again, we do not go down the “one-solution-fits-all” route.
- Result: This component makes our software engineers more engaged in the process as it allows them to see the effects of their work in the “real world”, so to speak. This includes the number of uses of the feature, improving the speed or processes within the application and reducing the need for human maintenance. These features allow the engineers to tweak their work accordingly and always provide the best possible solution. Not every client shares this type of data with the development team, however. Not sharing data unnecessarily separates the developers from the results of their work, disrupting the natural process of adjusting accordingly to the situation.
Epic owner:
Tasks are assigned to a person responsible for delivering solutions who will stay with them from the beginning to the end. They can be major tasks (even if they are single), or even entire clusters of less significant ones.
The role requires a high level of ownership as the person assigned needs to acquire information from various sources such as the client and other development teams, they need to take part in business idea evaluation workshops and also create proper documentation.
The mentioned task has to be complete in terms of the business aspect, as well as being technically correct and robust.
- Result: In most projects that utilize agile methods, the tasks are done by the product owner in co-operation with a team leader. Our way gives the developers more freedom in the decision-making process as they are the closest ones to the actual process itself and know the product the best. Long-term results show that passing the driving force to the development team increases their engagement and understanding of the product and also ensures the continuity of work in case the team leader is absent.
Demo for the client:
After completing each sprint, a demo for the client is prepared. During the demo, the team presents what has been done in the recent sprint by going over each and every implemented feature.
- Result: Proving a demo is an obligatory element of the implementation process. Its main purpose is acquiring the client’s acceptance and verifying that the features provided meet the requirements. The team takes full responsibility for any successes or failures. No achievement goes unrecognized and nobody is left anonymous. This is another element of building a sense of ownership and teamwork. Additionally, the process allows the client to maintain control over development and, quite literally, see the product being built in relatively close iterations.
Testing:
A finished task is a fully tested task. Our developers and testers are obliged to write automatic tests. Testing has to be implemented from the very start as it gets more difficult if the team starts writing tests further in the process. At the same time, tests should be prepared in a way that allows the code to be potentially tweaked if needed. If the client insists on a particular amount of testing but with a reduced number of work hours, this has to be addressed formally at some stage of the project as we believe that testing is an integral part of the development process as it helps to build features and create value in the product.
- Result: Preparing the tests guarantees avoiding regression errors. Writing a test forces a properly prepared solution. If a solution is difficult to test, there is a possibility that it has been prepared in an overly complex way. High-quality testing provides high-quality code. Application tests are the only determinant of the implemented solution. Automatic tests save time and reduce costs thanks to the avoidance of repetitive actions.
Documentation:
We prepare proper documentation for each of our projects and store them safely in repositories. Creating project documentation always starts in line with the beginning of the project itself.
Documentation can be divided into the following categories:
- Business documentation
- Functional documentation
- Technical documentation
- The project card/files
- Changelog
People responsible for creating the documentation are the product owners (the designer team), developers/testers (technical documentation, changelog, test documentation), project manager/product manager and tester (functional documentation, changelog, project card).
- Results: Creating the documentation teaches time management and helps to understand the implemented functionalities. It also serves as a validation of the implemented features in line with the business requirements. We always include information about how and why the given feature has been implemented and what business purpose it serves.
Calendar:
We run the project calendar in two variations: Firstly, each team member has his/her own individual calendar and secondly, we run a group project calendar.
In the team calendar, we set the time frame for each sprint and record all repetitive events occurring during the implementation process. The calendar is always created at the start of a project and is regularly updated and shared with each team member and the client’s representatives who are engaged in the process.
Managing individual calendars is one of the tasks each developer has to fulfill themselves. This task isn’t limited to booking calls and meetings and showing potential availability, running the calendar also includes managing individual tasks in a particular time frame and finishing them before a given deadline.
- Result: Working with a shared calendar allows everyone engaged in the process easy access to the project status and information on its current stage. It makes communication with the client much easier and more transparent. Planning individual work in a personal calendar improves productivity and allows easy verification, as well as time estimation, for each task. It sets a high standard for individual performance and mobilizes our developers to complete their tasks in a given time period.
Self-decision:
Professional confidence can be helpful when making critical decisions. In a situation where the client has to decide between various options and is unable to provide answers, the team should take ownership and make the right choice on their client’s behalf. Every choice should be based on proper expertise and research.
Self-decisiveness also refers to making decisions in the tech team. The team leader does not force any solution on the developers who are engaged in completing the tasks but is available for guidance throughout. Everyone is free to consult with any other team member at any time in order to help them make good, informed decisions.
- Result: The project will grow much more dynamically and with fewer unnecessary roadblocks when developers take ownership of their decisions in consultation with their teams. We’re confident in our skills and have great trust in our professionalism. This positively affects our clients’ satisfaction as they value the undisrupted work which offers them peace of mind.
Retrospective:
Retrospection after each sprint is a sure way to correct the course of team efforts and the project itself. It is also a great opportunity to provide feedback to the team members. Similarly to code review, retrospection offers room for discussion, feedback loops and overall helps to improve all processes.
- Result: Building a culture of feedback and self-improvement is an asset for every software company. As a growth-driven organization, we’re not afraid of making mistakes. “Fail fast, fail better” is one of our mottoes.
Team definition of awesome (TDoA):
TDoA is a meeting, aimed at improving the weak points of the team and tweaking specific areas of performance. During the meetings, the team marks aspects that need to be improved while defining measurable goals that need to be achieved within a specific timeline. The first effects of improvement should be measurable at about halfway towards the stated goal.
- Result: The team learns to spot potential issues and solve them quicker. Mutual trust increases as the search for a solution becomes a team effort. Additionally, honest communication brings benefits in the form of a better understanding of potential issues and more focus on future improvements.
Review:
The mutual review of developers’ work can be divided into two categories: Code review and design review. This is an obligatory stage of completing a task. Thanks to the review, the team can verify whether the task has been completed in the right way or not. The review process teaches humility and gives us a better overview on our own work. During the implementation stage, certain solutions often appear genius but turn out to be too complex or simply wrong when put into practice. Reviews can also be performed when the task is not fully ready; this allows us to correct potentially faulty features as we go along. The review should be requested personally unless the team already has a working feedback and review culture with a fixed time for conducting reviews.
- Result: We are not able to critically look at our work and judge its results, especially at the moment of finishing a task. Stepping back and looking at it with fresh eyes during a review can be a great turning point for some decisions. It also helps to develop technological skills faster as you’re able to discuss doubts in real-time and get answers instantly.
Tech Advisors Guild:
Tech Advisors Guild is a series of online meetings between our LEOCODE staff and some external experts who we invited to speak to us about the way issues are handled in different companies. They covered topics such as solving problems with certain specific solutions and shared their take on various technologies. TAG is a fantastic opportunity to learn from knowledgeable experts and use their experience to help make improvements to any organization so it’s definitely worth a view.
Software Craftsmanship Guild:
SCG is another series of internal meetings in which our software engineers exchange their insight and experience into all sorts of topics such as cultivating the culture of “Software Craftsmanship” and pushing each other to grow as professionals and extend their range of expertise.
Open source:
Recently, we started investing in Open Source technology and we share projects on our GitHub profile (link). In agreement with our team leaders, we decided to give our developers time to develop their own OS projects.
Why is that?
- We will pay back the debt incurred by using other OS solutions.
- We will build the company portfolio.
- Each member builds his/her own portfolio by contributing in team projects.
- It allows us to experiment with different technologies and approaches.
- It gives us an opportunity to school new developers!
Architecture guild:
This is simply the evolution of a daily team call. We did not see much value in a daily call in its base reporting form so we decided to add some elements to it. “Solution review” gives every member of the team a chance to discuss the features and technical solutions undergoing some work. It saves time during the final code review and lets the whole team stay updated on everything that’s happening in the project.
Dictionary:
Discussions between developers, designers, and clients can be problematic. The technical terms that are used can be misunderstood and are often imprecise which can quickly lead to communication issues.
The creation of a dictionary has proven to solve some of these issues and is a great addition to standard documentation. The dictionary contains the most commonly used terms, both internally (by developers) and externally (by end-users).
An hour of planning saves 1000 hours of coding
The most expensive mistake of software development is heading in the wrong direction only to eventually change course entirely. If the prepared mockup/prototype of an app does not offer the functionality that it is supposed to bring or interferes with existing features, it means that the solution has not been properly thought out and the time has been wasted. That is why we can not stress enough how important the preparation phase is.
Summary:
Let’s get something straight here; SCRUM does not answer all of the needs that a modern software development process has. WISE is neither a new framework nor a replacement for SCRUM. It also does not exclude working in SCRUM at the same time. It is merely an improvement to the existing ways. WISE compliments SCRUM’s organizational flaws with our custom-made artifacts and helps to build the real, measurable value of the product and allows our clients to reach their business goals.
WISE best fits fast-paced projects where the business requirements change rapidly. As it’s based on a proactive approach, it allows a quick reaction time to make suitable corrections and setting new goals without disturbing the process. It’s perfect for building MVPs, startups and other projects needing true agility. It is crucial to state that many teams are closed to that kind of approach and therefore limit themselves which will likely affect the quality of the end product.
Many digital products show flaws in their business aspects and their creators tend to forget about answering the real, measurable needs of the potential end-users. We fill in the holes by using the WISE approach; providing reliable user research and offering future-proof solutions to the potential issues that the clients are not even aware of yet. In addition, our 8+2 (eight days of undisrupted work and a two-day “safety margin” for unpredicted issues or organizational work such as managing the JIRA board system) offers ample room to complete the task successfully through frequent meetings and the chance to make quick readjustments to meet the ever-changing needs of a modern project.
