There are many commonly held myths about agile. Two of these myths are that agile projects don’t do any planning and that you can’t do agile on a fixed date project. On the other hand, organizations have customers they what to satisfy and operations to run. And sometimes they feel a need for planning, and sometimes they face a fixed date. Can we simple neglect these feelings or must we exclude such projects from our Agile world?
Read more
Project Management
There are not a lot of companies who publish any of the source code online. And why would they: documentation takes time, you need to package it some way and the only thing that can happen is that somebody secretly becomes rich from your work. Worse yet, the company may loose face when security bugs are discovered.
In the meantime, we developers know all know to look at open source involvement when we look at hiring. We know that if you publish code online you are willing to be open for suggestions and criticism from the outside world. Further more, if you are able to get patches accepted, you know how to work with a team you have not worked with yet and how difficult it can be to do it right. Working openly will set you open to opinion, and if you think your code is good, why should you not?
My brother is a projectmanger in construction. He builds complex stuff and I admire him for that. During the build, he transforms large sums of money and a set of mandates into a set of sellable real-estate features (sellable…did I really just write this in the midst of our crisis?). When his projects finish, the deliverable is a tangible end-product that people can use for living, working or to generally enjoy.
In Dutch language we have the saying that something “stands like a house” when it is well built or well organized. So in that sense, when we change organizations into high performing highly adaptable entities, could we say change agents are builders as well?
Let’s take a closer look at this comparison and see if it makes any sense.
Read more
This is a true story of a company. At the first of January this year ago this company was a great idea and a few pictures. It had been like that for a while. At the first of April it was a company with a production website doing actual business with actual clients. The 12 weeks in between that have been awesome, nerve-wrecking and scary at the same time. We’ve had to let go of some really cool features and we’ve found out things about the business case that we definitely didn’t know when we said we could build it in such a short time. At the beginning of the project I invented the term “Oh shit erlebnis” and I’ve had a few since then.
Because we were working in short iterations (1 week Sprints), we had awesome focus and we could deal with most discrepancies between dreams and reality quickly.
One of the basic ideas in Scrum is the backbone formed by Product Owner and the Agile Team, headed by their Scrum Master.
The Product Owner stands right in the middle of the business, knows every functional detail, is trusted and respected by his business colleagues. Furthermore he takes care of the acceptance and business implementation of products and features delivered by the Agile team.
The Scrum Master, with his team, takes care of the technical realization and delivery of new products and features.
Scrum advocates a very short, direct connection between the one who has a goal and the ones who deliver the solution to reach this goal. Scrum does not know a Projectmanager role. Traditional projectmanagement responsibilities are divided over the Product Owner and the Scrum Master roles. Read more
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.
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
- 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.
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:
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.
Read more