Rational Unified Process (RUP) was a long sustaining one, it was a paradigm shift back then. The idea of being iterative & not to wait for each phases to complete has reduced the software turn around & improved the delivery efficiency.
RUP even though an effective process model,
- Lacked early customer/business feedback
- Lacked shorter development cycle
- Lacked to embrace Test Driven Development
- Lacked the geekish/freekish/nerish culture :)
I know what your thinking, isn't the article on "Is agile boon or bane ?"
Above points are self explanation/boon of why software industry jumped into the bandwagon of Agile development process !!!
If you are a CTO/Enterprise Architect, let me guess what's your next big roadmap.
Let me guess, wasn't an easy guess :)
Go ..... Agile !!!
Currently, I am into Agile development projects, for a major client in San Francisco. It's been an interesting journey so far, coming from RUP background i could reflect on my past experience & how that's dealt in Agile development process.
Challenges in Adopting Agile (I am talking about real agile, not kind of...)
- Agile is an organizational mindset shift.
- Building an Agile team is even tougher (right proportion of IQ Vs EQ members is key).
- TDD/BDD(now) go hand in hand with Agile, be prepared for it.
- Concept of QA is slowly fading off, Developers are QA (It's Just about switching the hats). Make sure your developers are matured enough to accept this very fact.
- Business is the key driver irrespective of the process models, make sure they have time for the Agile teams.
- Agile advocates flattened hierarchy, make sure it's in your organizational interest.
Some questions dwelling in my mind (around Agile),
- Story points are kind of misrepresented, misunderstood, rather unclear topic to me :).
- By definition story points are based on the value the feature adds from a business standpoint.
- Developers estimate it by effort involved in development.
- Management uses it to forecast there projections, strange enough :).
- Tech/design/architecture Debt:
- In traditional process models, software quality is part of the delivery. No customer would accept extra effort to cleanup mess :).
- It's different here in Agile, techical/design/architecture debt is a queue of things gets prioritized & most interestingly you get paid for it. How cool ....
Just wanted to mention a point here, regarding the "Tech Debt queue" -
The motto of Agile projects is to deliver the product to business "asap" - since business cannot wait for 9 or more months to see its baby.
During the process of achieving the short milestones, we tend to take up short/quick solutions which can be extended as the product evolves - during this course, there can be values that gets hard coded which needs to be fine tuned and later date; this is done in technical debt. Also improving performance of application will be a Tech Debt item.
If a technical debt involves fine tuning dev code since it was violating basic coding standards is definitely not accepted.
Agreed valid point, sashi.
I too have same questions on estimation. it confuses me a lot. :) let me know if you found the answer...
Appreciate ur comment @deepan. IMHO estimation is complicated topic, in my knowledge agile uses a lot guestimation.
In scrum model estimation depends on parameters like product backlog,items which are prioritized for the sprint and also the capacity for the sprint. It is the responsibility of Product owner to decides the priority based on story points. How does the story points calculated is the question here. Estimated hours to finish a user story not always equal to actual efforts. Will the estimation get matured when the team get comfortable in sprints?
Looking at above comments, it sounds like we are on the same voyage in search for real meaning of story points !!!
If we keep the definition apart and look at practical application. It looks like one unit of measure is applied to multiple fields, estimation, velocity, business value & etc.
Strange, isn't it ?
Post a Comment