September 22, 2008 at 10:28 pm
Comments posted to this topic are about the item The Agile Cult
September 22, 2008 at 10:50 pm
I certainly agree that each group needs to try new methods of building software to see what works for them. While Agile is a buzz-word these days, it really does provide some benefits. There are various forms of Agile (XP, Scrum, etc.) and where I work, ChannelAdvisor, we have been doing a modified form of Scrum for just over a year. I have not worked here the entire time but from talking to those who have, it really has turned things around. But as I said, it is a modified Scrum. And I think the "modified" part is important because not everyone understands that these methods are not an all-or-none deal. How people work is a matter of personality and not everyone is adaptable to the same environments. So, you try to do what you can but it really depends on everyone really trying and working at it (i.e. the big picture and not just their part of a particular project). The nice thing about Agile is that it focuses on communcation and reflection. If something is not working, people can suggest something new and you try that for a while to see if it works and adjust from there. We are constantly going over what is and is not working for us and trying new things. While some might disagree with me, I feel that Agile is more suited to application development than it is database development. But that is not to say there is no middle-ground and in our DB team we do what we can and get mostly there. I think the biggest area of contention for me is in Data Modeling since Agile focuses on less planning and more on refactoring over time. That is all well and good for Stored Procedures and such, but it is certainly not as easy to refactor tables, especially when there are millions of rows of data (many gigs) and thousands of Stored Procs built on top of that model. With that one exception, I think Agile has worked out really well for us and certainly worth investigating for those who haven't tried it. However, it will not work for everyone as no way of thinking--whether it be politics, religion, economics, or software construction--will work for all people. The key is just to try until something works.
SQL# — https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
Sql Quantum Lift — https://SqlQuantumLift.com/ ( company )
Sql Quantum Leap — https://SqlQuantumLeap.com/ ( blog )
Info sites — Collations • Module Signing • SQLCLR
September 23, 2008 at 12:25 am
Agile, extreme programming, all common sense really. Some developers would come to something like the same methodologies on their own. It's not rocket science after all (unless you do rocket science).
What isn't common sense is allowing the customers to dictate everything without compromise, and the managers letting the customers do this. Organisations hardly ever understand the problems inherent in software development, and want to spend even less time and money solving those problems. Instead, let's outsource.
As I once said to a global head of IT for a major bank, "I can understand why you want to oursource. They produce the same kind of cr&p, but for a lot less money....."
Don't address the problems, just shift them onto someone else and pat yourselves on the back.
September 23, 2008 at 2:23 am
Didn't the three amigo's - Booch, Brady and Rumbaugh cook up the Capability Maturity Model back in 1995/6?
September 23, 2008 at 6:29 am
Reality can be a real problem sometimes. It seems like all good ideas run into it at some point.
Thanks for pointing us to another interestng article, Steve.
I think that software methodologies like the maturity model and later approaches like agile can be very valuable in certain situations. They're just not universal, though. I have a lot of friends who work for companies supplying the military. I totally understand and appreciate the maturity model when you need a product that absolutely can't fail. It requires a lot of money, but that's what you need to do to prevent your aircraft from falling from the skies. I appreciate concepts like Agile development, but as the article pointed out, they sometimes fall short.
The problem is that most companies in America start small. They just can't afford all of the expense of advanced methodologies. The owners hire their brother-in-law who just read "learn to program in 24 hours" to build their base software package and those of us who get called in later wind up cleaning up the terrible messes that the original developers create. In those cases you can get major improvements by introducing ANY level of order in the development process.
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.”
September 23, 2008 at 6:33 am
I have seen firsthand that the way things are built can be changed.
Our development group has undergone such a change. As I see it, 3 things happened to make it successful:
1) There was a change in leadership in the group. The new lead developer that was hired to replace an outgoing one brought new ideas to the development process and got developers excited to try the change.
2) They implemented an Agile / Scrum method. They sold management and marketing groups on the process and started to produce some favorable results. Because they started to produce, other groups stopped micromanaging their efforts, which in turn allowed them to make more progress.
3) Finally, there have been a core group of developers that have been kept together for that entire time.
The results are that in the past two years, the whole process has improved greatly.
September 23, 2008 at 6:56 am
Glad you liked the article and was curious how things have worked for people out there. From an ex-rugby player, the idea of doing something in a Scrum appeals to me. Was hoping it was a way to push developers around :w00t:
I think you have more chance of going with these advanced methodologies when you're small, it's when you're young that you have trouble with VCS, daily builds, etc.
Jason Fried at 37 Signals said it nicely. He said they try things, if it works, they do more. If it doesn't, they change.
September 23, 2008 at 7:41 am
Steve,
I think one of the keys is the developer's mindset. I have known some who get set in their ways and won't try anything different. Others will flit back and forth between methodologies and get very little accomplished. You have to be willing to change and learn new things but you have to actually produce results at some point.
The word cult in your title suggests, to me at least, that getting buy-in to a methodolgy is like getting people to join a cult. Once in that cult, they must throw off their other ideas and follow their fearless leader regardless of the outcome.
Agile development is just the opposite. I have employed parts of it to get buy-in from user departments who see progress being made sooner than if I sat at my computer for six months and then threw a product at them. You catch mistakes and misunderstanding sooner and that results in better product and happier users. Anyone who becomes cult-like in their devotion to a single methodology or technology needs to step back and examine if they're doing more harm than good.
It's about flexibility and doing what you need to get results.
September 23, 2008 at 7:42 am
I agree with SSC Journeyman- you do not need to fully adopt scrum page by page as described in books, training sessions, etc. We did in our organization, about 6 months ago. Initially, there was a lot of resistance and eventually everyone adapted to agile development using scrum methodology. This definitely improved the communication amongst team members, encouraged to work in a team environment as well as being agile to learn to adapt change quickly and learn to take on responsibility. We started with 1 team and now have 5 parallel scrum teams going on with a mixture of design, development, QA and tech writer. Overall, this has changed the mindset in people to adapt to quick change as companies are getting hit hard and things change as top executives make changes on a weekly basis to beat competition and to survive current market conditions and needs from our customers.
September 23, 2008 at 7:52 am
Similar to what Steve, our SSChampion said, with the use of scrum, we streamlined our builds process and definitely development team cleanup their act and constantly delivered builds to QA in a timely fashion. Again, like I mentioned in my previous reply, that the organization has to figure out how to adapt to agile method and it surely works if you put it to work and I would say that you will not see the results until your 2nd or 3rd sprint. Definitely, your 1st sprint, depending on the content, could be a failure but you learn and continue with the next sprint. Another great benefit of the scrum method is you constantly have the presence of the product owner, and at the end of the sprint, you demo the feature(s) (i.e. code complete, tested, etc) to the stake holders. The stake holders loved this for they got exposed to the features up front and at an early stage rather than at the end of the release since a release can be delivered in multiple sprints.
September 23, 2008 at 7:53 am
I think Agile definitely has some advantages in some environments, but it is not a one-size-fits-all solution to software development.
In any kind of a consulting/contract situation where the people doing the work are not actual employees of the firm receiving the work, it is necessary to have a clear understanding of what the deliverables are and when they are due. That's not to say that the incremental portions of getting that work done can't be done in a more Agile manner - but so often I hear people talk about "Agile" development as meaning "no set list of requirements, just build what we ask for when we ask for it, and be ready to change focus at the drop of a hat." That may be well and good when your developers are sitting down the hall from you and they are paid a salary regardless of what they do, but it doesn't work at all when a team of consultants is hired to do a particular project. It needs to be agreed upon what the scope of that project is for the negotiated fee, and substantive changes to that scope need to go through a process so that expectations and consequences (date slippage, increased development costs) are understood by both parties.
Working in-house though, I see much more advantage to Agile methodologies. You probably have different stakeholders and project priorities change with the business requirements, and it's important for the dev team to be responsive to that because it is the purpose of the dev team to help the business run smoothly, not just build cool stuff. That said, there is still no substitute for planning the big picture upfront and then implementing it incrementally in a more "agile" manner. If you don't plan your overall architecture upfront, you end up with a bunch of pieces jimmied together with no real cohesion. Spending time upfront on a flexible framework that supports modular application design will save you a bundle in time and money, prevent you from reinventing the wheel, simplify support etc.
--
Anye Mercy
"Service Unavailable is not an Error" -- John, ENOM support
"You keep using that word. I do not think it means what you think it means." -- Inigo Montoya in "Princess Bride"
"Civilization exists by geologic consent, subject to change without notice." -- Will Durant
September 23, 2008 at 8:57 am
Is there an alternative for the "blog post about Agile development" link? I can't seem to get anything to load from cio.com.
Thanks
September 23, 2008 at 9:10 am
I have worked for companies that use the Agile method and for ones that use the "waterfall" method. Agile seems to fit with the reality of the software development process better than other systems. The main advantage of Agile is the expectation of change and the methods for dealing with it. In systems that use a cast in stone pre-defined plan any changes (and I have never seen a project that didn't have changes) can cause problems because the design was inflexible.
September 23, 2008 at 9:28 am
I know Agile has advantages in our environment, but I agree that it is not a one-size-fits-all solution to software development.
Sprints and deliverables are nice to see early and it helps us meet the expectations of the users while they are still interested in the project. Using the older methods users and business experts use to loose focus in a shorter time the it took to see the first real deliverable. Agile gives them something sooner and keeps them more interested.
Huge difference for the better.
But for shops who are not ready to move fast, and would rather let the IT folks solve all the problems without interested business experts involved, Agile is not for them. They need to take a slower pace that will allow them to be further behind the curve and within the realm of safety. Always remember it is perfection and delivering the exact product to meet the stated need that works not being creative innovative or on time. :):):):P:):):)
(Just a little tongue-in-cheek here)
Miles...
Not all gray hairs are Dinosaurs!
September 23, 2008 at 1:13 pm
I am intrigued by Agile and I can see its benefits because I have used Agile-like methodologies before when doing application development, I have always tried to keep end users in the loop. But like previous comments have said, it looks to me like it's more appropriate for application development, not database development. You need to be involved with the stakeholders when developing databases, and you may need to break out E/R diagrams occasionally to explain how you're implementing business rules, but as a rule I would never show t-sql code to a stakeholder, or anyone outside of IT.
One of these days I'll pick up that book on Agile DB development.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply