Building an Application Development Team- First Thoughts
Posted by Andrew MooreNov 23
The formation of a scalable- functional AppDev department…
We are redefining our Application Development business line. I have been asked to head up the efforts to sort out the bodies and set solid direction. There are so many places to look, so much to digest. I believe we have been able to break down our needs into a few core pillars:
- What is our development philosophy
- What SDLC model do we use
- What type of work are we looking for
- What skill sets does the team have
- What skills will we need
- Now
- Next year
- In 3 years
- What tools do we use to:
- Code
- Define Scope
- Communicate with clients
- Define and track projects
We are currently trying to understand the difference in SDLC and development philosophy. I am not sure what the difference is in Water Fall vs. Agile. We understand the concepts- I would think Agile is a philosophy where Waterfall is a methodology for execution.
It is apparent that our current project tracking systems in Connectwise were not built for the type of projects an application development team executes. We would like to explore Base Camp and some other interactive, web based project management systems.
One of the most important parts of this will be the examination of our team and what they can do. In order for the rebuild to work, we will need to focus on the abilities of the team and define where we can generate the most opportunity for our dollars. We absolutely need to get a skills inventory from each member and focus on how that will define the line of business.
Very exciting- More to come….
Here is a good article that debates Waterfall vs. Agile development methodologies, http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/.
As you can see each has their advantages but we fall more inline with Agile on the development side.
Jeff
Found this one as well- Love the concept- creating managaged buckets …
http://itknowledgeexchange.techtarget.com/software-quality/choosing-combining-agile-waterfall-other-software-development-models/
Agile is just based on an iterative development model. It uses small chunks of manageable time so that products can be developed and released quickly. For example, we use two week iterations in our development cycle. The iteration involves a LOT of collaboration between the product specialists (those who received the acceptance criteria from the user groups and scoped out the story), the software analysts (those who design the UI, write requirements and test plans) and the Developers. Within that iteration, the story goes through research and analysis of requirements, UI design, coding, testing, may go back to dev for tweaking, final testing, and finally product acceptance. It may just be a small chunk of functionality for a much larger functional area, but if we were told we had to stop development and release right away, that piece of functionality would be ready to go.
This is very good- but I am curious about how the users/client interact during this process.
I don’t agree with the posted article defining Waterfall as an un-flexible approach to delivering software. It repeatedly hints that after delivery of the code, if something needs to be changed, the ENTIRE code-base would have to be re-written–that just doesn’t resonate with my experience.
I would like to know what your thoughts are on waterfall. We are building a team and are looking to solidify our development philosophy. My understanding of waterfall is that it is far more rigid than spiral or agile and that scope supercedes any changes. What is your experience regarding scope cahnge in waterfall?
Waterfall can be a very effective method for controlling organizations that do not, or cannot decide what it is they want to do. I’ve had the opportunity to work across Agile and Waterfall in a Six-Sigma shop, and the Waterfall approach drastically reduced the IT-Spend by quite a few million dollars. By imposing the rigid structure, we were able to control fickle users by demanding all requirements be known prior to scoping and planned delivery. This ultimately flushed out problems with the underlying business process that was responsible for software decisions.
On the flip side of that coin, I’ve seen Agile work beautiful to bring new businesses or markets to fruition. In environments that change regularly (e.g. implementing a new market such as CAISO’s MRTU) an inarguable ROI can be defined by lost opportunity, which justifies “coding on the fly” to keep pace with changing market and user requirements. While Agile delivers functionality quickly by focusing on smaller scope (sprints) and delivery periods (weeks in instead of months), it still must rely on a very disciplined approach in the form of SCRUM and sprint planning.
In both cases, executive management should decide the appropriate level of SDLC artifacts to collect, but they are still collected. I have had experience with shops that will neglect SDLC entirely and blame it on their Agile methodology. Tsssk! Tsssk! Tsssk!
I somehow managed to reply without even answering your answer directly. Change control processes in Waterfall can be managed a number of ways, but what I have seen to be the most effective in practice is by setting a scope-freeze date sometime into the development process. What time you choose is a factor of the contingency and float time built into the project for the functionality being requested.
Your comments are very welcome! You are reinforcing some information that I have heard from multiple people. Basically- Agile can work if you adhear to the methodology and understand how the SDLC should be focused.
I have been talking to a friend who is interested in possibly resurecting the Houston Agile Developers Group- would you have any interest in particiapting? I just linked to their Archive in my BlogRoll- very good info.