Posted by Geert Bossuyt at around evening time: October 16th, 2011
Market Driven Development (aka Agile Fixed Price)
I propose a paradigm shift in developing software to deliver business value.
For a team to satisfy a business need,
it is not the amount of work that defines the time needed,
it is the available time that defines the amount of work that can be done.
The deadline is part of the need, and not the result of estimation or planning techniques.
With the deadline being part of the need, the Team and the Product Owner have a shared budget ( = number of Sprints ) to realize the Vision.
Instead of using Poker to give insight in the estimated time of delivery, let’s create a Market Place where Product Owner and Team ‘negotiate’ on the complexity of each story.
Posted by Martien van Steenbergen mid-morning: August 29th, 2011
What electronics tools exist to electronically master the agile process like Scrum, Kanban, and others?
Since this question surfaces every now and then, answers collect here (in alphabetical order).
- Agile Bench
- Google Docs
- Microsoft » Excel
- FlowKaizen
- Atlassian » Greenhopper for JIRA
- Hansoft
- Bandit Software » LeanKit Kanban
- Pivot Labs » Pivotal Tracker
- Rally Software » Rally
- ScrumDesk
- Silver Stripe » Silver Catalyst
- smartQ
- TargetProcess
- Version One Suite
- Atlassian » Vodafone wins Ultimate Scrum Board Award
Got more?
Contributors:
- Serge Beaumont
- Erica
- Theo Gerrits
- Olav Maassen
- Pieter Rijken
- Yves Hanoulle
- Jem
Posted by Laurens Bonnema mid-afternoon: March 4th, 2011
- Create a list of all your requirements in Epic format (think Product Breakdown).
- Break down each Epic into work items in User Story format (think Work Breakdown).
- Determine which Epics and/or User Stories have dependencies.
- Visualize dependencies in a network diagram.
- Create an estimate for each User Story using Planning Poker Points, NESMA Function Points, Gummy Bears, anything but time and/or money.
- Assign business value to all Epics and divide this value between the User Stories based on their point-estimate.
- Sort the list of User Stories based on priority, dependencies and business value per point-estimate (triage). Having trouble sorting the list using triage? Pick another prioritization technique.
- Take an educated guess (assumption) about the number of hours per point you’re likely to spend, based on a representative sample of User Stories taken at random.
- Calculate duration based on your assumption.
- Use the calculated duration as input for a Monte Carlo analysis to create your first rolling wave planning.
- Correct the assumption every sprint based on the progressive average of the actual hours per point ánd a new Monte Carlo simulation for the remaining duration.
- Report regularly, preferably in a reporting format currently in use by the organization.
Posted by Iwein Fuld in the early evening: September 20th, 2010
Sharing knowledge is one of our core values and as lot’s of research confirms knowledge transfer is best done between peers. We have a great knowledge sharing platform at Xebia through bi-weekly evening sessions, where we do some experimental coding and some presentations. Once in a while we take it to the max and organise a tech rally. One of those happened last Friday and it was a total blast. I’ll give you some of the highlights. More detailed posts on the technical details will follow and I’ll update the list below as they do:
Posted by Marco Mulder just before lunchtime: September 9th, 2010
In this blog, I make a case for what I think is the next step in the evolution of Agile project management. The focus of project management used to be based on managing Tasks that people perform to deliver a piece of software. Agile project management shifted focus to managing the delivery of Features. I believe that the time is ripe for the Agile community to take the next step: move towards Value driven project management.
(more…)
Posted by Sander Hautvast mid-afternoon: June 4th, 2010
In this episode of the middleware pitfalls top-10 we want to discuss the merits of a clean and standardized set of (test) environments. Some refer to such a set as DTAP, an acronym for Development, Test, Acceptance-test (or pre-production) and Production. From here on the text contains capitals to indicate an environment. Basically the situation is like testing itself: you will never get it 100% right, but it will help you a lot if you invest in a sound, maintainable DTAP.
Posted by Jan Vermeir in the early morning: April 27th, 2010
Development teams or even development organizations, are not always the well balanced, smooth operations we’d like them to be. In our software quality audit practice we have had the privilege to investigate many different types of organizations and found many different ways quality and productivity can suffer from a problem known as the Prima Donna Syndrome: a single individual exercises a disproportionate influence on the team causing problems like stagnation and unnecessary complexity.
(more…)
Posted by Serge Beaumont around lunchtime: April 24th, 2009
My colleague Age pointed me at a blog post by Uncle Bob about a presentation where a Mr. Josuttis presented the inevitability of crappy code because “businesses will do whatever it takes to cut costs and increase revenue, and therefore businesses will drive software quality inexorably downward”. Uncle Bob proceeds to go against that argument, but I find it to be a technocratic (DSLs and produce better code) and ultimately unsatisfying answer. My answer to the problem?
Face reality, grow up.
Posted by Barre Dijkstra in the early afternoon: January 28th, 2009
This recipe describes the process of baking marvellous, slightly burned decisions. If you’re looking for the well-done version of decisions, I would suggest altering this recipe by adding things like “necessity”, “timing”, “context” and “feeling” or taking another recipe on the subject.
(more…)
Posted by ShriKant Vashishtha in the early evening: August 21st, 2008
You may land up in situations when a project is almost stable. For developers handling issues and enhancements for the project, the work available is not sufficient. So, when team is comfortable with the project and it’s already stabilized, team can start handling another project at the same time. It’s good for the people working in these projects from learning perspective. They are exposed to multiple technology stacks, problems and functionality. At the same time, it works well for an organization in general.
(more…)