Sign in or
Jon's Agile Development Tips
|NOTE:||This set of pages will take me a while to create. I am going to attempt to post my agile process tips and techniques.|
Process IntroductionOver the years, I have worked with many people and learned from masters and novices alike. Here you will read about a single, simple, slightly variable process with a handful of tenets that seem to routinely work at both getting the project off on the right foot, and providing checks and balances to catch us before/when we inevitably stumble.
Each situation is unique -- from the whole business/company culture/dev team culture/problem domain perspective. However, the overall approach to meeting the project head-on is very consistent -- just the details vary.
To some readers, this process may seem like "a lot of upfront work." All I can offer you is my advice against blindly applying some process (agile or not) without using your brain and without collaborating at a mental distance greater than just the coding aspects. There is a lot more to software development than software!
Software development of the the kind I have been involved with (and continue to enjoy doing) is always "knowledge work" and never "factory work." The projects tend to be 6 months to over a year, developing business-critical products and the team/process/culture to go with them. The more you understand about the company's business drivers (often a "level up" from your immediate project's needs), the more that you can provide innovative and explosive solutions to provide business value.
The process described herein is for just such type of projects.
BackgroundA conundrum of Agile Development to many laypeople is that we trade in seemingly precise process (sequential steps, roles, Gantt charts, lots of non-software-based evidence of activity) in the name of getting to production faster with higher quality -- yet mysteriously with seemingly less process.
The reaction of naive development teams is to "run wild" and do a poor job of delivering a professional solution and claim it is "agile." This gives agile a bad name -- at least to those who do not understand that software development is mostly about the quality and experience of the people and not the name of the process they followed.
Agile requires a keen understanding of sometimes subtle relationships between cause and effect in software development. This is true in many facets of software development:
- people's interactions
- frequent, tangible, working results
- involving the customer more often
- being able to embrace change
- All three approaches work.
- On the surface, the user would not be able to see any difference.
- All three approaches require about the same time to arrive at.
Success FactorsSome mantras that we choose to work by:
- Always be visible
- We work in a completely transparent way
- We are one, open team, from developer to stakeholder to gold owner
- Knowledge transfer is on an as-frequent basis as needed
- We tend to document in a natural, cost-effective manner
- Business vision is critical & necessary driver
- Development is to support marketing vision and business needs
- The closer we work with actual clients, the better the results
- Technology and business works together in a give and take
- We work our magic to make the business dreams a reality
- Close the "gaps" to reduce risks:
- ...of building the wrong thing by demonstrating working software in a matter of weeks, not months or years
- ...of being non-performant by testing early and continuously
- ...of being brittle by ensuring our code has appropriate level of tests
- ...of deployment by duplicating or simulating the environment(s)
General PhilosophyOur job is to do the best we can at shepherding the company's assets and resources, and the folks being assigned to the software product development.
The basic process:
- Building features in an iterative manner
- Having a range of tools to ensure efficiency of development and testing
- Evaluation by users after each iteration
- Take the reviews/critiques back to the product development team
- Be prepared to throw some things away and redesign/rebuild
- Repeat as needed
Some typical rules of thumb:
- Do not do any one aspect to excess, keep things reasonably in sync.
- The only truth: running (quality) software demonstrating feature completion.
- Client specifies features, dev team dictates cost and schedule.
- It is far better to collaborate than to engage in antagonistic "detailed contracts"
- Strive to be in a state where the software can be built and running at a moment's notice (best to have multiple environments)
- Tons of detailed documentation and requirements can be wasteful; keeping everything at the conversation level can be short-sighted
- Lots of fine-grained project plans for 5 years out is also wasteful
|Do Not Get Blocked|
You must not allow yourself to be blocked. That is, "stuck" from achieving success due to external forces. Bring this to the team's attention immediately as part of an email to the project list, or in the daily meeting or on IRC.
Latest page update: made by JonKern
, Sep 8 2010, 2:14 PM EDT
(about this update
About This Update
Edited by JonKern
3 words deleted
- complete history)
More Info: links to this page
There are no threads for this page. Be the first to start a new thread.