UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> State Of Agile    
 
   
nvogel
post May 10 2019, 01:49 AM
Post#1



Posts: 1,039
Joined: 26-January 14
From: London, UK


I'm sceptical about industry surveys generally but the State of Agile survey usually gets some attention and the latest one is just out. Items I found interesting: reducing cost is increasingly important as one of the reasons to adopt agile; Scrum is still the most important agile technique and SAFe the most common form of scaled agile; 68% of respondents used agile with teams that were distributed geographically.
Go to the top of the page
 
PhilS
post May 10 2019, 02:48 AM
Post#2



Posts: 651
Joined: 26-May 15
From: The middle of Germany


Thank you for the link; very interesting.
In your comment you refer to Scrum as an technique, which is misleading. Scrum is rather a methodology comprised of a number of techniques (e.g. daily standups, iteration planning/review and many more.)


I wonder how many developers in the Access community think about, let alone actually use, agile engineering practices like Units Tests, Continuous Integration/Delivery, and Pair Programming. - I guess, most of the agile practices are used only very, very rarely in an Access context.

Just two weeks ago, I held a talk on Software and Code Quality at the Access DevCon conference in Vienna. While the focus of my presentation was on coding standards and Clean Code, I touched topics like Units Tests, Continuous Integration/Delivery.
From the feedback of the audiences I gather that Access developers hardly even try to use something like Unit Tests, despite several frameworks and tools for Unit Tests being available.

Sure, it is not easy to implement many of these practices for Access/VBA. But still I wonder, are we giving up to easily? Shouldn't we emphasize the quality and maintainability of our applications more compared to just the raw speed of Access RAD development?

I fully acknowledge that the majority of the audience in this forum are beginners who are happy to get their first application(s) working at all. - Still, the professionals and experts here touch these topics rarely as well.

--------------------
Go to the top of the page
 
nvogel
post May 10 2019, 04:01 AM
Post#3



Posts: 1,039
Joined: 26-January 14
From: London, UK


The topic has been discussed in these forums once or twice and it seems there are people here who use or would like to use an agile approach.
http://www.UtterAccess.com/forum/index.php?showtopic=2035968

Access tends to get used on projects with quite small teams and is somewhat out of the mainstream so that may account for being behind the times on techniques like testing, CI and DevOps (if that is the case). I would anyway encourage any developer not to specialise but to work with as many different teams, tools and techniques as they can.

The authors of Scrum prefer to call it a framework rather than a methodology and I know people who get very uncomfortable when they hear the M-word. Perhaps framework or "portfolio of techniques" is a safer way to describe it. Personally I don’t really mind.


Go to the top of the page
 
Minty
post May 10 2019, 06:04 AM
Post#4



Posts: 312
Joined: 5-July 16
From: UK - Wiltshire


The plethora of terminology used to describe these "working practices" does make me smile.

It's almost as if using plain English to describe something is frowned upon in case the non-techies get wind of what you are doing.
As an old fart seasoned professional currently looking at job specs, I frequently end up googling the latest buzz phrase only to find it means the same as something else, but its "newer".
Go to the top of the page
 
GroverParkGeorge
post May 10 2019, 07:35 AM
Post#5


UA Admin
Posts: 36,177
Joined: 20-June 02
From: Newcastle, WA


Budget factors, real or imagined probably play a significant role here.

I've worked on Access projects of various sizes over the years. Larger projects are run by people who understand and budget for things like testing. Smaller projects are far more sensitive to budget restraints. When a project is estimated at 40-50 hours, and the allocated budget will barely cover 25 hours, the things that get jettisoned first are often documentation and testing. Whether that's a good thing or not is beside the point, unfortunately. A lot of database projects simply would not get done, and Excel would continue to be the data storage tool of choice, if every project had to have a full-blown project plan in place before it could be undertaken.


--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
DanielPineault
post May 10 2019, 07:50 AM
Post#6


UtterAccess VIP
Posts: 7,002
Joined: 30-June 11



Well said George.

I'll add a 'however' comment. While George hit the nail square on, the fact of the matter is that without taking the time to develop proper specs (what the ins and expects out will be) many projects quickly go awry. A proper plan/specs saves money, no way around this fact! It's just too bad people figure the opposite.

I always love clients who say make a 'client form' or it's easy 'he knows what we want', but when you actually take the time to discuss the matter and look at what they are currently doing (to define their needs and project specs) you find out there's a lot more to it. I also find in many instances management are completely detached from the actual data side of the business and often can define projects that will not help their employees. This is why it is critical to always speak directly with the employees that will be using the system, get their needs and feedback. It amazing what a simple conversation can achieve (beyond making them feel like they have some ownership in the overall project). Did I mention the importance of specs! Defining a map of what is wanted is crucial to the proper timely completion of a project.

--------------------
Daniel Pineault (2010-2019 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
GroverParkGeorge
post May 10 2019, 08:07 AM
Post#7


UA Admin
Posts: 36,177
Joined: 20-June 02
From: Newcastle, WA


Daniel reminds me of one of my most effective "project plans".

Managers of two teams in the organization called on my group to create a tracking tool for work they had to manage jointly. I forget the exact flow, but basically one team processed part of the paperwork and the other handled the rest.

After a twenty or thirty minute meeting, in which they described the tracking tool needed, I asked what would happen if Team "A" simply notified Team "B" their step(s) had been completed. A long stare passed between them. "Yes", they agreed, communication between their teams would solve the problem without a new database.

I walked away with nothing else to work on, and -- so far as I know -- the two teams lived happily ever after.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 
penfold098
post May 10 2019, 08:19 AM
Post#8



Posts: 150
Joined: 5-March 14




To Daniel's points: A fellow coder often tells me: "The manager/user rarely knows what they really want." [ha ha]

My challenge usually involves management who have little or no experience with the coding process, let alone CI. I give the users a beta iteration to test the features completed to-date, and the management assumes it is a completed version. Then they wonder why yet-to-be-coded features do not work. Attempts to explain the process prove fruitless.

nvogel and PhilS: Thank you for the links.

Go to the top of the page
 
nvogel
post May 10 2019, 02:11 PM
Post#9



Posts: 1,039
Joined: 26-January 14
From: London, UK


Thanks for the comments everyone. Agile and Scrum do strongly emphasise the importance of collaborating with and talking directly to real users and subject-matter experts. It's often said that a story on a product backlog should be considered a "promise of a conversation". I don't suppose anyone would recommend Scrum for a 40 hour piece of work.

Go to the top of the page
 
jleach
post May 10 2019, 04:24 PM
Post#10


UtterAccess Administrator
Posts: 10,275
Joined: 7-December 09
From: St. Augustine, FL


I think the greatest thing to come of agile practices is communication. I don't think there's nearly enough people (stakeholders or developers/PMs) that understand the importance of good communication to a successful project, and one of the core goals of agile practice is to promote that. That's certainly a good thing.

Regarding scrum, we're not strict practitioners, but we do core feature development around the idea. User stories are great for capturing requirements, but at some point in the process tend to be converted to a spec rather than followed through the whole gamut as the story. Maintenance work tends to follow more of a kanban style approach: prioritize and pick from the top.

Two of the things that I don't care for with scrum is a general lack of architecture planning (which usually takes place before we start a project, but heavily evolving projects get their share also, and it's hard to fit that into scrum workflows), and the sprint closures. While the general idea is that we sprint and pick what we want to work on and focus on quality etc etc etc, a common issue here is end-of-sprint crunch, or stretching if a part is done early.

All in all, I like many of the agile practices. XP's YAGNI is one of my favorite mantras. But, like most everything else, I tend to take the heart of things and implement it slightly in my own way rather than they way "everyone else" seems to (e.g., we borrow from Domain Driven Design practices quite heavily, but not to the purest sense of the form).

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
jleach
post May 10 2019, 04:29 PM
Post#11


UtterAccess Administrator
Posts: 10,275
Joined: 7-December 09
From: St. Augustine, FL


In addition, I think the ability to adopt standard scrum practices are very much dependent on the maturity of the development shop. If you're a one-man team or work with a small group of contractors, it's much more difficult than if you have a team of full-time people.

As a side note, I don't think testing: be it unit, integration, system, UAT etc, CI/CD etc - don't think it has much to do with agile in general - in fact, the more "agile" teams I've seen seem to have a tendency to shy away from heavy testing. TDD is a pretty good way to write domain features, I think, but it's a whole different conversation (I can't believe how many people I run into that know how to "unit test" and write a bunch of tests to make sure MVC is returning JSON but fail to check any conditions of a tuple overlap check method...)

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
jleach
post May 10 2019, 04:33 PM
Post#12


UtterAccess Administrator
Posts: 10,275
Joined: 7-December 09
From: St. Augustine, FL


>> budget for things like testing <<

One way or another it gets tested (or ends up costing more to fix later): You test it manually via debugging, or you unit test. The different is that unit tests are done in a way that when you test it, you retain the test so you can run it again later.

It's an investment to set up for sure, but once the testing framework and experience in doing so is there cost any more. In fact saves money in the long run (five years ago I struck out on my own as a single man shop not even knowing what unit testing is, and today we run CI/CD on numerous projects: it's a long climb, for sure, and untold hours invested into internal processes to make it happen, but that's how we grow and do better...)

Thing is, I don't bother unit testing Access work because most people (devs working in the space) have no idea what it is or how to really do it, let alone proficient.

My 2cents. Cheers,

--------------------
Jack D. Leach
Founder & CEO
Dymeng Services Inc.
Business Software Solutions
Go to the top of the page
 
DanielPineault
post May 10 2019, 06:37 PM
Post#13


UtterAccess VIP
Posts: 7,002
Joined: 30-June 11



QUOTE
One way or another it gets tested (or ends up costing more to fix later)

Ain't that the truth!

--------------------
Daniel Pineault (2010-2019 Microsoft MVP, UA VIP, EE Distinguished Expert 2018)
Professional Help: https://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: https://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
GroverParkGeorge
post May 11 2019, 07:27 AM
Post#14


UA Admin
Posts: 36,177
Joined: 20-June 02
From: Newcastle, WA


Good point. I should have phrased that "formal" testing, or "pre-deployment" testing, or something along those lines.

--------------------
My Real Name Is George. Grover Park Consulting is where I did business for 20 years.
How to Ask a Good Question
Beginning SQL Server
Go to the top of the page
 


Custom Search


RSSSearch   Top   Lo-Fi    9th December 2019 - 06:08 PM