Posts Tagged team
The right people are not afraid
Posted by Angelo van der Sijpt in Development Process on August 23rd, 2009
Quite some time ago, I read Jaibeer Malik’s excellent writeup on the right kind of people for staffing you agile project. I totally agree with his analysis that you need people that are “willing to make it happen”.
The right kind of people for your project have another trait in common: they are not afraid. What is there to be afraid of?
- Change It is in the nature of people to prefer it when things stay the same. Yet, change is the lifeblood of agile processes: we changed to get agile, we update our own process, and just when you think we figured it out, we change again. Better get used to it.
- Failure As John Holt wrote in Celebrate your mistakes, “If you’re not making mistakes, you’re not taking risks, and that means you’re not going anywhere. The key is to make mistakes faster than the competition, so you have more changes to learn and win.” Sure, failing is no fun, but fearing it will freeze you, making sure you can never make things happen.
- Visibility Tying into failure, visibility is about showing what you do. People tend to be very protective about “their job”, which they know bloody well how to do, thank you very much. Still, the open communication in an agile project forces us all to show what we’re doing, every minute we’re working on the project. I think it’s inexcusable to say “Well, I’m working on it now, so just come back tomorrow, and I’ll show you then”. Just show me now, I understand that not everything is OK yet; I would be surprised if it was OK, and you were still spending time on it.
The Agile Manifesto contains the same elements of collaboration, change and interaction. These can, indeed, be kind of intimidating when you are used to signing of work to be done, working under someone else’s responsibility, and consider yourself an expert. Then again, remember that we’re in this together, as a a team. Stop being afraid, and start making things happen!
Scrum to kanban
Posted by Jorg Hollenberg in scrum on May 26th, 2009
Recently we switched from scrum to kanban at one of our client’s projects. There is quite a buzz around kanban in the agile community, Henrik Kniberg wrote an excellent comparison between Scrum and Kanban.
Our project has got several software and hardware disciplines. Some disciplines have got a different ‘heartbeat’ than the software team. ‘Done’ features implemented by the software team constantly need to be validated with new and revised mechanics and updated electronics. Unforeseen issues will pop up (some blocking for the system integrators) and need to be fixed….now! Scrum isn’t very helpful here due to the sprint agreement with the product owner. The team switched to shorter sprints of about 2 weeks. This was a good improvement in providing the testers with a [potentially shippable] product more often.
However, since we’ve nearly reached ‘feature complete’, it’s hard to fill a sprint with known issues and work. Along with the team’s wish to be more reactive to blocking issues I proposed to move from scrum to kanban. Especially the possibility to have specialist columns on the ’scrumboard’ are really promising. I am keen on getting to know the effect of focusing on lead time and reducing this.
What did we keep:
- Scrumboard: added specialist columns: eg. .NET / JAVA / System Integration
- Daily standup
- The product owner: prioritises the remaining product backlog
- 2 weekly delivery of done work to get feedback from P.O. and other stakeholders
- Retrospective: team / process improvement
What did we stop:
- Team wide planning: some specialists are however still pokering and planning: why not
- the scrummaster role
- software only team, opened up the standup for different groups.
I will add new experiences along the way.
Technorati Profile

Recent Comments