How do I know if I am using Scrum methodologies?

Question

When I first started at my current job, my purpose was to rewrite a massive excel-VBA workbook-application to C# Winforms because it was thought that the new C# app will fix all existing problems and have all the new features for a perfect world.

If it were a direct port, in theory it would be easy as i just need to go through all the formulas, conditional formatting, validations, VBA etc. to understand it. However, that was not the case. Many of the new features are tightly dependant on business logic which I am unfamiliar with.

As a solo programmer, the first year was spent solely on deciphering the excel workbook and writing the C# app. In theory, I had the business people to "help" me specify requirements, how GUI looks and work, and testing of the app etc; but in practice it is like a contant tsunami of feature creep.

At the beginning of the second year I managed to convince the management that this is not going anywhere. I made them start from scratch with the excel-VBA.

I have this "issue log" saved on the network, each time they found something they didn't like about the excel-VBA app, they will write it in there. I check the log daily and consolidate issues (in my mind) mainly into 2 groups: (1) requires massive change. (2) can be fixed in current version.

For massive change issues, I make a copy of the latest excel-VBA and give it a new version number, then work on it whenever I can. For current version fixes, I make the changes in a few days to a week, and then immediately release it. I also ensure I update the same change in any in-progress massive change future versions.

This has gone on for about 4 months and I feel it works great. I made many releases and solved many real issues, also understood the business logic more and more. However, my boss (non-IT trained) thinks what I am doing are just adhoc changes and that i am not looking at the "bigger picture".

I am struggling to convince my boss that this works. So I hope to formalise my approach and maybe borrow a buzzword to confuse him. Incidentally, I read about Agile and SCRUM, about backlog and sprints. But it's all very vague to me still.

QUESTION (finally): I want to tell him that this is SCRUM! But I want to hold my breath first and ask whether my current approach is considered SCRUM or SCRUM-like? How can I make it more SCRUM-like? Note that I have only myself, there's no project leader or teams.

Answer 1

First, I'd recommend this Programmers SE post because it gets to good points pretty quickly: What is agile methodology?

The core to working within an Agile methodology is iterative development, so as to create value, adapt to changing customer needs, and always have a working app in front of you (as Andrew answered).

For some good points between Agile and a more Waterfall approach, which sounds like has been in your history, see: Don’t Go Chasing Waterfalls (Mini-waterfall vs Agile), the upshot of that post being

Stop thinking in terms of:

1. Get the requirements
2. Design the solution
3. Develop the solution
4. Test

Start thinking in terms of:

1. Figure out the first thing the user wants
2. Build a small piece, making sure it is right
3. Check with the user to see how to make it better
4. Continue until user is happy

If you were to say you're operating in an Agile way, or with Agile principles in mind, you wouldn't be mistaken; my question to you would be why are you trying to convince your boss of this? If it's because you have to explain yourself because your methodology is being negatively received by your customers/within the company, that's one thing -- and I don't think that you explaining Agile is going to change the fact that people internally are unhappy (if they are).

However, if it's to inform him or her of your development practices so that you can (and he or she can) manage expectations of the stakeholder groups, then great! In that case, you do have some more of the framework you can put in place, even as a lone developer, to keep yourself sane and keep shipping your app.

Consider the "Scrum Framework in 30 Seconds":

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work - usually two to four weeks - but meets each day to assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

Here's how that might map to your situation:

• You maintain your backlog -- your list of things you/the stakeholders want to do -- including a rough guideline of prioritization (e.g. show-stoppers, nice-to-haves, things promised by a certain date)
• Determine for yourself how often you want to release (every week? every 2 weeks? etc), and stick to that schedule
• At the beginning of every sprint cycle (every week, every 2 weeks, or whatever you decide), look at the backlog and determine how many of those things you can get done, putting them into thematic groupings if possible. Plan the next two sprints ahead if you can (put two sprint's worth of stuff into a "to do bucket")
• Tell your boss "this is what I'm committing to by date X, this is what I'm committing to by date Y" -- shoot low until you get a handle on what you can commit to
• Tell everyone else that nothing gets added to your to-do list for the sprint (unless it is a wild show stopper bug) but will be considered for evaluation of the next sprint.
• At the end of the sprint, note the things that were done, think about what you could do better, release the app, take a breath, and start again.

It doesn't sound all that far off from what you are doing -- or are prepared to do -- now, but does provide a little structure around your work that should be beneficial.

Answer 2

I am writing this in the hopes that someone more wise and experienced with real world Scrum can tell me all of my mistakes.

I see Scrum as a way to provide and create customer value. Scrum sprints and story boards are all about customer value. And Agile is about being able to adapt and provide fast customer value. What value would an entire rewrite of an existing application provide the customer with? That is the first question. The second is that saying you will rewrite an entire application doesn't seem very Agile to me.

In my mind the Agile way of "rewriting" this application would be to evaluate each of the new features that you are adding and see if they can be written in small modules using C# and the Microoft Office integration points into Excel. This way as time goes on most of the code will be written in a modern, management language and runtime.

The biggest thing with Agile and even the SCRUM methodology is to always have a working application. You add feature complete functionality at each iteration. By this very nature a complete "rewrite" is not possible. However, after a long time of adding new working features, potentially using a different integration mechanism such as C#, you'll have for all intents and purposes a new application.

Answer 3

When I got you right, this is mainly about you and your boss. What you are doing is not scrum, I guess (do you have daily scrum meetings? I don't think so.) For me it seems you are doing just classical incremental development in small steps, supported by an issue/requirement list and some lightweight configuration management. Some people call this "agile" nowadays, but for me that seems just to be a fancy word for an old wisdom.

However, my boss (non-IT trained) thinks what I am doing are just adhoc changes and that i am not looking at the "bigger picture".

[...] maybe borrow a buzzword to confuse him

I don't think this is a good strategy. If your boss does not see the value in your work, you should not confuse him with buzzwords. Instead you should make the value more transparent.

For example: do you keep a changelog? I mean, a changelog for the end-user, not referring to any internal code changes, but one where every user (and your boss) can see which new features / feature changes you have implemented in each version. This may a thing to start with.

What I don't understand is what your boss thinks what the bigger picture should look like, and why your approach does not go in that direction. From what you are telling, you are not just making ad-hoc changes, you are also planning and implementing bigger changes, and all changes are motivated by user requirements. So you obviously following a "bigger picture".

Or is your boss thinking the Excel-VBA solution should be replaced by a .NET application on the long-term? If that's the case, I would recommend to choose a path which can be followed incrementally. A C# rewrite may not be the best thing to reach that goal. A better approach may be to port parts of your Excel-VBA to VB.NET, step-by-step. I have done something similar in the past utilizing Excel-DNA. Using VB.NET when you have a lot of existing VBA code makes the porting a hell lot easier.

Concerning rewrites, I recommend this great article from Joel Spolsky.