This week's book giveaway is in the Artificial Intelligence and Machine Learning forum.
We're giving away four copies of Machine Learning with R: Expert techniques for predictive modeling and have Brett Lantz on-line!
See this thread for details.
Win a copy of Machine Learning with R: Expert techniques for predictive modeling this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

McKay Roozen:Challenges and Rewards in adoptation

 
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi McKay,

I have been educating myself where ever and whenever the opportunity arises ,Forums ...Boot camps ,Training ,certifications especially when i am at the crossroads ,and it would be nice if you and the community here throw couple of ideas /Suggestions.

we are currently working with our client on a proposal , A multi year Contract which we would be getting it another few weeks of time ,This is a very strategic in nature for both the client and the organization and within our organization there have been some adoption to agile already, we have both supporters and critics at all levels from the bottom to top ,With those strong leniencies, it makes this even more difficult to do a objective analysis.

The challenges are multifold,the client themselves are not accustomed to Agile.

For the very first time we are going to build a re-engineering project of an existing solid application, that has served its purpose all these years

Client is German speaking

Divergent technologies and competencies to be acquired and built both skill/Implementation wise

The development team would be geographically dispersed

External vendors /Suppliers to interface

Budget /Time line fixed

Time is critical for the client to take this to market and Client is insisting on to have this program run in Agile

We are planning for some workshops with both internal as well as external professionals in this adaptation.

Having come from the background of Traditional SDLC experience,given the above challenges(I presume it to be..) How would Agile and in more particular SCRUM would help in ironing out those challenges
and how we need to prepare ourselves better for the challenges?

Thanks and Regards
Sundar




 
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry to say this but it sounds like you have all the elements of the Perfect Badgile Storm. I see no good ever coming out of this. I will explain in a later reply as I am at my doctor's office right now.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recipe for a Perfect Storm: Inexperience with Agile + Budget/Time line fixed + External dependencies + Time Critical + Client insisting on Agile + Potential language/cultural differences + Multi-year plan + Geographically dispersed development team. You might as well add a couple of weapons of mass destruction while you're at it. Because that's what you're going to get.

It takes time, effort, knowledge, experience, dedication, and most of all, the desire and will to adjust to the way of working that makes agile methods effective. Imagine you're given 2 hours to learn how to handle a weapon, then get thrown in with a bunch of people who have varying degrees of experience with the same weapon ranging from none to "some", then the lot of you are thrown in with a group of people who are vehemently against any kind of violence let alone gun violence, then the whole lot of you are thrown into a war zone, then asked to capture a well-guarded and heavily fortified enemy position. And you lot must accomplish this objective within the next 48 hours with no backup or resupplies.

You all have about as much chance to come out alive in the above situation as the one you're heading into there, IMO. Sorry if this sounds alarmist but I have seen this and it's happening over and over and over ad nauseam. What can you do? Polish up your resume and get to somewhere that's not full of a bunch of crazy people.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

meenakshi sundar wrote:
How would Agile and in more particular SCRUM would help in ironing out those challenges
and how we need to prepare ourselves better for the challenges?


They can't, at least not without a lot of effort on your (the team's) part. Agile is mostly a set of guidelines and a mindset around those guidelines. Scrum is a framework. At most, they will HIGHLIGHT and make it painfully obvious what your problems are. They are not silver bullets that will kill your demons nor are they magic pills that will cure all your maladies. People have to work together within the frameworks, following the guidelines, getting into the same mindset, and figuring out the appropriate solutions to the problems that Agile and Scrum will show you have.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh and BTW, this: "reengineering projects of an existing solid application that has served its purpose all these years" is a red flag as well. Why reengineer it then if it's solid and has served its purpose well? Why not slowly adapt it to new and changing requirements? Why not build on and out from the solid core instead of build another from scratch? The kind of hubris and optimism involved in most reengineering efforts is amazing and it's been the downfall of many projects.

In previous posts in this forum, I have described one such effort that I was on when I first came to the US. It was a $36M colossal and absolute failure. Ironically, the acronym of the project was CPR, the "R" standing for "Rewrite" and the C & P standing for the two main lines of business of the company that was involved in the fiasco. But it might as well have stood for the emergency medical procedure that shares the same acronym. There was no hope of survival for this project though. It was purely traditional and was staffed with many experienced, intelligent, knowledgeable people. But the process was rigid, chaotic, and poorly coordinated despite the weekly status meetings, constant flow of reports, neverending generation of documentation, detailed analysis, detailed design, frantic development, and I don't even know what went around testing.

That project wasn't even an agile project. The project shut down in 2000, a year before the Agile Manifesto was signed in Utah in February of 2001. I can only imagine all the kinds of FUBAR it would have been had the project gone on longer and started to transition to Agile.
 
meenakshi sundar
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow ,Thanks Junilu for that extensive lowdown on Badgile:-( ,Should i take that with pinch of salt ?Still trying to digest that.

From what you suggest ,i understand,

Given the nature of problems/issues or rather i would put it as the complex business scenario as that is,
Agile can only help if there is a conducive environment attributes like flexibility in time line, budget, people with right mindset , trained manpower
.....is my understanding correct ?

And the bottom line is you can not run a Agile project, if that the environment is too rigid and run with a regimented approach
If things have to change and adopt to be more agile in an enterprise environment ,should the transformation and push come from the top or from the bottom?

Thanks once again for taking time to respond.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So I'll come at it now from the other side, just to confuse you

Yes, you should take it with a whole bowlful of salt. What I described were "most probable" and "worst case" scenarios, which is quite unfortunate and the odds are really stacked up against you, IMO

However, there's still a slim chance at success. But the road to success is narrow and fraught with many obstacles to maneuver around and the going will be slow, whereas the road to failure is wide and fast.

You need the right people in key positions. Coaches, leads, stakeholders who understand the complex dynamics of software development, understand the dangers of pushing for Agile when you have a mix of people who are inexperienced and/or hostile to the ideas and ways of working in Agile, know how to mitigate problems, etc. One of the biggest dangers when top managers / clients push to "run it as an Agile project" is that all they are really looking for is speed to market. They are fully and vocally asking for quick releases but tacitly also assuming that there will be quality in the delivered work. That very seldom happens.

When you throw a new process and new way of working into the mix, much of the team's focus will get taken away from ensuring quality in the product to also just following the new processes and ways of working. They will have to make very conscious and deliberate efforts to change the way they work. You can't get people to change the way they think and work easily, even when they want to, much less when they don't want to.

It's like asking people to ride Backwards Bicycles all of a sudden and expect them to win the Tour de France. It just not a reasonable expectation. People need time to change the way they think and work and adjust to the new way that Agile would have them think and work. Again, this is not an easy thing to do. I would echo what Destin said in that video: "You can't do it. You may think you can, but you can't!"
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

meenakshi sundar wrote:If things have to change and adopt to be more agile in an enterprise environment ,should the transformation and push come from the top or from the bottom?


It comes from all over. That's why the more successful adoptions are at the team level, involving a limited number of people. Like fewer than 10. Fewer than 7. Maybe 5 people. And it will take them some time to get it. Because it's not just the process stuff that needs to change. You can't wrap a great process management practice around a poor technical practice and expect great software to be produced. Good processes wrapped around bad engineering still equals BAD SOFTWARE.

That's one of the things many teams don't get and that's where they fail. People get so caught up in the process changes, the ceremonies, the frequent demos, daily stand up meetings, planning meetings, retrospectives, etc. that people can easily forget that they were actually supposed to write good software. They are pushed in front of this big wave of change and struggle not to drown in all these new and confusing things. They spend a lot of time and effort trying to follow the new rules and produce software FAST and within the time boxes that they have "committed" to.

In some environments, trying to produce software fast may be fine and even desirable. That's where the Lean Thinking folks come in. But Lean also doesn't mean that you just write crappy software and release it as fast as you can. Lean really means making reasonable compromises and assuming reasonable Technical Debt so that you can get early experience with the software, for strategic reasons. That may be so you can capture a market segment in a timely way, or grab consumer mindshare.

But you have to pay your debt back quickly once you know that your initial loan on time was worth what you gained from being able to release software earlier and achieve your strategic objectives. If you don't pay back your debt, it will eventually slow you down. It can get to a point where the interest and penalties on the Debt (time it takes to fix bugs, loss of customers and goodwill, etc) becomes TOTAL and you will no longer be able to make any significant progress or turn the tide of an increasingly vicious cycle. You may get some early wins but sooner or later, the weight of the Debt will catch up with you and you will go under and drown from it. Go watch the video of Ward Cunningham explaining the Debt Metaphor.

Only very experienced and disciplined teams can be successful in striking a balance of assuming Debt and paying it off in a timely manner. Unfortunately, yours does not sound like it's one of those experienced and disciplined teams.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I wrote:Only very experienced and disciplined teams can be successful in striking a balance of assuming Debt and paying it off in a timely manner.


Ok, that may be a bit much. But experience and discipline certainly helps. Maybe "savvy" and a good amount of luck plays into success as well. What I mean to say is that a lot of things need to come together so that the team can make good, reasonable compromises. They need to be aware of how much Debt they are getting themselves into and have a plan for paying it back in a timely manner so that it doesn't start to become too much of a burden or a detriment to the overall health and longevity of the project.
 
meenakshi sundar
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it all finally come down to the age old "common sense that prevails" ...Agile thoughts and philosophy were driven by these common sense and my thought is along the way the traditional model lost its way and
grounded in the bedrock of fallacies.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

meenakshi sundar wrote:Agile can only help if there is a conducive environment attributes like flexibility in time line, budget, people with right mindset , trained manpower
.....is my understanding correct ?

And the bottom line is you can not run a Agile project, if that the environment is too rigid and run with a regimented approach


Agile can help if you understand that it's not so much a prescription for curing whatever ails your project as much as it is a set of tools that will help you diagnose what's wrong. But you need to know how to read the symptoms and understand how the practices help to identify them.

For example, short iterations can bring out the pain that is caused by requirements that are too big, which leads to runaway complexity, which can lead to numerous bugs, which can cause lots of rework, which cause ... and so on and so forth. Many of the dysfunctions in a project are interconnected with each other. Trying to follow one practice as basic as short iteration timeboxes can make the pain you feel from these dysfunctions suddenly unbearable. So teams will often opt to lengthen their iterations, from 2 weeks to maybe 3 or 4 weeks.

Longer iterations in the onset may be fine and can give you time to adapt and make adjustments. However, you need to recognize the pains that you felt with the shorter iteration and deal with them as soon as you can, go back to the shorter iterations. You can't just say, Ok, now that's a little better, let's keep doing what we were doing before we felt the pain. That's the wrong reaction. You should recognize the pain(s), identify the dysfunction(s) that cause it, and figure out how to change for the better.

The practices won't bring about change in and of themselves, it's the people who need to change the way they think and work so that the practices make sense. Otherwise, none of it will make sense.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:They spend a lot of time and effort trying to follow the new rules and produce software FAST and within the time boxes that they have "committed" to.


Here's a recent tweet related to this: https://twitter.com/AgileFortune/status/705547453139779584?lang=en

It says "Agile Fail Mode-Myopically focusing on delivery, ignoring group performance and org'l capability to deliver"
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And yet another very relevant tweet for you: https://twitter.com/AgileFortune/status/702648330891894786?lang=en

"The #management cannot change an organisation's culture by force."
 
meenakshi sundar
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Agile Fail Mode-Myopically focusing on delivery, ignoring group performance and org'l capability to



That's a hard fact!!!


Here is an interesting link that i came across


http://34slpa7u66f159hfp1fhl9aur1.wpengine.netdna-cdn.com/wp-content/uploads/2014/05/teamsthatfinishearlyacceleratefaster.pdf
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the link to the article. I had a chance to meet and talk to Jim Coplien about a number of things at the SPLASH 2012 conference in Tucson AZ where he and I were on one of the panels. I was there filling in for a colleague. Jim is a very interesting and opinionated guy and he's well-known and well-respected in the global Agile community.
 
Junilu Lacar
Marshal
Posts: 14065
234
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I first heard of the Happiness Metric from Michael (Doc) Norton (@docOnDev), when he gave a talk at Agile 2013, IIRC. He called it the "Joy metric" -- all developers had to do was add a simple notation to their commit comment, like "[Joy=N]" or something similar, where N was a number on a scale from 1-5, with 1 indicating extreme dissatisfaction and 5 indicating extreme joy in committing the code. They would then have a program go through all the recent commits and report on the overall mood of the development team as they committed code over a given period of time.

When the Joy Factor started going down, that was a signal to have a conversation with the development team to figure out what was going on.
 
today's feeble attempt to support the empire
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!