Are solo developers adopting Agile practices? A short interview with an open source game engine confirms my suspicions and makes me think seriously about this and other issues…
This is a real video from my cat, not a random meme. He’s heavily trained to detect lousy Kanban implementations!
So… what is Agile, again?
Agile is a set of methods and methodologies that are optimized to help with specific problems that software teams run into, and kept simple so they’re relatively straightforward to implement.
These methods and methodologies address all of the areas of traditional software engineering, including project management, software design and architecture, and process improvement. Each of those methods and methodologies consists of practices that are streamlined and optimized to make them as easy as possible to adopt.
“Agile is also a mindset, and that’s a new idea for a lot of people who haven’t worked with agile before. It turns out that each team member’s attitude toward the practices they use can make a huge difference in how effective those practices are”. (Stellman and Greene 2017).
“The foundational building blocks of Agile are its values and principles. This is probably the most important point that is often misunderstood and needs to be recognized. Agile is not a process, methodology, practice, or tool but a set of values and principles. The implication is that Agile is more about a state of being: the Agile mindset. Agile values and principles are components of the Agile mindset”. (Moreira, M 2013).
Manifesto for Agile Software Development
In February 2001, 17 independent practitioners met at the Snowbird resort in Utah to discuss software development methods and they published the Manifesto for Agile Software Development. Apparently the participants didn’t agree about much but they found consensus around four key values. To this day their statement remains a foundation stone for the agile movement.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
If you don’t work in the software industry fear not, as authors Rob Cole and Edward Scotcher clarifies: “One of the recurring questions is whether agile only works well in the software development business or whether it can be applied more widely. Admittedly the Agile Manifesto was born of a desire to improve”. (Cole 2015).
The Manifesto is supplemented by Principles Behind the Agile Manifesto. Once again, it’s easy to remove the software-centric emphasis.The key is to understand the philosophy underpinning the principles
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity – the art of maximizing the amount of work not done is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behaviour accordingly.
One key reason why agile thinking is taking the business world by storm is because it wins hearts and minds quickly. The core messages are simple, powerful and extremely appealing:
- Increase return on investment.
- Deliver reliable results.
- Expect uncertainty.
- Unleash creativity and innovation.
- Boost performance.
- Improve effectiveness and reliability.
Software development is sometimes perceived as an undisciplined way of working, on that regard I found very interesting what Chapter 7 from ‘Agile in a Flash‘ (Langr 2011) explains about redefining discipline on this context :
An agile workflow is very disciplined but with a different definition of discipline. (Langr and Ottinger 2011)
Work attentively Try to keep up but also keep track:note which aspects of your work system are hard, clunky, troublesome, or slow.
Work on one thing at a time: do not dilute your effort and your attention by tak- ing on multiple tasks at once. Take one tiny, verifiable step at a time.
Shorten feedback loops: how long until you detect defects or reap benefits? Ag- gressively simplify your process to shorten that time.
Continuously reflect and adapt: invest in the team’s ability to easily produce a quality product. Always build a better “next week.”
Know when to call it a day: a few more minutes of digging might crack a tough problem, but so could a night’s sleep. Learn when to stop.
Push back when it matters: nobody wants a contentious employee. So, choose your battles carefully, but always protect the product, team, and company by advising against changes that oppose the values stated in the manifesto.
When it comes to running programmes and projects it’s time to get down to specifics and chose an Agile framework to work within. From all of them the Brillant Agile Project Management (Cole 2015) suggest to stay focused on the those tree favourites frameworks:
Lean : this methodology relies on 3 very simple ideas in order to creating more value for customers with fewer resources: deliver value from your customer’s perspective, eliminate waste (things that don’t bring value to the end product, continuous improvement. It derived from the Toyota Production System, established around 70 years ago.
Scrum: a simple framework for effective team collaboration on complex software projects. The Framework is based off of The Scrum Guide which Scrum co-creators Ken Schwaber and Jeff Sutherland have written to explain Scrum clearly and succinctly.
The Scrum practice of using sprints is a classic example of how teams use iteration in real life to deliver working software early and frequently. The Scrum team has a Product Owner who works with the users and stakeholders to understand their needs. Everyone learns more with each new version of the working software, and the Product Owner uses that new knowledge to add or remove features from the backlog. (Stellman & Greene 2017).
Kanban: a popular framework that requires real-time communication of capacity and full transparency of work. Work items are represented visually on a kanban board, allowing team members to see the state of every piece of work at any time.
Scrumban: best of two worlds? As we know, Kanban is described as a visually driven framework that utilizes a board and cards for communication. Scrum is a strict method can only implement change after a sprint, while Kanban is more flexible and can make changes at any point in the development process. A hybrid of the two methods, Scrumban is an alternative for users who find aspects of both methodologies to be appropriate for their team. There is a great deal of consideration required for independent game developers as they need to reflect on their team dynamics and situation before determining which methodology is best suited for them.
Whoa, whoa, whoa, yeah… one envision!
“Being able to envision what a new product or the next product version should look like and do is essential for getting there. Traditionally, organisations tend to carry out extensive upfront market research, product planning, and business analysis activities resulting in a product concept or a market requirements specification. Some fall into the other extreme: They rush into development without having carefully thought about the product’s target market and its value proposition. Neither of these two approaches is desirable”. (Roman Pichler 2010)
I have to admit that it took me a while (and more than a couple of reviews) of Alcwyn Parker video from this week’s Development Practice module about Envisioning but eventually got the concept: the goal is to move quickly from the guessing stage once we know which are the customer needs and our potential solution. This information is crucial to move to the next level of product creation that implies more detailed development.
“Envisioning a product in Scrum should not be confused with heavier-weight, ceremonial, plan-intensive project chartering. With Scrum, we don’t believe that we can (or should try to) know all the details about a product before we start. We do, however, understand that product funding usually can’t move forward without first having a vision; enough details to understand the customers, features, and high-level solution; and an idea of how much the product might cost”. (Rubin 2013).
Estimation, story points and user stories
“Estimating work effort in agile projects is fundamentally different from traditional methods of estimation. The traditional approach is to estimate using a “bottom-up” technique: detail out all requirements and estimate each task to complete those requirements in hours/days, then use this data to develop the project schedule. Agile projects, by contrast, use a “top-down” approach, using gross-level estimation techniques on feature sets, then employing progressive elaboration and rolling-wave planning methods to drill down to the task level on a just-in-time basis, iteratively uncovering more and more detail each level down”. (Sliger 2012).
The estimation process consists of an evaluation of the effort necessary to carry out a given task, most often expressed in terms of duration (hours, days, weeks) and it should provide answers to the following three main questions:
- How many features will be completed?
- When will be done?
- How much will this cost?
However there are a few Agile techniques that can be applied to the task of estimation, while most traditional estimations make use of time, some agile estimations prefer to use story points.
- A story point is a subjective unit of estimation used by Agile teams to estimate user stories.
- A user story is a very short description of a specific thing that users need.
Story points let the team focus on the relative size of each story, each user story should be estimated such that it can be completed in one sprint. If the bigness is larger than what can be done in a single sprint then you need to break it up.
Epics are simply larger user stories, usually from situations where you will deal with a story that must span multiple sprints, a larger project, or a new feature.They are used to group user stories that when delivered result in the completion of a project or large feature.
How story points work
I researched more on this topics as they were still not very clear to me. I found this paragraph from ‘A Brian Friendly Guide to Agile Principles, Ideas and Real-World Practices‘ (Stellman and Green 2017) frankly more approachable:
“Story points are simple: the team just picks a number of points that represents the amount of work required for each story, and assigns that number to every story in the sprint backlog. Instead of trying to predict exactly how long it will take to build a feature, the team assigns a point value to each story based on its size relative to other features they’ve built before. At first, the estimates vary a lot from story to story. But after a while, the team gets used to the scale they’re using to estimate and it gets easier to figure out how big each story is.” (Stellman and Green 2017)
At first, the estimates vary a lot from story to story. But after a while, the team gets used to the scale they’re using to estimate and it gets easier to figure out how big each story is.
The last concept I would like to aboard is the Product Backlog. As the Agile Alliance states ” A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome. The product backlog is the single authoritative source for things that a team works on. That means that nothing gets done that isn’t on the product backlog.
Product backlog items take a variety of formats, with user stories being the most common. The team using the product backlog determines the format they chose to use and look to the backlog items as reminders of the aspects of a solution they may work on.”
As I understand the product backlog is more a wish list than a to-do list of all the work that needs to get done and it should be periodically refined by the product owner and scrum team to ensure 2–3 sprints worth of work is always defined and prioritized.
Widely used estimation techniques
Planning Poker: is an Agile estimating and planning technique were all the people who are supposed to do the estimations, sit in a round circle for the Planning Poker session. Each estimator is having a set of Planning Poker Cards of values: 0,1,2,3,5,8,13,20,40 and 100. These values represent story points or measure in which the team estimates. After the story is read out , the discussions among the estimators and with the product take place; all estimators are asked to select one card to estimate a user story. If all estimators give same value, then that becomes the final estimate.
The bucket system: much quicker than planning poker is the Bucket System. Different buckets are created with similar values to the previous method, such as: 0,1,2,3,4,5,8,13,20,30,50,100, 200. The stories need to be placed within these where the estimator finds them suitable. The group estimates the items by placing them in these buckets.
T-Shirt Sizes : this is a technique for estimating a huge backlog of relative large items. Just as in the case of T-shirts, we see sizes: XS (Extra Small), S (Small), M (Medium), L (Large), XL (Extra Large). A similar approach is followed here.Items are estimated in T-shirt sizes. A relative size (mostly Medium) is decided after mutual discussion and agreement of the team members or estimators. Then, the no’s are assigned to the items according to the relative size that is assigned to Medium size. The primary advantage to t-shirt sizes is the ease of getting started. T-shirt sizes can be a great way of becoming familiar to relative estimating. So, you can start with it if your team finds that easier.
Dot voting: each person gets a small number of stickers and can choose to vote for the individual items. More the dots, bigger is the size. This method is very simple and fast, it will work effectively to assess a small number of stories.
Applying to my practice on a real project
I have gone just half way learning how to use some of this tools: on the one hand, throughout the creation of this blog (as weeks went by it has actually turned into an iterative process) and on the other hand, thanks to the two large projects during this term.
With all the new knowledge gained I am convinced that it will be a good idea to use an agile approach to create my colleague’s engine tutorials which I have mentioned before and try to establish the MVP (minimum viable product) for his needs. I suggest to re visit my previous enter on this subject to refresh your memory, but briefly:
Bladecoder Engine is a free, robust, stable, portable, modern game engine conceived to develop narrative adventure games (from visual novels to point and click adventures). It handles third party solutions as Ink or Spine and is able to export builds to iOS, Android, PC, Mac & Linux on the fly.
Problem is that only his author and a bunch of his closer followers knows how to use it, leaving aside a large community of potential users.The lack of documentation is a critical issue!
Keeping this in mind, my envisioning process to approach this problem should include the following activities:
| Vision | Establish Bladecoder Engine as the best game adventure engine on the market |
|---|---|
| Target Customer | Individuals or enterprises who wants to use Bladecoder engine to make visual narrative adventures |
| Key benefits | The engine is free, modern and open source, it can export to most platforms on the market |
| Purpose of the project | Teach people to use the engine in a fast and engaging way |
| Roles and responsibilities | I will be in charge of determining and creating the main contents, Rafael Garcia will provide technical assistance and a special framework to create the interactive tutorials and Anne Muriel will help me with additional content and practical exercises. |
I should say that for the creation of the first of these tutorials – nearly three years ago- I did no make use of any tool but my own experience. Taking into consideration all what I have learned and applied so far, I wonder: which is the smarter (and shorter) way to help an user to teach how to create a functional and self contained game using Bladecoder engine and keep his interest on learning more about it?.
Now I’m aware that I have gone from one extreme to the other: my first solution consisted of a series of articles posted as additional documentation on GitHub. Those tutorials were relatively easy to produce (and not expensive at all) but quite tedious and boring to read, and certainly not the most efficient way to explain the functionalities of the software related. But at least I was able to deliver one new chapter each weekend!
My second approach, the video tutorial series, was way more complex to produce: in addition to the script I need to capture clips from the play tests, do the voiceover (with the collaboration of a professional narrator), editing the videos, synchronise the voiceover, add the music and the sound effects, render and export the files, etc). The result was a lot better and eye-catching but it took me from 3 to 4 weeks to finish just one episode. Considering the amount of content to cover I never had the time, money or even energy to green light the project.
After reflecting on this situation during the last two weeks with the developer of Bladecoder, we figured out another possible MVP solution for this product: interactive tutorials made with the engine itself. They will be easy to create than a ten minute video and way more engaging than a text file!
A short interview with Rafael García creator of Bladecoder open source engine ( Part 2)
PL: Which are your future plans for Bladecoder?
RG: I would like to create a version that includes not only the ink compiler but also jdks for Windows version at least for the users not to install anything to start off using the engine. It would also be important to improve and automatize the generation of packages for the different platforms. The documentation should be another crucial point to work on.
PL: Back when I was working on my own game using some early version of your engine I ‘suggested’ you to add a lot of new features. From a couple of dozens of commands or instructions the engine was able to manage it finished with more than 70. I’m really sorry for all the pain I caused, but at the end of the day do you think that all the extra work was worth it?
RG: Thanks to your needs I have added lots of features I would not have added to my games because I thought I did not need to. Amongst them the support for animated icons, voices, interface design from the editor, control support and some other things that I am leaving out. You have also helped me out a lot to detect errors. I am very grateful for your support to implement these features and for getting the Nintendo Switch dev kit!
PL: My pleasure! When developing the engine, how have you organized the different tasks to carry out? Have you used any Agile approach?
RF: These kinds of methods do not make much sense when being alone. I have used a Kanban board like this one though…
SMART Goals for this future project
I have gone just half way learning how to use some of the tools mentioned above: on the one hand, throughout the creation of this blog (that turned out to be a full iterative process) and on the other hand, thanks to the two ideation exercises during this term.
Fortunately, to start off working on my theory I have a strong starting point: having delivered the first of these tutorials, I already know how long it is going to take to complete the next ones. By using a different approach for the content creation from now on, I will be able to reduce the development times significantly. What is more: Larger Anne-Murielle, developer of some great titles made with this tool will be join me on this effort!
My Smart Goals to accomplish this huge task goes as follow:
| Specific | A new series of tutorials to teach users how to use my friend's engine. |
|---|---|
| Measurable | Each interactive tutorial will last 10-15 minutes. |
| Attainable | I can devote my own time and resources to carry out this task during the next 6 months. |
| Relevant | It is of crucial importance that people learn how to use the engine since it is not entirely intuitive. The great engine’s potential is wasted given that the users do not know how to make good use of it. |
| Timebound | Each tutorial will be developed in two weeks, being ten tutorials in total, meaning 100 working days. |
That being said, I have a few doubts to clear up: do I have to publish all the tutorials together in one shot once I am done with them, or little by little as they become available every two weeks?.
Right now it is difficult to answer this question. Even if this issue seems to be of little relevance because they are going to be offered for free, it comes to my mind to draw a parallel with the way in which Netflix is used to offering their productions to the public. Though a few of them are lately delivered weekly, most are fully released including all the season’s episodes ready for the viewers having a series binge. I think that many of those who are interested in learning how to use an engine would prefer to have all the information beforehand, in a single package rather than wait and practice until every new delivery.
This will allow to convey reliability, stability and confidence to the future users of the engine. My aim is to let them know that the software is solid and stable enough to be worth choosing it to develop a full adventure game, without any undeveloped or missing features.
I can be wrong, but in any case must provide enough information for the user to move on without the urgent need to have the next one right away after being done with each reading.
List of figures
Fig 1. ‘Poncho’ the cat fighting lousy Kanban implementations. Video by the author.
Fig 2. Estimating poker templates available for free at www.agileestimating.com.
Fig 3. Agile principles help you deliver your product(as shown on ‘A Brian-friendly guide to Agile principles, ideas and real world practices’ page 42, chapter 2. Image (c) O’Reilly Media.
Fig 4 and Fig 5. The Revenge of Johnny Bonasera. Photo Rafael García.
Fig 6. Original Kanban board used during the development of the engine. Image provided by Rafael García.
References
Stellman, A. and Green, J. 2017. ‘Head First Agile A Brian-friendly guide to Agile principles, Ideas and Real-World Practices’. Published by O’Reilly Media, Inc.
Cole, R. and Scotcher, E. 2015. ‘Brillant Agile Project Management‘. Published by Pearson Education Limited.
Moreira, M. 2013. ‘Your Roadmap to Successful Adoption of Agile‘. Published by Apress Books USA.
Langr, J. and Ottinger, T. 2011. ‘Agile in a Flash Speed-learning Agile Software Development‘. Pragmatic Programmers, LCC.
Scrum Org. [online] Available at: <https://www.scrum.org/> [Accessed 6 April 2021].
Garcia, R. Bladecoder engine. [online] Available at: <https://bladecoder.github.io/bladecoder-adventure-engine/> [Accessed 6 April 2021].
Rubin, K. 2012. ‘Essential Scrum: A practical Guide to the Most Popular Agile Process’. Published by Addison-Wesley Professional.
Parker, A. 2021 ‘Envisioning Product Planning‘. [online] Available at: < https://flex.falmouth.ac.uk/courses/911/pages/week-10-envisioning?module_item_id=49213> [Accessed 6 April 2021].
Pitcher, R. 2010, ‘Envisioning your product‘. [online] Available at: <https://www.romanpichler.com/blog/envisioning-your-product/> [Accessed 8 April 2021].
Sliger, M. 2012. ‘Agile estimation techniques. Paper presented at PMI® Global Congress 2012 North America, Vancouver, British Columbia, Canada. Newtown Square, PA’. Project Management Institute. [online] Available at: <https://www.pmi.org/learning/library/agile-project-estimation-techniques-6110> [Accessed 10 April 2021].
Agile Alliance [online] Available at: <https://www.agilealliance.org> [Accessed 8 April 2021].
Scrumexpert.com ‘Open Source Planning Poker Tools‘. [online] Available at: <https://www.scrumexpert.com/tools/open-source-planning-poker-tools/> [Accessed 8 April 2021].
Sinha, D. 2018. ‘Top 5 Scrum Estimation Techniques – Find Your Best Fit’. [online] Available at: <https://www.knowledgehut.com/blog/agile/top-5-scrum-estimation-techniques-find-your-best-fit> [Accessed 8 April 2021].
Narechania, N. 2019. ‘The Fundamentals of User Stories and Product Backlogs‘. [online] Available at: <https://www.knowledgehut.com/blog/agile/top-5-scrum-estimation-techniques-find-your-best-fit> [Accessed 8 April 2021].
Aurich, R. and Mohiudin, A. 2019. ‘An outlook at Agile methodologies for the independent games developer’. [online] Available at:<https://doi.org/10.1080/1206212X.2019.1621463>, International Journal of Computers and Applications [Accessed 5 April 2021].
