I moved to a new job recently, which applies agile methodologies to manage software teams, particularly Scrum, which was adopted to make an effective management of price, estimates, task and resources. It’s my first experience working with an agile process and I’m no doubt it brings a lot of values for a software project.
The Scrum methodology works something like this:
The team works on iterations (called sprints) during from 2 to 4 weeks (it depends on the project, organization..) on features prioritized by the owner(s) and the Scrum master of the project referring to a list of requirements written on a document (called product backlog). The priority is set according to the business value of the feature. The called owner is a representation of the customer. The Scrum master is the person who removes impediments for the team to keep them focused on the tasks and keeps the focus on the sprint goal. More information you can find here.
Every sprint start we estimate some stories and select the work to be done on the current sprint. At the end of the sprint, we have the review and restrospective of was and wasn’t done.
Above are my opinions about this agile methodology working with for a month:
- The team is completely committed to the overall goal of the sprint
- Members try to help each other as soon as one poses an impediment
- Everyone on the team knows which task the others are doing
- Every member helps each other to complete their tasks when they finish their ones
- The Scrum Master is always there to remove obstacles, clarify the understanding of the stories and help the estimates
- The PO acts with the team to give directions and suggestions for the next stepsand how to interact with other areas on the organization
I’m very motivated with Scrum practices and the way we put it in practice, and I know I have to learn a lot more.
Have you ever worked with Scrum? What do you think about this agile methodology?
Pedro da Ros has pointed me an interesting article from Joel Spolsky about ways software projects go wrong. Five Easy Ways to Fail shows us five step-guide to ensure software failure:
- Mistake No. 1: Start with a mediocre team of developers
- Mistake No. 2: Set weekly milestones
- Mistake No. 3: Negotiate the deadline
- Mistake No. 4: Divide tasks equitably
- Mistake No. 5: Work till midnight.</li
Have you ever been in any situation like those above?
Some companies think they’re applying iterative and incremental development, but in practice are doing waterfall development. Here are some tips described in Applying UML and Patterns, by Craig Larman, which can help you discover if your company doesn’t understand the Unified Process and iterative development (these tips can clarify all stakeholders misunderstanding about the difference of the two approaches):
- You think that inception = requirements, elaboration = design, and construction = implementation (that is, superimposing a waterfall lifecycle onto the UP).
- You think that the purpose of elaboration is to fully and carefully define models, which are translated into code during construction.
- You try to define most of the requirements before starting design or implementation.
- You try to define most of the design before starting implementation; you try to fully define and commit to an architecture before iterative programming and testing.
- A “long time” is spent doing requirements or design work before programming starts.
- You believe that a suitable iteration length is four months long, rather than four weeks long (excluding projects with hundreds of developers).
- You think UML diagramming and design activities are a time to fully and accurately define designs and models in great detail, and of programming as a simple mechanical translation of these into code.
- You think that adopting the UP means to do many of the possible activities and create many documents, and thinks of or experiences the UP as a formal, fussy process with many steps to be followed.
- You try to plan a project in detail from start to finish; you try to speculatively predict all the iterations, and what should happen in each one.
- You want believable plans and estimates for projects before the elaboration phase is finished.
Are you involved in such a situation at your company?
For those interested in project management stuff, like issue tracking, team collaboration and other team planning resources, there is a free Eclipse plugin called Tracker, which is intended ( I didn’t have time to test it yet 🙂 ) to manage team development stuff inside Eclipse IDE. It provides, among other things (which I think are the best ones):
- Issue tracking and planning for Requirements, Tasks, Change Requests, etc. (called “Work ITems”)
- Linking of Work Items with other artifacts in the Eclipse workspace
- Search Work Items using the standard Eclipse search facility
- History of Work Items
- Comparison of different historical revisions of any Work Item
- XML data shared via Subversion – no complicated database setup, no administration headaches
If you ever tried this plugin, post your feelings and comments here.