I was very interested to read this blog post by Ben Alfree, "I'm a slow starter".
In his article, Ben describes how agile development makes things slow to start off with, but pays back in the end.
Actually my experience is the extreme opposite...
I have a lot of experience in traditional waterfall projects as well as in agile projects. In my experience of waterfall projects, typically the user/customer doesn't see anything very useful for a fairly long time.
Only when the analysis has been done in full, the design completed, the code implemented and the testing largely completed, does the customer get their hands on any working software. They might get demos, but this isn't the same as using working features, albeit in an incomplete product.
By contrast, in agile projects, some working features are delivered in early iterations. The user/customer is actively involved and sees the software develop throughout the duration of the project, from the outset.
As a result, I am slightly puzzled why we might have such different experiences? Your view on this topic would be gratefully received - please comment about your experience below. Does agile start slow for the user/customer, or provide them with early visibility?
Subscribe
Agile Development Is Slow To Show?
3 comments
See other entries about: collaboration
How To Implement Scrum In 10 Easy Steps - Step #5: Create A Collaborative workspace
So now you’ve got your backlog in order, estimated your backlog, clarified your requirements, and planned your sprint.
Now you’re ready for Step #5 – Create a collaborative workspace …
I know I called this series, ’10 easy steps’, but the first 4 steps are actually quite hard work! This one’s a breeze…
Whiteboard your walls
Cover your walls in whiteboards. You can’t have too many.
A whiteboard beats any software system and for many purposes. High level plans/roadmaps, key dates, design discussions, sketches of functionality, issues log, ideas, stats, status reports, topical posters, etc, etc. You name it, stick it on the wall!
Create a place for Collaboration
The whiteboarded area will be your team’s “collaboration hub”. A visibility wall. The centre of all team discussions. The place where the team meets every day (standing up). The place where you can get everything you need to know. At a glance.
Management by post-it note
Mark up a whiteboard with 5 columns. You can add more if you want to. But at least do these. Label the columns: Product Backlog, Tasks To Do, Work In Progress, Ready To Be Verified and Done!
On a post-it note or card, write the reference number and description of each Product Backlog item that is included in the current Sprint. Put these in the left-most column, 'Product Backlog'. These notes don’t need to fully describe the functionality or requirements. They're just reminders about what’s included in the Sprint, and indications of progress.
Then write up a note for each Task on the Sprint Backlog. Place the Tasks beside their relevant Product Backlog items, in the column labelled Tasks To Do.
When someone starts working on a Task, they should move it to the column labelled Work In Progress. When it's ready to be verified, move it to the next column. When it’s done, it should be moved to the Done! column (remember to define what your team means by done).
This will create unrivalled visibility for you, the team, the product owner and any other interested managers and stakeholders.
Touchy feely
In my opinion, no software tool can replace the board. People have a special tactile relationship with the board.
Like email compared with face-to-face communication, no tool will replace the sense of collaboration and teamwork this focal point provides.
Yes, it might be more efficient to use a software tool. But efficiency isn’t everything. Effectiveness is more important than efficiency.
This is so much more than a progress board. It’s an excuse for people to collaborate. And in development, where many people are not necessarily natural collaborators, it’s an important step to get the team talking. To get the team working together. As a team.
Next, Step #6: The team Sprints to achieve the Sprint Goal...
Follow this series by email
See also:
How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...
'Implementing Scrum' PowerPoint Presentation
10 Key Principles of Agile Software Development
3 comments
See other entries about: collaboration , scrum