Random Ramblings on LabVIEW Design

Community Browser
Labels
cancel
Showing results for 
Search instead for 
Did you mean: 

Agile - Tail wagging the Dog(ma)

Active Participant

It's been a whole month since my last post, currently I'm filling my time doing

Single-shot oscilloscopes

Ferry alarm systems

Tow-tank instrumentation

Presentation for Mil/Aero Forum UK

2 NIWeek presentations

NIWeek.png

Lots of moving databases about and back-up work.

Lots of open document stuff

I am becoming very frazzled!

SSDC has it's first certified scrum-master (stand up Jon Conway), so I thought it might be a good idea get our teeth into Agile it and give it a shake. I'm not going to describe any of it, go get the books or check out wikipedia.

Here also is some more material that's well work a look.

The source material from this comes from an ACM presentation by Bertrand Meyer based on his book (Agile!: The Good, the Hype and the Ugly) <--video

And this presentation on youtube A Retake on the Agile Manifesto

In typical style I am not completely sold, some of the language almost completely puts me off. It feels monetised and corporate. I can't stand company mission statements and it feels a bit like that. It's as if by talking the talk we don't have to knuckle down and do the hard work.

By the way if you need a mission statement try this---->Mission Statement Generator

I've said before that I think LabVIEW is the original Agile language, I also think that our way of working is a reasonable compromise. It's not dogmatically Agile, it's not completely plan driven. Consider the following image based on the rather excellent (and short) book Balancing Agility and Discipline.

BackProcess-radar-chart.png

Taken from http://algoviz.org/OpenDSA/dev/OpenDSA/Books/Everything/html/IntroProcess.html

From this we can see that where the considerations are nearer the centre it favours Agile methods, whereas when we start moving out a more plan driven approach is needed.

Note: on Personnel for level 1 think CLAD/CLD for Level 2 think CLA, for Level 3 think CLA with a lot of project experience, the Boehm/Turner book classifies Level 3 as a very rare resource, it also splits 1a and 1b and -1 as levels.

I would add that as you travel through a project there are aspects that would benefit from being more plan-driven and other times where an Agile approach is definitely the way to go. For most of our projects we go in hard with prototyping, design reviews and iterate until we're happy we have collected a sufficient amount of requirements (the requirements shift is high at this point). Then the customer interaction naturally reduces as we knuckle down and do the hard architectural work. At this point in the project the requirements shift will be low. The next stage is commonly the Beta stage and we tend to try and hit this stage as early as possible, this is because the requirements shift begins to increase as the users actually start using the system. The effort you have put in prior to this creating a decent flexible, configurable back-end will now pay off coping with this ramp-up in requirements feedback. This is pretty predictable for a majority of our projects.

I've left quite a lot unsaid as it's a large topic and I know that Agile has vastly improved project delivery in many industries, but that's not comparing like for like. I would bet that very few LabVIEW projects are built using large teams where a customer does not see anything working for years. This is the environment that Agile has thrived in.

In short I like the adjective "agile" when used to describe a nimble way to run projects. I dislike the noun "Agile" where it is a commercial commodity to be sold as a self-help silver-bullet.

Lots of Love

Steve

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Comments
Active Participant

Steve,

As usual, you hit the mark.

I have been reading The Agile Samurai by Jonathan Rasmusson and one of the things he mentions is that names are all good, but if something in the "Agile way" doesn't work for your team, then drop it. I don't find him as dogmatic as other authors and I loved the first section of the book where he focuses on the inception deck. Whether you are doing an Agile project or you will proceed to gather all your requirements before starting to code, this single tool will help the team (including the customer) understand: Why, When and how.

So if you have time in between all the hard work you are doing, I recommend you give it a read, at least to that first section.

Good luck with your projects and see you at NI Week.

Fab

Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion
Active Participant

I'm a sucker for any book with Pragmatic in the title. The original title for our book was "LabVIEW Software Design a Pragmatic Approach". The publisher nixed it! Another in my list of grievances..

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Member

You're gonna love this, Steve: The Pragmatic Bookshelf (https://pragprog.com)



Joerg Hampel, CLA | hampel-soft.com
Active Participant

I'm trying to recall the publishers exact words.. it was along the lines of "what's pragmatic got to do with software?"

sigh.

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Active Participant

Maybe there's an opportunity here for someone with time and interest:

prag_no_luck.JPG

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Active Participant

Look at the ROI, before you commit time is my advice.

I strongly believe that the concept of a computer book is nearly dead (as much as I love books)

We invested at least £100k in time, probably only got a fraction of that back in sales.

You get intangibles like free kudos, marketing etc.

You also get intangibles like pride and fulfilled ambitions. (I still get a kick out of the fact that I helped write a book!)

I'm wondering if a collaborative effort would be more manageable idea. (on the assumption that it is not a money making venture!)

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Active Participant

I'm wondering if a collaborative effort would be more manageable idea. (on the assumption that it is not a money making venture!)


                   

I think it would be.  Several years ago there was a bit of noise about collaborating on writing a new Labview book.  Mostly I think it just needs a champion to take ownership.

Active Participant

Daklu wrote:

I think it would be.  Several years ago there was a bit of noise about collaborating on writing a new Labview book.  Mostly I think it just needs a champion to take ownership.


                   

I'm too old to be herding those cats. But if I were.....the most interesting thing I would like to see is how different people attack projects from the ground up. It would then be nice to try and split out best-practices, types of developer (my current enthusiasm is more people-oriented).

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Active Participant

I agree that the concept of hard books are nearly dead. I couldn't justify committing any time to writing content for print. But getting a large pool of developers together to combine contributions increases the total effort considerably - that would be a management nightmare. Best of luck to anyone who is interested in such an idea.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Proven Zealot

FabiolaDelaCueva wrote:


                       

if something in the "Agile way" doesn't work for your team, then drop it.


                   

I wish Agile authors were more dogmatic and saying, "No. You must do it this way UNTIL you CAN do it this way and only THEN can you drop the stuff that doesn't work well for you, knowing what it is you are dropping." The problem is that I have seen too many groups that claim to be Agile and are not because they drop key practices and don't put anything in their place. There's still work to be done. Agile should mean that you CAN change direction, not that you get blown about by the wind!

Like Steve, I'm very skeptical of these systems, but of all of them, Agile has the most research data and the right "feel" to it for me. I have worked on a CMM Level 4 team... that was awful. I've worked under a PSP system. That was awful. I've never worked on team that I would call Agile. I think I would like to do so.

Active Participant

I don't think CMM is for me, and I agree, I think there is something to Agile.

I worked in Aerospace years back, and they started down the route of statistical process control. The first action was to sack everyone in QA. It didn't end well!

Most of the key practices that get dropped first are difficult or expensive. I.e. the most essential.

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Active Participant

AristosQueue wrote:


                       

FabiolaDelaCueva wrote:


                       

if something in the "Agile way" doesn't work for your team, then drop it.


                   

I wish Agile authors were more dogmatic and saying, "No. You must do it this way UNTIL you CAN do it this way and only THEN can you drop the stuff that doesn't work well for you, knowing what it is you are dropping." The problem is that I have seen too many groups that claim to be Agile and are not because they drop key practices and don't put anything in their place. There's still work to be done. Agile should mean that you CAN change direction, not that you get blown about by the wind!


                   

The author was referring for example to the daily stand up. My team is not co-located, we live and work in different time zones, we cannot have the entire team meet everyday. We have managed to follow other practices and we compensate in other ways. And this is why I have never claimed we are doing Agile, but we do follow a lot of the Agile practices by coincidence really   The author did say to try things enough before dropping them.

Certified LabVIEW Architect * Certified Professional Instructor * LabVIEW Champion
Knight of NI Knight of NI
Knight of NI

Thoric wrote:


                       

Maybe there's an opportunity here for someone with time and interest:

prag_no_luck.JPG


                   

I'm just going to leave this stink bomb here:

Since it's an Agile book, maybe it could be written in an Agile manner?

OK, I'm gonna slowly back away now.


___________________
Try to take over the world!
Active Participant

I like it!

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Knight of NI Knight of NI
Knight of NI

swatts wrote:


                       

I like it!


                   

Yeah, Steve, but you probably also like Colin Furze, so I don't know if your preferences are an indication of good taste.


___________________
Try to take over the world!
Member

Huh? Colin Furze does awesome videos.

Active Participant

Michael Aivaliotis wrote:

Huh? Colin Furze does awesome videos.


                   

His firework rocekt launchers is most-excellent!





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

It's the only way I remove my clothes now!

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Active Participant

swatts wrote:


                       

It's the only way I remove my clothes now!


                  

Well, your business socks at least...





Copyright © 2004-2017 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

Full on velcro quick-release undercrackers is the future

 photo 4be9e774-656d-44c1-9a8d-1db1a15cdd42_zps6445ae67.png
Member

Oh! Agile homemadeHoverbike.

Certified LabVIEW Architect
Certified TestStand Architect