June 11, 2019 at 12:00 am
Comments posted to this topic are about the item Slower is Faster
MVDBA
June 11, 2019 at 8:35 am
I think it is good to call out the human side. An awful lot has been written about Agile and DevOps, not all of it what was intended by the original signatories to the agile manifesto. I always refer back to https://ronjeffries.com/ and https://www.jamesshore.com/
There are many things I like about working in an Agile environment is that, when done correctly, the team can perform at a consistent pace indefinitely. Sickness, absence, vacations have minimal impact on the pace of the team because the teams are better balanced in terms of their capabilities and what capabilities they are allowed to develop and use.
June 11, 2019 at 11:29 am
I think agile is a good practice overall, but sometimes not enough up-front planning is done on the project as a whole. People just pick the first logical thing they think should be in the backlog and start developing, only to have to rework later when unforeseen issues arise, all of which could have been avoided with good planning.
Take the time to plan the entire project out at first and create a complete and full backlog of activities to choose in each sprint. It might seem like waterfall dev, but it will save you mid to long term.
June 11, 2019 at 12:25 pm
I come from a manufacturing operations background. DevOps applies many concepts of the Toyota Production System (aka 'just in time') that have been honed by that company since the middle of the 20th century. The penny game is a classic example, demonstrating jidoka, as referenced here on wikipedia:
https://en.wikipedia.org/wiki/Toyota_Production_System
'The right process will build the right results --> 4. Build a culture of stopping to fix problems, to get quality right from the start. (Jidoka).
Before moving to data work I spent over 6 years as a manufacturing planner at one of Toyota's North American Manufacturing plants. I realize quality was not the point of this article, but in my experience, quality improves and wasted time is reduced when this approach is used (in addition to an overall increase in delivery speed).
This process works. I am glad to see the concepts moving into the data and software space.
June 11, 2019 at 1:04 pm
Great article! As one of the "support people have to pick up bugs in live code," we tend to be quick to blame the developers without considering their world. Most times, they are not allowed to see the big picture. As someone else mentioned, developers pick what they feel is most important and lose focus on other items. Suddenly, there is a mad dash to get the product finished and into production...bugs and all. I believe the lack of access to both Dev and Ops into a new product's BRD creation process is the fear of hearing "It can't be done." This is an unfounded fear as most people I've worked with are willing to provide valuable input and think outside the box (I know, I'm lucky!).
June 12, 2019 at 12:39 am
In other words, good quality costs less. Here it is, rediscovered.
Before working in IT for thirty years, I was a manufacturing quality control engineer (semiconductors). We spent many hours listening to lectures by Dr. W. Edwards Deming, after whom the Deming Prize is named. This prize is awarded by JUSE (Japanese Union of Scientists and Engineers).
Dr. Deming was an industrial statistician, and was one of those who were involved in the early stages of the mid-twentieth-century quality revolution in Japan. Some of you will be too young to remember this, but Japan, formerly a supplier of cheap, low-quality consumer goods, took over much of American market share (automobiles, cameras, televisions) by delivering superior quality at lower cost.
Consider the supreme cost disadvantage of having to ship an automobile across the Pacific Ocean. Yet, their quality was superior, and their cost lower.
Why is good quality less expensive?
LESS REWORK.
June 12, 2019 at 8:23 am
Herb (and anyone interested) - I highly recommend reading a book called "the phoenix project"
it details the story of and IT engineer in an engineering company, trying to get things better
https://www.amazon.co.uk/Phoenix-Project-Devops-Helping-Business/dp/1942788290
(it's not my book, so i'm not advertising 🙂 )
I'm pretty sure anyone who has read it will find it both funny and remind you of the things we need to fix in the IT environment.
MVDBA
June 12, 2019 at 11:19 am
Victor,
I don't think you fully understand how Agile works. Your description of planning the entire project up front is also known as scrummerfall. It misses every benefit of Agile.
Beyond that, simply picking the first logical thing to develop means the product owner is not doing their job. They should be prioritizing the backlog based on the highest value returned.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
June 12, 2019 at 11:58 am
Been on agile teams for almost 2 decades, and know almost every detail about Agile. My point is that Agile is not the perfect / end-all system of development if the team, including Product, has not sufficiently planned up front well enough to have a good backlog of logic steps that will lead to a successful software product once deployed. I just believe that teams do not do enough planning anymore... which, as Herb says, leads to a lot of rework.
June 12, 2019 at 12:10 pm
I can't disagree that some forward thought is an absolute necessity. Part of the value I see in Agile is not overplanning the future, just like not developing for a future that may or may not occur. It is also my personal opinion that a team without a fairly firm plan for the 2 sprints following the current one is simply inviting confusion...and rework for a different reason.
We still have projects that are completely waterfall in nature, starting with a fixed project end date. They are fewer and fewer. What we also find with Agile and not planning far into the future is that we are able to adapt quickly and efficiently to unanticipated changes be they regulatory, change in business direction...
I would also argue that research tasks performed in sprints are valid work product. Some people get the idea that only code deployed to production is valid work product. I never saw that in the Agile Manifesto.
Agile, in whatever the chosen implementation form, is no more a panacea than waterfall or any other 'methodology'. What it helps us do more efficiently is control WIP, a central tenet in Lean Sigma.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
June 12, 2019 at 12:31 pm
while it's slightly off topic,
I worked with a team that mixed the V model (kinda like waterfall) and agile.. it had an unfortunate nickname of "vagile"
but I do agree with Bryant and Victor on various points
My take is that I would like an overall roadmap (a bit waterfall but we get a direction), then we plan at least 2 sprints ahead.
At the minute, we are planning an hour ahead and it is hurting us. this is where a scrum master can really make a difference. Unfortunately most scrum masters seem to take the side of the BA/PM.
Get me a good Scrum master and he'll never want for free cake at work 🙂
MVDBA
June 12, 2019 at 12:53 pm
Sorry, you can't have any of our Scrum Masters or POs. We have spent too much to properly train them. 😉
Speaking of which, do your SMs and POs have formal Scrum training?
------------
Buy the ticket, take the ride. -- Hunter S. Thompson
June 12, 2019 at 1:04 pm
Lol
I work for a company that was founded in 1851. our practices are built on fax machines. (seriously, at one point I dreamt that our DR scenario revolved around faxing all our records to the chief exec's house)
a Scrum master is a luxury, a PO is a salesperson.
but that's why we are hiring new blood... get some better practices in place. I have formal Scrum training and I've been a "stand in" scrum master, but you are correct, the "non technical" people do need that training
MVDBA
June 17, 2019 at 8:35 pm
while it's slightly off topic, I worked with a team that mixed the V model (kinda like waterfall) and agile.. it had an unfortunate nickname of "vagile"
I came so close to spitting out my drink when I read this, thanks a lot! 🙂
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
June 18, 2019 at 4:25 am
while it's slightly off topic, I worked with a team that mixed the V model (kinda like waterfall) and agile.. it had an unfortunate nickname of "vagile"
What did you develop? Properly enumerated numeric information systems and did it support binary uploaded transfer tables? 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 28 total)
You must be logged in to reply to this topic. Login to reply