I am a consultant and coach and train in Agile software development. Wondering if there is any interest in classes?
1 Like
Definitely interested. My company uses Agile and I’d appreciate another perspective.
I’ve also taken some of the Lynda courses on Agile.
Extremely interested. I am going to work this summer for a company that is 100% Agile so YES definitely interested in classes.
I’ll go ahead and proclaim absolute confusion and gaping ignorance.
Can you elaborate on what is “Agile Software Training”?
1 Like
Don’t feel alone, I’m hoping to find out also.
Agile is a modern software development methodology which is used to rapidly develop software applications. It is based upon a number of concepts but the most important is that the customer is involved in the definition of the product at frequent intervals throughout the development process. These intervals are called sprints and usually result in the release or generation of a software application iteration. These are sometimes released to customers for their feedback and this feedback is incorporated into future sprints.
The concept is that the traditional waterfall development methodology which would define the overall product initially and then progress through several waterfall stages of design, detailed design, code, unit test and systems testing doesn’t always deliver exactly what the customer wants and usually underestimates the overall scope of the product resulting in over-budget and over time schedules.
There are a lot of companies working away from waterfall and towards Agile, but both offer their own benefits and drawbacks. A lot depends upon the team and the tools, too.
The fun thing about sprints is you get to see code and the basics of the application much sooner. We are building our mobile app using Agile methods. Our sprints run about 2-3 weeks and we release these interim releases to our Release Candidate customers.
I’m interested in hearing more about what others are doing and how effective the methodology is under different software development projects.
1 Like
Lots of interest. It would be awesome to see this likeeps the six Sigma offering.
Dan explained it very well. A few additional things:
Agile Manifesto: http://agilemanifesto.org
Principles behind the Agile Manifesto:
Principles behind the Agile Manifesto
One of the many good books: Scrum: The Art of Doing Twice the Work in Half
the Time by Jeff Sutherland, co-creator of Scrum.
- Many of the early ideas in Agile surfaces in the early 70s. It gained
recognition in the mid-90s with Extreme Programming (XP). - Astute people realized that you can’t design software like you do a
building or a bridge. There are too many variables and “You don’t know what
you don’t know.” You can’t discover the answers to many questions in
software until you actually start coding. - Customers of software often don’t know what they want or, if they do,
they are not very good at expressing it. But customers are VERY good at
telling you what they don’t like once they see it! - The "waterfall’ methodology has too many people involved in the process
between the customer and the developer. Each person adds their own bias,
perception and assumptions (often incorrect) about what the customer wants. - Each “hand-off” of information represents waste that can be eliminated
(One of the “Lean” principles). - Software is not “Done” until it is tested. Waiting until the coding is
“complete” before testing it represents a huge risk in the success of the
project. - The time it takes to fix a software “bug” increases almost exponentially
in relation to how long it has been since the initial code was written. The
cost to fix the bug rises with the time increase.
The problems with waterfall methodology in software development gained
visibility in 1995 with the often cited Standish Group “Chaos Report”. It
concluded that only 16.2% of software projects successfully delivered
expected functionality on time and on budget (
The Curious Case of the CHAOS Report 2009).
BTW, there are also articles debunking the Standish Chaos report:
Here is a good overview of the Agile methodology:
The Beginners Guide To An Agile SEO Approach | Emulent.
Agile represent a culture change in an organization and this is FAR more
difficult than implementing process changes. Any company that is just now
transitioning to Agile is WAY behind the curve and the organization’s
cultural issues that have delayed this transition also make the transition
significantly more difficult.
Waterfall = Command and control people
Agile = Empower people to self-organize and self-manage
In the example below from this page (
Agile for Dummies: How to Make Sense of it All),
the first example represents the “waterfall” approach and the second
example represents the Agile approach:
Agile for Dummies – A Very Simple Example
Let’s use a very simple example of a vehicle owner who takes his car in for
repair to a dealership. Most dealerships operate in this fashion:
-
Owner/Service Writer – The vehicle owner first meets a service writer
and speaks with them about desired repairs or problems with the vehicle.
The service writer creates a work order and the customer leaves the vehicle. -
Service Writer/Technician – The service writer will assign the
repairs to a technician who diagnoses the problem and reports to the
service writer before repairs are made. -
Service Writer/Owner – The service writer calls the owner and
informs him about needed repairs and the estimated cost of those repairs. -
Owner Questions/Service Writer – Say at this point the owner has a
question the service writer doesn’t know such as, “what was causing the
transmission failure?” -
Service Writer/Technician – The service writer must hang up with
the owner and speak to the technician to answer any questions the owner may
have posed. -
Service Writer/Owner – The owner is called again by the service
writer to answer posed questions. At this point the owner is angry and
wants to know why the repairs are so much and what exactly is being done
because the service writer (who is not a technician) is having a hard time
explaining the repairs. Now the owner wants to speak to the service manager. -
Service Writer/Service Manager – Prior to the service manager
calling the owner, the service writer must inform the service manager of
all the details regarding this owner’s repairs. -
Service Manager/Technician – Prior to calling the owner, the
service manager also speaks with the technician before calling the owner to
gain full knowledge of the needed repairs.
Service Manager/Owner – Once the service manager has all the
information, the owner is called and given a more detailedexplanation on
what repairs are being done and the reason for the cost of those repairs.
10. Service Manager/Service Writer – The service manager tells the
service writer to complete the required repairs per the owner.
11. Service Writer/Technician – The service writer tell the technician
to complete the repairs.
12. Owner/Cashier – The owner picks up the vehicle and pays the
cashier for repairs made.
Whew! What a process, but since we are discussing agile for dummies, how
could this example of a project with a goal be shortened or completed more
efficiently?
-
Owner/Service Writer – The owner brings in the vehicle for repairs
and the service writer asks if the owner can attend a pre-repair test drive
with the technician who will be completing the repairs. -
Owner/Technician – Through the pre-test drive, the technician
explains their thoughts on what is needed and immediately can answer any
questions the owner may have. The owner gives a go ahead for all the
repairs. -
Technician/Service Writer – The technician informs the service
writer of what repairs will need to go on the repair order and then makes
the repairs. -
Owner/Cashier – The happy owner picks up his vehicle and pays the
cashier.
By using Agile to complete this project of repairing an owner’s vehicle, we
have cut 12 steps down to 4. The owner is happy, the repair facility made
money, the technician will get paid, and the service manager has empowered
his team to get the job done
http://www.brighthubpm.com/monitoring-projects/62415-seven-factors-of-effective-team-performance/
.
1 Like
It would be interesting to have a discussion about how these compare. I
wanted to take the Six Sigma offering but it was well under way when I
first learned of this Makerspace.
Thank you and @coloneldan for the excellent writeups. I was confused about exactly what was on the table and that clears it up nicely!
Interested.
To best prepare people for the class and discussion, I will provide links to information. Here is a free course giving this guy’s opinion on Agile vs Waterfall and how to make them work together:
https://www.udemy.com/learn-the-truth-about-agile-versus-waterfall
I personally take offense to him reframing “Waterfall” as “Plan driven” yet not doing a similar reframing for Agile. This seems to imply that Agile is “Working with no plan”, which obviously is not true. To be fair, he should have reframed Agile as “Business value driven”. But it is still a good overview of the two approaches.
Hi, I would be interested.
Thanks
Here is a free online course in Scrum. You can even get certified by them: https://www.udemy.com/scrum-methodology
Their approach is pretty “prescriptive”, which Agile is not. Scrum can be implemented in a more “lightweight” manner than they describe. They do admit that some of what they present is “optional”. Just keep that in mind. The course is easily worth the time invested.